Was ich beim Aufbau eines internen KI-Tools mit über 200 Nutzern gelernt habe

Jedes KI-Produkt muss entscheiden, was das Modell übernehmen soll, was das Produkt durchsetzt und was unter der Kontrolle der Nutzer bleibt.

Wenn ein Modell Fehler macht, ist die Versuchung groß, eine weitere Prompt-Regel oder eine technische Einschränkung einzubauen. Das kann das unmittelbare Problem lösen. Gleichzeitig kann es das Modell an anderer Stelle weniger nützlich machen. Eine Vorgabe für einen einzelnen Sonderfall gilt plötzlich für jede Anfrage.

Bei der Planung wurde dieser Zielkonflikt besonders deutlich. Viele KI-Produkte erstellen einen Plan, sobald jemand eine Aufgabe abschickt. Die Idee ist nachvollziehbar: Das Modell bekommt eine feste Abfolge, damit es keinen wichtigen Schritt auslässt. Ich habe mich dagegen entschieden, das fest in das Produkt einzubauen.

Die richtigen Schritte stehen am Anfang nicht immer fest. Handeln schafft Erkenntnis. Eine Websuche kann etwas aufdecken, das die Aufgabe grundlegend verändert. Ein zu früher Plan lässt den Ablauf geordnet aussehen und kann das Modell zugleich daran hindern, auf neue Erkenntnisse zu reagieren.

Diese Entscheidung war eine Wette. Ich vertraute darauf, dass die Anbieter ihre Modelle bei mehrstufigen Aufgaben verlässlicher machen würden, statt diese Schwäche dauerhaft im eigenen Produkt auszugleichen. Modelle sind ein bewegliches Fundament. Ein heute nützlicher Umweg kann in der nächsten Generation überflüssig sein und trotzdem als zusätzliche Komplexität im Produkt bleiben.

Natürlich können Nutzer nicht auf das nächste Modell warten. Ich setze Vorgaben deshalb gezielt ein. Sie müssen ihren Preis klar rechtfertigen und leicht wieder zu entfernen sein. Wenn eine sinnvolle Voreinstellung, eine Entscheidung in der Oberfläche oder ausdrückliche Nutzerkontrolle dasselbe Problem löst, ohne das Modell einzuschränken, ziehe ich das vor.

Das nützliche Versprechen für dieses Tool lautete nicht: Gib uns die Arbeit und wir automatisieren sie weg. Es lautete: Behalte die Kontrolle und erledige die Arbeit mit mehr Möglichkeiten und weniger Reibung.

Dieser Unterschied war wichtig. Andere interne Tools setzten darauf, dass Menschen mehr Arbeit abgeben wollten. Einige wurden gebaut und verschwanden wieder, weil diese Annahme dem Arbeitsalltag nicht standhielt. Redaktionen hatten erlebt, wie Automatisierung Entwürfe erzeugte, deren Korrektur mehr Mühe kostete als eine Zusammenarbeit mit der KI von Anfang an.

Einem Assistenten vertrauten die Menschen eher, weil er ihre Erfahrung und Urteilskraft respektierte. Das Tool half bei der Recherche, beim Schreiben, Analysieren und Überarbeiten, ohne so zu tun, als wäre menschliches Urteilsvermögen überflüssig geworden.

Meine Wette war, dass diese Haltung zu besserer Arbeit und dauerhafterer Nutzung führen würde. In den beobachteten Arbeitsabläufen entstand mehr Wert, wenn Menschen den Prozess lenkten, Ergebnisse bewerteten und nach einem schwachen ersten Versuch den Kurs änderten. Schließlich nutzten mehr als 200 Menschen das Tool, und es blieb ein Assistent unter ihrer Kontrolle.

Ich verankerte die Wette auch in der Oberfläche. Ich gestaltete sie als Arbeitsbereich mit verschiedenen Werkzeugen. Unnötige Schritte fielen weg, Überarbeitungen gehörten zum normalen Ablauf und die Nutzer behielten die Kontrolle.

