Vom Pilot zum Produktivbetrieb: Warum die meisten KI-Projekte stecken bleiben, und was die Ausnahmen anders machen

Im Januar habe ich angefangen, ein Cloud-Security-SaaS zu bauen. Allein, ohne Entwicklerteam, mit einer Handvoll KI-Coding-Agenten. Fünf Monate später läuft es im Produktivbetrieb.

Und ich verstehe jetzt aus eigener Erfahrung, warum genau dieser Schritt, vom Piloten in den echten Betrieb, für die meisten Unternehmen der schwierigste ist. Die Zahlen dazu sind ernüchternd, und sie passen zu dem, was ich in Kundengesprächen höre.

Die unbequeme Datenlage

Das MIT hat mit der NANDA-Initiative im Report "The GenAI Divide" 300 öffentliche KI-Projekte, 150 Interviews und eine Mitarbeiterbefragung ausgewertet. Das Ergebnis, das durch die Fachpresse ging: Rund 95 Prozent der Enterprise-GenAI-Piloten zeigen keine messbare Wirkung auf die Gewinn- und Verlustrechnung. Nur etwa 5 Prozent schaffen den Sprung.

Über die genaue Höhe der Zahl wird gestritten, und das zu Recht. Die Richtung aber ist über Studien hinweg konsistent. McKinsey kommt im "State of AI 2025" zum selben Muster aus einem anderen Blickwinkel: 78 Prozent der Organisationen nutzen KI in mindestens einer Funktion, aber nur 39 Prozent führen überhaupt eine EBIT-Wirkung darauf zurück. Bei den meisten davon liegt der Effekt unter 5 Prozent. 62 Prozent experimentieren mit Agenten, nur 23 Prozent skalieren sie irgendwo im Unternehmen.

Die RAND Corporation hat den Blick auf gescheiterte Projekte gerichtet und kommt auf eine Misserfolgsquote von gut 80 Prozent: ein Drittel wird abgebrochen, ein weiteres Drittel liefert keinen Wert, der Rest rechtfertigt die Kosten nicht.

Anders gesagt: Fast alle haben angefangen. Fast niemand ist angekommen.

Woran es nicht liegt

Die erste Reaktion in vielen Vorständen ist, am Modell zu zweifeln. Falsches Modell, falscher Anbieter, zu wenig Fine-Tuning. Das MIT-Team ist da deutlich: Das Modell ist selten der Engpass. Der Engpass ist die Lücke zwischen Werkzeug und Organisation.

Konkret tauchen einige Muster immer wieder auf. Die Integration in gewachsene Altsysteme wird unterschätzt. Ein Pilot, der auf einem sauberen Datensatz brilliert, scheitert an der Realität aus drei Quellsystemen, zwei Namenskonventionen und einer Schnittstelle, die seit 2018 niemand mehr angefasst hat. Die Output-Qualität, die im Demo überzeugt, bricht im Volumen ein, weil aus zehn handverlesenen Beispielen plötzlich zehntausend Echtfälle werden. Es fehlt das Monitoring, um überhaupt zu sehen, ob das System im Betrieb noch tut, was es soll. Und niemand ist eindeutig verantwortlich, wenn der Pilot in die Fläche gehen soll.

Dahinter steht oft dasselbe Datenproblem. RAND führt einen Großteil der gescheiterten Projekte auf ungelöste Datenfragen zurück, nicht auf die KI selbst. Wer kein belastbares Fundament hat, baut auf Sand, egal wie gut das Modell ist.

Und es steht ein Denkfehler dahinter. Ein großer Teil der Unternehmen behandelt KI als IT-Projekt, nicht als Geschäftsveränderung. Ein IT-Projekt liefert ein System und ist dann fertig. Eine Geschäftsveränderung verändert, wie Menschen arbeiten, und ist erst dann fertig, wenn der neue Ablauf sitzt. Genau das ist der Unterschied zwischen den 95 und den 5 Prozent.

Was die Ausnahmen anders machen

McKinsey hat den stärksten Einzelfaktor benannt, der mit echter EBIT-Wirkung korreliert: das fundamentale Neudenken von Arbeitsabläufen. Nicht das beste Modell gewinnt, sondern die Organisation, die ihren Prozess um die KI herum neu baut, statt die KI in den alten Prozess zu kleben.

Ein Beispiel aus meiner eigenen Arbeit. Früher hieß die Reihenfolge: Anforderung, Code schreiben, testen, reviewen. Mit Agenten habe ich die Reihenfolge umgedreht. Erst die Spezifikation sauber formulieren, dann den Agenten bauen lassen, dann den Großteil meiner Zeit in die Prüfung stecken. Das ist nicht derselbe Prozess mit einem schnelleren Werkzeug. Es ist ein anderer Prozess.

