KI vom Pilotprojekt in die Produktion: Warum die meisten Piloten stecken bleiben

Die Demo war der einfache Teil

Die meisten KI-Initiativen in Unternehmen folgen demselben Muster: Ein Pilot überzeugt in der Demo, die Führungsebene genehmigt die nächste Phase — und dann verbringt das Projekt Monate in einem Zustand zwischen tot und ausgeliefert. Den meisten Schätzungen zufolge erreicht deutlich mehr als die Hälfte aller Piloten nie die Produktion; unsere Projekterfahrung bestätigt das. Am Modell liegt es selten. Es liegt an allem, was die Demo nie überstehen musste: unordentliche Produktionsdaten, feindliche Eingaben, Kostengrenzen, Audit-Anforderungen und Nutzer, die beim Kickoff nicht dabei waren.

Die Korrektur beginnt mit einem Perspektivwechsel. Ein Pilot beweist, dass eine Fähigkeit existiert. Produktion verlangt den Nachweis, dass sich ein System unter realer Last, mit realen Daten und realen Fehlermodi akzeptabel verhält — ein Problem der Systemtechnik, nicht der Datenwissenschaft.

Use Cases nach Fehlerkosten auswählen

Die folgenreichste Entscheidung fällt, bevor eine Zeile Code geschrieben ist. Piloten, die um die beeindruckendste Demo herum gebaut werden, bleiben meist stecken; Piloten mit einem tolerierbaren Fehlermodus kommen durch. Vier Filter leisten den Großteil der Arbeit:

• Es existiert eine messbare Basislinie — Minuten pro Fall, Kosten pro Ticket, Rückstandsgröße —, damit Verbesserung eine Zahl ist und keine Meinung.
• Fehler sind korrigierbar: Ein falscher Entwurf wird geprüft, eine falsche Klassifikation nachgelagert korrigiert, und kein einzelnes Ergebnis löst eine unumkehrbare Aktion aus.
• Eine menschliche Kontrollinstanz fügt sich natürlich in den Arbeitsablauf ein, statt nachträglich aus Compliance-Gründen angebaut zu werden.
• Das Volumen ist hoch genug, dass ein Effizienzgewinn von 30–50 % die Engineering-Investition rechtfertigt.

Beachten Sie, was fehlt: Neuartigkeit. Der beste erste Produktions-Use-Case ist meist der unspektakulärste.

Die Datenbasis bestimmt die Obergrenze

Welche Architektur Sie auch wählen — Retrieval-Augmented Generation, Fine-Tuning oder strukturierte Extraktion —, die Qualitätsobergrenze setzen die Daten, nicht die Modellwahl. Drei Fundamente wiegen am schwersten. Erstens: Zugriffskontrolle muss zum Zeitpunkt des Retrievals durchgesetzt werden. Wenn ein Nutzer ein Dokument nicht öffnen darf, darf das System es auch nicht in eine Antwort zitieren können — keine Prompt-Anweisung ersetzt Berechtigungsprüfungen in der Retrieval-Schicht. Zweitens: Aktualität und Herkunft. Das System muss wissen, welche Version einer Richtlinie oder Preisliste es liest, sonst antwortet es mit voller Überzeugung aus veralteten Daten. Drittens: Der Umgang mit sensiblen Daten — Schwärzung personenbezogener Daten, Aufbewahrungsregeln, Datenresidenz — muss vor der ersten Integration konzipiert sein, denn ihn nachzurüsten bedeutet, die Pipelines neu zu bauen.

Evaluation trennt Demos von Systemen

Der stärkste Prädiktor dafür, ob ein Pilot die Produktion erreicht, ist aus unserer Sicht die Existenz eines Evaluations-Harness. Teams, die Qualität durch das Durchscrollen von Ergebnissen beurteilen, können die einzige Frage nicht beantworten, die im Review zählt: Hat diese Änderung das System besser oder schlechter gemacht?

• Bauen Sie ein Referenzdatenset aus realen Fällen auf — einige hundert Eingaben mit geprüften Soll-Ergebnissen —, bevor Sie irgendetwas optimieren.
• Führen Sie Evaluationen bei jeder Prompt-, Modell- oder Retrieval-Änderung aus, in der CI, genau wie eine Regressionstest-Suite.
• Automatisieren Sie die Bewertung, wo möglich — kalibrieren Sie automatisierte Bewerter aber regelmäßig gegen menschliche Reviews, damit die Werte aussagekräftig bleiben.
• Messen Sie Qualität auch in der Produktion, nicht nur vor dem Release: stichprobenartige menschliche Reviews und Nutzerfeedback sind Teil des Systems, kein Nachtrag.

Guardrails und Integrationsmuster

In der Produktionsarchitektur ist das Modell eine unzuverlässige externe Abhängigkeit und sollte wie eine solche integriert werden: mit Timeouts, begrenzten Wiederholungen über idempotente Operationen und einem deterministischen Fallback-Pfad für den Fall, dass das Modell ausfällt oder sich verschlechtert. Schränken Sie die Schnittstelle auf beiden Seiten ein — validieren und bereinigen Sie Eingaben, verlangen Sie schemagebundene Ausgaben, die vor der Verwendung validiert werden statt als freier Text auf gut Glück geparst zu werden, und geben Sie dem Modell den engsten Werkzeugzugriff, den der Use Case erlaubt. Ausgaben, die Aktionen auslösen — Schreibzugriffe, E-Mails, Transaktionen —, laufen durch eine Autorisierungsschicht, die die Modellausgabe als nicht vertrauenswürdige Nutzereingabe behandelt. Denn genau das ist sie.

Ein Betriebsmodell, kein Projekt

Piloten sind Projekte; Produktionssysteme sind Produkte. Jemand muss Qualität, Kosten und Incidents nach dem Go-live verantworten: Modell- und Prompt-Versionen werden fixiert und nur über Reviews geändert, die Kosten pro Anfrage werden budgetiert und überwacht, und es gibt eine Rufbereitschaft für die Nacht, in der die Leistung des Anbieters einbricht. Teams, die diese Verantwortung vor dem Go-live vergeben, behalten ihre Systeme; die anderen sehen zu, wie die Qualität driftet, bis jemand das Feature leise abschaltet.

Was einen festgefahrenen Piloten löst, ist selten ein besseres Modell. Es sind ein engerer Use Case, ein echtes Evaluations-Harness, Guardrails, die vom Fehlerfall ausgehen, und ein benannter Verantwortlicher. Nichts davon ist glamourös — aber genau das macht aus einer Demo Infrastruktur.