KI-Pilot erfolgreich? Die Stoppuhr läuft bis zur Freigabe

Die KI braucht zwei Minuten. Der Mensch brauchte vorher zwanzig. Auf der Folie steht: 90 Prozent Zeitersparnis. Alle sind begeistert.

Dann öffnet jemand das Ergebnis.

Eine Zahl stimmt nicht. Eine Quelle fehlt. Ein Absatz klingt hervorragend, sagt aber etwas anderes als das Ausgangsdokument. Also nachlesen, vergleichen, korrigieren. Und weil die nächste Ausgabe wieder anders ausfällt, auch beim nächsten Mal nachlesen, vergleichen, korrigieren.

Das ist eine erfundene Szene. Aber sie zeigt sehr gut, welche Frage eine schöne KI-Demo offenlässt: Wie lange dauert es, bis die Arbeit wirklich erledigt ist?

Mich interessiert an einem KI-Piloten genau dieser Moment nach dem Applaus. Dann, wenn aus einer beeindruckenden Ausgabe ein Ergebnis werden muss, für das jemand die Hand hebt und sagt: Ja. Damit können wir arbeiten.

Die Demo hört auf, bevor die Arbeit fertig ist

Eine Demo darf zeigen, was möglich ist. Ein Pilot muss herausfinden, ob es unter Deinen Bedingungen sinnvoll funktioniert. Das sind zwei unterschiedliche Aufgaben. Wenn Du beides vermischst, bekommt die Begeisterung einen Messwert und sieht plötzlich aus wie eine belastbare Investitionsentscheidung.

„Wir wollen mal schauen, was KI bei uns kann“ ist deshalb für mich kein ausreichender Pilotauftrag. Für einen Workshop reicht das. Für ein Projekt, das anschließend über Budget, Prozesse oder Personal entscheiden soll, ist es zu ungenau.

Nimm eine konkrete Aufgabe: Aus einem Gesprächsprotokoll soll ein Entwurf für ein Kundenangebot entstehen. Dann lautet die Frage nicht, ob die KI ein Angebot schreiben kann. Natürlich kann sie Text produzieren, der wie ein Angebot aussieht. Die Frage ist, ob Dein Vertrieb damit schneller zu einem fachlich korrekten, freigegebenen Angebot kommt.

Das Angebot muss die vereinbarten Leistungen enthalten. Es darf keine Zusagen erfinden. Preise und Termine müssen stimmen oder als ungeklärt erkennbar sein. Und der Mensch, der es prüft, muss diese Dinge mit vertretbarem Aufwand feststellen können. Eine elegante Formulierung heilt keine falsche Lieferzusage.

Ich würde einen Piloten auf eine Frage verpflichten: Welche Entscheidung können wir danach besser treffen als vorher?

Zum Beispiel: Sollen wir diese Unterstützung für genau diese Angebotsart weiterentwickeln? Dafür brauchst Du keinen vollständigen Zukunftsplan. Du brauchst eine begrenzte Aufgabe, überprüfbare Erwartungen und die Bereitschaft, auch ein Nein zu akzeptieren.

Die Stoppuhr läuft bis zur Freigabe

Rechnen wir das einmal durch. Die folgenden Zahlen sind ein hypothetisches Beispiel, keine Projektergebnisse und kein Versprechen.

Ein Vorgang braucht bisher zwanzig Minuten: zwei für die Vorbereitung, zwölf für den Entwurf und sechs für die Prüfung einschließlich Korrekturen. Mit KI dauert die Vorbereitung drei Minuten, die Ausgabe zwei, die Prüfung sieben und die anschließende Korrektur drei. Macht fünfzehn Minuten. In diesem Beispiel laufen die Schritte nacheinander; gemessen wird die Durchlaufzeit bis zum fertigen Ergebnis.

Der Entwurf braucht damit rund 83 Prozent weniger Zeit. Der gesamte Vorgang aber nur 25 Prozent. Das kann sich trotzdem lohnen. Es ist bloß eine andere Geschichte als die auf der ersten Folie.

