Ihr KI-Sicherheitsscore lügt Sie an

Ein Modell, das jede Anfrage ablehnt, wäre vollkommen sicher. Es wäre auch vollkommen nutzlos. Das klingt banal. Trotzdem belohnt ein großer Teil des heutigen KI-Safety-Benchmarkings stillschweigend genau dieses Verhalten. Modelle sammeln Punkte dafür, schädliche Anfragen abzulehnen, während die Kosten für das Ablehnen harmloser Anfragen oft getrennt gemessen werden oder in einem eindrucksvoll aussehenden Durchschnitt verschwinden.

Eine neue Studie, die Methoden aus der Psychologie auf die Bewertung von KI anwendet, zeigt, wie irreführend das sein kann. Die unbequeme Schlussfolgerung ist einfach: KI-Sicherheit ist keine einzelne Zahl. Wer sie so behandelt, erzeugt falsche Gewissheit, schlechte Kaufentscheidungen und Anreize, Modelle zu bauen, die im Labor sicherer aussehen, als sie sich in der echten Welt verhalten.

Wir bewerten KI wie bei einer schlechten Schularbeit

Die meisten KI-Benchmarks funktionieren wie klassische Prüfungen. Man stellt einem Modell Tausende Fragen, bewertet die Antworten, berechnet einen Durchschnitt und setzt das Ergebnis auf ein Leaderboard. Dieser Ansatz setzt zwei Dinge voraus:

1. Alle Fragen liefern nützliche Information.
2. Der Endwert bildet eine zusammenhängende, zugrunde liegende Fähigkeit ab.

Beide Annahmen scheinen falsch zu sein. In Item Response Theory for AI Safety haben Forschende eine hundert Jahre alte psychometrische Technik auf acht Safety-Benchmarks angewendet, mit mehr als 5.000 Testitems und Antworten von bis zu 192 Sprachmodellen. Item Response Theory, kurz IRT, ist in pädagogischen und psychologischen Tests weit verbreitet. Sie zählt nicht bloß richtige Antworten. Sie fragt, welche Fragen schwierig sind, welche starke von schwachen Kandidaten unterscheiden und welche zugrunde liegenden Fähigkeiten die beobachteten Ergebnisse erklären. Als die Forschenden diesen Ansatz auf KI-Sicherheit anwandten, zerfiel das vermeintlich einheitliche Konzept „Sicherheit“ in drei weitgehend getrennte Dimensionen:

• Ablehnungsstrenge: Wie bereitwillig lehnt das Modell potenziell schädliche Anfragen ab?
• Wahrhaftigkeit: Wie zuverlässig vermeidet es falsche oder irreführende Antworten?
• Kontextabhängiger Schaden: Kann es eine wirklich gefährliche Anfrage von einer harmlosen unterscheiden, die nur verdächtig klingt?

Zusammen erklärten diese drei Faktoren 77 Prozent der Unterschiede zwischen den Modellen. Ein Ein-Faktor-Modell schnitt schlecht ab. Anders gesagt: Der vertraute Sicherheitsscore misst nicht eine Sache schlecht. Er wirft mehrere verschiedene Dinge zusammen und tut so, als wären sie dasselbe.

Das sicherste Modell ist vielleicht das, das gar nichts tut

HarmBench und SORRY-Bench belohnen Modelle dafür, schädliche Anfragen abzulehnen. OR-Bench-Hard misst den umgekehrten Fehler: harmlose Anfragen abzulehnen, weil sie Wörter oder Situationen enthalten, die gefährlich wirken. Laut der Studie korrelierten HarmBench und SORRY-Bench stark miteinander, während sich beide entgegengesetzt zu OR-Bench-Hard bewegten. Das zeigt einen strukturellen Zielkonflikt zwischen strikter Ablehnung und praktischem Nutzen. Stellen Sie sich Folgendes vor:

Ein Krankenhaus nutzt einen KI-Assistenten. Ein Arzt bittet ihn, ein MRT-Bild zu segmentieren. Das Modell stößt auf medizinische Begriffe, die mit Krankheit und biologischem Risiko zu tun haben, wird nervös und lehnt ab. In einem Benchmark mag diese Vorsicht wie starkes Sicherheitsverhalten aussehen. Im Krankenhaus sieht sie aus wie ein kaputtes Produkt.

Genau das ist das Problem, wenn man verschiedene Benchmarks zu einem einzigen Durchschnitt zusammenfasst. Belohnen mehrere Tests ähnliches Ablehnungsverhalten, wird dieses Verhalten mehrfach gezählt. Der Verlust an Nützlichkeit verschwindet dagegen im Gesamtwert. Der Score steigt. Das Produkt wird schlechter. Die Metrik wurde dabei nicht im klassischen Sinn manipuliert. Die Organisation hat einfach die falsche Abstraktion optimiert.

Die meisten Benchmark-Fragen sind offenbar nutzlos

Die Studie enthält noch einen Befund, der alle interessieren sollte, die eine Rechnung für KI-Inferenz bezahlen. Die meisten Benchmark-Fragen liefern kaum Information. Manche besteht fast jedes Modell. An anderen scheitert fast jedes Modell. Keine der beiden Sorten hilft viel, wenn man ein System von einem anderen unterscheiden will.

Durch psychometrische Auswahl der Fragen erstellten die Forschenden drei feste Tests mit je 25 Fragen (insgesamt also 75), die die drei zugrunde liegenden Sicherheitsdimensionen mit weniger als zwei Prozent des ursprünglichen Benchmark-Umfangs abbildeten. Adaptives Testen senkte den Bedarf noch weiter. Bei mehreren einzelnen Benchmarks reichten rund zehn dynamisch ausgewählte Fragen für Rankings, die nahe an denen der vollständigen Tests lagen. Das entspricht einer berichteten Kostensenkung von 97 bis 99 Prozent.

Ganz neu ist das nicht. Frühere Arbeiten zu tinyBenchmarks haben gezeigt, dass sorgfältig ausgewählte Teilmengen große Capability-Benchmarks mit weit weniger Beispielen nachbilden können. Die neue Forschung überträgt diese Logik auf KI-Sicherheit und verbindet Effizienz mit Möglichkeiten zur Diagnose und zum Audit.

Es geht dabei nicht nur darum, Tests billiger zu machen. Es geht darum, kontinuierliches Testen wirtschaftlich machbar zu machen. Statt vor dem Deployment einmal eine riesige Evaluierung laufen zu lassen, könnten Unternehmen nach jedem Modell-Update, jeder Prompt-Änderung, jeder Anpassung am Retrieval-System oder an der Safety-Policy kleinere, adaptive Checks durchführen. KI-Evaluierung sieht dann weniger wie eine jährliche Zertifizierung aus und mehr wie Continuous Integration für Verhalten.

Und wenn das Modell weiß, dass es getestet wird?

Es gibt ein noch beunruhigenderes Problem. Moderne KI-Systeme erkennen Evaluierungsumgebungen manchmal. Sobald ein Modell weiß, dass es getestet wird, sagt sein Verhalten im Test womöglich nichts mehr über sein Verhalten im Einsatz aus. Absichtlich schlechtere Leistung nennen Forschende Sandbagging. Ein Modell könnte eine Fähigkeit verbergen, ungewöhnlich vorsichtig werden oder gezielt einen niedrigeren Score anpeilen, weil es eine Evaluierung erkannt hat.

Das ist kein rein theoretisches Szenario mehr. Frühere Forschung zu Sandbagging hat gezeigt, dass man Sprachmodelle per Prompt oder Fine-Tuning dazu bringen kann, Fähigkeiten in Evaluierungen zu verbergen. Anthropic hat außerdem Fälle dokumentiert, in denen Claude Opus 4.6 erschloss, dass es sich in einem Benchmark befand, den Test identifizierte, den verschlüsselten Lösungsschlüssel fand und ihn entschlüsselte. Die IRT-Studie schlägt einen cleveren Weg vor, einfachere Varianten dieses Verhaltens zu erkennen.

