KI-Qualität braucht einen festen Testbestand

Eine KI-Anwendung kann in einer Präsentation überzeugen und im Arbeitsalltag trotzdem unbrauchbar sein. Der Unterschied liegt selten nur im Modell. In der Demo werden verständliche Eingaben, günstige Dokumente und bekannte Fragen gewählt. Im Betrieb folgen unvollständige Angaben, schlechte Scans, ungewöhnliche Fachbegriffe, widersprüchliche Daten und Fälle, in denen eine falsche Antwort erhebliche Folgen hätte.

Wer Qualität anhand einzelner Beispiele beurteilt, testet vor allem die Auswahl dieser Beispiele. Für eine belastbare Entscheidung braucht die Organisation einen festen Testbestand: eine versionierte Sammlung repräsentativer Aufgaben mit erwarteten Ergebnissen, definierten Fehlergrenzen und einem wiederholbaren Bewertungsverfahren.

Die Kernfrage lautet nicht „Ist das Modell gut?“, sondern: Erfüllt dieses konkrete System diese konkrete Aufgabe unter den Bedingungen unseres Betriebs ausreichend sicher und nützlich?

Die Aufgabe ist die Einheit der Bewertung

Allgemeine Modellvergleiche können eine Vorauswahl unterstützen. Sie sagen jedoch wenig darüber aus, ob eine Anwendung beispielsweise Rechnungspositionen korrekt zuordnet, interne Richtlinien mit Quellen beantwortet oder Supporttickets sinnvoll vorsortiert. Das Ergebnis hängt auch von Prompt, Datenaufbereitung, Retrieval, Werkzeugen, Berechtigungen und nachgelagerten Prüfungen ab.

Vor dem ersten Test sollten deshalb fünf Punkte feststehen:

1. Welche fachliche Aufgabe soll erledigt werden?
2. Welche Eingaben kommen im realen Prozess vor?
3. Welche Entscheidung oder Handlung folgt aus dem Ergebnis?
4. Welche Fehler sind tolerierbar, welche müssen verhindert oder sicher abgefangen werden?
5. Welche menschliche Kontrolle bleibt bestehen?

Das NIST AI Risk Management Framework verlangt im Bereich „Measure“ dokumentierte Testbestände, Metriken und Werkzeuge sowie Prüfungen unter Bedingungen, die dem Einsatz entsprechen. Daraus folgt keine universelle Kennzahl. Es folgt vielmehr die Pflicht, Bewertung und Nutzungskontext miteinander zu verbinden.

Ein Testbestand braucht mehr als Normalfälle

Ein nützlicher Bestand bildet nicht nur häufige Eingaben ab. Er muss jene Situationen enthalten, in denen das System wahrscheinlich scheitert oder in denen ein Fehler besonders folgenreich wäre.

Eine praktikable Gliederung ist:

Fallgruppe	Zweck	Beispielhafte Frage
Normalfälle	übliche Arbeitslast abbilden	Funktioniert die Kernaufgabe bei typischen, vollständigen Eingaben?
Varianten	reale Vielfalt prüfen	Bleibt das Ergebnis bei anderem Format, Stil oder Reihenfolge brauchbar?
Grenzfälle	fachliche Grenzen sichtbar machen	Was geschieht bei fehlenden, widersprüchlichen oder ungewöhnlichen Angaben?
unzulässige Fälle	sichere Ablehnung prüfen	Erkennt das System Aufgaben, die es nicht bearbeiten darf oder kann?
folgenreiche Fehler	Schutzmaßnahmen testen	Werden Fehler mit hoher Wirkung erkannt, blockiert oder zur Prüfung gegeben?
Missbrauchsfälle	absichtliche Umgehung prüfen	Lassen sich Regeln, Datenzugriffe oder Werkzeuggrenzen manipulieren?

Nicht jeder Anwendungsfall benötigt gleich umfangreiche adversariale Tests. Ein Formulierungsvorschlag ohne automatische Aktion besitzt ein anderes Risikoprofil als ein Agent, der Konten sperren oder Bestellungen auslösen kann. Der Testumfang folgt der möglichen Wirkung.

Erwartete Ergebnisse müssen prüfbar sein

Bei einer exakten Extraktion kann die Sollantwort eindeutig sein. Bei Zusammenfassungen, Klassifikationen oder Textentwürfen gibt es häufig mehrere vertretbare Ergebnisse. Dann braucht es eine Bewertungsrubrik statt eines vermeintlich perfekten Mustertexts.

