Ein AI-Assistent soll Angebote schneller vorbereiten. Im Pilot wurden hundert Fälle geprüft, kein Fehler wurde gefunden. Reicht das, um ihn in den Vertrieb zu geben? Nehmen wir diese Situation als illustratives Beispiel, nicht als Fassbender-Kundenfall.
Die Zahl klingt beruhigend. Sie sagt aber noch nicht, welche Fehler gesucht wurden, wer sie erkennen konnte und ob die geprüften Fälle die künftige Arbeit abbilden. Eine falsche Lieferzusage ist etwas anderes als ein unsauber formulierter Absatz. Wer beides unter „bestanden“ zusammenfasst, schafft keine belastbare Entscheidungsgrundlage.
Ich würde eine Freigabe nicht auf „100 Tests, null Fehler“ stützen, sondern auf den belegten Einsatzbereich und die Grenzen dieses Nachweises. Das schützt nicht nur vor Fehlentscheidungen. Es verhindert auch, dass ein Team einen nützlichen, begrenzten Einsatz unnötig zurückhält, weil es absolute Sicherheit nachweisen soll.
Was hundert fehlerfreie Fälle tatsächlich belegen
Eine ausdrücklich illustrative Modellrechnung macht die Grenze sichtbar. Angenommen, hundert unabhängig ausgewählte Fälle wurden bei unverändertem Systemzustand nach einer klaren Fehlerdefinition geprüft. Jeder Fall besitzt im statistischen Modell dieselbe Fehlerwahrscheinlichkeit. Für eine Übertragung auf den Betrieb muss die Auswahl außerdem dessen relevante Fälle repräsentieren.
Bei null beobachteten Fehlern liegt die einseitige exakte 95%-Obergrenze für den Fehleranteil bei rund 3 %. Grundlage ist die Binomialverteilung; die Berechnung ergibt etwa 2,95 %. NIST beschreibt die Methode für exakte Konfidenzgrenzen. Das ist keine gemessene AI-Fehlerquote und kein erwarteter Fehleranteil Ihres Systems. Die 95 % bezeichnen das Konfidenzniveau des Verfahrens, nicht die Wahrscheinlichkeit, dass Ihr Pilot sicher ist. 1
Für die Geschäftsleitung heißt das zunächst: Null beobachtete Fehler sind kein Nachweis von Nullrisiko. Auch diese begrenzte statistische Aussage trägt nur, wenn die Annahmen passen. Hundert Varianten derselben einfachen Anfrage ersetzen keine hundert unabhängigen Fälle aus dem späteren Einsatz.
Mehr Tests können die Aussage verbessern. Sie helfen aber nicht gegen eine falsche Fehlerdefinition oder einen wichtigen Falltyp, der überhaupt nicht geprüft wurde.
Erst den Nachweis beschreiben, dann über Freigabe sprechen
Vor dem nächsten Pilotreview würde ich eine kurze Testnotiz verlangen. Sie soll von der fachlich verantwortlichen Person mitgetragen werden, nicht allein vom Entwicklerteam. Auf eine Seite gehören:
- ◆Gegenstand: Welche konkrete Arbeit wurde mit welcher Modell-, Quellen- und Konfigurationsversion geprüft?
- ◆Fehlerdefinition: Was gilt als fachlich falsch oder unzulässig und wer hat die Ergebnisse beurteilt?
- ◆Auswahl: Woher stammen die Fälle, welche Einsatzsituationen decken sie ab und was fehlt?
- ◆Grenze: Für welchen Einsatz gilt der Nachweis und welcher bleibt ausdrücklich ausgeschlossen?
Das ist keine neue Berichtsbürokratie. Fehlen diese Angaben, kann die Geschäftsleitung die Erfolgsmeldung nicht sinnvoll einordnen. Das Team kann sie später ebenfalls kaum reproduzieren.
Im Angebotsbeispiel könnte der Pilot nur das Zusammenstellen bereits freigegebener Informationen umfassen. Eine selbstständige Preisänderung wäre dann gar nicht geprüft. Dass die Zusammenstellung fehlerfrei war, rechtfertigt keine Erweiterung auf Preisentscheidungen.
Für häufige Standardfälle und seltene, folgenreiche Ausnahmen muss außerdem erkennbar bleiben, welcher Nachweis jeweils vorliegt. Eine unzulässige Zusage darf nicht in einem guten Gesamtdurchschnitt verschwinden. Welche Restunsicherheit akzeptabel ist, hängt von ihren Folgen und den vorhandenen Kontrollen ab. Das ist eine Managemententscheidung, keine allgemeine Benchmarkvorgabe.
Der freiwillige US-Referenzrahmen NIST AI 600-1 von 2024 empfiehlt, AI-Verhalten in realistischen Szenarien zu prüfen. Er warnt vor Messlücken zwischen kontrollierten Tests und tatsächlicher Nutzung. Er bietet Orientierung, keine Zertifizierung und keine Rechtsgarantie. 2
Ein begrenzter Nachweis braucht einen begrenzten Einsatz
Wenn die Testnotiz einen nützlichen, klar umrissenen Einsatz stützt, würde ich diesen entsprechend begrenzen. Der Assistent darf beispielsweise Informationen für einen Angebotsentwurf vorbereiten. Eine fachlich befugte Person prüft weiterhin die verbindlichen Konditionen, bevor das Angebot den Betrieb verlässt.
Die Kontrolle muss tatsächlich durchführbar sein. Eine verpflichtende Prüfung hilft wenig, wenn niemand die nötigen Quellen sieht oder dafür Zeit hat. Der zusätzliche Prüfaufwand gehört deshalb in die Wirtschaftlichkeitsbetrachtung. Entscheidend ist die Zeit bis zum fachlich freigegebenen Angebot, nicht nur die Geschwindigkeit des ersten Entwurfs.
Ein Teil der Fälle sollte vor der abschließenden Bewertung unberührt bleiben. Sonst zeigt der Test möglicherweise nur, wie gut das Team die bereits bekannten Aufgaben nachgebessert hat. Bei geänderten Quellen, Modellversionen oder einem erweiterten Einsatzbereich muss neu geklärt werden, welche Nachweise noch gelten.
Wenn solche Einsatzgrenzen und Freigabekriterien über mehrere Workstreams hinweg erst entschieden werden müssen, kann der Executive AI Transformation Blueprint die Managementarchitektur dafür schaffen. Der dreiwöchige Sprint legt Prioritäten, Verantwortung und Wertnachweise fest. Er ersetzt keine anschließende Prüfung im Betrieb.
Im nächsten Review würde ich mir deshalb nicht nur die hundert grünen Ergebnisse zeigen lassen. Ich würde fragen: Welche konkrete Freigabe tragen diese Tests und welche eben nicht?