Die Demo hat funktioniert. Der Verwaltungsrat war beeindruckt. Acht Monate später ist es immer noch eine Demo. Die Gründe, warum KI-Piloten im Unternehmen nie live gehen, sind vorhersehbar – und vier der fünf haben nichts mit dem Modell zu tun.

Branchenumfragen melden immer wieder dieselbe unbequeme Zahl: Die grosse Mehrheit der KI-Piloten in Unternehmen schafft es nie in die Produktion. Der Reflex ist, die Leistungsfähigkeit des Modells oder die Datenqualität verantwortlich zu machen, doch das ist selten die eigentliche Ursache. Wir wurden oft genug gerufen, um festgefahrene Piloten zu retten, dass wir das Muster kennen – und das Modell ist fast nie der Engpass. Der Engpass ist alles rund um das Modell, das niemand eingeplant hat, weil die Demo es nicht brauchte.

Das eigentliche Problem: Eine Demo und ein Produktionssystem sind verschiedene Artefakte

Eine Demo läuft einmal, mit ausgewähltem Input, unter den Augen ihres Erstellers, optimiert darauf, in einem Meeting zu beeindrucken. Ein Produktionssystem läuft tausende Male am Tag, mit allem, was hereinkommt, während alle schlafen, optimiert darauf, nicht zu versagen. Die Fähigkeiten, Komponenten und Budgets, die das Erste hervorbringen, sind für das Zweite weitgehend irrelevant. Den Piloten als «zu 90 % fertig, muss nur noch gehärtet werden» zu behandeln, ist der Kategorienfehler, an dem er strandet.

Hier sind die fünf Lücken, in der Reihenfolge, in der sie Projekte zu Fall bringen.

Lücke 1: Niemand ist für das Produktionssystem verantwortlich

Der Pilot wurde von einem Innovationsteam oder einem externen Partner mit einem Projektbudget gebaut. Die Produktion braucht ein namentlich benanntes Team mit Bereitschaftsdienst, einem Wartungsbudget und Verantwortung für Verfügbarkeit und Qualität. Wenn der Pilot endet, endet auch das Projektbudget, und es gibt niemanden, zu dessen Aufgaben es gehört, das System zu betreiben. Es wird nicht gestoppt – es wird verwaist, was langsamer und demoralisierender ist. Das ist die mit Abstand häufigste Ursache, und es ist ein Versagen der Organisationsgestaltung, kein technisches. Entscheiden Sie, wem das System in Produktion gehört, bevor Sie den Piloten bauen.

Lücke 2: Kein Evaluation Harness

Der Pilot wurde nach «sieht gut aus» beurteilt. Die Produktion muss die Frage beantworten: «Ist Version 2 besser oder schlechter als Version 1?» – und eine Modell- oder Prompt-Änderung kann die Qualität unbemerkt verschlechtern, ohne Fehlermeldung und ohne Alarm. Ohne Eval-Suite ist jede Änderung ein Glücksspiel und jedes Update des Modellanbieters eine Runde Roulette. Teams frieren das System lieber ein, als es anzufassen, und ein eingefrorenes KI-System verfällt, während sich die Welt um es herum weiterbewegt. Was Sie nicht messen können, können Sie nicht betreiben.

Lücke 3: Integration und Fallback wurden nie gebaut

Die Demo hat eine saubere API aufgerufen. In Produktion ruft das System Ihr CRM auf, das in Spitzenzeiten in Timeouts läuft, Ihr Auth-System, Ihr Logging und drei interne Services mit inkonsistenten Schnittstellenverträgen – und es muss sich korrekt verhalten, wenn einer davon langsam ist oder ausfällt. Der Fallback-Pfad (was passiert, wenn die KI nicht antworten kann oder eine Abhängigkeit ausfällt) ist oft mehr Code als das KI-Feature selbst, und in der Demo ist er unsichtbar. Piloten, die ihn ignoriert haben, stellen beim Launch fest, dass der Happy Path nur 30 % der Arbeit war.

