Die meisten KI-Pilotprojekte scheitern nicht an einer falschen Idee. Sie scheitern, weil niemand die Mechanik gebaut hat, mit der ein probabilistisches System unbeaufsichtigt in einem Workflow laufen kann, auf den es ankommt. Eine Demo beweist, dass das Modell die Aufgabe einmal lösen kann. Produktion beweist, dass es sie zehntausendmal löst, ohne dass ein Mensch jeden Fehler abfängt.
Den Abstand zwischen beiden behandeln wir als fünf Gates, also fünf Prüfpunkte. Jedes beantwortet eine Frage, die früher oder später jemand stellt, bevor das System unbeaufsichtigt laufen darf. Jedes ist früh günstig zu bauen und spät teuer nachzurüsten. Fehlt auch nur eines, bleibt der Pilot stecken, und zwar meist nicht im Engineering, sondern im Review-Termin, in dem niemand die Frage beantworten kann, für die dieses Gate da ist.
Die fünf Gates
| Gate | Die Frage, die es beantwortet | Woran Sie merken, dass es fehlt |
|---|---|---|
| Evals | Ist es gut genug, und hat diese Änderung es besser gemacht? | Jedes Release ist eine Diskussion nach Bauchgefühl |
| Observability | Was hat es in diesem Fall tatsächlich getan? | Sie erfahren es von einem verärgerten Kunden |
| Leitplanken | Was ist das Schlimmste, das es tun kann? | Es kommt nie durch die Prüfung von IT-Sicherheit und Rechtsabteilung |
| Rollback | Was tun wir, wenn sich das Modell unter uns ändert? | Ein Update des Anbieters macht es unbemerkt kaputt |
| Verantwortung | Wessen Kennzahl ist das? | Ein Gremium genehmigt es, und niemand bringt es in Betrieb |
Gate 1: Eine Eval-Suite, die misst, worauf es Ihnen ankommt
Eine Eval-Suite ist ein fester Satz echter Fälle mit bekannten richtigen Ergebnissen, der bei jeder Änderung automatisch bewertet wird. Keine Stichprobe und kein Sieht diese Ausgabe richtig aus?, sondern eine Zahl, die Sie mit der Zahl der Vorwoche vergleichen können.
Ohne sie ist Qualität Ansichtssache. Jede Anpassung am Prompt wird zur Debatte, niemand kann sagen, ob die Änderung geholfen hat, und niemand will ein Release freigeben, das sich nicht messen lässt. Das ist kein Problem des Modells. Es fehlt der Maßstab. Was Sie nicht bewerten können, können Sie nicht ausliefern. Deshalb steht dieses Gate für uns vor allen anderen, und deshalb haben wir ihm einen eigenen Artikel (Englisch) gewidmet.
Dieses Gate haben Sie passiert, wenn Sie ein Modell austauschen oder einen Prompt umschreiben können und innerhalb von Minuten wissen, ob sich die Qualität verändert hat und in welche Richtung.
Gate 2: Observability, die zeigt, was das System tatsächlich getan hat
Kein aggregiertes Dashboard, sondern Forensik für jeden einzelnen Lauf: zu jeder Ausführung die Eingabe, der abgerufene Kontext, die aufgerufenen Tools, das Ergebnis, die Kosten und die Dauer.
Probabilistische Systeme versagen leise. Ein deterministischer Fehler wirft eine Fehlermeldung. Ein Modell liefert etwas leicht Falsches, mit voller Überzeugung, und macht weiter. Ohne Traces bleiben diese Fehler unsichtbar, bis sie sich zu etwas summieren, das einem Menschen auffällt. So entdecken Teams einen Monat fehlerhafter Ausgaben in einer einzigen Support-Eskalation.
Dieses Gate haben Sie passiert, wenn jemand die Frage Warum hat es das in genau diesem Fall am letzten Dienstag getan? in weniger als fünf Minuten beantworten kann.
Gate 3: Leitplanken, die den schlimmsten Fall begrenzen
Ausdrückliche Grenzen dafür, worauf der Agent zugreifen darf, was er ausgeben darf, was er sagen darf und wann er an einen Menschen übergeben muss. Diese Grenzen werden im Code durchgesetzt. Eine höfliche Bitte im Prompt reicht nicht.
An diesem Gate scheitern die meisten Pilotprojekte tatsächlich, und selten liegt es am Engineering. Es liegt an der Sicherheitsprüfung, der juristischen Prüfung und dem Gespräch über Risiken, das nie zu einem Ergebnis kommt, weil niemand den möglichen Schaden in einem Satz benennen kann. Ein Agent, der sich wahrscheinlich richtig verhält, bekommt keinen Schreibzugriff auf ein Produktivsystem, und so bleibt er für immer eine Demo. Die Lösung ist, den schlimmsten Fall klein und ausdrücklich zu machen, statt zu argumentieren, dass er unwahrscheinlich ist.
Dieses Gate haben Sie passiert, wenn Sie in einem Satz sagen können, was das System schlimmstenfalls anrichten kann, und die Person, die für dieses Risiko verantwortlich ist, damit einverstanden ist.
Gate 4: Ein Rollback-Pfad für den Fall, dass sich die Grundlage ändert
Fest gepinnte Modellversionen, versionierte Prompts und Konfigurationen und die Möglichkeit, jederzeit zu einem bekannten funktionierenden Stand zurückzukehren. Die Modelle unter Ihrem System sind keine stabile Infrastruktur. Anbieter stellen sie ein, justieren sie nach und liefern Verhaltensänderungen nach ihrem Zeitplan aus, nicht nach Ihrem.
Teams, die das auslassen, merken es jedes Mal auf dieselbe Weise: Etwas, das monatelang funktioniert hat, wird über ein Wochenende schlechter, und es gibt keine frühere Konfiguration, auf die man zurückgehen könnte, weil die aktuelle direkt überschrieben wurde. Aus dem Zurücksetzen wird ein erneutes Herleiten.
Dieses Gate haben Sie passiert, wenn ein Rollback ein Deployment ist und kein Neuaufbau.
Gate 5: Eine namentlich benannte Person, die für die Kennzahl verantwortlich ist
Eine Person. Eine Kennzahl. Kein Sponsor, keine Arbeitsgruppe, kein Dienstleister, sondern eine namentlich benannte Person, deren Arbeit davon abhängt, ob sich die Zahl bewegt.
Das ist das am wenigsten technische Gate und das mit der größten Vorhersagekraft. Gremien sind gut darin, KI-Projekte zu genehmigen, und strukturell nicht in der Lage, sie in Betrieb zu bringen: Verantwortung, die sich auf acht Personen verteilt, spürt niemand, wenn das Projekt an einem Donnerstag um 18 Uhr noch einen letzten Anschub braucht. Wir nennen dieses Muster die Steering-Committee Tax, den Preis des Lenkungsausschusses. Es ist das verlässlichste Signal, das wir für ein Programm kennen, das ins Stocken gerät.
Dieses Gate haben Sie passiert, wenn Sie die Person und die Kennzahl nennen können, ohne etwas nachzuschlagen.
Warum das meiste in den ersten 90 Tagen schiefgeht
Das Scheitern entscheidet sich meist lange, bevor es jemand bemerkt: im ersten Quartal, in drei Schritten, die im jeweiligen Moment alle vernünftig wirken.
Monat eins: Die Strategie ist eine Liste von Anwendungsfällen. Ein Workshop liefert fünfzehn mögliche Workflows, sortiert nach Begeisterung, und ausgewählt wird der eindrucksvollste statt des am besten umsetzbaren. Niemand fragt, welcher der fünfzehn heute schon messbare Kosten verursacht. Also gibt es später keine Zahl, an der sich jemand messen lassen muss.
Monat zwei: Niemand ist für die Kennzahl verantwortlich. Das Projekt hat einen Sponsor, einen Dienstleister und einen Lenkungsausschuss. Das ist nicht dasselbe wie eine namentlich benannte Person, deren Arbeit davon abhängt, dass sich eine Zahl bewegt. Gremien können ein KI-Projekt genehmigen, zum Laufen bringen können sie es nicht. Das ist die Steering-Committee Tax, und sie sagt ein stockendes Programm verlässlicher voraus als alles andere.
Monat drei: Die Demo überzeugt und definiert stillschweigend den Erfolg um. Sie funktioniert im Idealfall, der Raum ist beeindruckt, und das Ziel verschiebt sich unbemerkt von in Betrieb zu vorgeführt. Von hier an scheitert das Projekt nicht, es kommt nur nie zum Abschluss. Deshalb haben 95 % der Pilotprojekte mit generativer KI in Unternehmen keinen messbaren Effekt auf die Gewinn- und Verlustrechnung (MIT Project NANDA, 2025), und Gartner erwartet, dass mehr als 40 % der Projekte mit agentischer KI bis Ende 2027 eingestellt werden (Gartner, 2025).
Die Gegenmaßnahme ist unspektakulär: Wählen Sie einen Workflow, der heute schon jemanden Geld kostet, schreiben Sie einen Namen an die Kennzahl und definieren Sie fertig als unbeaufsichtigten Betrieb in Produktion, nicht als Demo, die einen Raum beeindruckt hat. Aus genau diesem Grund beginnen unsere Projekte mit einem zweiwöchigen Sprint zum Festpreis, an dessen Ende etwas in Betrieb ist und kein Foliensatz. Wenn Sie noch davor stehen, ist das AI Readiness Assessment (Englisch) der günstigere erste Blick.
An welchem Gate hängen Sie fest?
Festgefahrene Pilotprojekte fühlen sich von innen gleich an. Das Symptom weist aber meist auf genau ein fehlendes Gate:
- Wir justieren ständig nach und können nicht sagen, ob es besser wird. Das ist Gate 1: Ihnen fehlt der Maßstab.
- Es funktioniert, außer wenn es nicht funktioniert, und wir können den Fehler nicht reproduzieren. Das ist Gate 2: Ihnen fehlen Traces.
- Das Engineering ist seit Monaten fertig, aber es steckt noch in der Prüfung. Das ist Gate 3: Niemand kann den schlimmsten Fall begrenzen.
- Früher hat es funktioniert, und dann hat sich etwas geändert. Das ist Gate 4: Ihnen fehlt ein bekannter funktionierender Stand, zu dem Sie zurückkehren können.
- Alle sind sich einig, dass es wichtig ist, und nichts bewegt sich. Das ist Gate 5: Keine einzelne Person ist für die Kennzahl verantwortlich.
Diese Diagnose ist wichtiger, als sie klingt, denn die Gates sind in der Reihenfolge oben günstig und in jeder anderen teuer. Wer Evals bei einem System nachrüstet, das schon in Produktion läuft, muss die richtigen Ergebnisse aus Fällen rekonstruieren, die niemand aufgezeichnet hat. Wer Observability erst nach einem Ausfall einführt, untersucht etwas, von dem es keine Spur gibt. Fast jede teure KI-Rettung, zu der wir gerufen werden, ist ein Team, das den Nachrüstpreis für ein Gate zahlt, das am Anfang Tage gekostet hätte.
Nichts davon ist exotisch. Es ist dieselbe Disziplin, die vor einem Jahrzehnt aus Web-Demos zuverlässige Software gemacht hat, angewandt auf einen Stack, der nun einmal nicht deterministisch ist. Den Unternehmen, die in der Pilot-Falle stecken, fehlt es nicht an Ehrgeiz. Ihnen fehlen die Gates, und genau die baut ein Projekt mit Gigabit Agents ein.
