Warum LLM-Evaluierungen für KI-Governance entscheidend sind

Wenn Sie irgendetwas ausliefern, das auf einem Large Language Model basiert, leben Sie mit einer unangenehmen Wahrheit. Sie können nicht wissen, dass es in jedem Fall korrekt funktioniert. Der Raum möglicher Eingaben ist faktisch unendlich, und selbst der Modell-Anbieter kann keine Konsistenz zwischen zwei fast identischen Prompts garantieren. Diese Unsicherheit ist der Grund, warum Governance-Teams jetzt Evaluierungs-Ergebnisse sehen wollen, bevor irgendetwas live geht.

Dieser Beitrag ist ein praktischer Blick darauf, was Evaluierungen messen, warum Teams sie auslassen, und wie sie mit den KI-Governance-Frameworks zusammenhängen, die Aufsichtsbehörden inzwischen durchsetzen: das EU AI Act, ISO/IEC 42001 und die Dokumentationserwartungen, die aus beiden fließen.

Die vier Risiken, die Evaluierungen sichtbar machen sollen

Wenn Teams fragen „ist das Modell gut genug?", meinen sie üblicherweise eines von vier sehr unterschiedlichen Dingen. Evaluierungen sind die Art, sie auseinanderzuhalten.

Halluzination. Das Modell produziert plausibel klingende Ausgaben, die nicht wahr sind. Es passiert mit schwachen Trainingsdaten, häufiger aber, wenn ein Unternehmen dem Modell seine eigenen Daten gibt (eine Knowledge Base, eine Policy-Bibliothek, Kundendatensätze) und das Modell sie falsch liest oder um die Lücken herum erfindet. Sie testen darauf, indem Sie einen Datensatz bekannter Fragen durchlaufen lassen und prüfen, ob die Antwort des Modells mit dem in der Quelle Stehenden übereinstimmt.

Bias und Fairness. Das ist der Teil, der Aufsichtsbehörden am meisten interessiert. Es gibt nicht viel Regulierung, die rohe Genauigkeit verlangt, aber es gibt sehr viel Regulierung, die faire Behandlung über Gruppen hinweg verlangt. Eine sinnvolle Bias-Evaluierung stellt dieselbe Frage unter Variation von Geschlecht, Einkommen, Ethnizität, Alter, Geografie und ungefähr 20 weiteren Achsen, und prüft dann, ob sich die Antwort auf Weisen ändert, auf die sie sich nicht ändern sollte.

Ungenauigkeit durch Fine-Tuning. Sobald Sie ein Basismodell auf Ihren eigenen Daten fine-tunen, verändern Sie sein Verhalten. Diese Veränderung kann nützlich sein. Sie kann auch leise Fehler und Schieflagen einführen. Evaluierungen sind, wie Sie die Regression abfangen, bevor sie ausgeliefert wird.

Geerbte Modellfehler. Kleinere Open-Weights-Modelle haben bekannte Schwächen. Größere Frontier-Modelle von OpenAI oder Anthropic haben ihre eigenen. Ihre Evaluierung muss die ans Licht bringen, die Ihren spezifischen Use Case treffen.

Wenn Sie RAG oder einen Agenten ausliefern, erweitert sich das Metrik-Vokabular (Faithfulness und Contextual Precision für Retrieval, Tool Correctness und Plan Adherence für Agenten), aber die vier zugrunde liegenden Risiken und das Governance-Argument ändern sich nicht.

Reine Human-Review skaliert nicht mehr

Vor ein paar Jahren evaluierten Sie ein LLM, indem Sie Menschen vor jede Ausgabe setzten. So funktionierte RLHF in den großen Laboren. Forschende lasen Antworten, markierten sie und führten das Signal ins Training zurück. Es funktioniert noch immer. Es kommt nur nicht mehr mit dem Volumen an Evaluierungen mit, das Produktiv-KI heute verlangt.

Der aktuelle Standard ist LLM-as-a-judge. Sie nutzen ein starkes Modell, um die Ausgaben des Modells zu evaluieren, das Sie ausliefern. Der Judge liest jede Antwort, bewertet sie gegen eine definierte Metrik (Korrektheit, Halluzination, Bias, Fairness usw.) und gibt sowohl den Score als auch eine kurze schriftliche Begründung zurück, damit ein Mensch das Urteil auditieren kann, statt ihm blind zu vertrauen.

Rein mathematische Evaluierungsmethoden existieren weiterhin (Exact-Match, BLEU, ROUGE, Embedding-Similarity) und haben ihren Platz. Aber für die qualitativen Fragen, die Governance interessieren („war diese Antwort fair?", „war sie im Quellmaterial verankert?"), ist LLM-as-a-judge zum Default geworden.

