Stichprobe bei KI-Systemen: Wie viele Fälle reichen?

Im Kursraum stelle ich diese Frage gern zurück. Jemand hat gerade erklärt, er habe die KI-gestützte Angebotsprüfung auditiert: zwanzig Fälle gezogen, alle in Ordnung, Haken dran. Dann frage ich, wie oft er jeden dieser zwanzig Fälle gezogen hat. Meistens kommt eine Pause. Einmal natürlich. So macht man das ja.

Bei einer Buchung, einer Rechnung oder einem Prüfprotokoll ist einmal auch richtig. Der Datensatz liegt fest. Er ändert sich nicht, während Sie hinsehen. Bei einem Sprachmodell ändert er sich. Dieselbe Eingabe erzeugt nicht zwangsläufig dieselbe Ausgabe. Wer einmal zieht, hat nicht das System geprüft, sondern eine Ziehung daraus.

Ich baue selbst KI-Systeme und auditiere sie. Deshalb hier die Überlegung, die hinter dem Stichprobenumfang steckt, und vor allem die Frage, die Sie zuerst stellen müssen, bevor überhaupt eine Zahl herauskommen kann.

Die Stichprobe hat bei KI zwei Richtungen

Bei einem klassischen Prüfgegenstand hat die Stichprobe eine Richtung: Wie viele Elemente ziehen Sie aus der Grundgesamtheit? Zwanzig von tausend Rechnungen, und jede Rechnung ist eine Beobachtung. Bei einem nicht-deterministischen System zerfällt diese eine Richtung in zwei.

• Breite: Wie viele verschiedene Fälle ziehen Sie? Sie sagt Ihnen, ob das System über die Bandbreite der echten Eingaben hinweg trägt, also auch bei dem seltenen Sonderfall, den niemand vorgesehen hat.
• Tiefe: Wie oft ziehen Sie denselben Fall mit identischer Eingabe? Sie sagt Ihnen, wie weit die Ergebnisse bei gleichem Input auseinanderlaufen. Das ist die Größe, die es bei einer Rechnung schlicht nicht gibt.

Zwanzig Fälle mit je einer Ziehung ergeben zwanzig Beobachtungen von zwanzig verschiedenen Dingen. Zwanzig Fälle mit je fünf Ziehungen ergeben hundert Beobachtungen und zusätzlich etwas, das die einfache Ziehung überhaupt nicht zeigen kann: die Streuung innerhalb eines einzigen Falls. Genau dort sitzt das Risiko, das die Betroffenen später trifft. Der eine Bewerber, dessen Vorauswahl beim zweiten Durchlauf anders ausgefallen wäre, taucht in einer Stichprobe mit einer Ziehung nie auf.

Eine Stichprobe, die nur einmal zieht, prüft den Zufall mit und nennt das Ergebnis dann Konformität.

Woher die Zahl kommt, und warum sie nicht bei Ihnen anfängt

Die häufigste Rückfrage lautet: Wie viele denn nun? Und die ehrliche Antwort ist, dass diese Zahl nicht dem Auditor gehört. Sie gehört der auditierten Organisation, und sie muss dort schon liegen, bevor jemand von außen kommt.

ISO/IEC 42001 verlangt in Anhang A unter A.6.2.4, Verifizierung und Validierung von KI-Systemen, dass die Organisation Prüfmethoden festlegt, die Auswahl der Testdaten begründet, Freigabekriterien definiert und akzeptable Fehlerquoten festschreibt. Der zugehörige Leitfaden in Anhang B nennt dazu ausdrücklich Zuverlässigkeitsanforderungen einschließlich akzeptabler Fehlerquoten sowie betriebliche Faktoren, die ein Mindestleistungsniveau verhindern können.

Aus dieser Fehlerquote folgt der Umfang. Wer sagt, ein Prozent falsche Vorauswahl sei tragbar, braucht eine deutlich größere Stichprobe als jemand, der zehn Prozent akzeptiert, weil ein Mensch ohnehin jeden Fall gegenliest. Beides kann richtig sein. Was nicht geht, ist die Zahl hinterher zu wählen.

Und damit sind wir bei der Feststellung, die in der Praxis viel häufiger ist als jede Frage nach dem Umfang: Es liegen Testergebnisse vor, aber keine vorab festgelegten Freigabekriterien und keine akzeptable Fehlerquote. Das Ergebnis wird nachträglich als ausreichend bewertet. Wenn Sie das antreffen, ist Ihre Stichprobe nicht zu klein. Sie hat nur einen anderen Zweck bekommen: Sie belegt jetzt, dass der Maßstab fehlt.