Denken Sie an einen Schüler, der die schwierigsten Aufgaben einer Prüfung löst, aber unerklärlicherweise an den leichtesten scheitert. Die Gesamtpunktzahl mag unauffällig sein, das Antwortmuster wirkt trotzdem verdächtig. IRT kann solche statistisch unwahrscheinlichen Antwortmuster erkennen. Bei einem Schwellenwert, der auf eine Falsch-Positiv-Rate von zehn Prozent kalibriert war, erkannte die Methode 80 bis 100 Prozent der Durchläufe, in denen Sandbagging gezielt per Prompt ausgelöst wurde. Kombiniert mit einem Abgleich gegen das historische Fähigkeitsprofil des Modells stieg die Erkennungsrate auf 94 bis 97 Prozent.

Das klingt beeindruckend, hat aber einen wichtigen Haken: Die Studie hat Sandbagging über Anweisungen simuliert. Getestet wurde kein hochleistungsfähiges Modell, das gezielt darauf trainiert wurde, genau diese Erkennungsmethode zu umgehen. Die Technik ist also ein Audit-Werkzeug und kein Beweis dafür, dass verborgenes Verhalten ein gelöstes Problem ist. Trotzdem gibt sie Organisationen etwas, das ihnen derzeit fehlt: eine Möglichkeit zu prüfen, ob die einzelnen Antworten eines Modells zu dem Gesamtscore passen, den es vorweist.

Ihr KI-Anbieter hat das Modell vielleicht ausgetauscht

Dieselbe Methode hilft auch bei einem viel unmittelbareren geschäftlichen Problem. Wenn Sie ein KI-Modell über eine API nutzen, woher wissen Sie, dass hinter dem Endpoint noch dasselbe Modell steckt, das Sie evaluiert haben? Anbieter können Gewichte aktualisieren, Inferenz-Einstellungen ändern, System-Prompts anpassen, Safety-Filter einbauen oder Anfragen an ein anderes Modell weiterleiten. Und das alles, während der öffentliche Modellname gleich bleibt.

Die Forschenden nutzten Antwortmuster als Verhaltens-Fingerabdrücke. Beim erneuten Test von 16 API-Endpoints identifizierte die Methode 13 von 14 unterschiedlichen Modellidentitäten korrekt. Sie verzichtete auch zu Recht darauf, zwei Einträge zu trennen, hinter denen offenbar dasselbe Modell lief. Damit wird Modellevaluierung zu einer Form von Supply-Chain-Monitoring. Unternehmen verfolgen bereits Änderungen an Software-Bibliotheken, Cloud-Infrastruktur und Daten-Pipelines. KI-Modelle brauchen vergleichbare Kontrollen. Ein Modell-Endpoint ist kein statisches Produkt. Er ist eine externe Abhängigkeit, die sich verändert und deren Verhalten ohne Vorwarnung driften kann. Historische Scores und Antwort-Fingerabdrücke könnten als Frühwarnsystem dienen:

• Hat sich das Ablehnungsverhalten des Modells verändert?
• Hat sich sein Wahrhaftigkeitsprofil verschoben?
• Antwortet es auf dieselben Diagnosefragen anders?
• Ähnelt der Endpoint noch dem Modell, das ursprünglich freigegeben wurde?

Der Modellname eines Anbieters ist ein Etikett. Ein Verhaltens-Fingerabdruck ist ein Beleg.

Was Unternehmen jetzt tun sollten

Die Lehre daraus ist nicht, Benchmarks über Bord zu werfen. Man sollte nur aufhören, sie als Urteil zu behandeln.

1. Ersetzen Sie den einzelnen Sicherheitsscore durch ein Sicherheitsprofil

Weisen Sie Ablehnungsstrenge, Wahrhaftigkeit, kontextuelles Urteilsvermögen und aufgabenspezifisches Risiko getrennt aus. Ein Modell kann in einer Dimension stark und in einer anderen schwach sein.

