Vom Piloten zur Produktion: Warum KI-Projekte im Proof-of-Concept stecken bleiben
Der Pilot lief gut. Alle waren begeistert. Sechs Monate später läuft das System noch immer auf dem Laptop des Beraters. Was zwischen einem überzeugenden Demo und einem produktiven KI-System liegt — und warum dieser Schritt so oft unterschätzt wird.
Vom Piloten zur Produktion: Warum KI-Projekte im Proof-of-Concept stecken bleiben
Ich begleite seit Jahren Unternehmen bei KI-Projekten. Und eines der häufigsten Muster, das ich sehe, ist so konstant, dass es fast komisch wäre — wenn es nicht so viel Geld kosten würde.
Der Pilot wird gebaut. Die Demo läuft gut. Alle sind begeistert. Sechs Monate später läuft das System noch immer auf dem Laptop des Beraters, und im Unternehmen redet kaum noch jemand davon.
Das ist nicht die Ausnahme. Das ist das Standardmuster.
Was ein Proof-of-Concept beweist
Ein PoC hat eine klare Aufgabe: zeigen, dass ein Konzept technisch funktioniert. Das schafft er fast immer. GPT-4 versteht Ihre Dispositionsanfragen. Claude extrahiert Daten aus Ihren Rechnungen. Ein Classifier sortiert Ihre Support-Tickets.
Das alles stimmt. Unter PoC-Bedingungen.
Was ein Pilot meist nicht zeigt: wie das System auf Ihren echten Daten performt — den fünfzehn verschiedenen Formaten, den veralteten Feldern, den Sonderzeichen in Kundennamen. Wie es sich verhält, wenn fünfzig Nutzer gleichzeitig darauf zugreifen statt einem. Was passiert, wenn ein Modell-Update das Verhalten verändert. Und wer das System betreibt, wenn der Berater beim nächsten Kunden sitzt.
Das ist kein Vorwurf an den PoC-Ansatz. Er soll schnell zeigen, ob eine Idee trägt. Aber viele Unternehmen behandeln einen guten Piloten wie einen fast fertigen Produktiveinsatz — und wundern sich, dass der Weg zur Produktion so lang ist.
Warum Projekte im Pilot stecken bleiben
Die Ursachen sind selten technisch.
Kein Product Owner. Jemand muss das System besitzen — nicht nur betreiben. Die IT sagt, das sei Sache des Fachbereichs. Der Fachbereich sagt, das sei IT. Das System gehört niemandem. Und was niemandem gehört, verkümmert.
Meine Empfehlung: Benennen Sie einen internen Product Owner, bevor der PoC anfängt. Jemanden, dem der Erfolg des Systems persönlich wichtig ist, der Nutzer-Feedback einholt und der Entscheidungen trifft.
Echte Daten sehen anders aus. Ein Demo läuft meist auf sauberen Testdaten. In der Produktion kommen unvollständige Datensätze, Sonderfälle, Legacy-Systeme ohne aktuelle API-Dokumentation und Datenformate, die seit Jahren niemand mehr angepasst hat.
KI-Modelle können mit Unordnung umgehen — aber nur mit Unordnung, die man ihnen gezeigt hat. Ein Modell, das auf Musterdaten trainiert wurde, stolpert auf echten Daten. Die nötige Bereinigung kostet Zeit und Budget, die niemand eingeplant hat. Und weil das unvorbereitet trifft, wirkt es wie ein Fehler des Modells — dabei ist es ein Fehler in der Projektplanung.
Governance wurde auf später verschoben. Wer darf das System nutzen? Was passiert, wenn das Modell falsch liegt? Welche Kundendaten dürfen in den Prompt? Wie wird das Modell aktualisiert, wenn sich Prozesse ändern?
Diese Fragen wirken wie Bürokratie — bis man versucht, ein System in Produktion zu bringen, und plötzlich wochenlang in der Rechtsabteilung wartet. Ich habe Projekte gesehen, bei denen genau das passiert ist, weil diese Fragen nicht vor dem PoC, sondern nach dem Demo gestellt wurden.
Das Problem mit PoC-Code in Produktion
Ein Pilot wird schnell gebaut, um schnell zu zeigen, was möglich ist. Das ist sein Zweck. Aber schnell gebauter Code ist selten robust.
Kein Fehlerhandling für Grenzfälle. Kein Monitoring. Keine Alerting-Logik, wenn das Modell schlechte Antworten liefert. Kein Rollback, wenn ein Update etwas kaputt macht.
Wenn dieser Code direkt die Grundlage für das Produktivsystem wird, bauen Sie auf Sand.
Ich erkläre es meinen Kunden so: Ein PoC ist Wegwerfcode. Er beantwortet eine Frage. Wenn die Antwort Ja ist, brauchen Sie ein neues System — eines, das für Produktion ausgelegt ist, nicht für eine Präsentation.
Der Umbau kostet mehr, als manchen lieb ist. Er kostet deutlich weniger als ein Produktivsystem, das niemand versteht, weil der Berater, der es gebaut hat, längst woanders ist.
Was ein Rollout wirklich braucht
Monitoring und Alerting. Sie müssen wissen, wenn das Modell anfängt, Fehler zu machen — nicht weil jemand zufällig eine schlechte Ausgabe sieht, sondern automatisch. Konfidenz unter einem Schwellenwert: Alarm. Fehlerquote steigt: Alarm.
Human-in-the-Loop für Grenzfälle. Kein Modell liegt immer richtig. Gute Produktivsysteme legen fest, ab welchem Unsicherheitsgrad eine manuelle Prüfung ausgelöst wird. Wer das weglässt, baut ein System, das irgendwann ohne Begleitung falsche Entscheidungen trifft.
Rollback-Fähigkeit. Modell-Updates verändern Verhalten — manchmal in eine Richtung, die Sie nicht wollen. Sie müssen zurückkönnen.
Stufenweiser Rollout. Nicht Big Bang. Erst eine Abteilung, Feedback einholen, anpassen, dann weitergehen. Das klingt langsamer. Es ist in der Regel schneller — weil Sie nach einem schrittweisen Rollout nicht alles auf einmal reparieren müssen.
Lasttest vor Go-Live. Ein Demo-Nutzer ist nicht fünfzig parallele Nutzer. Testen Sie das vorher.
Warum es auch mit guter Planung straucheln kann
Manchmal ist die Planung solide — und der Rollout stockt trotzdem.
Die Mitarbeiter wurden nicht vorbereitet. Wenn jemand im Team hört, dass "KI jetzt seine Anträge prüft", ohne dass erklärt wurde, was er tun soll, wenn das Ergebnis falsch aussieht — dann wird er das System meiden. Nicht aus Sturheit, sondern weil niemand ihm gesagt hat, wie er damit umgeht. Das ist kein technisches Problem. Es ist ein Kommunikationsproblem.
Der PoC hat das falsche Problem gelöst. Manche Projekte scheitern nicht am Rollout, sondern daran, dass der Pilot von Anfang an das Falsche optimiert hat. Wenn Ihr echter Engpass in einer fünfstufigen Genehmigungskette liegt, hilft eine schnellere Rechnungsverarbeitung nur begrenzt.
Zu großer erster Schritt. Der PoC beweist ein Konzept für einen kleinen Use Case. Phase 2 deckt auf einmal den gesamten Prozess ab. Das Risiko steigt, die Komplexität auch. Machen Sie es kleiner. Machen Sie es schrittweise.
Die Frage, die entscheidet
Bevor ein Projekt in die Produktionsphase geht, stelle ich immer dieselbe Frage: Wer betreibt dieses System in zwölf Monaten? Wer ist verantwortlich, wenn etwas schiefläuft? Wer sammelt Nutzer-Feedback und entscheidet, was verbessert wird?
Wenn Sie das nicht beantworten können, ist Ihr PoC noch nicht bereit für Phase 2.
Ein erfolgreicher Pilot ist ein gutes Zeichen. Er ist kein Beleg dafür, dass das Deployment einfach wird. Wer Phase 2 als eigenständiges Projekt behandelt — mit eigenem Scope, eigenem Budget, eigenem Product Owner — der kommt zur Produktion. Wer denkt, der Pilot sei fast fertig, erzählt in zwei Jahren noch von dem eindrucksvollen Demo.
Welche Prozesse in Ihrem Unternehmen sind bereit für einen produktiven KI-Einsatz? Unser kostenloser Automations-Check gibt Ihnen in 30 Minuten eine klare Antwort.