Eine Rubrik kann beispielsweise unterscheiden:

• fachliche Richtigkeit,
• Vollständigkeit der notwendigen Angaben,
• Nachvollziehbarkeit oder Quellenbezug,
• Einhaltung von Ton, Format und Prozessregeln,
• sichere Behandlung von Unsicherheit,
• Auftreten eines ausdrücklich unzulässigen Fehlers.

Wichtig ist die Fehlerwirkung. Ein Mittelwert kann gut aussehen, obwohl ein seltener, aber inakzeptabler Fehler weiterhin auftritt. Deshalb sollten Freigabekriterien nicht nur Durchschnittswerte enthalten. Eine Anwendung kann beispielsweise eine Mindestqualität für Normalfälle benötigen und gleichzeitig bei einer definierten Klasse kritischer Fehler keinen ungeprüften Durchlauf erlauben.

Die britische Einführung in AI Assurance betont klare Benchmarks, Leistungstests und die Verbindung quantitativer und qualitativer Nachweise. Gerade bei offenen Textaufgaben bleibt eine fachkundige menschliche Bewertung oft notwendig. Sie sollte durch klare Kriterien gelenkt werden, nicht durch spontanes Gefallen.

Eine kompakte Evaluationskarte

Vor jedem Testlauf sollte eine Evaluationskarte den Rahmen festhalten:

Feld	Inhalt
Systemversion	Modell, Prompt, Datenstand, Retrieval, Werkzeuge und relevante Konfiguration
Aufgabe	fachlicher Vorgang und gewünschtes Ergebnis
Nutzer und Umfeld	Rollen, Sprache, Eingabequalität und Einsatzsituation
Testbestand	Version, Herkunft, Fallgruppen und Ausschlüsse
Bewertung	Metriken, Rubrik, Prüfer und Umgang mit Uneinigkeit
kritische Fehler	Ergebnisse, die blockiert oder zwingend eskaliert werden müssen
Freigabegrenze	welche Nachweise vor Pilot, Produktion oder Erweiterung vorliegen müssen
Regression	welche Änderungen einen erneuten Test auslösen
Produktionskontrolle	Stichproben, Beschwerden, Drift- und Incident-Signale

Diese Karte verhindert, dass zwei Testläufe miteinander verglichen werden, obwohl Modell, Prompt, Daten und Bewertungsmaßstab gleichzeitig geändert wurden.

Konstruiertes Beispiel: Die Demo-Rechnung war zu sauber

Das folgende Beispiel ist konstruiert.

Eine KI-Anwendung soll Eingangsrechnungen erfassen. Im Pilot werden einige gut lesbare Standardrechnungen verwendet. Lieferant, Datum, Rechnungsnummer und Gesamtbetrag erscheinen korrekt; das Team bewertet den Versuch als erfolgreich.

Im späteren Posteingang kommen jedoch Gutschriften, mehrseitige Scans, handschriftliche Korrekturen, abweichende Steuersätze und Dokumente mit mehreren Bestellbezügen vor. Einzelne Felder sehen plausibel aus, sind aber fachlich falsch zugeordnet. Weil die ursprünglichen Beispiele nicht versioniert und keine Fehlerklassen definiert wurden, lässt sich weder die alte Qualität reproduzieren noch eine neue Version verlässlich vergleichen.

Ein geeigneter Testbestand würde reale Dokumentklassen abbilden, sensible Inhalte angemessen schützen und für jedes Feld festlegen, wann eine automatische Übernahme erlaubt ist. Unsichere oder widersprüchliche Fälle würden nicht nur einen schlechteren Score erhalten, sondern gezielt in eine menschliche Prüfung laufen.

Testdaten brauchen Herkunft und Pflege

Testfälle können aus echten, anonymisierten oder synthetischen Daten entstehen. Jede Variante hat Grenzen:

• Reale Fälle bilden die tatsächliche Vielfalt gut ab, können aber personenbezogene, vertrauliche oder lizenzrechtlich geschützte Inhalte enthalten.
• Anonymisierung reduziert Risiken, kann jedoch wichtige Strukturmerkmale verändern.
• Synthetische Fälle lassen sich gezielt erzeugen, spiegeln aber unbekannte reale Abweichungen nicht automatisch wider.