Was ISO 19011 hergibt, und was nicht

Der Auditleitfaden ISO 19011:2026 behandelt die Stichprobenbildung in Anhang A, Abschnitt A.6. Er ist die Grundlage, auf der ich plane, und er gibt mehr her, als die meisten erwarten. Abschnitt A.6.1 beschreibt die Schritte einer Stichprobe der Reihe nach.

• Das Ziel der Stichprobe festlegen.
• Die Grundgesamtheit abgrenzen, aus der gezogen wird.
• Das Verfahren wählen.
• Den Umfang bestimmen.
• Die Ziehung durchführen.
• Auswerten, berichten und dokumentieren.

Der Umfang ist also nur ein Schritt von sechs, und er kommt an vierter Stelle. Wer mit ihm anfängt, hat drei Entscheidungen übersprungen. Besonders die zweite wird bei KI regelmäßig verschenkt: die Abgrenzung der Grundgesamtheit. Sehr oft bekomme ich eine Exportdatei, und erst auf Nachfrage stellt sich heraus, dass darin nur die Fälle stehen, in denen ein Mensch den Vorschlag übernommen hat. Die abgelehnten und die abgebrochenen fehlen. Wer daraus zieht, prüft die Zustimmung und nicht das System. ISO 19011 weist in A.6.1 ausdrücklich darauf hin, dass eine Stichprobe aus unzureichenden oder ungenauen Daten kein brauchbares Ergebnis liefert; das gilt auch dann, wenn die Zahl der gezogenen Fälle beeindruckend aussieht.

Danach unterscheidet ISO 19011 zwei Familien: die Ziehung nach fachlichem Ermessen in A.6.2 und die statistische Ziehung in A.6.3.

Die Ermessensziehung stützt sich auf Kompetenz und Erfahrung des Auditteams und berücksichtigt unter anderem die Komplexität der Anforderungen, das Ausmaß technischer und personeller Veränderung sowie früher erkannte Risiken. Ihr Nachteil steht im Leitfaden selbst und wird gern überlesen: Bei dieser Vorgehensweise lässt sich die Unsicherheit der Feststellungen statistisch nicht beziffern. Sie dürfen so ziehen. Sie dürfen das Ergebnis nur nicht so berichten, als sei es gerechnet.

Der Punkt mit dem Ausmaß der Veränderung verdient bei KI besondere Aufmerksamkeit. Bei einer Maschine wissen Sie, wann zuletzt etwas geändert wurde, weil jemand geschraubt hat. Bei einem zugekauften Sprachmodell kann der Anbieter die Modellversion hinter demselben Produktnamen austauschen, ohne dass im Betrieb irgendjemand etwas unterschreibt. Wenn Sie also die Veränderungsintensität als Kriterium für Ihren Stichprobenumfang heranziehen, dürfen Sie sich nicht auf die Änderungsliste der auditierten Organisation verlassen. Sie müssen fragen, wie diese Organisation überhaupt mitbekommt, dass sich draußen etwas geändert hat, und in aller Regel ist genau das die interessantere Feststellung.

Die statistische Ziehung unterscheidet zwischen Attributprüfung, wenn es je Fall genau zwei Ausgänge gibt, und variablenbasierter Prüfung, wenn das Ergebnis in einem stetigen Bereich liegt. Dort taucht auch das Vertrauensniveau auf: Ein Stichprobenrisiko von fünf Prozent entspricht einem Vertrauensniveau von 95 Prozent, also der bewussten Inkaufnahme, dass etwa eine von zwanzig Stichproben nicht das Bild der Grundgesamtheit zeigt.

Und hier liegt die Grenze, die Sie selbst schließen müssen. ISO 19011 denkt die Grundgesamtheit als Menge vorhandener Aufzeichnungen. Ein Element wird gezogen und ist dann, was es ist. Dass ein einzelnes Element beim zweiten Hinsehen anders antwortet, kommt in dieser Denkweise nicht vor, weil es bei Aufzeichnungen auch nicht vorkommt. Die Tiefe der Stichprobe steht deshalb in keinem Auditleitfaden. Sie muss in Ihren Auditplan.

Attributprüfung passt, bis die Grenze unscharf wird

Attributprüfung setzt voraus, dass jeder Fall eindeutig in zwei Ausgänge fällt: richtig oder falsch, bestanden oder nicht. Bei einer Formularprüfung ist das trivial. Bei einem Sprachmodell ist genau das die eigentliche Arbeit, und sie passiert vor der ersten Ziehung.

