Der Graben zwischen Prototyp und Produktion

Ein Prototyp soll eine Idee sichtbar machen. Er läuft auf ausgewählten Daten, für ausgewählte Nutzer, in einer freundlichen Umgebung. Ein produktives System muss dagegen täglich mit unerwarteten Eingaben umgehen, verschiedenen Rollen dienen, Laststärken aushalten und bei Änderungen nicht umkippen. Zwischen beiden liegt kein gradueller Unterschied, sondern ein anderer Aufgabentyp.

Für Unternehmen ist das folgenreich. Die Zeit und das Budget für einen beeindruckenden Prototyp sind in der Regel unproblematisch. Die Zeit und das Budget für den Schritt danach werden unterschätzt. Das Ergebnis ist eine bekannte Konstellation: das Proof of Concept überzeugt, die Stimmung ist gut, aber im Alltag nutzt es kaum jemand.

Warum so viele Piloten stecken bleiben

Drei Ursachen tauchen in der Praxis am häufigsten auf. Erstens ist der Use Case zu weit geschnitten. „Alle Support-Fragen beantworten" klingt attraktiv, lässt sich aber nicht sauber bewerten und verliert beim Rollout gegen die Vielfalt echter Fälle. Zweitens fehlt die Verbindung zwischen Prototyp und Zielsystem: Der Prototyp arbeitet mit lokalen Daten, das Zielsystem mit Rollen, Rechten und Schnittstellen, die im Prototyp nie berührt wurden.

Drittens ist niemand für die Zeit nach dem Pilot verantwortlich. Ein Team baut den Prototyp, ein anderes Team soll ihn später betreiben, und die Übergabe ist nicht Teil des Auftrags. In der Folge verliert das Vorhaben genau an dem Punkt, an dem es anfangen würde, Wirkung zu zeigen.

Was sich zwischen Prototyp und Produktion alles ändert

In einem produktiven System kommen Eingaben, die im Pilot nie getestet wurden: Tippfehler, fremdsprachige Einschübe, Copy-Paste-Blöcke aus PDFs, unklare Fragen, mehrstufige Anfragen. Gleichzeitig treffen sich Rollen mit unterschiedlichen Berechtigungen, und das System muss entscheiden, was welche Gruppe sehen darf.

Auch die Last verändert sich. Ein Pilot mit zehn Nutzern pro Tag ist etwas anderes als eine interne Anwendung, die nach dem Rollout parallel dutzendfach angefragt wird. Die Infrastruktur muss darauf vorbereitet sein: stabiler Modellzugriff, sinnvolle Limits, graceful Degradation, klare Fehlerpfade. All das ist keine Kleinigkeit, sondern einer der Hauptgründe, warum AI Engineering Zeit kostet, wenn es sauber gemacht wird.

Die Infrastruktur-Seite: Modelle, Betrieb, Kosten

Im Pilot wird oft das leistungsfähigste verfügbare Modell verwendet, ohne über Kosten und Antwortzeiten nachzudenken. In Produktion wird diese Entscheidung zum Kostenhebel. Ein Teil der Anfragen braucht kein Top-Modell, und eine abgestufte Strategie aus schnelleren Modellen für einfache Fälle und stärkeren Modellen für komplexe Aufgaben verändert Betriebskosten spürbar.

Gleichzeitig muss der Betrieb robust werden. Das heißt definierte Retries, Timeouts, ein klares Verhalten bei Ausfällen eines Anbieters, idealerweise die Möglichkeit, Modelle oder Anbieter zu wechseln, ohne die Anwendung neu zu bauen. Wer sich an einen einzigen Endpunkt ohne Abstraktionsschicht bindet, zahlt das später als Projektaufwand zurück.

Die Qualitäts-Seite: Tests, Monitoring, Regression

Ein Prototyp wird an wenigen Beispielen geprüft. Ein produktives System braucht einen wiederholbaren Testdatensatz, der echte Fragen, kritische Grenzfälle und bewusste Fallen enthält, bei denen das System sich zurückhalten soll. Ohne diesen Datensatz gibt es keine belastbare Aussage darüber, ob eine Änderung die Qualität verbessert oder verschlechtert.

Dazu kommt Monitoring im Alltag. Welche Fragen kommen tatsächlich? Wo sind die Antwortzeiten hoch? Wo greifen Nutzer nach einer Antwort zu Kollegen statt zu Folgefragen? Welche Fälle landen bei menschlichen Bearbeitern und sollten eigentlich automatisiert sein? An diesen Stellen setzt strukturierte LLM-Qualitätssicherung an. Sie macht sichtbar, was der Pilot bewusst ausgeblendet hat, und liefert die Zahlen, die für Weiterentwicklung und Priorisierung nötig sind. Ein unterschätzter Teil davon ist die gezielte Beobachtung von Halluzinationen im laufenden Betrieb.

