Warum euer KI-Pilot nicht in Produktion kommt

Ein KI-Pilot scheitert fast nie daran, dass die Technik nicht funktioniert. Er scheitert daran, dass niemand entschieden hat, was danach passieren soll.

Dieser Artikel benennt die vier Gründe, an denen ein Pilot tatsächlich hängen bleibt, und für jeden das Anzeichen, an dem man ihn vor dem Start erkennt.

Die Ausgangslage, gemessen

95 Prozent der KI-Piloten in Unternehmen liefern keinen messbaren Ergebnisbeitrag. Der Unterschied zu den übrigen 5 Prozent lag nicht an der Modellqualität und nicht an der Regulierung, sondern am Vorgehen.

MIT Media Lab, The GenAI Divide: State of AI in Business 2025

Die Untersuchung des MIT-Media-Lab-Projekts NANDA wertete 300 öffentliche KI-Einführungen aus, ergänzt um 52 Interviews und eine Befragung von 153 Führungskräften. Dem gegenüber standen 30 bis 40 Milliarden Dollar Investitionen.

Der Befund, auf den es ankommt, ist die Begründung: Generische Werkzeuge funktionieren hervorragend für einzelne Personen und bleiben im Unternehmen stecken, weil sie sich nicht an einen Arbeitsablauf anpassen und nichts aus ihm lernen.

Die deutsche Entsprechung dieser Lücke steht in den Bitkom-Zahlen: 57 Prozent der Unternehmen ab 20 Beschäftigten setzen KI ein, nach 36 Prozent im Vorjahr, und kein einziges gibt an, das Potenzial vollständig auszuschöpfen.

Grund 1: Der Pilot hatte nie eine Vergleichsgröße

Ein Pilot ohne Vorher-Messung kann nicht bestehen, weil niemand sagen kann, ob er besser ist als vorher.

Am Ende der Pilotphase sitzen alle im Raum, das System funktioniert, und die Frage „hat es was gebracht?“ wird mit Eindrücken beantwortet. Eindrücke gewinnen keine Budgetentscheidung gegen eine laufende Kostenposition.

Woran man es vorher erkennt: Es gibt keine Zahl im Kickoff-Protokoll. Keine Stunden pro Woche, keine Durchlaufzeit, keine Fehlerquote, keine Menge. Wenn im Kickoff niemand sagen kann, wie lange der Prozess heute dauert, wird das am Ende auch niemand sagen können.

Was hilft: Vor dem ersten Zeilencode eine Woche lang messen, wie oft der Prozess läuft und wie lange er dauert. Das ist eine unglamouröse Woche und die einzige, die später zählt.

Grund 2: Es waren fünf Piloten gleichzeitig

Verteilte Aufmerksamkeit ist der Mechanismus hinter der MIT-Zahl. Fünf Werkzeuge werden parallel ausprobiert, jedes bekommt ein Fünftel Aufmerksamkeit, keines erreicht den Punkt, an dem es unentbehrlich wird.

Das Muster ist verführerisch, weil es nach Fortschritt aussieht und weil sich niemand für eine Sache entscheiden muss. Nach zwei Quartalen lautet die Bilanz „KI bringt bei uns nichts“, obwohl in Wahrheit nichts zu Ende gebracht wurde.

Woran man es vorher erkennt: Die Liste der laufenden KI-Initiativen ist länger als drei, und keine hat eine benannte zuständige Person.

Was hilft: Einen Ablauf produktiv machen, nicht drei anfangen. Der zweite Agent kostet deutlich weniger als der erste, weil Zugänge, Datenbasis und Überwachung schon stehen, aber nur, wenn es den ersten wirklich gibt.

Grund 3: Der Pilot lief neben dem Arbeitsalltag, nicht darin

Ein System, das in einer eigenen Oberfläche lebt, wird nach Ende der Pilotphase nicht mehr geöffnet.

Das ist der Grund, warum die Frage „welche neue Software müssen wir dafür kaufen“ so viel über die Erfolgswahrscheinlichkeit verrät. Jedes zusätzliche Login, jede zusätzliche Oberfläche, jede zusätzliche Gewohnheit ist eine Hürde, die die Wirkung des Systems übersteigen muss, bevor überhaupt etwas passiert.