Der Judge ist kein Freifahrtschein. Studien haben gezeigt, dass LLM-Judges ihre eigenen Ausgaben bevorzugen, über Läufe hinweg inkonsistent bewerten und Fehler übersehen, wenn eine Antwort selbstsicher vorgetragen wird. Der Judge selbst braucht also Stichproben. Eine menschliche Reviewerin liest eine kleine Stichprobe der bewerteten Ausgaben und bestätigt, dass sich die Bewertung mit ihrer eigenen Lesart deckt. Das Modell und die Version des Judges gehören in den Audit-Trail neben alles andere.

Drei Stufen der Evaluierungsreife

Evaluierung ist nicht binär. Die meisten Teams bewegen sich durch drei Stufen, und zu wissen, in welcher Sie stecken, sagt Ihnen, wo der nächste Invest hingehört.

Stufe 1: deterministische Assertions. Billig, schnell, brüchig. Regex-Checks, Schema-Validierung, Längengrenzen, Refusal-Detection. Sie fangen die offensichtlichen Fehler ab und laufen auf jedem Commit. Erstaunlich viel Governance-Wert entsteht allein dadurch, das konsistent zu tun.

Stufe 2: LLM-as-a-judge auf einem statischen Datensatz. Eine kuratierte Sammlung von Prompts, ein stärkeres Modell, das gegen rubrik-definierte Metriken bewertet, ein versionierter Report. Das ist die Stufe, die die meisten Aufsichtsbehörden implizit voraussetzen, wenn sie unter dem EU AI Act nach „Test-Evidenz" fragen.

Stufe 3: kontinuierliche Evaluierung auf Produktiv-Traffic. Sampling von Live-Anfragen, Reference-free-Judges darauf, Alerts bei Score-Drift. Hier lebt ISO 42001, und es ist die Stufe, in der fast niemand schon ist.

Sie können eine Stufe nicht wirklich überspringen. Stufe 3 ohne einen Stufe-2-Datensatz zu versuchen ist Monitoring von Rauschen, für das Sie keinen Baseline-Wert haben.

Wie das mit dem EU AI Act und ISO 42001 zusammenhängt

Evaluierungen sind für Governance nützlich, weil sie etwas produzieren, wonach Regulierer ausdrücklich fragen: Evidenz dazu, wie sich das System verhält, nicht nur Evidenz dazu, wie es gebaut wurde.

Unter dem EU AI Act müssen Anbieter und Deployer von Hochrisiko-KI-Systemen technische Dokumentation pflegen, Tests durchführen und nachweisen, dass die Risiken des Systems identifiziert und gemindert wurden. Ein Evaluierungs-Report mit Scores zu Halluzination, Bias und Fairness (mit den zugrunde liegenden Samples und der Begründung des Judges angehängt) ist ein konkretes Artefakt, das Sie einer Prüferin vorlegen können. Schwerer zu zerreden als „wir haben ein angesehenes Modell genutzt".

ISO/IEC 42001, der AI-Management-System-Standard, verlangt etwas Ähnliches: kontinuierliche, dokumentierte Zusicherung, dass das System weiter innerhalb der von Ihnen definierten Risiko-Schwellen performt. Evaluierungen verwandeln diese abstrakte Anforderung in etwas Messbares. Eine Schwelle pro Metrik. Ein Pass/Fail-Status. Ein versionierter Trail.

Kontinuierlich ist das operative Wort. Ein einzelner Eval-Lauf vor dem Launch befriedigt ISO 42001 nicht. Der Standard erwartet einen wiederkehrenden Rhythmus: periodische Re-Evaluierung gegen denselben Datensatz, gesampletes Monitoring von Live-Traffic und eine dokumentierte Reaktion, wenn Scores driften. Ein Point-in-Time-Test segnet den Launch ab, hält das System danach aber nicht im Scope.

Mehr zum Vergleich der beiden Frameworks und ihren Divergenzpunkten in unserem Deep Dive EU AI Act vs. ISO 42001.

Was im Audit standhält, ist nicht der Score. Es ist der Trail dahinter: wer was getestet hat, gegen welchen Datensatz, auf welcher Modellversion, mit welchem Judge, gegen welche Metriken, mit welchem Ergebnis.

Was eine echte Evaluierung braucht

Vier Zutaten:

