Von AI-Piloten in die Produktion

Fast jede Organisation hat inzwischen ihre AI-Erfolgsgeschichte. Einen Piloten, der funktioniert hat. Eine Demo, die den Vorstand beeindruckt hat. Einen Use Case, der nachweislich Zeit gespart hat. Diese Geschichten werden auf Managementklausuren erzählt, in Strategiefolien zitiert und in Budgetrunden als Beleg angeführt.

Deutlich seltener ist eine andere Geschichte: derselbe Use Case, sechs Monate später, verlässlich im Regelbetrieb — ohne eine heldenhafte Einzelperson, die ihn im Hintergrund zusammenhält. Zwischen diesen beiden Zuständen liegt die Lücke, in der sich Enterprise AI tatsächlich entscheidet. Und wer verstehen will, warum so viele AI-Initiativen in ihr verschwinden, sollte aufhören, auf die Technologie zu schauen.

Piloten sind auf ein Ja optimiert

Der Pilot ist eine wunderbare Erfindung — und eine systematisch irreführende. Er läuft in einer kontrollierten Umgebung, mit motivierten Nutzern, mit kuratierten Daten und mit einem Champion, der jeden Tag hinschaut, weil sein Projekt daran hängt. Alles an einem Piloten ist darauf ausgelegt, die Frage „Kann das funktionieren?" mit Ja zu beantworten.

Der Regelbetrieb stellt eine härtere Frage: Kann das weiter funktionieren — für alle, dauerhaft, ohne besondere Aufmerksamkeit? Wenn der Pilot endet, zieht der Champion zum nächsten Thema weiter. Die Nutzer, die jetzt dazukommen, haben keinen Workshop besucht. Die Daten driften. Die Ausnahmefälle, die im Piloten nie auftraten, treffen alle gleichzeitig ein. Nichts davon ist ein Versagen des Piloten. Es ist die Differenz zwischen zwei grundverschiedenen Fragen, die eine Organisation zu oft für dieselbe hält.

Warum es rational ist, im Piloten stecken zu bleiben

Die gängige Erklärung für hängende AI-Initiativen lautet: fehlende Reife der Technologie, fehlende Datenqualität, fehlende Skills. Alles real, alles nachrangig. Die unbequemere Erklärung: In vielen Organisationen ist es für jeden einzelnen Beteiligten rational, den Sprung in die Produktion nicht zu wagen.

Denn der Schritt vom Piloten in den Betrieb ist eine teure Entscheidung. Jemand muss dauerhaft Verantwortung übernehmen, Budget binden, Risiken tragen, die im Piloten niemand beziffern musste. Wenn unklar ist, wer dieses Ja überhaupt geben darf — wer das Mandat hat, wer die Kriterien kennt, wer im Zweifel geradesteht —, dann gibt es dieses Ja schlicht nicht. Nicht weil jemand Nein gesagt hätte, sondern weil Nein-durch-Schweigen die sicherste Option für alle ist. Das Ergebnis kennt fast jede Organisation: ein Portfolio gepflegter Piloten, die Kosten verursachen und Referenzfolien liefern, aber keinen Wertbeitrag im Betrieb. Ich habe dafür noch keine bessere Beschreibung gefunden als: Die Organisation ist auf das Ausprobieren eingerichtet, aber nicht auf das Entscheiden.

Genau das meint die These, dass Governance keine Bremse, sondern die Voraussetzung für Skalierung ist: Ohne klare Entscheidungsrechte bleibt der Pilot der risikoärmste Endzustand.

Was der Betrieb tatsächlich verlangt

Die gute Nachricht: Was fehlt, ist bekannt und baubar. Der Weg in die Produktion hat weniger mit dem Modell zu tun als mit allem darum herum — vier Dinge, keines davon glamourös.

Ownership. Eine namentlich verantwortliche Person für den Use Case im Betrieb. Nicht das Projektteam, das sich nach dem Rollout auflöst, sondern jemand, der auch im nächsten Jahr noch antwortet, wenn etwas auffällt.

Ein wiederholbarer Änderungsweg. Modelle, Prompts und Datenquellen ändern sich laufend. Ohne definierten Weg zum Ändern, Prüfen und Freigeben wird jede Anpassung zum Ad-hoc-Eingriff — und jeder Ad-hoc-Eingriff zur potenziellen Störung.

Betriebsfähigkeit. Jemand bemerkt, wenn sich das Verhalten verschlechtert, es gibt einen Eskalationsweg und einen Plan für den Fall, dass abgeschaltet werden muss. Für Agents, die selbstständig handeln, gilt das doppelt — die sechs Governance-Fragen müssen vor dem Betrieb beantwortet sein, nicht nach dem ersten Vorfall.

Entscheidungsrechte. Der Punkt, an dem sich alles entscheidet: klare Kriterien und ein klares Mandat dafür, was in Produktion gehen darf. Damit der sichere Weg auch der schnelle ist — und nicht der, den alle umgehen.

Das Operating Model ist das Produkt

Die Organisationen, die AI verlässlich in den Betrieb bringen, unterscheiden sich von den anderen durch eine Verschiebung im Selbstverständnis: Sie behandeln nicht den einzelnen Use Case als das Produkt, sondern das Operating Model — den wiederholbaren Pfad von der Idee über die Risikoeinordnung und Freigabe bis in Betrieb und Außerbetriebnahme.

Der Pilot bekommt damit eine neue Rolle. Er ist nicht länger ein Einzelstück, das nach dem Erfolg mühsam „irgendwie produktiv gemacht" werden muss, sondern die erste Instanz eines Systems, das für Wiederholung gebaut ist. Der zweite Use Case folgt demselben Pfad wie der erste, der zwanzigste wie der zweite. Aus einer Serie von Einzelanstrengungen wird eine Fähigkeit.

Piloten beweisen Möglichkeit. Operating Models liefern Verlässlichkeit. Die Reihenfolge ist kein Zufall — aber wer dauerhaft beim Beweisen bleibt, hat sich nur besonders gründlich aufs Anfangen spezialisiert. Wert entsteht im Betrieb. Und der Weg dorthin ist keine technische Meisterleistung, sondern eine organisatorische Entscheidung: Verantwortung benennen, Entscheidungsrechte klären, den Pfad bauen. Wer das tut, dem gelingt der Sprung nicht einmal, sondern jedes Mal.