Bei hundert Vorgängen pro Monat summiert sich die kürzere Durchlaufzeit auf fünfhundert Minuten, also acht Stunden und zwanzig Minuten. Das ist noch keine gewonnene Arbeitszeit: Wenn die Person während der zweiminütigen KI-Ausgabe etwas anderes erledigen kann, wäre sie in diesem Beispiel dreizehn statt zwanzig Minuten gebunden. Rechnerisch wären das elf Stunden und vierzig Minuten pro Monat. Fallen zehn Stunden Betreuung des neuen Ablaufs an, bleiben eine Stunde und vierzig Minuten. Toolkosten und Einrichtung wären noch gar nicht berücksichtigt. Bei tausend vergleichbaren Vorgängen pro Monat sähe dieselbe Rechnung deutlich anders aus.

Genau deshalb gehören Fallzahl und Gesamtaufwand in die Rechnung. Gesparte Minuten sind außerdem nicht automatisch gesparte Personalkosten. Vielleicht wird ein Angebot früher fertig. Vielleicht bekommt das Team Luft für schwierige Kundenfragen. Das kann wertvoll sein. Es sollte dann aber auch so benannt werden.

Ich würde zwei Uhren führen: die gesamte Durchlaufzeit bis zum freigegebenen Ergebnis und die tatsächlich gebundene Arbeitszeit der Menschen. Ein Modell kann lange rechnen, während jemand anderes arbeitet. Umgekehrt kann eine schnelle Ausgabe intensive Aufmerksamkeit verlangen. Wer beides in eine einzige Zahl wirft, übersieht entweder Wartezeiten oder Personalaufwand.

Und bitte nicht nur die gelungenen Vorgänge zählen. Wenn ein Entwurf verworfen und die Aufgabe anschließend manuell erledigt wird, gehört dieser Aufwand dazu. Sonst misst Du die Geschwindigkeit Deiner besten Beispiele statt die Leistung Deines Arbeitsablaufs. Wie leicht ein einzelner beschleunigter Schritt den Blick auf das Ganze verstellt, beschreibe ich ausführlicher im mythischen KI-Monat.

Gib dem Piloten Fälle, die ihm widersprechen dürfen

Wenn Du die Testfälle nach der Demo auswählst, hast Du ein Problem. Du weißt dann bereits, womit die KI gut aussieht. Die Versuchung ist groß, genau solche Beispiele zu nehmen und den Rest als Sonderfall zu behandeln.

Ich würde zuerst mit den Menschen sprechen, die den Vorgang heute erledigen. Welche Fälle kommen häufig vor? Welche kosten besonders viel Zeit? Wo ist ein Fehler ärgerlich, wo gefährlich? Beim Angebotsentwurf wären das etwa ein klares Standardgespräch, ein unvollständiges Protokoll und widersprüchliche Angaben zur Leistung. Der letzte Fall darf nicht einfach aus dem Test verschwinden, weil er der KI Schwierigkeiten macht.

Trenne dabei zwei Sammlungen: Fälle, an denen Du den Ablauf entwickelst, und Fälle für die abschließende Prüfung. Wer an denselben Beispielen optimiert und Erfolg misst, weiß am Ende vor allem, dass er diese Beispiele gut bearbeiten kann. Neue Fälle können eine andere Geschichte erzählen.

Für den Vergleich braucht es den bisherigen Ablauf unter fairen Bedingungen. Etwa zwei vergleichbare Fallgruppen, die zufällig auf Bearbeitung mit und ohne KI verteilt werden. Lass nicht ausschließlich die begeisterten KI-Profis die neue Variante testen und ausschließlich gestresste Neulinge die alte. Und wenn dieselbe Person dieselbe Aufgabe zweimal erledigt, kann sie beim zweiten Mal vom ersten Durchgang profitieren. Das ist kein KI-Effekt.

Für die fachliche Bewertung hilft es, die Herkunft eines Ergebnisses zu verbergen, soweit das praktisch möglich ist. Ein prüfender Kollege soll beurteilen, ob das Angebot stimmt, nicht ob er grundsätzlich für oder gegen KI ist. Dafür braucht er Kriterien, die mehr leisten als „wirkt professionell“.