Lücke 4: Stückkosten, die die Skalierung nicht überleben

Bei Pilotvolumen prüft niemand die Kosten pro Aufruf. Bei Produktionsvolumen kann ein KI-Feature unbemerkt mit negativer Bruttomarge laufen oder ein Budget sprengen, das nie jemand festgelegt hat. Teams, die die Inference-Kosten nicht für das erwartete Volumen modelliert haben, bekommen entweder eine böse Rechnung oder müssen nach dem Launch unter Druck neu architektieren. Kosten sind eine Architekturentscheidung; wer sie auf «später» verschiebt, architektiert später neu.

Lücke 5: Kein Weg, das Vertrauen der Nutzenden aufzubauen

Der Pilot hat die Geschäftsleitung beeindruckt. Die Menschen, die ihn täglich tatsächlich nutzen müssen – Agents, Analystinnen, Ärzte –, waren nicht eingebunden, und sie werden jedes Tool umgehen, das ihre Zeit verschwendet oder sie vor Kundschaft schlecht dastehen lässt. Ein technisch exzellentes System mit 10 % Nutzung liefert 10 % seines Business Case. Vertrauen entsteht durch Transparenz (die Quellen zeigen), einen souveränen Umgang mit Unsicherheit («nicht sicher» sagen statt zu bluffen) und die Einbindung der Nutzenden ins Design – nichts davon hat die Demo berücksichtigt.

Praxisbeispiel: ein festgefahrener Pilot zur Vertragsanalyse

Ein Legal-Ops-Team hatte einen Piloten zur Vertragsanalyse, der in Tests hervorragend abschnitt und seit sieben Monaten unausgeliefert herumlag. Die Diagnose entlang der fünf Lücken:

• Verantwortung: keine – gebaut von einem Innovation Lab, ohne finanziertes Produktionsteam. (Behoben: an das Legal-Ops-Engineering übergeben, mit Wartungsbudget.)
• Evals: keine – die Qualität bemass sich an «den Juristen hat es gefallen». (Behoben: 150 annotierte Verträge als Regressions-Set.)
• Integration: Der Pilot las hochgeladene PDFs; die Produktion musste Dokumente aus dem DMS ziehen und in das Mandatssystem zurückschreiben. Rund 60 % der verbleibenden Arbeit.
• Wirtschaftlichkeit: in Ordnung, geringes Volumen.
• Vertrauen: Die Juristinnen und Juristen vertrauten Extraktionen ohne Quellenangabe nicht. (Behoben: verpflichtende Zitate auf Klauselebene.)

Zeit vom «festgefahrenen Piloten» bis zur Produktion: neun Wochen, keine davon mit dem Modell verbracht. Die Nutzung unter den vorgesehenen Juristinnen und Juristen erreichte innert eines Monats rund 75 %, sobald die Zitate den Output überprüfbar machten.

Das Muster hinter dem Muster: Piloten optimieren für das falsche Publikum

Treten Sie einen Schritt von den fünf Lücken zurück, und eine tiefere Ursache wird sichtbar. Piloten werden gebaut, um eine interne Entscheidung zu gewinnen – um die Führungskraft zu beeindrucken, die über das Budget verfügt –, während Produktionssysteme dazu da sind, den Menschen zu dienen, die die Arbeit machen. Das sind unterschiedliche Publika mit gegensätzlichen Bedürfnissen. Die Führungskraft will in einer Fünf-Minuten-Demo die ambitionierteste Fähigkeit sehen; die Nutzenden wollen ein schmales, zuverlässiges Tool, das sie vor Kundschaft nicht blamiert. Optimieren Sie für das Erste, bauen Sie ein breites, flaches Schaufenster. Die Produktion belohnt das Gegenteil: schmal, tief und verlässlich.