Das heißt nicht, dass dieser Ansatz für jedes KI-Produkt der richtige ist. Bei einem stabilen, wiederkehrenden Ablauf kann eine weit stärkere Automatisierung die bessere Wette sein. Bei diesem Tool und diesen redaktionellen Abläufen wollten die Menschen die Kontrolle behalten. Andere Ansätze kamen und gingen. Dieser blieb.

Nutzer beschreiben häufig eine Lösung: einen Button, einen Ablauf oder eine gewünschte Einstellung. Meine Aufgabe war, von diesem Wunsch zurück zum eigentlichen Problem zu arbeiten. Was versucht diese Person wirklich zu lösen? Tritt das Problem wiederholt auf? Hilft dieselbe Lösung auch anderen Menschen?

Ein einzelner Wunsch kann ein flüchtiger Gedanke sein. Beim zweiten lohnt sich die Untersuchung. Wenn dasselbe Muster immer wieder auftaucht, steckt womöglich eine echte Produktchance dahinter. Selbst dann kann die beste Lösung ganz anders aussehen als der ursprüngliche Vorschlag.

Ich wollte das Tool aus wenigen verlässlichen Bausteinen aufbauen, statt es für jeden Wunsch einzeln zuzuschneiden. Jeder Baustein sollte einfache Aufgaben lösen und sich mit anderen zu komplexeren Abläufen verbinden lassen. Mit der Zeit sollten sich mehr Wünsche mit „So helfen dir die vorhandenen Bausteine dabei“ beantworten lassen statt mit „Dafür brauchen wir noch einen Sonderfall“.

Power-User verdienen besondere Aufmerksamkeit. Ihre intensive Nutzung verursacht höhere Kosten. Gleichzeitig decken sie Grenzen früher auf, bringen unbekannte Arbeitsabläufe mit und fragen nach Fähigkeiten, die später auch für andere wichtig werden können.

Power-User sind jedoch ein Erkenntniskanal, nicht das ganze Produkt. Auch ihre Wünsche müssen im Zusammenhang mit der breiteren Nutzerbasis betrachtet werden. Menschen, die das Tool seltener nutzten, brauchten ein verständliches Produkt, ohne wie Power-User arbeiten zu müssen. Erst diese breitere Gruppe machte aus begeisterter früher Nutzung eine dauerhafte interne Verbreitung.

Eine Funktion, von der ich mir viel versprach, ließ den Chat vor seiner Antwort eine Rückfrage stellen. In der Theorie sollten bessere Eingaben zu einem präziseren Ergebnis führen.

Im Alltag nervte die Funktion viele Menschen.

Sie kehrten zum Chat zurück und erwarteten ein fertiges Ergebnis. Stattdessen wartete eine weitere Frage und damit zusätzliche Arbeit auf sie. Der mögliche Qualitätsgewinn wog den Bruch dieser Erwartung nicht auf. Sie glaubten, die Aufgabe abgegeben zu haben, doch das Produkt gab ihnen einen Teil davon zurück.

Seitdem frage ich mich bei jeder Funktion, was der Ablauf den Nutzern verspricht. Eine Rückfrage kann sinnvoll sein, aber Zeitpunkt und Grund müssen klar sein. Sonst wirkt das Produkt weniger fähig, obwohl seine spätere Antwort technisch besser ausfällt.

Dasselbe gilt für die Geschwindigkeit. Eine etwas bessere Antwort rechtfertigt nicht automatisch eine mehrfach längere Wartezeit. Qualität besteht aus Nutzen, Geschwindigkeit, Reibung, Vorhersehbarkeit und dem Gefühl, dass die Arbeit vorankommt.

Deshalb teste ich solche Änderungen in der Praxis. Verschlechtert eine gut gemeinte Funktion das Gesamterlebnis, entferne ich sie. Eine Entscheidung zurückzunehmen ist kein Scheitern. Das Produkt reagiert damit auf Erkenntnisse.