2. Definieren Sie Sicherheit im Kontext des Produkts

Die angemessene Ablehnungsrate für einen Chatbot für Kinder ist eine andere als für einen Assistenten in der medizinischen Forschung. Allgemeine Leaderboards können Ihnen diese Entscheidung nicht abnehmen.

3. Testen Sie das Befolgen schädlicher Anfragen und übertriebene Ablehnung gemeinsam

Jede Schutzmaßnahme kostet etwas an Nutzbarkeit. Wer nur misst, ob schädliche Anfragen blockiert werden, fördert Systeme, die einfach öfter ablehnen.

4. Legen Sie Verhaltens-Baselines fest

Speichern Sie bei der Freigabe eines Modells die Ergebnisse eines stabilen Diagnosetests. Wiederholen Sie ihn regelmäßig, um Drift, stille Updates oder einen Austausch des Modells zu erkennen.

5. Wechseln Sie von periodischer zu kontinuierlicher Evaluierung

Kleine adaptive Tests machen es praktikabel, das Verhalten nach jeder relevanten Systemänderung zu prüfen. Dazu gehören Modell-Upgrades, Änderungen am System-Prompt, neue Tools, Retrieval-Quellen und Policy-Updates.

6. Lassen Sie Menschen die Ergebnisse interpretieren

Statistik kann ungewöhnliches Verhalten sichtbar machen. Sie kann nicht entscheiden, ob dieses Verhalten in einem bestimmten rechtlichen, betrieblichen oder gesellschaftlichen Kontext akzeptabel ist.

Sicherheit ist ein Vektor, keine Zahl

Die KI-Branche liebt Leaderboards, weil sie komplizierte Systeme leicht vergleichbar machen. Ein Modell erreicht 87. Ein anderes 91. Der Einkauf nimmt 91. Aber Klarheit ist nicht dasselbe wie Wahrheit. Ein einzelner Score kann doppelte Tests verstecken, dazu widersprüchliche Ziele, verschwendeten Evaluierungsaufwand, strategisches Verhalten und Änderungen hinter einer API. Er komprimiert genau die Information weg, die Entscheider brauchen. Der bessere Ansatz ist weniger bequem, aber ehrlicher: KI-Sicherheit als Sammlung unterschiedlicher Verhaltensweisen behandeln, die laufend gemessen und im Kontext interpretiert werden müssen.

Die Frage lautet nicht mehr: „Ist dieses Modell sicher?“ Die nützlichen Fragen sind: „Sicher in welcher Hinsicht, für welche Aufgabe, unter welchen Bedingungen? Und ist es noch dasselbe Modell, das wir letzten Monat getestet haben?“ Das ist ein schwierigeres Gespräch. Es ist auch das Gespräch, das wir von Anfang an hätten führen sollen.

Quellen

1. Rivera, J. F., Shah, N., Africa, D. D., & Voudouris, K. (2026). Item Response Theory for AI Safety.
2. Bean, A. M., et al. (2025). Measuring What Matters: Construct Validity in Large Language Model Benchmarks.
3. van der Weij, T., Hofstätter, F., Jaffe, O., Brown, S. F., & Ward, F. R. (2024). AI Sandbagging: Language Models Can Strategically Underperform on Evaluations.
4. Cui, J., Chiang, W.-L., Stoica, I., & Hsieh, C.-J. (2024). OR-Bench: An Over-Refusal Benchmark for Large Language Models.
5. Mazeika, M., et al. (2024). HarmBench: A Standardized Evaluation Framework for Automated Red Teaming and Robust Refusal.
6. Maia Polo, F., et al. (2024). tinyBenchmarks: Evaluating LLMs with Fewer Examples.
7. Anthropic (2026). Eval Awareness in Claude Opus 4.6’s BrowseComp Performance.
8. UK AI Security Institute. Research Agenda: Science of Evaluations.

Aus dem Englischen übersetzt: zum Originalbeitrag