Ein erfolgreicher Pilot ist noch keine erfolgreiche KI-Adoption

Ein Pilot beweist ein Prinzip. Er zeigt, dass ein bestimmtes Verfahren mit bestimmten Daten für eine bestimmte Aufgabe funktioniert. Das ist eine wichtige Vorbedingung, um weitere Schritte einzuleiten – und es ist der Anfang der eigentlichen Arbeit!

Zwischen einem ersten Beweis eines Konzepts und einem operativen Routinebetrieb liegt noch eine weite Strecke. Die konkrete Planung dieses Ausbaus wird in den meisten Pilotprojekten gar nicht thematisiert. Sechs Etappen bis zum Abschluss des Projekts kosten Zeit und brauchen Aufmerksamkeit. Jede einzelne kann für sich genommen zum Abbruch des Projekts führen. Es ist daher hilfreich, sich vor Augen zu führen, was nach dem erfolgreichen Abschluss eines Pilotprojekts noch folgt!

Vor diesem Hintergrund ist einleuchtend, dass Pilotprojekte, die zu kurz gedacht und zu klein dimensioniert sind, viele Fragen offen lassen und ggf. sogar den Projekterfolg insgesamt riskieren. Es ist also sinnvoll, sich schon bei der Konzeption des Pilotprojekts entsprechende Gedanken zu machen.

1. Von Testdaten zu realen Daten

Ein Pilot basiert oft auf Daten, die zum Zwecke der Demonstration geschaffen oder gesammelt worden sind. Im realen Produktivbetrieb wird sichtbar, welche tatsächlich verarbeitet werden: oft sind die Datensätze lückenhaft oder beinhalten unerwartete Altbestände aus drei Systemgenerationen oder ähnliche Dinge. Dies sind Mehrdeutigkeiten, die im Testset fehlten und dort nicht bemerkt werden konnten.

Diese Etappe ist reine Datenarbeit, und sie dauert nicht selten länger als der Pilot selbst. Wer einen Piloten auf idealisierten Daten basieren lässt, weil es den Beweis erleichtert, der hat sich die Etappe nicht erspart, sondern nur verschoben. Und es ist nicht unwahrscheinlich, dass spätere Aufwände zum Erweitern der Lösung teurer werden – das gilt insbesondere, wenn die Problemlage nicht sofort auffällt.

Greift der Pilot hier zu kurz: Das Modell trifft auf eine Datenrealität, die es nie gesehen hat. Die Qualität fällt langsam genug, dass es nicht auffällt, bis jemand weiter hinten in der Kette eine falsche Auskunft weitergibt.

2. Vom Einzelfall zur Prozessvariante

Der Pilot implementiert einen Ablauf. In der Organisation existiert dieser Ablauf aber vielleicht in Varianten: pro Standort, pro Produktlinie, pro gewachsener Ausnahme, die vor Jahren aus gutem Grund eingeführt wurde.

Jede Variante ist eine Entscheidung. Bilden wir sie ab, vereinheitlichen wir den Prozess, oder nehmen wir sie bewusst aus? Diese Entscheidungen sind fachlich, nicht technisch, und sie brauchen Menschen, die den jeweiligen Ablauf verantworten.

Greift der Pilot hier zu kurz: Es wurde auf eine idealisierte Anforderung optimiert. Die Ausrollung des echten Projekts stößt auf Varianten, und es ist denkbar, dass die Entscheidungsbefugnisse in Bezug auf den Umgang mit den Varianten nicht geklärt sind. Nicht selten steckt die Roadmap fest, während die benötigten und unvorhergesehenen Abstimmungen laufen.

3. Von der Demo zur Betriebsfähigkeit

Während eines Pilotprojektes wird oft übersprungen, was im Regelbetrieb eingehalten werden muss: Authentifizierung, revisionssichere Protokollierung, Zugriffsgrenzen, Anbindung an die vorhandenen Datenstrecken, Abnehmer der Ergebnisse. Dazu kommt alles, was das System braucht, um beobachtbar zu sein – Überwachung, Alarmierung, ein Fallback, wenn eine neue Version schlechter ist als die alte.

Diese Arbeit ist gut verstanden und planbar. Sie ist nur meistens nicht beauftragt, weil sie im Piloten nicht vorkam.

Greift der Pilot hier zu kurz: Das Folgevorhaben braucht ein Budget, das der Erfolg des Piloten nicht automatisch rechtfertigt und das im laufenden Jahr oft nicht eingeplant worden ist.

4. Vom Einzelsponsor zur betrieblichen Verantwortung

Ein Pilot hat häufig einen Sponsor in der Organisation. Ein Regelbetrieb braucht aber eine Struktur, die die Verantwortung für den Betrieb tragen kann: für Verfügbarkeit, Kosten, Qualitätsdrift, Verhalten im Störfall. Die Abläufe müssen eingebunden sein und ein neues System muss entsprechend budgetiert sein. Es wäre nicht das erste Mal, dass eine gute Idee, die auch technisch vorbereitet worden ist, an den fehlenden organisatorischen Strukturen scheitert.

