Das Muster wiederholt sich so zuverlässig, dass es fast langweilig ist. Ein Unternehmen startet einen KI-Piloten, die Demo beeindruckt, alle nicken. Sechs Monate später wird der Pilot leise beerdigt, die Budgetzeile verschwindet, und im Haus setzt sich die Überzeugung fest, „für unsere Branche ist KI noch nicht so weit“. Am Modell lag es selten. Am Zuschnitt des Piloten fast immer.
Branchenumfragen verorten den Anteil der KI-Piloten, die nie in Produktion gehen, beharrlich zwischen 70 % und 90 %, und was wir an festgefahrenen Piloten übernommen haben, deckt sich ungefähr mit dieser Spanne. Was die Umfragen nicht sagen: Diese Ausfälle sind vorhersehbar. Dieselben drei Designfehler erklären die meisten davon, und alle drei sind schon in der ersten Woche sichtbar, lange bevor irgendein Modell die Gelegenheit hatte, zu enttäuschen.
Drei Todesursachen
Tod durch fehlende Kennzahl. Der Auftrag lautete, „KI-Potenziale zu erkunden“, und damit hat niemand die Zahl definiert, die der Pilot bewegen soll. Ohne Kennzahl gibt es keine Ziellinie, und ohne Ziellinie erledigt ihn die nächste Budgetrunde von allein. Ein Pilot ist ein Experiment mit einer Hypothese: „Dieses Modell halbiert die Zeit der Erstprüfung bei gleicher Genauigkeit.“ Ob bestanden oder durchgefallen, Sie lernen etwas, das sich budgetieren lässt.
Erkennen lässt sich das an der Sprache des Auftrags. „Erkunden“, „das Potenzial bewerten“, „Kompetenz aufbauen“: Formulierungen, die nicht scheitern können, und was nicht scheitern kann, kann auch nicht gelingen. Zum Vergleich: „Die mediane Bearbeitungszeit von Ausnahmen bis Ende Q2 von 40 Minuten auf unter 15 senken, gemessen am Live-Volumen.“ Dieser Satz kann verlieren. Genau deshalb ist er finanzierbar, wenn er gewinnt.
Tod durch Demo-Daten. Der Pilot lief auf sauberen, ausgewählten Beispielen. In der Produktion begegnen ihm gescannte Faxe, weitergeleitete E-Mail-Ketten und der eine Lieferant, der immer noch TIFFs schickt. In der Lücke zwischen Demo-Genauigkeit und Produktionsgenauigkeit stirbt das Vertrauen, und sobald die Anwender dem Werkzeug misstrauen, holt keine Verbesserung der Genauigkeit sie zurück. Die Abhilfe ist wenig aufregend: Stellen Sie das Evaluationsset zuerst aus Ihren hässlichsten echten Fällen zusammen.
Der tiefere Grund liegt darin, dass sich diese Lücke nicht als einzelner Ausfall zeigt, sondern als Erosion. Das Werkzeug liegt bei den einfachen Fällen richtig, die das Team ohnehin bewältigt hat, und bei den schweren falsch, also genau dort, wo Hilfe gebraucht wurde. Die Anwender rechnen schnell. Nach einem Monat hat das Werkzeug einen Spitznamen, und der ist nicht liebevoll gemeint.
Tod durch fehlenden Verantwortlichen. Der Pilot gehörte einem Innovationsteam, der Ablauf gehörte dem Betrieb. Als der Pilot endete, war niemand für die Übernahme zuständig, dessen Bonus am Prozess hängt. Piloten überleben, wenn der Prozessverantwortliche nach ihnen fragt und nicht der Sponsor.
Zwei weitere Muster verdienen eine Erwähnung. Tod durch Wrapper: Der Pilot lebt in einem eigenen Tab, mit eigenem Login, in einem eigenen Fenster, und jeder Kontextwechsel, den er verlangt, kostet Akzeptanz. Erscheint der Output des Modells nicht in dem Werkzeug, in dem die Entscheidung fällt, wird er eine Woche lang aufgerufen und danach vergessen. Tod durch späte Governance: Sicherheit, Recht und Compliance erfahren im vierten Monat vom Piloten, und dann bleibt ihnen als einziger Zug, ihn zu stoppen. Legen Sie ihnen das Datenflussdiagramm in der ersten Woche vor, und sie werden zu Mitstreitern; überraschen Sie sie, werden sie zum Bremsklotz, zu Recht.
Ein Pilot ist keine kleine Demo, sondern ein kleines Produktionssystem: mit einer Kennzahl, mit echten Daten und mit einem Verantwortlichen.
Welcher Workflow einen Piloten tragen kann
Die Hälfte des Erfolgs entscheidet sich, bevor der erste Anbieter angerufen wird, nämlich bei der Wahl des Workflows. Gute Kandidaten teilen vier Eigenschaften. Volumen: Die Aufgabe fällt mehrere hundert Mal im Monat an, sodass Gewinne messbar werden und sich Trainingssignal ansammelt. Billige Prüfbarkeit: Ein Mensch kann den Output mit wenig Aufwand kontrollieren, etwa beim Zusammenfassen, Klassifizieren, Extrahieren und Entwerfen, im Unterschied zu Aufgaben, deren Prüfung so viel kostet wie die Arbeit selbst. Vorhandene Daten: Die historischen Fälle für ein Evaluationsset liegen bereits in einem System und nicht in den Köpfen zweier Veteranen. Schmerz: Die Menschen, die die Aufgabe heute erledigen, hassen ihren schlimmsten Teil, weil ihre Motivation der Akzeptanzmotor ist, den kein Rollout-Plan ersetzt.
Die schlechten Kandidaten sind ebenso leicht zu erkennen. Alles Sicherheits- oder Compliance-Kritische als erstes Projekt, nicht weil KI dort nicht helfen könnte, sondern weil das erste Projekt das Vertrauensbudget der Organisation setzt und ein sichtbarer früher Fehlschlag in einem heiklen Ablauf es vollständig aufbraucht. Alles mit weniger als 100 Fällen im Monat, wo die Statistik Signal nie von Glück trennen wird. Und die Lieblingsdemo des Geschäftsführers von einer Konferenz, die zwar Rückendeckung hat, aber selten das Volumen, die Daten oder den Verantwortlichen. Nehmen Sie im Zweifel den langweiligen, hochvolumigen, verhassten Workflow.
Der Machbarkeits-Sprint, Schritt für Schritt
Der zweiwöchige Sprint, mit dem jedes unserer KI-Projekte beginnt, hat eine feste Form, und jeder Schritt darin existiert, weil sein Auslassen schon jemanden teuer zu stehen kam. Am ersten und zweiten Tag sammeln wir das Evaluationsset: 100 bis 200 echte Fälle aus dem Live-Volumen, wobei die Anwender zeigen, welche schwer sind und warum. Nicht die Fälle, die der Sponsor weiterleitet, sondern die, vor denen das Team sich fürchtet. Am dritten und vierten Tag vermessen wir die Menschen als Basislinie: Wie lange dauert die Aufgabe heute, was kostet sie, wie hoch ist die Fehlerrate? Ohne diese Zahl kann der Pilot später nichts beweisen.
In der mittleren Woche messen wir die Kandidatenmodelle am Evaluationsset und bauen die Fehlertaxonomie auf: nicht nur „87 % genau“, sondern welche 13 % danebenliegen und ob sich die Fehler an einer billigen Stelle häufen (seltene Dokumenttypen, die man an Menschen weiterleiten kann) oder an einer fatalen (die wertvollsten Fälle). An den letzten Tagen kalkulieren wir die Stückkosten, also die Kosten pro Fall bei Produktionsvolumen einschließlich der menschlichen Prüfung, die das Konfidenz-Routing auslöst, und schreiben das Go/No-Go-Memo. Rund ein Drittel unserer Sprints endet mit einem No-Go, und diese Memos haben Kunden mehr Geld gespart als manches System, das wir in Betrieb genommen haben.
Drei, die es geschafft haben
Vertragsprüfung in einer Kanzlei. Der Auftrag benannte eine einzige Zahl: die Zeit der Erstprüfung. Das Evaluationsset entstand aus den eigenen früheren Verträgen der Kanzlei, gerade auch aus den unordentlichen, und wurde anhand der früheren Anmerkungen der Partner bewertet. Die Anwälte sahen zu jeder Klausel die Konfidenz des Modells und konnten Vorschläge mit einem Klick ablehnen, und jede Ablehnung floss zurück in die Evaluation. Die Nutzung wurde nicht angeordnet; sie stellte sich ein, weil das Werkzeug den lästigsten Teil der Arbeit verkürzte.
Ausnahmen-Triage bei einem Händler. Statt das Modell auf den gesamten Bestellablauf zu richten, richtete man es allein auf die Ausnahmen, also auf die 4 % der Bestellungen, die 60 % der Zeit des Teams verschlangen. Konfidenz-Routing hieß hier: Das Modell erledigte die Routinefälle und eskalierte die seltsamen. An niemandes Aufgabe änderte sich etwas, außer an der schlimmsten Stunde davon.
Bedarfsprognose in der Einsatzplanung. Das vorherige „KI-Dashboard“ war ein Jahr lang ignoriert worden. Die neue Version setzte die Prognose in das Planungswerkzeug selbst, genau in den Moment der Zusage, und wies die Fehlerspanne des Modells offen aus. Die Disposition überstimmte sie nach Belieben, und die Überstimmungsquote wurde selbst zur Akzeptanzkennzahl. Sie fiel Monat für Monat.
Was die drei Überlebenden verbindet, ist bemerkenswert schlicht. Keiner richtete KI auf eine ganze Tätigkeit, sondern jeder auf deren schlimmsten Teil. Alle drei zeigten ihre Unsicherheit, statt sie zu verstecken, sodass die Menschen ihr Vertrauen kalibrieren konnten, statt es zu verlieren. Und in allen drei Fällen gehörte die Kennzahl denen, die die Arbeit machen, und nicht einer Folie. Das Muster ist in seiner Einfachheit fast peinlich, es wird nur selten befolgt: „Die Abteilung transformieren“ gibt ein besseres Kickoff-Meeting ab als „die schlimmste Stunde des Dienstags reparieren“.
Konfidenz-Routing: das Muster, das KI einsatzfähig macht
Wenn ein einziges Engineering-Muster ausgelieferte Systeme von eingemotteten trennt, dann dieses. Jeder Modell-Output trägt ein Konfidenzsignal, und das System routet danach. Hohe Konfidenz: direkt durch, protokolliert. Mittlere Konfidenz: in die Queue zur menschlichen Prüfung, vorausgefüllt, ein Tastendruck zur Freigabe. Niedrige Konfidenz oder ein Falltyp, den das Evaluationsset nie gesehen hat: vollständig eskalieren und die Lücke markieren. Die Schwellenwerte sind keine technischen, sondern kaufmännische Entscheidungen, denn sie bilden ab, wie teuer ein Fehler ist, und bei einem Marketing-Entwurf liegen sie anders als bei einer Zahlungsanweisung.
Das Routing erledigt drei Aufgaben auf einmal. Es begrenzt den Schaden, den ein Modellfehler anrichten kann, und macht das System damit vor einem Risikoausschuss vertretbar. Es erzeugt gelabelte Trainingsdaten als Nebenprodukt der normalen Arbeit, weil jede Freigabe und jede Korrektur die nächste Evaluationsrunde schärft. Und es gibt der Akzeptanz einen Verlauf: Das Team sieht Fall für Fall zu, wie sich die Maschine Vertrauen verdient, statt es vorab gewähren zu müssen. So eingeführte Systeme werden mit der Zeit autonomer, mit Belegen bei jedem Schritt. Systeme, die als „vollautomatisch“ eingeführt werden, schaltet jemand beim ersten sichtbaren Fehler ab.
Was ein Pilot kosten sollte
Ein Pilot, der nicht billig scheitern kann, wird gar nicht erst scheitern dürfen: Er wird zum Erfolg erklärt und leise nicht benutzt, was schlimmer ist. Die Kostenstruktur sollte deshalb der Entscheidungsstruktur folgen. Ein Machbarkeits-Sprint wird nach Wochen bepreist, der Produktionsaufbau nach Meilensteinen, von denen jeder etwas Überprüfbares liefert, und die laufenden Kosten werden vor dem Go-live pro Fall modelliert, statt auf der ersten Rechnung aufzutauchen. Modellnutzung ist ein variabler Kostenblock, und Workflows mit schweren Dokumenten oder langen Kontexten können bei Produktionsvolumen überraschen; der Stückkosten-Schritt im Sprint sorgt dafür, dass die Überraschung in einer Tabelle passiert.
Hüten Sie sich auch vor dem umgekehrten Fehler, dem Piloten, der zu klein ist, um irgendetwas zu beweisen. Ein Wochenend-Prototyp auf zehn handverlesenen Fällen produziert genau ein Artefakt, nämlich eine irreführende Demo. Wenn ein Workflow einen Piloten wert ist, ist er auch eine saubere Basislinie und eine Evaluation auf echtem Volumen wert. Der kleinste ehrliche Pilot ist kleiner, als die meisten Unternehmen fürchten, und größer als ein Hackathon: Wochen statt Tage, mehrere hundert Fälle statt zehn.
Was Sie nach dem Go-live messen
Die Pilotkennzahl beantwortet die Frage, ob es im ersten Monat funktioniert hat. Für die Produktion brauchen Sie ein Dashboard, das die Frage nach dem zwölften Monat beantwortet, und die interessanten Zahlen sind Verhaltenszahlen. Die Überstimmungsquote: fallend ist gesund, steigend bedeutet Drift in den Daten, im Modell oder im Vertrauen des Teams. Der Eskalationsmix: Wächst die Queue der menschlichen Prüfung, hat sich entweder das Volumen verschoben oder das Modell deckt es nicht mehr ab. Die Stückkosten pro Fall, weil sich Modellpreise und Nutzungsmuster beide bewegen. Und die Genauigkeit auf einer wechselnden Stichprobe aus Live-Fällen, neu bewertet am Evaluations-Framework, denn die Welt, an der Ihr Modell letztes Jahr gemessen wurde, ist nicht die Welt, in der es heute läuft.
Das ist zugleich die ehrliche Antwort auf die Frage, wann ein KI-Projekt fertig ist: nie ganz. Die laufenden Kosten sind allerdings klein, budgetierbar und langweilig, wie die Wartung jedes anderen Produktionssystems auch. Nicht akzeptabel ist die Alternative, für die sich die meisten gescheiterten Projekte entschieden haben: ausliefern, aufhören zu messen und von einem verärgerten Kunden erfahren, dass das Modell seit März leise danebenliegt.
Geben Sie den Zahlen einen festen Termin, sonst überleben sie das Quartal nicht. Ein monatlicher Termin von 30 Minuten mit dem Prozessverantwortlichen, einem Entwickler und dem Dashboard genügt: was sich bewegt hat, was gedriftet ist, welche Eskalationen neu waren und welche Verbesserung im kommenden Monat ansteht. Das Ritual zählt mehr als das Werkzeug, denn ein Dashboard, auf das niemand planmäßig schaut, ist nur ein Screenshot mit Hosting-Kosten. Halten Sie außerdem schriftlich fest, was jede Runde entschieden hat: Spätestens beim dritten Modellwechsel oder der dritten verschobenen Schwelle entscheidet dieses Protokoll darüber, ob eine Organisation lernt oder ein Team zum zweiten Mal rät.
Die Checkliste
Eine Kennzahl, im Auftrag benannt, die sichtbar scheitern kann. Ein Evaluationsset aus Ihren hässlichsten echten Fällen, nicht aus Ihren schönsten. Ein Prozessverantwortlicher, der den Piloten will, statt eines Sponsors, der ihn finanziert. Output in dem Werkzeug, in dem die Entscheidung fällt, und nicht in einem weiteren Tab. Sicherheit und Compliance in der ersten Woche mit am Tisch. Konfidenz-Routing an Menschen von Anfang an, mit Schwellen nach den Kosten eines Fehlers. Ein Machbarkeits-Sprint vor der Umsetzung, damit die Go/No-Go-Entscheidung Wochen kostet statt Quartale. Und ein Dashboard nach dem Launch, das jemand tatsächlich verantwortet. Mehr Unterschied ist zwischen einem Piloten und einer Pressemitteilung nicht.