Warum KI-Piloten im Proof of Concept stecken bleiben – und wie sie in Produktion kommen

Das bekannte Muster

Fast jedes Unternehmen, das sich ernsthaft mit generativer KI beschäftigt, hat inzwischen einen oder mehrere Prototypen gebaut. Viele davon funktionieren erstaunlich gut – in der Präsentation. Danach beginnt eine Phase, die sich zäh anfühlt: Die IT stellt Fragen zur Anbindung, der Datenschutz zur Verarbeitung, der Fachbereich zu falschen Antworten. Niemand sagt Nein, aber es geht auch nicht voran.

Das ist kein Versagen des Teams. Es ist eine strukturelle Lücke: Ein Proof of Concept ist darauf optimiert, schnell eine Frage zu beantworten – „Geht das überhaupt?“. Ein produktives System muss hunderte andere Fragen beantworten, die in der Demo bewusst ausgeklammert wurden.

Was unter der Wasserlinie liegt

Das Bild vom Eisberg ist abgegriffen, trifft es aber genau. Sichtbar sind Modell, Prompt und eine Oberfläche. Darunter liegt die Arbeit, die über Erfolg oder Stillstand entscheidet.

Einige dieser Punkte verdienen einen genaueren Blick, weil sie besonders oft unterschätzt werden:

• Datenanbindung: Im PoC liegen zwanzig ausgewählte PDFs in einem Ordner. In Produktion sind es zehntausende Dokumente in mehreren Systemen, die sich laufend ändern. Das ist eine eigene Ingenieursaufgabe.
• Berechtigungen: Ein Assistent, der allen Mitarbeitenden die Gehaltsliste zusammenfasst, wird zu Recht gestoppt. Rechte müssen aus den Quellsystemen übernommen und bei jeder Anfrage geprüft werden.
• Fallbacks: Was passiert, wenn das Modell nicht erreichbar ist, die Antwort unsicher ist oder eine Frage außerhalb des Einsatzzwecks liegt? „Ich weiß es nicht“ ist eine gute Antwort – wenn sie vorgesehen ist.
• Kostenkontrolle: Ein Fehler in einer Schleife oder ein unerwartet beliebter Anwendungsfall kann Token-Kosten vervielfachen. Limits pro Anwendung und Nutzer gehören in die Architektur, nicht in die Monatsabrechnung.

Fünf Gründe, warum Piloten stecken bleiben

1. Kein messbares Ziel. „Wir wollen KI ausprobieren“ ist kein Ziel. „Angebotsanfragen sollen in einem Tag statt in drei beantwortet werden“ ist eins.
2. Demo-Daten statt echter Daten. Ausgewählte Beispiele sind sauber, vollständig und eindeutig. Echte Daten sind es nicht. Die Lücke zeigt sich spät und teuer.
3. Qualität nach Bauchgefühl. Ohne festen Satz an Testfällen wird jede Diskussion über Qualität zur Anekdote: „Gestern hat es bei mir falsch geantwortet.“
4. Betrieb ungeklärt. Wer überwacht das System, spielt Updates ein, reagiert auf Fehler? Solange diese Frage offen ist, gibt keine IT-Abteilung eine Freigabe.
5. Datenschutz zu spät. Wird die Einordnung erst nach dem Pilot gemacht, kann sie die gewählte Architektur grundsätzlich infrage stellen.

Drei Stufen, zwei Gates

Der Weg in die Produktion wird planbar, wenn Sie ihn in Stufen mit klaren Übergängen teilen. Jede Stufe hat ein eigenes Ziel und endet mit einem Gate: einer kurzen Liste von Kriterien, die erfüllt sein müssen. Ist ein Kriterium nicht erfüllbar, ist das ebenfalls ein Ergebnis – und ein günstiges, wenn es früh kommt.