Deshalb verkleinern die erfolgreichsten Programme, die wir durchführen, den Umfang des Piloten bewusst, statt ihn zu vergrössern. Statt zehn Fähigkeiten bei 80 % zu demonstrieren, beweisen Sie eine einzige bei 98 % – auf der echten Integration, mit dem echten Fallback, vor den echten Nutzenden. Ein Pilot, der eine Sache produktionsreif erledigt, ist ein weit besserer Erfolgsindikator als einer, der zehn Dinge eindrucksvoll erledigt, denn er hat die operative Steuer bereits bezahlt, die die eindrucksvolle Demo aufgeschoben hat. Wir haben erlebt, wie ein bewusst unspektakulärer Pilot mit einem einzigen Intent in sechs Wochen live ging, während ein glänzender Pilot mit vielen Fähigkeiten aus demselben Unternehmen ein Jahr lang auf Grund lag – der Unterschied lag einzig darin, für welches Publikum er gebaut worden war.

Das hat auch Folgen fürs Budget. Weil Piloten über ihre Ambition verkauft werden, werden sie als Innovationsexperimente finanziert, und Innovationsbudgets enthalten keine Betriebsposition. Den Piloten als «erstes Inkrement eines Produktionsservices» neu zu rahmen – mit einer verantwortlichen Person und einem Wartungsbudget von Anfang an –, ändert das Finanzierungsmodell und beseitigt Lücke 1, bevor sie entstehen kann. Die wichtigste Entscheidung über einen Piloten fällt, bevor die erste Zeile Code geschrieben ist: Ist das ein Experiment, das wir wegwerfen, oder die erste Scheibe von etwas, das wir betreiben werden? Beantworten Sie das ehrlich und finanzieren Sie entsprechend.

Die Checkliste für den Weg in die Produktion

1. Wem gehört das System in Produktion, und ist seine bzw. ihre Zeit finanziert? (Wenn unbeantwortet: hier aufhören.)
2. Gibt es ein Evaluation Harness, das Regressionen bei jeder Änderung erkennt?
3. Sind alle echten Integrationen und deren Fehler- und Fallback-Pfade gebaut und getestet?
4. Haben wir die Stückkosten für das erwartete Volumen modelliert, nicht für das Pilotvolumen?
5. Haben die täglichen Nutzenden das Design mitgeprägt, und verdient sich das System ihr Vertrauen?
6. Gibt es in Produktion ein Monitoring für Qualität, Latenz, Kosten und Fehlerraten?
7. Gibt es einen definierten Weg, das System sicher zu aktualisieren, wenn sich Modelle und Daten ändern?

Die gridz-Sicht

Die Lücke zwischen einem Piloten und einem Produkt ist überwiegend organisatorisch und operativ, nicht technisch – und das ist eine gute Nachricht, denn diese Lücken lassen sich in Wochen schliessen, sobald Sie nicht mehr erwarten, dass das Modell der schwierige Teil ist. Bevor wir einen KI-Piloten gutheissen, fragen wir, wem er in Produktion gehören wird; gibt es keine Antwort, ist der Pilot bereits eine Demo mit Ablaufdatum. Wir bringen festgefahrene Piloten in Produktion, indem wir die fünf Lücken in der Reihenfolge schliessen, die zählt – und das Modell ist meist der Teil, den wir am wenigsten anfassen.

Wenn Sie gerade einen Piloten in der Schwebe haben, prüfen Sie ihn ehrlich anhand der fünf Lücken, bevor Sie einen weiteren Franken in das Modell stecken. Unserer Erfahrung nach hat die Diagnose fast immer dieselbe Form: Die Verantwortung ist nicht finanziert, es gibt kein Evaluation Harness, und die echten Integrationen wurden nie gebaut – drei organisatorische und operative Lücken in technischer Verkleidung. Schliessen Sie diese drei, und die meisten «festgefahrenen» Piloten erreichen die Produktion in Wochen, denn die Intelligenz war nie das Hindernis. Die unbequeme, aber befreiende Wahrheit: Enterprise AI auszuliefern ist vor allem eine Übung in operativer Disziplin, und operative Disziplin können Sie am Montag anwenden – ganz ohne Modell-Upgrade. Wenn Sie dabei eine zweite Meinung wollen, sprechen Sie uns an.