Ein Beispiel aus der Vorauswahl von Bewerbungen. Die Frage darf nicht lauten, ob ich als Auditor dieselbe Entscheidung getroffen hätte. Das ist meine Meinung und kein Kriterium. Sie muss lauten: Bleibt das Ergebnis innerhalb der Grenzen, die die Organisation selbst gezogen hat, ist es begründet, und trägt die Begründung die Entscheidung? Diesen Satz schreibe ich vor der Ziehung auf und lasse ihn von der Fachseite bestätigen. Sonst diskutieren wir hinterher über jede einzelne Antwort statt über das System.

In der Vision-Prüfung an der Maschine ist die Grenze schärfer, weil es ein physisches Gutteil gibt, gegen das Sie messen können. In der Angebots- oder Belegverarbeitung im ERP liegt sie dazwischen: Ein Betrag ist richtig oder falsch, eine Zuordnung oft nur mehr oder weniger plausibel. Je unschärfer die Grenze, desto wichtiger wird die Tiefe, denn dann ist die Streuung selbst das Ergebnis.

Wie ich es im Audit tatsächlich mache

Ich fange nie mit einer Zahl an. Ich fange mit der Frage an, welche Fehlerquote die Organisation für dieses System festgeschrieben hat und wer sie freigegeben hat. Kommt darauf eine Zahl mit Datum und Unterschrift, ist der Rest Handwerk. Kommt keine, habe ich meine Feststellung und brauche die große Stichprobe gar nicht mehr, um sie zu belegen.

Danach lege ich Breite und Tiefe getrennt fest und schreibe beide Begründungen in den Auditplan. Die Breite folgt der Vielfalt der echten Eingaben, nicht der Bequemlichkeit der Exportfunktion. Die Tiefe folgt der Frage, wie stark das System überhaupt streut: Bei einer eng geführten Extraktion mit festem Ausgabeformat reichen wenige Wiederholungen, bei frei formulierten Bewertungstexten brauche ich mehr. Bei jeder Ziehung werden Modellversion, Stand des Systemprompts und Zeitpunkt mitgeschrieben, sonst ist die Wiederholung später nicht nachvollziehbar.

Wenn die Streuung innerhalb eines einzigen Falls größer ist als die festgelegte Toleranz, lautet die Feststellung nicht, dass eine Antwort falsch war. Sie lautet, dass das System bei identischer Eingabe kein Ergebnis innerhalb der eigenen Grenzen liefert. Das ist ein anderer Befund, er trifft die Wirksamkeit der Maßnahme und nicht den Einzelfall, und er ist für die Organisation deutlich unangenehmer.

Bei zugekauften Systemen scheitert die Mehrfachziehung oft an der Praxis: Jeder Aufruf kostet, die Produktivumgebung darf nicht mit Testfällen belastet werden, oder der Anbieter lässt Sie schlicht nicht. Dann verschiebt sich die Tiefe von der Ziehung in die Aufzeichnung. Sie messen die Streuung nicht selbst, Sie lesen sie aus dem laufenden Betrieb.

Dafür brauchen Sie Protokolle, die Ein- und Ausgabe zusammen mit der Modellversion führen. ISO/IEC 42001 sieht das in A.6.2.8 zur Aufzeichnung von Ereignisprotokollen vor, und für Hochrisikosysteme verlangt Artikel 12 der KI-Verordnung eine Protokollierung über die Lebensdauer. Fehlen diese Protokolle, ist auch das eine Feststellung, und zwar eine, die sich nicht durch eine größere Stichprobe heilen lässt.

Was in keinem Fall geht: die Tiefe stillschweigend weglassen und den Bericht so schreiben, als hätte man sie gehabt.

Der Satz, der am Ende im Bericht stehen muss

Ein Auditbericht, der nur sagt, es seien zwanzig Fälle ohne Abweichung geprüft worden, ist nicht überprüfbar. Er nennt weder die Grundgesamtheit noch das Verfahren, weder Breite noch Tiefe, und er verschweigt das Stichprobenrisiko, das nach ISO 19011 ausdrücklich zur Sache gehört.

Ich schreibe deshalb in jeden Bericht, woraus gezogen wurde, wie viele verschiedene Fälle es waren, wie oft je Fall gezogen wurde, gegen welches vorab festgelegte Kriterium bewertet wurde und mit welcher Modellversion zu welchem Zeitpunkt. Dazu einen Satz darüber, was diese Stichprobe nicht zeigen kann. Das klingt nach mehr Aufwand, als es ist, und es ist der Unterschied zwischen einem Nachweis und einer Behauptung mit Datum.