Warum KI-Pilotprojekte nicht in Produktion gehen — und fünf Prüfungen, die das ändern

KI-Projekte scheitern auf eine sehr bestimmte Art. Nicht daran, dass die Technik nicht funktioniert — die Demo funktioniert meist hervorragend. Sondern daran, dass Demo und Produktivsystem zwei verschiedene Dinge sind und fast alle Kosten im zweiten stecken. Ein Pilot beweist, dass ein Modell etwas einmal kann, unter Bedingungen, die jemand ausgesucht hat. Der Betrieb verlangt, dass es dasselbe vierzigmal am Tag tut, auf Eingaben, die niemand ausgesucht hat, während ein Unternehmen sich auf das Ergebnis verlässt.

Es folgen fünf Prüfungen, die wir anlegen, bevor wir etwas als fertig bezeichnen. Sie sind unspektakulär — und sie sind der Unterschied zwischen einem Projekt, das live geht, und einem, das im Statusmeeting einfach nicht mehr erwähnt wird.

1. Gibt es ein Testset aus echten Fällen?

Der zuverlässigste Indikator dafür, ob ein KI-System in den Betrieb kommt, ist die Frage, ob irgendjemand sagen kann, wie gut es funktioniert. Nicht „sieht gut aus“ — eine Zahl, auf einer festen Menge von Fällen, vor dem Start vereinbart.

Zwanzig bis fünfzig echte Fälle mit bekannter richtiger Antwort reichen zum Anfangen. Bauen Sie es aus den unaufgeräumten Eingaben, nicht aus dem sauberen Export: die schief gescannte Rechnung, die E-Mail mit der Frage im dritten Absatz, der Datensatz mit dem zweckentfremdeten Feld. Und führen Sie es bei jeder Änderung erneut aus. Ohne das können Sie nicht sagen, ob das Prompt-Tuning der letzten Woche geholfen oder geschadet hat — und sonst auch niemand.

2. Gibt es einen entworfenen Weg für die Fälle, die falsch laufen?

Jedes KI-System liegt manchmal daneben. Die Frage ist, was dann passiert. Piloten haben darauf typischerweise keine Antwort, weil in einer Demo die interessanten Fälle die sind, die funktionieren.

Wir entwerfen den Ausnahmepfad zuerst: eine Konfidenzschwelle, eine Prüfliste und eine Person, die die unsicheren Fälle sieht, bevor sie etwas auslösen. Danach automatisieren wir die Masse darum herum. Grob angestrebt läuft die große Mehrheit direkt durch und ein einstelliger Prozentsatz erreicht einen Menschen — aber die genaue Aufteilung ist ein Regler, der Ihnen gehört, und konservativ zu starten kostet fast nichts.

Ein System, das sagen darf „das weiß ich nicht“, ist erheblich nützlicher als eines, das immer sicher klingt — und es lässt sich deutlich leichter freigeben.

3. Lebt es dort, wo die Arbeit ohnehin stattfindet?

Ein Werkzeug, für das Ihr Team seine eigentlichen Werkzeuge verlassen muss, wird zwei Wochen lang benutzt. Integration ist nicht der langweilige Teil nach dem KI-Teil — bei den meisten Projekten ist sie der größere Teil der Entwicklung, und dort landet der Nutzen tatsächlich.

Konkret: Das Ergebnis muss im CRM, im ERP, im Ticketsystem oder im geteilten Postfach ankommen, das die Leute ohnehin öffnen. Das heißt Authentifizierung, Berechtigungen, Ratelimits, Wiederholungen, Idempotenz und ein Protokoll. Nichts davon ist glanzvoll, und alles davon ist tragend.

4. Meldet es sich, wenn es stehen bleibt?

Eine stille Automatisierung ist schlimmer als ein manueller Prozess, denn ein manueller Prozess bleibt sichtbar stehen und eine stille nicht. Wir haben Systeme übernommen, die wochenlang fehlgeschlagen sind, ohne dass es jemandem auffiel — und in jedem Fall bestand die Lösung aus fünf Zeilen Alarmierung, die nie geschrieben worden waren.

• Wiederholungen mit Backoff bei jedem externen Aufruf
• Idempotenz, damit eine Wiederholung keinen Datensatz doppelt anlegt
• Ein Alarm, wenn die Warteschlange nicht mehr abgearbeitet wird — nicht erst beim Absturz
• Ein Dashboard, auf das jemand tatsächlich schaut, oder eine Nachricht im Kanal, den er ohnehin liest

5. Ist der erste Release schmal genug, um zu überleben?

Nach einem erfolgreichen Piloten ist der Reflex, den Umfang auszuweiten. Fast immer ist das der falsche Schritt. Der echte Einsatz bringt Fälle hervor, die das Testset nicht hatte — und er bringt sie am schnellsten hervor, wenn die Angriffsfläche klein ist.

Wir liefern die schmale Version aus — ein Dokumententyp, eine Absicht, ein Team — und verbringen die folgenden Wochen mit dem, was die Realität zeigt. Die meisten Systeme werden in den sechs Wochen nach dem Start deutlich besser, und das ist nur möglich, wenn die Sache live und klein genug ist, um schnell geändert zu werden.

Die unbequeme Prüfung

Es gibt eine sechste Frage, und sie spart das meiste Geld: Sollte das überhaupt mit KI gebaut werden?

Ein erheblicher Teil der Probleme, die zu uns kommen, ist mit einem geplanten Job, einer festen Schnittstelle oder einem korrigierten Prozess besser gelöst. Das ist günstiger zu bauen, günstiger zu betreiben und deutlich weniger überraschungsanfällig. Ein Pilot, der mit „das sollte eine Datenbankansicht sein“ endet, ist ein erfolgreicher Pilot — und er ist sehr viel billiger als die Alternative.

“Der Abstand zwischen etwas, das im Meeting funktioniert, und etwas, das an einem Dienstagnachmittag mit echten Daten funktioniert, ist die Stelle, an der die meisten KI-Budgets verschwinden.”