Ein Agent, der in dem CRM arbeitet, das ohnehin offen ist, hat diese Hürde nicht. Er wird auch dann benutzt, wenn niemand an ihn denkt, weil das Ergebnis einfach schon da ist. Genau daran entscheidet sich, ob ein Werkzeug im Alltag benutzt wird oder nach dem Pilot liegen bleibt.

Woran man es vorher erkennt: Im Pilotplan steht das Wort „Schulung“. Ein System, das eine Schulung braucht, konkurriert um Aufmerksamkeit.

Was hilft: Das Ergebnis dorthin liefern, wo die Arbeit ohnehin stattfindet. Als Nachricht, als Entwurf, als ausgefülltes Feld.

Grund 4: Nach der Pilotphase war niemand zuständig

Ein Pilot hat ein Projektteam. Ein Produktivsystem braucht eine Person. Der Übergang zwischen beidem ist die Stelle, an der die meisten Systeme verschwinden.

Der Ablauf ist immer derselbe: Der Pilot läuft, das Projektteam löst sich auf, drei Monate später ändert sich ein Feld im CRM, der Agent liefert stillschweigend Unsinn, und weil niemand zuständig ist, merkt es zuerst ein Kunde. Danach wird das System abgeschaltet, und der Grund geht als „hat nicht funktioniert“ in die Firmengeschichte ein.

Dabei ist die eigentliche Ursache banal: Ein Agent scheitert selten laut. Er wird still schlechter, weil ein Modell abgelöst, ein Feld umbenannt oder eine Schnittstelle geändert wurde. Ohne automatische Prüfung ist das unsichtbar, und ohne zuständige Person schaut auch niemand nach. Wie sich beides messbar machen lässt, steht im Text zur 30-Tage-ÜbergabeEN (in English).

Woran man es vorher erkennt: Auf die Frage „wer ist danach dafür zuständig?“ folgt eine Rolle statt eines Namens.

Was hilft: Der Name steht vor dem Projektstart fest, nicht in der Abschlusspräsentation. Und das Betriebsbudget von 25 bis 40 Prozent der Erstinvestition pro Jahr steht im selben Dokument wie der Baupreis; die Kostenseite haben wir separat aufgeschlüsselt.

Die vier Fragen vor dem Kickoff

Alle vier Gründe sind vor dem Start erkennbar, und zwar in einem Gespräch von zwanzig Minuten:

1. Welche Zahl beschreibt den heutigen Zustand? Keine Zahl, kein Pilot.
2. Wie viele KI-Initiativen laufen parallel? Mehr als zwei, und dieser wird auch nicht fertig.
3. In welchem System sieht der Nutzer das Ergebnis? „In unserem neuen Dashboard“ ist die falsche Antwort.
4. Wer heißt die Person, die danach zuständig ist? Eine Rolle ist keine Antwort.

Auffällig an dieser Liste: Keine der vier Fragen ist technisch. Das ist der eigentliche Inhalt des MIT-Befunds, und es ist auch die gute Nachricht: organisatorische Probleme sind billiger zu lösen als technische, sie werden nur seltener gestellt.

Was ein Pilot eigentlich beweisen soll

Zum Schluss die Frage, die den Rest sortiert: Ein Pilot ist kein Machbarkeitsnachweis. Dass ein Sprachmodell eine E-Mail klassifizieren kann, ist seit Jahren bekannt und muss in keinem Unternehmen erneut gezeigt werden.

Ein Pilot soll beweisen, dass dieser Prozess in diesem Unternehmen mit diesen Daten und diesen Leuten dauerhaft besser läuft. Diese vier Faktoren sind die eigentliche Unbekannte, und drei davon haben nichts mit KI zu tun.

Wer den Piloten so aufsetzt, hat am Ende entweder ein System im Betrieb oder eine belastbare Erkenntnis darüber, woran es lag. Beides ist ein Ergebnis. Ein funktionierender Prototyp ohne Vergleichsgröße und ohne zuständige Person ist keines.

Häufig gestellte Fragen