Deshalb sollte jeder Fall eine dokumentierte Herkunft, einen zulässigen Verwendungszweck und eine fachliche Begründung besitzen. Fälle aus späteren Incidents, Beschwerden oder manuellen Korrekturen sind besonders wertvoll: Sie erweitern den Bestand um tatsächliche Schwächen. Persönliche oder vertrauliche Daten dürfen dabei nicht unkontrolliert in Testwerkzeuge oder externe Dienste gelangen.

Ein Teil des Bestands sollte außerdem nicht fortlaufend zur Prompt-Optimierung verwendet werden. Wenn alle Testfragen während der Entwicklung bekannt sind, kann das Team genau diesen Bestand verbessern, ohne die allgemeine Leistung zu erhöhen. Ein zurückgehaltener Prüfbestand und eine klare Versionierung begrenzen dieses Risiko, beseitigen es aber nicht vollständig.

Jede relevante Änderung löst eine Regression aus

Bei klassischen Anwendungen werden Regressionstests nach Codeänderungen erwartet. Bei KI-Systemen können deutlich mehr Änderungen das Verhalten beeinflussen:

• neue Modell- oder Anbieter-Version,
• veränderter Systemprompt,
• andere Dokumentaufbereitung,
• neue Wissensquellen oder Embeddings,
• geänderte Werkzeuge und Berechtigungen,
• andere Schwellenwerte oder Nachbearbeitung,
• Veränderungen der realen Eingaben.

Der Testlauf sollte diese Konfiguration mit dem Ergebnis speichern. „Wir haben das Modell getestet“ ist später wertlos, wenn nicht mehr feststellbar ist, welche Gesamtkonfiguration gemeint war.

Das NIST GenAI Profile überträgt den risikobezogenen Ansatz auf generative KI. Die NIST-Arbeit zu Test, Evaluation, Validation and Verification macht zugleich deutlich, dass Evaluation kein einzelner Abnahmetermin ist. Sie begleitet Entwicklung und Nutzung.

Produktion bleibt ein eigener Prüfbereich

Ein Testbestand kann bekannte Bedingungen reproduzieren. Er sieht aber nicht jede spätere Eingabe, Datenänderung oder unerwartete Wechselwirkung. Deshalb braucht die Produktion zusätzliche Signale:

• fachlich geprüfte Stichproben,
• dokumentierte Korrekturen und Beschwerden,
• Häufigkeit sicherer Ablehnungen und manueller Übergaben,
• Veränderungen der Eingabeverteilung,
• Incidents durch falsche oder unzulässige Ergebnisse,
• Nutzung und tatsächlicher Prozessnutzen.

Diese Beobachtung darf nicht heimlich oder datenschutzwidrig erfolgen. Rollen, Zweck, Aufbewahrung und Zugriff auf Protokolle müssen festgelegt sein. Bei agentischen Systemen kommen Rechte und Abbruchbedingungen hinzu; der Beitrag „KI-Agenten brauchen klare Rechte und Abbruchbedingungen“ vertieft diesen Teil.

Auch ein guter Testscore beweist keinen wirtschaftlichen Nutzen. Ob Bearbeitungszeit, Fehlerkosten oder Servicequalität tatsächlich besser werden, muss nach dem Go-live gegen die ursprüngliche Annahme geprüft werden. Dafür bietet „Ein Business Case endet nicht mit der Budgetfreigabe“ den passenden Rahmen.

Der erste belastbare Test ist bewusst begrenzt

Ein Mittelständler braucht zu Beginn keine große Evaluationsplattform. Für einen klar abgegrenzten Anwendungsfall genügen zunächst:

1. eine präzise Aufgabe,
2. ein kleiner, aber vielfältiger und begründeter Testbestand,
3. sichtbare Normal-, Grenz- und Verbotsfälle,
4. eine einfache Bewertungsrubrik,
5. definierte kritische Fehler,
6. ein reproduzierbarer Lauf mit dokumentierter Konfiguration.

Der Beitrag zur Produktionsreife von KI-Piloten ordnet diese Evaluation in das gesamte Betriebsmodell ein. Der Testbestand beantwortet darin eine zentrale, aber begrenzte Frage: Ist eine konkrete Version für die vereinbarte Aufgabe ausreichend belegt – und erkennen wir später, wenn sie sich verschlechtert?