Vom AI-Prototyp zur Produktion: was zwischen Demo und Betrieb liegt

Der Prototyp war in zwei Wochen fertig, die Demo hat die Geschäftsführung überzeugt, das Budget ist freigegeben. Und dann passiert etwas Merkwürdiges: Das Projekt, das eben noch flog, wird zäh. Sechs Monate später ist das System immer noch nicht im Regelbetrieb, und niemand kann so recht sagen, woran es liegt.

Dieses Muster ist so verbreitet, dass es sich lohnt, den Weg vom AI-Prototyp zur Produktion einmal nüchtern zu vermessen. Die Antwort auf die Frage, was zwischen Demo und Betrieb liegt, ist nämlich keine Liste technischer Details. Es ist ein grundsätzlich anderes Anforderungsprofil: Ein Prototyp muss zeigen, dass etwas möglich ist. Ein Produktionssystem muss garantieren, dass etwas verlässlich passiert, auch an schlechten Tagen, auch mit schwierigen Eingaben, auch wenn der Entwickler im Urlaub ist.

Warum Demos begeistern und der Betrieb ernüchtert

Eine Demo läuft unter Bedingungen, die sich im Betrieb nie wieder einstellen. Die Eingaben sind ausgewählt, der Vorführende kennt die Schwächen und umschifft sie, und die Bewertung erfolgt durch Zuschauer, die das Beeindruckende sehen, nicht das Fehlende. Sprachmodelle verstärken diesen Effekt: Sie liefern auch auf schwache Eingaben eine flüssige, souverän klingende Antwort. Die Demo sieht deshalb fast immer besser aus, als das System ist.

Der Betrieb kehrt die Bedingungen um. Die Eingaben wählt niemand aus, die Nutzer kennen die Schwächen nicht und finden sie deshalb alle, und bewertet wird nicht der beste Fall, sondern der Durchschnitt und der schlechteste Fall. Wer den Übergang plant, sollte diese Umkehrung ernst nehmen: Nicht die Demo ist der Maßstab, sondern die Frage, was das System mit den zehn Prozent unangenehmster Eingaben macht.

Die Lücken zwischen Demo und Betrieb

Vier Lücken tauchen in nahezu jedem Projekt auf, und keine davon ist in der Demo sichtbar.

• Fehlerfälle. Der Prototyp behandelt den Erfolgsfall. Produktion heißt: definiertes Verhalten bei Zeitüberschreitung, bei überlastetem Anbieter, bei Antworten im falschen Format, bei inhaltlich unbrauchbaren Ergebnissen. Jeder dieser Pfade braucht eine Entscheidung: wiederholen, ausweichen, an einen Menschen übergeben. Nichts davon existiert im Prototyp, und zusammen ist das oft mehr Code als der Erfolgsfall.
• Berechtigungen. Die Demo läuft mit einem Konto, das alles sieht. Im Betrieb gilt: Das System darf einem Nutzer nur zeigen und für ihn nur tun, was dieser Nutzer selbst dürfte. Sobald ein Modell auf interne Datenquellen zugreift, wird das zur eigentlichen Konstruktionsaufgabe, denn die Berechtigungsprüfung muss vor der Modellantwort greifen, nicht danach.
• Monitoring. Der Prototyp wird beobachtet, indem jemand hinschaut. Der Betrieb braucht Messbarkeit ohne Zuschauer: Wie viele Vorgänge laufen, wie viele scheitern, wie entwickeln sich Antwortzeiten und Antwortqualität, und wer wird alarmiert, wenn sich etwas verschlechtert. Bei AI-Systemen kommt eine Besonderheit dazu: Qualität kann schleichend sinken, ohne dass ein technischer Fehler auftritt. Dafür braucht es eigene Signale, etwa Stichprobenprüfungen und Nutzerrückmeldungen, die ausgewertet werden.
• Kosten. In der Demo kostet der Vorgang Centbeträge und niemanden interessiert es. Im Betrieb multipliziert sich der Preis pro Vorgang mit dem Volumen, und Agent-Schleifen oder große Kontexte können den Preis pro Vorgang vervielfachen. Ohne Kostenüberwachung pro Vorgang und ohne Obergrenzen entdeckt man das auf der Monatsrechnung.