Ein KI-Tool hat keine stabile Kostenkurve. Die Zahl der Nutzer kann wachsen. Bestehende Nutzer können das Tool intensiver einsetzen. Anbieter können ihre Preise ändern. Eine neue Funktion kann jede Sitzung plötzlich verteuern. Mehrere Variablen bewegen sich gleichzeitig.

Ein fester Preis pro Nutzer ist einfach, kann aber künstliche Limits erzwingen oder das Produkt unwirtschaftlich machen. Eine nutzungsabhängige Abrechnung gab mir mehr Spielraum. Sie erforderte zugleich ein laufendes Gespräch mit dem Unternehmen: die Nachfrage abschätzen, ein Budget vereinbaren, die tatsächliche Nutzung beobachten und die Entscheidung transparent anpassen.

Ich dachte bei den Ausgaben eher an ein Personalbudget als an klassische Softwarelizenzen. Die Ausgaben sollten der nachgewiesenen Nachfrage und dem tatsächlichen Wert folgen, nicht dem Wunsch, KI-Nutzung verkünden zu können.

Kostenkontrolle funktioniert in beide Richtungen. Das Produkt braucht genug Budget für wertvolle Arbeit und sollte dieses Budget effizient nutzen. Aber möglichst wenig auszugeben ist das falsche Ziel. Ein günstigerer Ablauf mit schwachen Ergebnissen, mehr Wiederholungen oder weniger Vertrauen kann pro Durchlauf billiger sein und insgesamt trotzdem mehr Geld verschwenden.

Das bessere Ziel sind nützliche Ergebnisse pro ausgegebenem Euro. Dafür braucht das Produkt eine erkennbare Werteinheit. In meinem Fall war das ein gespeicherter Prompt, den Menschen wiederholt ausführten und der ein weitgehend vollständiges Arbeitsergebnis erzeugte. Die Kosten jedes Durchlaufs ließen sich berechnen und das Ergebnis überschritt eine erkennbare Qualitätsschwelle. Bei anderen Produkten kann die Einheit ein Recherchebriefing, ein gelöster Supportfall oder ein Entwurf zur menschlichen Prüfung sein.

Erst dann lässt sich eine Effizienzänderung sinnvoll bewerten. Sie ist eine Verbesserung, wenn sie die Kosten senkt, ohne das Ergebnis unter das tatsächlich benötigte Niveau zu drücken.

Ein internes KI-Tool beginnt vielleicht als freiwilliges Extra für wenige Enthusiasten. Sobald Menschen es in echte Arbeitsabläufe einbauen, ändert sich der Maßstab. Ein Ausfall unterbricht dann kein Experiment mehr. Er blockiert die Arbeit eines Menschen.

Supportfragen werden dringender. Kritik wird direkter. Nutzer machen womöglich das Produkt verantwortlich, obwohl auch ihr eigener Ablauf oder ihr Verständnis zum Problem beigetragen hat.

Ihnen die Schuld zurückzugeben hilft nicht. Verwirrung ist ein Produktsignal. Sie zeigt, dass die Oberfläche, das Verhalten oder die Kommunikation etwas nicht verständlich gemacht hat.

Das Betriebsmodell muss mit der Nutzung reifen. Das Produkt muss verhindern, dass Nutzer ihre Arbeit verlieren. Grundlegende Änderungen teste ich deshalb gründlicher als normale neue Funktionen. Mit Feature Flags schalte ich sie zuerst für kleine Gruppen frei, nicht sofort für alle. Power-User eignen sich oft als frühe Tester, weil sie Änderungen bereitwillig erkunden und genau erklären können, wo etwas scheitert.

Fehler werden trotzdem passieren. Vertrauen hängt dann von der Reaktion ab: das Problem klar benennen, schnell beheben und betroffene Nutzer sinnvoll in die Lösung einbeziehen. Wenn sie die Verbesserung bewerten, erhalten sie echten Einfluss auf ein Tool, auf das sie inzwischen angewiesen sind.