1. Das zu testende Modell. Das exakte Modell und die Version, die Sie ausliefern wollen, mit derselben Konfiguration, mit der Sie in Produktion laufen werden.
2. Ein Datensatz. Eingabe-Prompts und, für messbare Metriken, erwartete Ausgaben. Der Datensatz muss die reale Verteilung von Fragen widerspiegeln, die Ihr System sehen wird, nicht nur die leichten. Manche Metriken brauchen Referenz-Ausgaben (Korrektheit, Exact-Match). Andere (Faithfulness, Helpfulness, Toxicity) sind reference-free und bewerten die Antwort direkt. Stufe-3-Evaluierung auf Produktiv-Traffic ist meistens die zweite Sorte, weil Sie für Live-Anfragen selten Ground Truth haben.
3. Ein Judge. Entweder ein stärkeres Modell oder, für manche Metriken, ein deterministischer Check. Der Judge braucht eine klare Bewertungs-Rubrik und sollte verpflichtet sein, eine Begründung zu liefern, nicht nur eine Zahl.
4. Metriken und Schwellen. Eine numerische Definition von „gut genug". Ein üblicher Startpunkt liegt bei rund 0,5 bis 0,6 pro Metrik, alles darunter geht an eine menschliche Reviewerin. Wo Sie die Latte legen, ist eine Produkt- und Risikoentscheidung, nicht eine technische, und Sie sollten diese Entscheidung neben dem Score dokumentieren. Auditoren werden fragen, warum Sie 0,6 und nicht 0,8 gewählt haben, und „die Metrik hatte das als Default" ist keine Antwort.

Die Ausgabe ist eine Per-Sample-Aufschlüsselung: jeder Prompt, die Antwort des Modells, der Score des Judges, die Begründung des Judges. Für volumenarme Use Cases können Sie jedes Sample lesen. Für volumenstarke Systeme sind die Begründungs-Zusammenfassungen, wie Governance und Engineering Fehler prüfen, ohne sich durch tausende Antworten zu wühlen. Fehler-Cluster sind, woher die Arbeit des nächsten Sprints kommt. Ein wiederkehrendes Halluzinationsmuster ist ein Prompt- oder RAG-Fix. Ein wiederkehrendes Bias-Muster ist eine Fairness-Eskalation. Ein wiederkehrender Tool-Fehler ist ein Agent-Design-Problem. Eine Evaluierung, die im nächsten Sprint nichts ändert, ist ein Statusbericht, kein Control.

Warum Teams hier weiter unter-investieren

Zwei Gründe, im Wesentlichen.

Der erste: Evaluierungen sehen wie Overhead aus, bis etwas schiefgeht. Es gibt kein dringendes Ticket, das einen Bias-Audit fordert, bis es ein sehr dringendes Ticket gibt, das fragt, warum das Modell zwei Kundenkohorten unterschiedlich behandelt hat.

Der zweite: Das Tooling ist seit Jahren fragmentiert. Separate Libraries für Metriken, separate Dashboards für Ergebnisse, separate Tabellen für die Dokumentation, die Regulierer wollen. Teams enden mit Evaluierungs-Logik, verteilt auf drei Orte, und ohne ein einziges Artefakt, das sie einer Prüferin oder dem Legal-Team in die Hand drücken können.

Diese Lücke zu schließen ist, wofür gutes Evaluierungs-Tooling da ist. Ein Ort, um Modell, Datensatz, Judge, Metriken und Schwellen zu definieren. Ein Ort, um Ergebnisse pro Sample zu sehen. Ein Trail, den Sie jedem hinhalten können, der fragt.

Was Sie dieses Quartal tun

Wenn Sie irgendetwas LLM-basiertes ausliefern und noch keine Evaluierungs-Pipeline haben, ist der kleinste sinnvolle Schritt dieser.

• Wählen Sie den einen Use Case, in dem eine schlechte Antwort Sie am meisten kosten würde: rechtlich, reputationell oder kommerziell.
• Bauen Sie einen Datensatz von 50 bis 100 realen Prompts für diesen Use Case (wo möglich aus Produktiv-Logs gezogen, ergänzt um synthetische Edge Cases, generiert von einem stärkeren Modell), mit erwarteten Antworten, wo zutreffend.
• Lassen Sie eine LLM-as-a-judge-Evaluierung gegen Korrektheit, Halluzination und Bias laufen. Drei Metriken, nicht 30.
• Setzen Sie eine Schwelle. Schlagen Sie laut Alarm, wenn Sie sie überschreiten.
• Speichern Sie den Report. Versionieren Sie ihn neben Ihrem Modell.

Das ist das Maß an Sorgfalt, das Regulierer von Hochrisiko-Systemen unter dem EU AI Act erwarten, und das Maß an Evidenz, nach dem ISO-42001-Audits zunehmend fragen werden. Unabhängig von Compliance ist es auch der billigste Weg herauszufinden, dass Ihr Modell falsch liegt, bevor Ihre Kunden es tun.

Evaluierungen sind keine akademische Übung. Sie sind, wie Sie auf Papier nachweisen, dass Ihr KI-System getan hat, was Sie gesagt haben.

VerifyWises Plattform bringt Model Inventory, Evaluierungen, Risk und Evidence in einen Arbeitsbereich, sodass sich der Audit-Trail von selbst aufbaut, während Ihr Team arbeitet. Wenn Ihre Evaluierungs-Logik gerade über Libraries, Dashboards und Tabellen verteilt ist, lohnt ein Blick.