Dazu kommen drei Dinge, die in den erfolgreichen Projekten auffallen. Es gibt eine klare fachliche Verantwortung, nicht nur ein Projektteam in der IT. Es gibt ein belastbares Datenfundament, bevor der erste Agent startet. Und es bleibt ein Mensch in der Schleife, dort wo Entscheidungen Wirkung haben.

Ein Befund aus der MIT-Untersuchung verdient besondere Aufmerksamkeit, gerade für den Mittelstand: Zugekaufte Lösungen und Partnerschaften waren in rund zwei Dritteln der Fälle erfolgreich. Reine Eigenentwicklungen nur etwa ein Drittel so oft. Der Reflex "das bauen wir selbst" ist verständlich, aber er ist statistisch der teurere Weg. Wer keine eigene KI-Erfahrung im Haus hat, kauft mit einem Partner nicht nur Technik, sondern den Umweg um die typischen Fehler.

Was ich selbst gelernt habe

Zwei Momente aus meinem eigenen Projekt haben mir mehr beigebracht als jeder Report.

Der erste war eine positive Überraschung, gleich zu Beginn. Als Product Owner habe ich jahrelang Geschäftsanforderungen in User Stories übersetzt und die Abhängigkeiten sortiert, bevor eine Zeile Code entstand. Der Agent hat genau das in Minuten erledigt, und der Dependency-Split war sauber. Ich kann diese Arbeit immer noch selbst, und genau deshalb konnte ich erkennen, dass sie richtig war. Wer den Prozess nie von Hand gemacht hat, kann das Ergebnis der KI nicht beurteilen. Das ist keine Nostalgie, das ist Qualitätskontrolle.

Der zweite Moment war ein Fehlschlag. Ich habe einen Plan versehentlich unbeaufsichtigt laufen lassen. Beim Deployment stellte ich fest, dass der Agent Anforderungen, die er vorher implementiert hatte, einfach wieder entfernt hatte. Funktionierende Funktionen, einfach weg. Ein Rollback kam nicht in Frage, weil inzwischen zu viel Code geschrieben war, und wenn man wöchentlich am Token-Limit sitzt, sind Tokens Budget. Also habe ich die ursprüngliche Funktion neu aufgebaut. Das hat Zeit gekostet, die ich nicht eingeplant hatte.

Die Lehre daraus ist dieselbe, die hinter der ganzen Adoptionslücke steht. Die KI war brillant bei der Arbeit, die ich früher von Hand gemacht habe. Gefährlich war sie genau dort, wo kein Mensch mehr hingeschaut hat. Den Bau kann man automatisieren. Die Prüfung muss man besitzen.

Vier Fragen, bevor ihr skaliert

Wer einen Piloten in den Produktivbetrieb heben will, kann sich viel Frust sparen, wenn vorher vier Fragen geklärt sind.

Wer ist fachlich verantwortlich, nicht nur im Projekt, sondern im Betrieb? Wenn die Antwort "die IT" lautet, fehlt der Geschäftsbezug, und genau daran scheitern die meisten.

Steht das Datenfundament? Bevor ein Agent in der Fläche arbeitet, muss klar sein, auf welche Daten er zugreift, in welcher Qualität und mit welcher Freigabe.

Wo bleibt der Mensch in der Schleife? Nicht überall, das wäre der alte Prozess. Aber an jeder Stelle, an der eine Entscheidung Wirkung nach außen hat, gehört eine Prüfung dazu.

Und schließlich: baut ihr selbst oder mit einem Partner, der den Weg schon gegangen ist? Die Statistik ist hier eindeutiger, als der Stolz manchmal zulässt.

Was das für euch heißt

Wer KI vom Piloten in den Produktivbetrieb bringen will, hat es nicht mit einem Werkzeugproblem zu tun, sondern mit einem Governance-Problem. Klare Verantwortung, ein Datenfundament, Leitplanken und eine echte Review-Kapazität: das sind dieselben Disziplinen, die eine saubere Cloud-Transformation ausmachen. Wer Cloud-Governance kann, kann auch KI-Governance. Wer beides ignoriert, landet in den 95 Prozent.

Genau diese Lücke zwischen "läuft im Pilot" und "trägt im Betrieb" schauen wir uns bei Tallence Cloud an. Nicht mit einem weiteren Tool, sondern mit der Frage, wie der Prozess um die KI herum aussehen muss, damit sie produktiv und auditierbar bleibt.

Eine Frage zum Schluss, die mich selbst umtreibt: Wo in eurer Organisation haben Agenten schon Aufgaben übernommen, bei denen niemand mehr systematisch prüft, was sie tun?