• Inhalt: Sind vereinbarte Leistungen vollständig und korrekt wiedergegeben?
• Grenzen: Werden fehlende Angaben sichtbar gemacht, statt plausibel ergänzt?
• Verwendbarkeit: Wie viel Prüfung und Korrektur braucht das Ergebnis bis zur Freigabe?

Es geht dabei um den Ablauf aus Mensch und KI. Wenn ein erfundener Termin nur durch sorgfältige Kontrolle auffällt, hat diese Kontrolle eine Funktion und einen Preis. Fällt er nicht auf, ist „der Mensch prüft ja noch“ keine ausreichende Absicherung.

Diese Nähe zur späteren Arbeit ist auch im NIST AI Risk Management Framework angelegt: MEASURE 2.1 verlangt dokumentierte Testsets und Messgrößen, MEASURE 2.3 die Bewertung unter Bedingungen, die dem geplanten Einsatz ähneln. Daraus folgt keine universelle Erfolgsquote. Für mich folgt daraus: Ein Pilot gehört an echte Aufgaben und klare Kriterien gebunden.

Ein guter Pilot darf mit einem Nein enden

Bevor das erste Ergebnis da ist, gehört die Entscheidungsregel auf den Tisch. Wie viel Entlastung brauchst Du? Welche Fehler darf es nicht geben? Wer muss den Ablauf im Alltag verantworten können? Wenn Du die Grenze erst nach dem Test ziehst, wird sie erstaunlich oft genau dort landen, wo Dein Ergebnis gerade noch darüberkommt.

Ich würde die Abschlussentscheidung auf eine Seite reduzieren. Kein Siegertreppchen für Modelle, sondern eine nüchterne Zuordnung:

Was der Test zeigt	Was daraus folgt
Qualität stimmt, Entlastung ist relevant, Zuständigkeit steht.	Den nächsten Schritt zum Betrieb konkret planen.
Ein klar begrenztes Problem verhindert den Nutzen.	Genau dieses Problem ändern und gezielt erneut prüfen.
Prüfung frisst den Gewinn oder kritische Fehler bleiben unbeherrscht.	Den Ansatz beenden oder auf eine einfachere Aufgabe begrenzen.
Zu wenige oder zu einseitige Fälle.	Keine Erfolgsaussage; die offene Frage mit passenden Fällen prüfen.

Bei kleinen Fallzahlen würde ich die Unsicherheit ausdrücklich benennen. Zwanzig Angebote ohne kritischen Fehler beweisen nicht, dass kritische Fehler ausgeschlossen sind. Ein Mittelwert kann außerdem verschweigen, dass neun Standardfälle schneller gehen und der zehnte Ausnahmefall plötzlich eine Stunde braucht. Schau auf die Verteilung und auf die Ausnahmen.

Ein Abbruch kann deshalb ein sehr gutes Ergebnis sein. Wenn Du rechtzeitig herausfindest, dass sich ein Ansatz nicht lohnt, hast Du etwas gelernt und eine größere Fehlinvestition vermieden. Problematisch wird es, wenn „Pilot“ nur das höfliche Wort für eine bereits beschlossene Einführung ist.

Auch ein positives Ergebnis ist noch kein Betriebsmodell. Im Test hilft jemand beim Prompt, sortiert Dokumente und greift ein, sobald etwas klemmt. Im Alltag muss geklärt sein, wer das übernimmt, wer auf welche Daten zugreifen darf und was bei einem Ausfall passiert. Nach Änderungen am Modell oder am Ablauf braucht es erneute Prüfungen. Mein Beitrag zu Harness Engineering erklärt, warum diese Umgebung so viel zur Verlässlichkeit beiträgt.

Ich will keine Piloten, die am Ende beweisen, dass KI beeindruckend ist. Das wissen wir längst. Ich will Piloten, nach denen Du genauer weißt, was Du einführen solltest, was noch Arbeit braucht und was Du Dir sparen kannst.