Die Organisations-Seite: Rollen, Betrieb, Weiterentwicklung

Produktive KI ist nicht nur eine Anwendung, sondern ein laufender Prozess. Wer pflegt die zugrundeliegenden Inhalte? Wer entscheidet über neue Use Cases? Wer reagiert, wenn Nutzer unerwartete Antworten melden? Wer gibt Änderungen frei, bevor sie in Produktion gehen? Ohne benannte Verantwortung passiert entweder zu wenig oder zu viel gleichzeitig.

In stabilen Setups gibt es typischerweise drei klar getrennte Rollen: jemanden, der für die Inhalte und Quellen verantwortet, jemanden, der für die Anwendung und ihre Qualität steht, und jemanden, der den technischen Betrieb übernimmt. Diese Rollen können in einer Person gebündelt sein, müssen aber benannt und in der Organisation verankert sein. Fehlt eine, wird der Rest mittelfristig überlastet.

Akzeptanz: der still wirksame Faktor

Eine Anwendung, die technisch funktioniert, aber im Alltag nicht genutzt wird, ist praktisch nicht vorhanden. Akzeptanz entsteht selten durch Werbung intern, sondern durch drei Dinge: spürbare Zeitersparnis bei einer Aufgabe, die Menschen ohnehin regelmäßig haben, Vertrauen in die Antworten und eine Oberfläche, die keinen eigenen Kurs verlangt.

Zeitersparnis entsteht nur bei sauber geschnittenen Use Cases. Vertrauen entsteht nur bei nachvollziehbaren Antworten. Unauffällige Bedienung entsteht nur, wenn die Anwendung dort lebt, wo gearbeitet wird, also in Teams-Chats, Ticket-Tools, Intranet-Suchen, Mail-Clients. Produktive KI ist häufig unsichtbar und gerade deshalb wirksam.

Typische Fehler beim Schritt in Produktion

Der häufigste Fehler ist der Versuch, den Pilot einfach breiter auszurollen. Was für zehn Nutzer überzeugt hat, trägt selten für hundert, weil die Bandbreite der Fragen, Rollen und Kontexte explodiert. Sinnvoller ist ein bewusster Zuschnitt, bei dem der Pilot als Grundlage dient, aber als eigenes Produkt neu gedacht wird.

Der zweite Fehler ist eine unklare Datenstrategie. Im Pilot ist die Datenbasis klein und überschaubar. In Produktion kommen Dokumente, Kategorien und Systeme dazu, mit denen der Pilot nie gearbeitet hat. Ohne eine Vorstellung davon, wer diese Daten pflegt und nach welchen Kriterien, degradiert das System in Wochen, nicht in Monaten.

Der dritte Fehler ist, den Betrieb als nachgelagertes Thema zu behandeln. Monitoring, Testdatensätze, ein klarer Prozess für Änderungen und ein Pfad für Nutzerfeedback gehören in die erste Produktivversion, nicht in das zweite Jahr. Alles, was dort fehlt, kommt als stille Qualitätsabnahme zurück.

Der vierte Fehler ist, Erfolg nur am technischen Ergebnis zu messen. Eine KI, die gute Antworten liefert, aber keinen konkreten Prozess verbessert, bleibt ein Werkzeug ohne Wirkung. Erfolgskennzahlen sollten früh an einen geschäftlichen Nutzen geknüpft sein, nicht an Modellmetriken allein.

Wann externe Unterstützung sinnvoll ist

Der Schritt von einem funktionierenden Pilot zu einem produktiven System ist der Moment, an dem sich externe Unterstützung in der Regel am schnellsten rechnet. Nicht, weil die Technologie unbekannt wäre, sondern weil die Verzahnung aus Architektur, Qualitätssicherung, Betrieb und Organisation Erfahrung verlangt, die in vielen internen Teams schlicht noch nicht vorhanden ist.

Wir arbeiten mit Unternehmen, die einen Pilot haben und entscheiden wollen, wie daraus ein stabil laufendes System wird. In der Praxis heißt das: Use Case nachschärfen, Architektur bewerten, Test- und Monitoring-Grundlage aufsetzen, Verantwortlichkeiten klären und den Rollout so planen, dass er belastbar bleibt. Wer an genau diesem Übergang steht, sollte ihn nicht zum unangenehmsten Teil des Projekts machen, sondern zum bewusst gestalteten.