
Die Demo, die alle begeistert hat, und dann verschwand
Vor ein paar Monaten saß ich in einem Besprechungsraum eines Maschinenbauers mit knapp 60 Mitarbeitern. Auf dem Bildschirm lief etwas, auf das das Team sichtlich stolz war: ein KI-Assistent, der Angebote aus alten Projektdaten zusammenstellte. Ein Mitarbeiter tippte eine Anfrage ein, und nach drei Sekunden stand ein sauber strukturierter Angebotsentwurf da. Im Raum war Begeisterung. „Das spart uns Stunden", sagte der Vertriebsleiter.
Dann fragte ich, seit wann das im Einsatz sei. Stille. Es war nicht im Einsatz. Es war eine Demo, gebaut vor vier Monaten, vorgeführt vor der Geschäftsführung, beklatscht, und seitdem lief es auf dem Laptop eines Mitarbeiters, der inzwischen in einem anderen Projekt steckte. Niemand benutzte es. Die echten Angebote wurden weiter von Hand geschrieben.
Das ist kein Einzelfall. Es ist das häufigste Muster, das mir bei KI-Vorhaben im Mittelstand begegnet. Der Pilot funktioniert. Die Demo begeistert. Und dann passiert nichts. Das Ding landet in der Schublade, während alle weiter glauben, man habe „etwas mit KI gemacht".
Die Zahlen, die das Muster sichtbar machen
Wenn Sie das Gefühl haben, Ihr Unternehmen sei mit diesem Problem allein, kann ich Sie beruhigen: Es ist eher die Regel als die Ausnahme. Durch die Studienlage der letzten zwei Jahre zieht sich ein erstaunlich stabiles Bild.
Sehr häufig zitiert wird eine Größenordnung von rund 78 % der Unternehmen mit aktiven KI-Piloten, denen nur etwa 14 % gegenüberstehen, die einen dieser Piloten tatsächlich in den produktiven Betrieb gebracht haben. Die genauen Prozentwerte schwanken je nach Erhebung, Branche und Definition von „Produktion", aber die Richtung ist über alle Studien hinweg dieselbe: Es wird viel pilotiert und wenig betrieben.
Dazu passt eine zweite Beobachtung, die das Bild abrundet. In Befragungen geben oft über 70 % der Mitarbeiter an, KI im Arbeitsalltag bereits zu nutzen, während nur rund 30 % der Geschäftsführer und CEOs mit den Ergebnissen ihrer KI-Initiativen zufrieden sind. Hohe Nutzung, niedrige Zufriedenheit. Das ist kein Widerspruch. Das ist genau das, was passiert, wenn KI als verstreutes Experimentieren stattfindet und niemand sie als betriebenen Prozess führt.
Ich nehme diese Zahlen als Symptombeschreibung, nicht als exakte Wahrheit. Sie sagen nicht „KI funktioniert nicht". Sie sagen: Der Sprung vom Pilot in die Produktion gelingt fast nie, und das hat einen Grund, der sich benennen lässt.
Der Grund ist nicht die Technik
Die naheliegende Erklärung wäre: Das Modell war nicht gut genug, die Daten waren zu schlecht, die Technik noch nicht reif. In den allermeisten Fällen, die ich sehe, stimmt das nicht. Die Technik des Piloten funktioniert ja, das ist gerade das Verwirrende. Die Demo läuft. Das Modell antwortet. Der Use-Case ist real.
Der Pilot scheitert nicht an dem, was er kann. Er scheitert an allem, was um ihn herum fehlt.
Ein Pilot wird typischerweise gebaut, um eine Frage zu beantworten: Geht das überhaupt? Kann ein Sprachmodell aus unseren Projektdaten ein Angebot bauen, einen Reklamationstext entwerfen, eine technische Frage beantworten? Diese Frage ist nach zwei Wochen beantwortet, mit Ja. Und genau in diesem Moment hört das Projekt meistens auf, ohne dass es jemand merkt.
Denn die Frage, die in Produktion zählt, ist eine völlig andere: Kann das jeden Tag, für jeden Mitarbeiter, mit echten Daten, unter echten Bedingungen, verlässlich laufen, und merkt jemand, wenn nicht? Diese Frage hat der Pilot nie gestellt. Er war nie dafür gebaut.
Ein Pilot beweist, dass etwas möglich ist. Produktion beweist, dass etwas verlässlich ist. Das sind zwei verschiedene Projekte, und die meisten Unternehmen bauen nur das erste.
Demo-Theater: Warum so gebaut wird
Ich nenne das Demo-Theater. Es entsteht nicht aus Dummheit. Es entsteht aus einer nachvollziehbaren Dynamik.
Der Auftrag lautet oft: „Zeig uns mal, was mit KI geht." Das ist ein Auftrag für eine Demo, keiner für ein Produkt. Wer ihn ernst nimmt, baut das Beeindruckendste, was in der kürzesten Zeit machbar ist. Er nimmt saubere Beispieldaten, weil die echten Daten chaotisch sind. Er umgeht die Schnittstelle zum ERP, weil ein Export schneller geht. Er baut auf einem lokalen Rechner, weil das keine IT-Freigabe braucht. Jede dieser Abkürzungen ist für eine Demo richtig und für Produktion tödlich.
Das Ergebnis ist eine Demo, die genau deshalb so gut aussieht, weil sie alle schweren Teile weggelassen hat. Die schweren Teile sind nämlich nicht das Modell. Es sind:
- der Zugriff auf die echten, unaufgeräumten Daten
- die Anbindung an die Systeme, in denen die Arbeit tatsächlich passiert
- die Frage, wer das Ding betreibt, wartet und verantwortet
- die Frage, was passiert, wenn die KI einmal Unsinn ausgibt
- die laufenden Kosten und ihre Kontrolle
Eine Demo, die diese fünf Dinge auslässt, ist in zwei Wochen fertig. Ein produktives System, das sie ernst nimmt, braucht länger, läuft danach aber auch. Das Demo-Theater verwechselt die Geschwindigkeit des ersten mit der Machbarkeit des zweiten. An dieser Verwechslung sterben 78 % der Piloten.
Die fehlende Produktions-Checkliste
Wenn ein Pilot nie in Produktion geht, fehlt fast immer dieselbe Handvoll Dinge. Keines davon ist eine Modell-Frage. Alle sind organisatorisch oder architektonisch. Ich gehe sie der Reihe nach durch, weil diese Liste der eigentliche Unterschied zwischen Schublade und Betrieb ist.
Daten
Im Pilot werden saubere Beispieldaten verwendet. In Produktion treffen Sie auf die Wirklichkeit: Dubletten, Tippfehler, fehlende Felder, drei verschiedene Schreibweisen desselben Kunden, PDF-Scans statt strukturierter Datensätze. Ein Produktionssystem muss mit dieser Wirklichkeit umgehen, automatisch, jeden Tag, ohne dass jemand vorher von Hand aufräumt. Wenn der Pilot nie mit echten Daten getestet wurde, wissen Sie schlicht nicht, ob er funktioniert.
Schnittstellen
Der Pilot lebt isoliert. Produktion lebt im Prozess. Das heißt: Die KI muss dort sitzen, wo die Arbeit passiert, im CRM, im ERP, im Postfach, im Ticketsystem. Eine Lösung, für die ein Mitarbeiter erst ein separates Tool öffnen, etwas hineinkopieren und das Ergebnis zurückkopieren muss, wird nicht benutzt. Der Grund ist nicht ihre Qualität. Sie erzeugt Reibung. Integration in echte Prozesse ist kein Nice-to-have. Sie ist die Bedingung dafür, dass das System überhaupt verwendet wird.
Owner
Das ist der am häufigsten fehlende Punkt. Wem gehört dieses System? Wer ist verantwortlich, wenn es nicht läuft? Wer entscheidet über Änderungen, beantwortet Fragen der Nutzer, prüft die Ergebnisse? Ein Pilot ohne Owner ist ein Waisenkind. Sobald der Mitarbeiter, der ihn gebaut hat, in das nächste Projekt wechselt, ist niemand mehr zuständig, und ohne Zuständigkeit verfällt jedes System. Ein produktives KI-System braucht einen Namen daneben, keine Abteilung.
Monitoring
In Produktion müssen Sie merken, wenn etwas schiefgeht, bevor es ein Kunde merkt. Gibt die KI plausibel klingenden Unsinn aus? Hat sich die Datenquelle geändert? Ist die Antwortqualität über die Wochen abgedriftet? Ein System ohne Beobachtung ist eine Blackbox, der man irgendwann nicht mehr traut, und dann schaltet man sie lieber ganz ab. Monitoring heißt nicht zwingend ein teures Dashboard. Es heißt: ein definierter Weg, auf dem Fehler sichtbar werden, und jemand, der hinschaut.
Kosten
Ein Pilot mit zehn Anfragen am Tag kostet nichts der Rede wert. Dasselbe System mit tausend Anfragen am Tag, über alle Mitarbeiter, kann eine spürbare laufende Rechnung erzeugen. Wer das nicht vorab durchrechnet und nicht laufend kontrolliert, erlebt eine böse Überraschung, oder schaltet im Zweifel wieder ab. Kostenkontrolle gehört in den Produktionsplan, nicht in die nachträgliche Schadensbegrenzung.
Diese fünf Punkte sind keine technische Kür. Sie sind die Differenz zwischen einem Experiment und einem Betrieb. Und sie erklären, warum der Sprung in die Produktion eine organisatorische und architektonische Frage ist, keine Modell-Frage.
Den Piloten von Anfang an produktionsfähig bauen
Die naheliegende Reaktion auf diese Liste wäre: erst pilotieren, dann nachrüsten. Genau das funktioniert nicht. Wer einen Piloten als Demo-Theater baut und ihn anschließend produktionsfähig machen will, baut faktisch zweimal, einmal die Demo und einmal das echte System. Meistens passiert das zweite Mal nie, weil das Budget für das erste Mal draufgegangen ist und die Begeisterung mit der Demo verpufft ist.
Der Ausweg aus der PoC-Falle ist eine andere Reihenfolge im Kopf: Bauen Sie den Piloten von Anfang an so, dass er in Produktion gehen könnte. Das ist nicht aufwendiger. Es ist anders.
Das heißt konkret:
- Echte Daten statt Beispieldaten. Testen Sie von Tag eins mit dem realen Chaos. Lieber ein kleinerer Use-Case mit echten Daten als ein beeindruckender mit geschönten.
- Eine echte Schnittstelle statt Insellösung. Der Pilot sitzt im Prozess, nicht daneben. Auch wenn er klein anfängt, sitzt er an der richtigen Stelle.
- Ein Owner ab dem ersten Tag. Bevor gebaut wird, steht fest, wer das Ding nach der Demo verantwortet. Kein Owner, kein Start.
- Ein definierter Erfolgsmaßstab. Nicht „sieht beeindruckend aus". Stattdessen ein „spart der Buchhaltung pro Woche X Stunden" oder „beantwortet Y % der Anfragen ohne Nachbearbeitung". Etwas, das überprüfbar ist.
- Offene, austauschbare Bausteine. Damit das, was im Piloten funktioniert, weiterwächst und nicht weggeworfen werden muss. Ein Pilot, der in einer geschlossenen Logik gefangen ist, lässt sich nicht in Produktion überführen. Er muss neu gebaut werden.
Das ist derselbe Grundsatz, der hinter warum so viele KI-Projekte scheitern steht: Über Erfolg oder Misserfolg entscheidet selten das Modell. Es entscheidet die Frage, ob Sie von Anfang an einen Betrieb gebaut haben oder nur eine Vorführung.
Reihenfolge und Befähigung
Wer der PoC-Falle dauerhaft entkommen will, muss noch einen Schritt weiter denken. Der erste produktive Use-Case ist nicht das Ziel. Er ist der Beweis, dass Ihr Unternehmen den Weg von der Idee bis zum Betrieb gehen kann. Und dieser Weg ist eine Fähigkeit, die im Haus bleiben muss.
Denn das nächste KI-Vorhaben kommt bestimmt. Wenn jeder neue Use-Case wieder als isolierte Demo beginnt, die wieder nachträglich produktionsfähig gemacht werden muss, wiederholen Sie die Falle in Serie. Der Unterschied zwischen Unternehmen, die mit KI vorankommen, und solchen, die in Pilot-Friedhöfen feststecken, ist selten das Budget. Es ist die Frage, ob das interne Team gelernt hat, einen Use-Case von der ersten Idee bis zum überwachten Betrieb zu führen, mit Daten, Schnittstellen, Owner und Monitoring im Blick.
Das ist auch der Grund, warum ein KI-Vorhaben nicht mit dem Kauf eines Werkzeugs endet. Es endet mit einer aufgebauten Fähigkeit. Wer dieses Denken konsequent weiterführt, landet bei dem, was ich an anderer Stelle beschrieben habe: einem KI-Betriebssystem, das man baut statt kauft. Ein einzelner produktiver Use-Case ist der erste tragende Stein davon. Ein Pilot in der Schublade ist gar nichts.
Die ehrliche Frage an Ihren nächsten Piloten
Wenn auf Ihrem Tisch gerade ein KI-Pilot liegt oder einer geplant ist, stellen Sie eine einzige Frage, bevor die erste Zeile gebaut wird:
Was genau muss passieren, damit dieser Pilot in vier Wochen ein Mitarbeiter im echten Arbeitsalltag benutzt, und nicht eine Demo bleibt, die wir einmal vorführen?
Wenn Sie diese Frage nicht klar beantworten können, wer die Daten liefert, wo das System sitzt, wer es verantwortet, woran man Erfolg misst, dann bauen Sie gerade Demo-Theater. Das ist nicht weiter schlimm, solange Sie es wissen und es bewusst als Erkundung deklarieren. Schlimm wird es, wenn Sie glauben, Sie hätten „etwas mit KI gemacht", während das Ergebnis längst in der Schublade liegt.
Wenn Sie unsicher sind, ob Ihr aktueller KI-Pilot überhaupt produktionsfähig gedacht ist oder ob er auf dem direkten Weg in die Schublade ist, ist ein nüchterner Digital-Realitäts-Check der schnellste Weg zu einer ehrlichen Einschätzung. Und wenn die Richtung klar ist und Sie einen Use-Case wollen, der von Anfang an für den Betrieb gebaut wird, zeigt der KI-Sprint, wie aus einer Idee in vier Wochen ein erstes Stück läuft. Keine Vorführung. Etwas, das am Ende wirklich jemand benutzt.
