Enterprise-KI-Piloten scheitern vor der Produktion, weil ein Pilot nur beweist, dass ein Modell eine Aufgabe ausführen kann, während die Produktion verlangt, dass eine Kette aus acht Dingen hält: ein gemessenes Problem, ein neu gestalteter Workflow, ein belegter Wertnachweis, Umsetzungsbereitschaft, eine zum Unternehmen passende Architektur, Integration mit den Systemen der Wahrheit, in den Workflow hineingestaltete Governance und ein Eigner, der das Ergebnis betreiben kann. Die meisten Piloten überspringen die ersten vier Glieder und entdecken die letzten vier zu spät. Das Gegenmittel ist die Reihenfolge: die Kette belegen, bevor man baut, und nur bauen, was belegt wurde.
Das Projekt NANDA des MIT fand, dass etwa 5 % der individuell entwickelten Enterprise-Tools für generative KI die Produktion erreichten. S&P Global fand, dass die durchschnittliche Organisation 46 % ihrer KI-Proofs-of-Concept verwirft, bevor sie dort ankommen, und dass der Anteil der Unternehmen, die die meisten ihrer KI-Initiativen aufgeben, binnen eines Jahres von 17 % auf 42 % stieg. Gartner erwartet, dass mehr als 40 % der agentischen Projekte bis 2027 abgebrochen werden. Die Zahlen schwanken; das Muster nicht. Unternehmen sind gut darin, KI-Piloten zu starten, und schlecht darin, sie zu beenden.
Unser früherer Artikel, Warum die meisten KI-Initiativen scheitern, argumentierte, dass das Problem die Methode ist und nicht die Technologie. Dieser hier ist enger und mechanischer. Er begleitet einen Piloten entlang der Kette, die er durchlaufen muss, um ein Produktionssystem zu werden, und zeigt, wo jedes Glied bricht. Es ist dieselbe Kette, die das AI Transformation Framework mit Gates versieht; hier liegt die Betonung auf dem Versagen in jeder Stufe statt auf dem Gate, das es verhindert.
Warum scheitern Enterprise-KI-Piloten, bevor sie die Produktion erreichen?
Weil ein Pilot eine enge Frage beantwortet – „Kann das Modell diese Aufgabe?“ –, die Produktion aber eine andere stellt: „Kann diese Operation so laufen, im Volumen, integriert, gesteuert, gemessen und mit einem Eigner?“ Ein Pilot, der ohne gemessenes Problem, neu gestalteten Workflow und belegten Wertnachweis beginnt, hat nichts, in das er hineinwachsen kann, und entdeckt Architektur, Integration, Governance und Verantwortung erst, wenn er die Sandbox verlassen will. Das Scheitern geschieht nicht am Ende des Piloten. Es war am Anfang entschieden.
Deshalb sind die üblichen Erklärungen – „das Modell war nicht genau genug“, „die Nutzer haben es nicht angenommen“, „die IT konnte es nicht integrieren“ – Symptome und keine Ursachen. Ein für eine Demo genaues Modell ist selten die bindende Einschränkung. Nutzer übernehmen keine Tools, die an unveränderte Workflows angeflanscht sind, weil der Workflow sie nicht braucht. Integration ist unmöglich, wenn niemand definiert hat, was das System lesen und schreiben soll. Jedes davon ist ein Glied, das weiter vorn in der Kette übersprungen wurde.
Die acht Glieder zwischen einem Problem und der Produktion
Ein KI-System in der Produktion ruht auf acht Gliedern, der Reihe nach: ein gemessenes Geschäftsproblem; ein Workflow, neu gestaltet rund um KI und menschliche Entscheidungsgewalt; ein Wertnachweis an Kosten pro Ergebnis und Durchlaufzeit; Umsetzungsbereitschaft bei Daten, Fähigkeiten, Verantwortung und Veränderung; eine Architektur, die zu den Einschränkungen des Unternehmens passt; Integration mit den Systemen der Wahrheit, die der Workflow berührt; in den Workflow hineingestaltete Governance; und Produktionsbetrieb mit Überwachung, Evaluation und einem Eigner. Piloten brechen dort, wo ein Glied übersprungen wurde, und der Bruch zeigt sich meist zwei oder drei Glieder später.
| Glied | Was wahr sein muss | Wie der Bruch sich zeigt |
|---|---|---|
| 1 · Problem | Ein gemessenes operatives Problem mit einem Eigner | Der Pilot löst etwas, das niemand beziffert hat; niemand kämpft dafür |
| 2 · Workflow | Der Workflow ist rund um KI und menschliche Entscheidungsgewalt neu gestaltet | Tool neben einem unveränderten Prozess; Nutzer umgehen es |
| 3 · Wert | Ein Business Case, gegen eine Baseline belegt | „Vielversprechende Ergebnisse“, die sich nicht beziffern lassen; Budget wird nicht verlängert |
| 4 · Bereitschaft | Daten, Fähigkeiten, Verantwortung und Veränderungskapazität bewertet | Der Case war solide; die Organisation konnte ihn nicht aufnehmen |
| 5 · Architektur | Ein Design, das Einschränkungen bei Sicherheit, Souveränität, Kosten und Skalierung erfüllt | Die Pilot-Architektur lässt sich im Volumen weder freigeben noch bezahlen |
| 6 · Integration | Liest aus Systemen der Wahrheit und schreibt in sie | Copy-and-paste zwischen Tool und echten Systemen; der Pilot ist ein Nebenkanal |
| 7 · Governance | Entscheidungsrechte, Rückführbarkeit und Kontrollen hineingestaltet | Die Risikoprüfung am Ende blockiert oder verwässert das Deployment |
| 8 · Produktion | Eigner, Budget, Überwachung, Evaluation, Verbesserung | Der Pilot „endet“; niemand wird dafür bezahlt, ihn am Laufen zu halten |
Das Problem wurde nie gemessen
Piloten scheitern am ersten Glied, wenn sie bei einer Fähigkeit statt bei einem bezifferten operativen Problem beginnen. Ein Pilot, der „Verträge zusammenfasst“, hat keine Baseline, keinen Eigner und keine Zahl, die sich ändern wird; ein Pilot, der die Freigabe von Lieferantenverträgen von drei Wochen auf zwei Tage senken soll, hat alle drei. Ohne gemessenes Problem lässt sich nichts Nachgelagertes belegen, und wenn die Budgets knapper werden, hat der Pilot keinen Fürsprecher.
Die Auswahldisziplin, die im vorigen Artikel dieser Serie beschrieben ist, soll diesen Bruch verhindern: dort beginnen, wo Wert abfließt, eine Zahl daran hängen und den Eigner benennen, bevor etwas gebaut wird. Die Beobachtung des MIT NANDA, dass mehr als die Hälfte der GenAI-Budgets in Vertrieb und Marketing floss, während die messbaren Erträge im Back Office lagen, zeigt, wie ein Portfolio aussieht, wenn Glied 1 im großen Maßstab übersprungen wird.
Der Workflow wurde nie neu gestaltet
Hier brechen die meisten Piloten, selbst wenn das Problem real war. Das Modell wird neben dem bestehenden Workflow deployt; die Übergaben, Freigaben, Stapel und Neuerfassungen, die es beseitigen sollte, existieren weiter; und die Menschen im Workflow behandeln das Tool zu Recht als optional. Der Pilot meldet dann geringe Adoption, die als Change-Management-Problem gelesen wird. Es ist ein Designproblem: Der Workflow wurde nie so geändert, dass er das System braucht.
Der Befund von McKinsey, dass die grundlegende Neugestaltung von Workflows die stärkste Korrelation mit dem EBIT-Effekt hat und nur 21 % der Anwender sie vorgenommen hatten, ist die Umfrageperspektive auf diesen Bruch. Das Gegenmittel ist die Methode in Workflow-Neugestaltung mit KI: vom Ergebnis ausgehen, die Schritte entfernen, die wegen menschlicher Einschränkungen existierten, Lesen und Entwerfen dem System zuweisen und die Entscheidungen den Menschen. Ein Pilot eines neu gestalteten Workflows testet eine Operation. Ein Pilot eines Tools neben einem alten Workflow testet eine Demo.
Der Wert wurde behauptet, nicht belegt
Piloten brechen am dritten Glied, wenn der Business Case eine Projektion eingesparter Stunden ist statt einer gemessenen Veränderung von Kosten pro Ergebnis und Durchlaufzeit gegen eine Baseline. Eingesparte Stunden erscheinen in keiner GuV; Kosten pro Rechnung, pro Angebot oder pro gelöstem Fall schon. Ein Pilot ohne Baseline kann nur berichten, dass die Ergebnisse „vielversprechend“ waren, und vielversprechende Ergebnisse überstehen keine Budgetrunde.
Das Gegenmittel ist, den Wertnachweis vor dem Piloten zu erstellen, als Projektion gegen die Baseline, und den Piloten so durchzuführen, dass er diese Projektion bestätigt oder verwirft. Das macht aus dem Piloten statt einer Erkundung einen Test mit Bestehensgrenze, und es erzeugt das eine Artefakt, auf das ein CFO reagieren kann: ein Vorher-nachher in den eigenen Einheiten der Operation. Das Projekt NANDA des MIT führte einen großen Teil der von ihm gefundenen „fehlenden messbaren GuV-Wirkung“ auf Piloten zurück, die überhaupt keine Baseline vor dem Deployment hatten.
Die Organisation war nicht bereit, es aufzunehmen
Ein Pilot kann ein reales Problem, einen neu gestalteten Workflow und einen soliden Wertnachweis haben und dennoch scheitern, weil die Organisation die Veränderung nicht aufnehmen kann: Die Daten, die das System braucht, sind nicht zugänglich oder nicht vertrauenswürdig; die Menschen an den neuen Entscheidungs-Gates wurden nicht auf die Rolle vorbereitet; niemand verantwortet das Ergebnis über die vom Workflow berührten Funktionen hinweg; oder die Veränderung fällt in ein Quartal, in dem die Operation sie nicht tragen kann. Bereitschaft wird vor dem Bau bewertet oder währenddessen entdeckt.
BCGs Beschreibung erfolgreicher Programme als zu 70 % Menschen und Prozesse ist eine Aussage über dieses Glied. Die Bereitschaftsbewertung ist unglamourös, weshalb sie übersprungen wird, und sie ist das Glied, das am ehesten einen guten Piloten in einen eingemotteten verwandelt. Sie ist auch das Glied, das am häufigsten eine berechtigte Anhalten-Entscheidung hervorbringt: Der Case ist solide, und die Organisation sollte zuerst die Vorarbeit leisten. Anhalten als Erfolg der Methode zu behandeln statt als Scheitern des Piloten, erlaubt erst, Bereitschaft ehrlich zu bewerten.
Die Architektur passte zur Demo, nicht zum Unternehmen
Pilot-Architekturen werden gebaut, um zu zeigen, dass etwas funktioniert: ein gehostetes Modell, ein Vektorspeicher über einer Stichprobe von Dokumenten, eine Weboberfläche. Produktionsarchitekturen müssen Einschränkungen erfüllen, die der Pilot nie traf: Datenresidenz und Souveränität, Sicherheitsprüfung, Identität und Berechtigungen, Kosten im vollen Volumen, Latenz, Verfügbarkeit und die Fähigkeit, bei Netzausfall zu laufen. Piloten brechen hier, wenn die Architektur, die den Raum beeindruckte, im Maßstab nicht freigegeben, bezahlt oder betrieben werden kann.
Das Gegenmittel ist, die Architekturentscheidung – einschließlich Bauen, Kaufen, Konfigurieren oder Partnern – nach der Neugestaltung und vor dem Bau gegen die tatsächlichen Einschränkungen des Unternehmens zu treffen. Der Command-&-Control-Fall ist ein Extrembeispiel: Das System musste Edge-first auf souveräner Infrastruktur laufen und unter eingeschränkten oder verweigerten Netzwerkbedingungen weiterarbeiten. Keine Pilot-Architektur hätte das erfüllt; es musste von Anfang an darauf ausgelegt werden. Die meisten Unternehmen stehen vor milderen Fassungen derselben Einschränkungen und entdecken sie am selben späten Punkt, wenn sie nicht früh danach gefragt werden.
Das System berührte nie die Systeme der Wahrheit
Ein Pilot, der nicht aus den Systemen liest und in sie schreibt, auf denen der Workflow tatsächlich läuft, ist ein Nebenkanal, und Nebenkanäle überstehen den Kontakt mit der Produktion nicht. Nutzer kopieren Eingaben hinein und Ausgaben heraus; der Nachweis dessen, was geschah, lebt im Tool statt im Unternehmen; und die Durchlaufzeit des Workflows bewegt sich kaum, weil die manuelle Übertragung, die der Pilot beseitigen sollte, einfach gewandert ist. Integration ist kein Implementierungsdetail. Sie macht das System zum Teil der Operation.
Integration hängt auch vom Glied davor ab: Ein neu gestalteter Workflow legt genau fest, welche Systeme die KI lesen und aktualisieren muss, in welchen Schritten, mit welchen Berechtigungen. Ein Pilot, der die Neugestaltung übersprang, kann seine Integration nicht spezifizieren, weshalb sich Integration „als schwieriger als erwartet“ erweist. Sie wurde nie umrissen. In World AI OS sind Produktionsintegration und Deployment die Aufgabe von Factory; auf welcher Plattform auch immer, ein Pilot ohne Integrationsplan ist ein Pilot ohne Produktionsplan.
Die Governance kam am Ende statt am Anfang
Piloten brechen an der Governance, wenn Risiko-, Compliance- und Rechtsprüfung der letzte Schritt vor dem Deployment ist statt eine Eigenschaft des Designs. Die Prüfung fragt, was das System entscheiden darf, wie seine Ausgaben nachvollzogen werden, wer verantwortlich ist und was geschieht, wenn es falschliegt – und stellt fest, dass niemand das entschieden hat. Das Deployment wird dann blockiert oder eingeschränkt, bis das System nichts tut, was der alte Workflow nicht auch tat – dasselbe Ergebnis, nur teurer.
Das Gegenmittel ist, die Entscheidungsgewalt bei Glied 2 in den Workflow zu gestalten: was das System allein tun darf, was eine Freigabe braucht, was es eskalieren muss; Konfidenzschwellen, Freigabe-Gates, Rückführbarkeit, protokollierte Gründe und Fallback-Pfade. Ein Pilot, der nach diesem Design gebaut ist, kommt zur Prüfung mit den Antworten, die bereits im Workflow stehen. Die McKinsey-Umfrage 2025 fand 51 % der Organisationen, die mindestens eine negative Folge des KI-Einsatzes berichteten, und nannte Human-in-the-Loop-Regeln, zentralisierte Aufsicht und Verantwortung der Geschäftsleitung als das, was High Performer abhob. Das sind Designentscheidungen, keine Prüfergebnisse. In World AI OS liegen sie in Control.
Niemand wurde dafür bezahlt, es zu betreiben
Der letzte Bruch ist der leiseste. Der Pilot „endet“, das Projektteam löst sich auf, und das System hat keinen Eigner, keine Budgetlinie, keine Überwachung, keinen Evaluationsrhythmus und keinen Verbesserungsweg. Es läuft, bis sich etwas ändert – eine Richtlinie, eine Datenquelle, eine Modellversion –, und verschlechtert sich dann oder bleibt stehen. Ein Produktionssystem ist kein abgeschlossenes Projekt. Es ist eine Operation, und Operationen brauchen Betreiber.
Produktion bedeutet einen benannten Eigner, der für das Ergebnis verantwortlich ist, ein Budget, das Inferenz und Wartung deckt, Überwachung von Leistung und Drift, regelmäßige Evaluation gegen die Baseline, Versionierung und Rollback sowie einen Prozess, den Workflow anhand dessen zu verbessern, was er lernt. Unternehmen, die das als dauerhafte Fähigkeit behandeln, einmal gebaut und über Workflows hinweg wiederverwendet, sind diejenigen, deren zweites und drittes System die Produktion schneller erreichen als das erste. Unternehmen, die jeden Piloten als Projekt behandeln, bauen all das jedes Mal neu – oder, häufiger, gar nicht.
Ein Pilot beweist, dass das Modell die Aufgabe kann. Die Produktion beweist, dass das Unternehmen die Operation betreiben kann. Das sind verschiedene Fragen, und nur die zweite ist Geld wert.
Was die Piloten, die die Produktion erreichten, anders gemacht haben
Sie haben die Reihenfolge umgekehrt. Statt zuerst zu bauen und die Kette später zu entdecken, haben sie die Kette zuerst belegt: ein beziffertes Problem, ein neu gestalteter Workflow, ein Wertnachweis gegen eine Baseline, eine Bereitschafts- und Governance-Bewertung sowie ein Architektur- und Integrationsplan, alles vor Beginn des Engineerings. Der Pilot bestätigte dann eine Projektion, statt einen Zweck zu suchen, und die Produktion war die Fortsetzung eines Designs statt eines neuen Projekts.
Die Produktionsfälle von World AI X haben diese Form. Der Mengenermittlungs-Workflow begann mit einer dreiwöchigen Baseline, einer Neugestaltung, in der KI entwirft und Mengenermittler freigeben, und jeder Zeile rückführbar zu ihrer Zeichnung; er ging in Wochen in Produktion, weil die Kette schon stand. Der Angebots-Workflow folgte demselben Weg, mit Experten, die freigeben, bevor etwas eingereicht wird. Keiner der beiden Piloten musste Governance, Integration oder Eigner nachträglich entdecken, denn alles war Teil des Designs.
Glieder 1 und 2: ein gemessenes Problem und ein neu gestalteter Workflow, bevor etwas gebaut wird.
Arbeitsteilung, Entscheidungsgewalt, Kontext und Integration als Teil des Designs spezifiziert.
Glieder 3, 4, 5 und 7: Wertnachweis, Bereitschaft, Architektur und Governance, dann Bauen oder Anhalten.
Glieder 6 und 8: integrieren, deployen, überwachen, evaluieren, verbessern – mit Eigner und Budget.
Diese Abfolge führt World AI X als Discovery Sprint mit anschließendem Produktionsbau durch, und die stufenweise Logik dahinter ist in Das AI Transformation Framework beschrieben. Der Sinn der Abfolge ist keine Zeremonie. Er liegt darin, dass jedes Glied geprüft wird, solange es noch günstig zu beheben ist.
Folgerungen für Führungskräfte
- Fragen Sie, auf welchem Glied ein Pilot steht. Kann niemand die Baseline, den neu gestalteten Workflow und den Eigner benennen, steht der Pilot auf Glied 0.
- Finanzieren Sie zuerst den Nachweis, dann den Bau. Diagnose, Neugestaltung und Business Case sind günstig; Produktions-Engineering ist es nicht. Geben Sie in dieser Reihenfolge aus.
- Machen Sie Anhalten zu einem akzeptablen Ergebnis. Ein Pilot, der aus guten Gründen bei der Bereitschaft gestoppt wurde, hat die Kosten der nächsten vier Glieder gespart.
- Gestalten Sie Governance von Anfang an ein. Entscheidungsrechte und Rückführbarkeit gehören ins Workflow-Design, nicht in die Prüfung vor dem Start.
- Budgetieren Sie Betrieb, nicht Projekte. Jedes Produktionssystem braucht einen Eigner und ein Betriebsbudget, bevor es gebaut wird.
Häufig gestellte Fragen
Warum erreichen die meisten Enterprise-KI-Piloten die Produktion nicht?
Weil ein Pilot beweist, dass ein Modell unter kontrollierten Bedingungen eine Aufgabe ausführen kann, und die Produktion etwas anderes verlangt: einen neu gestalteten Workflow, einen gemessenen Business Case, Integration mit Systemen der Wahrheit, definierte menschliche Entscheidungsgewalt, Governance, die hineingestaltet statt am Ende geprüft wurde, und einen Eigner mit Budget für den Betrieb. Piloten, die diese Glieder überspringen, haben nichts, in das sie hineinwachsen können.
Was ist der Unterschied zwischen einem KI-Piloten und einem KI-Proof-of-Concept?
Ein Proof of Concept zeigt, dass ein technischer Ansatz mit Beispieldaten funktioniert. Ein Pilot führt diesen Ansatz mit echter Arbeit und echten Nutzern für einen begrenzten Umfang oder Zeitraum aus. Beide bleiben vor der Produktion stehen, die verlangt, dass der Workflow kontinuierlich im vollen Volumen läuft, integriert in das Unternehmen, mit Überwachung, Kontrolle und einem Eigner. Die meisten Enterprise-„Piloten“ sind Proofs of Concept mit angehängten Nutzern.
Woran erkennt man, dass ein KI-Pilot produktionsreif ist?
Er hat eine Baseline und ein gemessenes Ergebnis bei Kosten pro Ergebnis und Durchlaufzeit; der Workflow, in dem er läuft, wurde neu gestaltet statt nachgebildet; er liest aus den benötigten Systemen der Wahrheit und schreibt in sie; die Entscheidungen, die er allein, mit Freigabe und nie treffen darf, sind definiert und protokolliert; er hat einen Evaluations-, Überwachungs- und Fallback-Plan; und ein benannter Eigner hält das Budget, ihn zu betreiben und zu verbessern. Fehlt etwas davon, ist er noch ein Pilot.
Was ist der häufigste Grund, warum KI-Implementierungen ins Stocken geraten?
Das Fehlen eines neu gestalteten Workflows. Ein neben einem unveränderten Prozess deploytes Modell findet keinen Platz: Die Übergaben, Freigaben und Neuerfassungen, die es beseitigen sollte, existieren weiter, der Wert, den es schaffen sollte, ist nicht messbar, und die Governance, die es braucht, wurde nie gestaltet. Die meisten anderen Fehler, darunter Integrations- und Adoptionsprobleme, sind Folgen dieses einen.
Sollten KI-Piloten von der IT oder vom Geschäft geleitet werden?
Keins allein. Das Geschäft besitzt den Workflow, die Baseline und die Entscheidung darüber, was das System tun darf; die Technologie besitzt Integration, Architektur, Evaluation und Betrieb. Allein von der IT geleitete Piloten erzeugen Fähigkeiten ohne operative Heimat; allein vom Geschäft geleitete Piloten unterschätzen, was die Produktion verlangt. Die Piloten, die die Produktion erreichen, haben einen Geschäfts-Eigner, der für das Ergebnis verantwortlich ist, und einen Technologie-Eigner, der für das System verantwortlich ist.
Wie lange sollte ein Enterprise-KI-Pilot dauern?
Lange genug, um ein gemessenes Ergebnis gegen eine Baseline zu erzeugen, und nicht länger. Wurde der Workflow neu gestaltet und der Business Case zuerst erstellt, genügt ein Pilot von mehreren Wochen auf echtem Volumen meist, um die projizierte Ökonomie zu bestätigen oder zu verwerfen. Piloten, die viele Monate ohne Entscheidung laufen, sind meist Piloten, die nie eine Baseline hatten, gegen die sich entscheiden ließe.