Wichtig ist der Charakter der Stufen. Der PoC darf improvisieren, er soll schnell sein. Der Pilotdagegen läuft bereits auf der Architektur, die auch in Produktion trägt – nur mit begrenztem Nutzerkreis. Wer im Pilot noch improvisiert, verschiebt die eigentliche Arbeit nur nach hinten.

Evaluation: das unterschätzte Werkzeug

Wenn ich nur eine Maßnahme empfehlen dürfte, wäre es diese: Bauen Sie früh einen festen Satz an Testfällen auf. Echte Fragen aus dem Alltag, jeweils mit einer erwarteten Antwort oder klaren Kriterien, was eine gute Antwort enthalten muss. Zu Beginn reichen einige Dutzend Fälle; wichtiger als die Menge ist, dass sie typische Anfragen und bekannte Sonderfälle abdecken.

Jede Änderung – am Prompt, an der Datenaufbereitung, am Modell – läuft automatisch gegen diese Testfälle. Das Ergebnis ist eine Zahl, über die man sprechen kann, statt einer Sammlung von Einzelbeobachtungen.

Ein paar Erfahrungen aus der Praxis:

• Rückschritte sind normal. Ein neueres Modell ist nicht automatisch besser für Ihre Aufgabe. Ohne Evaluation fällt das erst im Betrieb auf.
• Automatische Bewertung braucht Kontrolle. Ein zweites Modell kann Antworten bewerten, aber seine Urteile sollten regelmäßig stichprobenartig von Menschen geprüft werden.
• Testfälle wachsen mit. Jede falsche Antwort aus dem Pilot wird ein neuer Testfall. So lernt das System nicht zweimal denselben Fehler.
• Die Schwelle ist eine fachliche Entscheidung. Wie gut „gut genug“ ist, hängt vom Einsatz ab – ein Entwurfsassistent verträgt mehr Fehler als eine automatische Freigabe.

Ein typischer Verlauf

Wie das konkret aussieht, zeigt ein konstruiertes, aber typisches Beispiel: Ein Vertriebsinnendienst möchte eingehende Anfragen schneller beantworten. Der PoC entsteht in zwei Wochen – ein Modell liest Anfragen und schlägt Antworten vor. Die Demo überzeugt.

Am ersten Gate zeigt sich: Es gibt noch keine Testfälle, und die Beispielanfragen waren handverlesen. Das Team sammelt daraufhin echte Anfragen aus den letzten Monaten, definiert, was eine gute Antwort enthalten muss, und misst. Das Ergebnis ist ernüchternder als die Demo, aber ehrlich – und es zeigt, wo nachgebessert werden muss: Preise und Lieferzeiten fehlen, weil das ERP nicht angebunden ist.

Im Pilot arbeitet eine kleine Gruppe mit dem System auf echten Daten. Jede falsche Antwort wird zum Testfall. Monitoring zeigt, welche Anfragetypen gut funktionieren und welche besser weiterhin von Menschen beantwortet werden. Am zweiten Gate ist klar, wer den Betrieb verantwortet, und der Fachbereich entscheidet über die Ausweitung.

Der Unterschied zum Stillstand liegt nicht in der Technik, sondern darin, dass an jeder Stelle klar war, was als Nächstes zu beweisen ist.

Was das für Ihre Planung bedeutet

Planen Sie den PoC kurz und das, was danach kommt, ausdrücklich ein. Budget, Zeit und Personen für Datenanbindung, Evaluation und Betrieb gehören von Anfang an in den Projektplan – nicht als Nachtrag, wenn die Demo überzeugt hat.

Und wählen Sie den ersten Anwendungsfall so, dass er diesen Weg auch tragen kann: ein klar umrissener Prozess, verfügbare Daten, ein Fachbereich mit echtem Leidensdruck. Ein erfolgreich produktiver Anwendungsfall bringt mehr als fünf beeindruckende Demos – weil die Architektur, die dabei entsteht, für die nächsten wiederverwendet werden kann.