Ein Kriterienkatalog für Produktionsreife

Statt Produktionsreife zu diskutieren, hilft es, sie als Liste prüfbarer Aussagen festzuhalten. Ein brauchbarer Katalog umfasst mindestens diese Punkte:

• Jeder Fehlerpfad hat ein definiertes, getestetes Verhalten. Es gibt keine Stelle, an der das System stillschweigend hängen bleibt.
• Ausgaben, die weiterverarbeitet werden, sind gegen ein Schema validiert.
• Der Zugriff auf Daten und Aktionen folgt den Berechtigungen des jeweiligen Nutzers, und das ist getestet, nicht nur beabsichtigt.
• Es existiert ein Prüfbestand realer Fälle, gegen den jede Änderung an Prompts oder Modellen vor dem Ausrollen läuft.
• Betriebskennzahlen und Kosten sind pro Vorgang sichtbar, mit Alarmen bei Abweichung.
• Es ist festgelegt, wer das System betreibt, wer bei Störungen reagiert und wie Nutzer Fehler melden.
• Datenschutz und Vertragslage der eingesetzten Anbieter sind geprüft und dokumentiert.

Der Katalog wirkt unbequem lang. Sein Wert liegt genau darin: Er macht die Restarbeit sichtbar, bevor Termine zugesagt werden, nicht danach.

Schrittweiser Rollout statt Stichtag

Auch ein System, das den Katalog erfüllt, sollte nicht an einem Stichtag für alle live gehen. Bewährt hat sich eine Abfolge, die das Risiko in kleinen Stufen erhöht. Zuerst der Schattenbetrieb: Das System läuft mit echten Eingaben mit, seine Ergebnisse werden gesammelt und verglichen, aber niemand arbeitet damit. Dann eine kleine Pilotgruppe, die eng begleitet wird und deren Rückmeldungen in kurzen Zyklen einfließen. Erst danach die Ausweitung, gegebenenfalls Team für Team.

Diese Stufen sind keine Vorsicht um ihrer selbst willen. Jede Stufe beantwortet eine Frage, die vorher niemand beantworten kann: Der Schattenbetrieb zeigt die Qualität auf realen Daten, der Pilot zeigt, ob die Arbeitsabläufe tragen, die Ausweitung zeigt, ob Betrieb und Kosten skalieren. Wer Stufen überspringt, beantwortet dieselben Fragen später trotzdem, nur teurer und vor größerem Publikum.

Betrieb ist der Anfang, nicht das Ende

Die vielleicht wichtigste Erwartungskorrektur betrifft die Zeit nach dem Go-live. Ein AI-System ist mit dem Rollout nicht fertig, es beginnt dort. Modelle werden aktualisiert, Eingaben verschieben sich, Nutzer entwickeln neue Verwendungen, und der Prüfbestand muss mit alldem wachsen. Sinnvoll ist, von Anfang an Kapazität für diese Pflege einzuplanen, ein spürbarer, dauerhafter Anteil der ursprünglichen Entwicklungsleistung, statt das Projektteam nach dem Go-live vollständig abzuziehen. Systeme, deren Pflege niemand verantwortet, verfallen leise: Die Qualität sinkt schleichend, das Vertrauen der Nutzer folgt, und am Ende steht ein System, das technisch läuft und praktisch gemieden wird.

Fazit

Zwischen Demo und Betrieb liegt keine Restarbeit, sondern der größere Teil des Projekts: Fehlerfälle, Berechtigungen, Monitoring und Kostensteuerung, dazu ein geordneter Rollout und dauerhafte Pflege. Wer das vom ersten Tag an einpreist, im Budget wie im Zeitplan, erlebt den Übergang vom AI-Prototyp zur Produktion nicht als Ernüchterung, sondern als planbare Strecke. Der Prototyp beantwortet die Frage, ob etwas geht. Produktionsreife beantwortet die Frage, ob man sich darauf verlassen kann. Es sind zwei verschiedene Fragen, und die zweite ist die teurere.