Einen unternehmens­weiten KI-Chatbot einführen

Eine städtische Entwicklungs­gesellschaft hat eine KI-Strategie erarbeitet und steht vor der Frage, mit welchem Schritt begonnen wird. Ein lizenziertes Assistenz­werkzeug ist im Haus vorhanden, wird aber nur eingeschränkt genutzt und findet bei den Mitarbeitenden begrenzte Akzeptanz — es erfüllt die Anforderungen an eine leistungs­fähige KI-Anwendung nicht vollständig, und die Eingabe von Geschäfts­vorgängen ist ohnehin untersagt. Gleichzeitig wuchs der Bedarf nach einer zentralen Lösung für den sicheren Einsatz im Arbeitsalltag. Die Aufgabe ist deshalb nicht, ein weiteres Werkzeug bereitzustellen, sondern eine Anwendung einzuführen, die drei Bedingungen gleichzeitig erfüllt: daten­schutz­konform, vertrauens­würdig, und tatsächlich benutzt. Der dritte Punkt ist der schwierigste und derjenige, an dem das vorhandene Werkzeug gescheitert ist.

Der erste Umsetzungs­schritt kommt aus der eigenen Strategie, nicht aus dem Katalog. Die Anwendung wurde nicht gewählt, weil ein Chatbot naheliegt, sondern weil er die Grundlage für die zuvor priorisierten Anwendungs­fälle ist. Damit ist die Reihenfolge umgekehrt zum üblichen Weg: Nicht ein Werkzeug wird eingeführt und danach nach Anwendungs­fällen gesucht, sondern die Anwendungs­fälle waren bekannt und bestimmen, was das Werkzeug können muss.

Befähigung ist ein eigenes Arbeitspaket, mit eigenem Budget. Das dritte Paket heißt Inbetriebnahme und Befähigung, und das ist kein Etikett: Die Vorgeschichte war ein vorhandenes Werkzeug, das an der Akzeptanz gescheitert ist. Wer daraus nicht lernt, führt dasselbe Ergebnis mit anderer Technologie erneut ein. Die Frage ist nicht, ob die Anwendung funktioniert, sondern ob sie am dritten Tag noch geöffnet wird.

Der Anbieter des Sprachmodells ist eine Entscheidung und keine Voreinstellung. Das zweite Arbeitspaket besteht darin, ihn auszuwählen, einzurichten und anzubinden — getrennt von der Anwendung selbst. Diese Trennung ist der praktische Ausdruck der modularen Architektur, die schon in der Strategie gefordert war: Wechselt die Modell­generation oder die Rechtslage, wird ein Baustein ausgetauscht und nicht das System.

Entwickelt wird spezifikations­getrieben, und der Code entsteht KI-gestützt. Am Anfang jeder Umsetzung steht eine Spezifikation: ein versioniertes Dokument, das wie Code geprüft wird, für Technik und Fachbereich gleichermaßen lesbar, in dem Entscheidungen, Sonderfälle und Abwägungen geklärt sind, bevor eine Zeile entsteht. Die Architektur wird nach einem etablierten Rahmenwerk dokumentiert. Der Grund für diese Reihenfolge ist nicht Ordnungsliebe, sondern Prüfbarkeit: Erzeugter Code wächst schneller, als die Zeit reicht, ihn zu lesen. Wer einem Modell nur beschreibt, was er ungefähr will, bekommt schnell Code und bei jedem Durchlauf einen anderen. Die Spezifikation ist zugleich die Dokumentation, die sonst am Ende fehlt — und in einem Haus, das öffentlich beschafft, ist sie die Grundlage, gegen die eine Leistung abgenommen wird.

Eine zentrale Anwendung statt vieler kleiner. Der Bedarf ging ausdrücklich auf eine unternehmens­weite Lösung, nicht auf abteilungs­weise Werkzeuge. Für ein Haus dieser Größe ist das die entscheidende Vorentscheidung: Bei rund einhundertfünfzig Beschäftigten und knappen IT-Kapazitäten lässt sich ein System betreiben, absichern und pflegen — fünf nicht. Und nur in einem gemeinsamen System setzt der nächste Anwendungs­fall auf dem vorhandenen Zugang, der Protokollierung und den Rechten auf, statt all das noch einmal einzurichten.