Greift der Pilot hier zu kurz: Nicht selten fängt am Ende der Pilotphase die Diskussion über die Schaffung der benötigten Struktur in der Organisation erst an. Wer wird dauerhaft zuständig sein? Wer bekommt das neue Projekt als Erweiterung der bisherigen Aufgaben? Welche Budgets werden benötigt und aus welchen Töpfen wird es finanziert?

5. Sonderfall KI: Was darf sie entscheiden?

Hier unterscheidet sich KI von klassischer Software. Ein herkömmliches System führt aus, was jemand entschieden hat. Ein KI-System liefert ein Urteil — eine Empfehlung, eine Einstufung, einen Entwurf —, und damit steht eine Frage im Raum, die vorher niemand stellen musste: Wer verantwortet dieses Urteil?

Daran hängen mehrere Festlegungen, die zusammengehören. Wer darf die Ausgabe überstimmen, und wer ist sogar verpflichtet, sie zu prüfen? Ab welcher Tragweite entscheidet zwingend ein Mensch? Wer hält das System an, wenn es erkennbar falsch liegt, und ohne wessen Zustimmung? Und wer erfährt überhaupt, dass ein Urteil maschinell zustande kam — die Betroffenen eingeschlossen?

Diese Fragen berühren Haftung, Aufsichtspflichten und in regulierten Bereichen auch Dokumentationspflichten. Bleiben sie offen, zieht jede Abteilung die Grenze anders: Die einen prüfen jede Ausgabe und verlieren den Nutzen, die anderen winken alles durch und tragen ein Risiko, das niemand bilanziert hat.

Greift der Pilot hier zu kurz: Im Piloten wurde jedes Ergebnis angesehen und beurteilt — oft informell, weil es wenige Fälle sind. In der Breite eines Regelbetriebs reicht das nicht mehr und ist nicht praktikabel. Dieser wesentliche Unterschied wird oft falsch eingeschätzt.

6. Vom Testlauf zum Dauerbetrieb

Verfügbarkeit bedeutet noch keine Nutzung, und Nutzung bzw. die Auslastung kann sich noch verändern. Menschen ändern ihre Arbeitsweise, wenn sie einem System vertrauen und auf dessen Verfügbarkeit setzen. Prozesse ändern sich oft, Verfahren werden ersetzt, Verantwortlichkeiten wechseln. Aber die KI-Technologie entwickelt sich weiter, und wenn Systeme mit neuen Modellen betrieben werden, stellt sich die Frage: Wer prüft, ob das System noch korrekt funktioniert? Wer entscheidet über die nächste Modellversion, und auf welcher Basis? Diese Qualitätssicherung hat oft keinen Termin, der eine Prüfung erzwingt — und fällt deshalb am häufigsten aus.

Greift der Pilot hier zu kurz: Piloten werden oft mit Mitarbeitern durchgeführt, die am Gelingen des Piloten interessiert sind und die das neue Verfahren gut finden. Wenn nicht definiert ist, woran Leistung gemessen werden kann, dann fehlt im Regelbetrieb oft die Aufgabe zur Qualitätsprüfung und der Maßstab, an dem sich Verschlechterung überhaupt zeigen ließe.

Das Design des Pilotprojekts hat Einfluss auf den Erfolg

Sechs Etappen, die am Ende einer Pilotphase zu bewältigen sind. Das ist keine Kritik an der Methode, die Machbarkeit über Pilotprojekte zu prüfen, aber es muss klar sein, dass Pilotprojekte hier viele Fragen offen lassen müssen. Es gibt aber gute Argumente dafür, Pilotprojekte in Erwartung der abschließenden Implementierungs- und Aufbauphase zu konzipieren.

Nicht für jedes Pilotprojekt ist der Aufwand gleich, nicht jede Strecke bis zum Regelbetrieb ist gleich lang. Ein Pilot, der den saubersten Datenausschnitt, den einfachsten Standort und die wohlwollendste Nutzergruppe wählt, beweist sein Prinzip schneller und lässt jede der sechs Etappen in voller Länge vor sich. Ein Pilot, der bewusst eine mittlere Schwierigkeit wählt – echte Daten, ein Standort mit typischen Abweichungen, Nutzende, die nicht darum gebeten haben –, braucht zwar länger und ist aufwändiger, aber er verkürzt auch alles, was danach kommt.

Praktisch heißt das: Vor dem Start festlegen, welche Schwellen für den Regelbetrieb gelten – Antwortzeit, Genauigkeitsuntergrenze, Kosten pro Aufruf, Verhalten im Fehlerfall. Die verantwortlichen Stellen schon beim Start benennen und die Organisationsstruktur schon vorbereiten, statt erst bei der Übergabe eines fertigen Projekts die Frage anzugehen, wie der Regelbetrieb gesichert werden kann. Besteht die Antwort bei einer frühen Diskussion aus Dingen, für die niemand die Zeit oder die Mittel hat, prüft der Pilot nicht die Machbarkeit in dieser Organisation. Er prüft nur, ob sich ein Demonstrator technisch herstellen lässt.

Wie gut ein Pilotprojekt am Ende dann das anschließende Projekt trägt, entscheidet sich in seiner Dimensionierung und in den Fragen, die früh beantwortet werden können: zu einem Zeitpunkt, an dem beides noch nicht viel kostet.