Ein gemeinsamer Leitfaden für vertrauenswürdige Evaluierungen durch Dritte

Unabhängige, vertrauenswürdige Evaluierungen durch Dritte spielen eine entscheidende Rolle⁠ bei der Stärkung des Sicherheitsökosystems. Diese Evaluierungen werden an Frontier-Modellen durchgeführt, um zusätzliche Evidenz für Behauptungen über kritische Fähigkeiten und Sicherheitsmaßnahmen bereitzustellen. In diesem Beitrag teilen wir die bisherigen Erkenntnisse und empfehlen Ansätze für die Gestaltung von Evaluierungen, die Frontier-Modelle auf gültige Art und Weise bewerten können und die, was wir begrüßen würden, als Grundlage für entstehende Standards in diesem Bereich dienen können.

Früher behandelten viele Evaluierungen Modelle wie Chatbots: Die Evaluierung gab einem Modell einen Prompt, als wäre sie eine nutzende Person mit einer Frage, das Modell antwortete, und eine evaluierende Person beurteilte die Ausgabe. Die heutigen Frontier-Modelle können weit mehr: Sie können Tools nutzen, Informationen über viele Schritte hinweg nachverfolgen und innerhalb eines größeren Workflows handeln. Das bedeutet, dass die Leistung nicht nur vom Modell abhängt, sondern auch von der Umgebung, in der die Aufgabe stattfindet, und vom Setup, das seine Handlungen ermöglicht. Dieses umgebende Setup, das wir als „Harness“ bezeichnen, kann zentrale Aspekte der Systemleistung verändern, darunter wie es Tools nutzt, Informationen nachverfolgt oder mit Fehlern umgeht.

Dadurch ändert sich, wie Evaluierungen durchgeführt werden müssen und worauf Leser:innen in Evaluierungsberichten achten sollten. Aus unserer Sicht beschreiben die nützlichsten Berichte ausdrücklich zwei Dinge zusätzlich zum Ergebnis selbst: Erstens legen sie fest, welche Behauptung das Evaluierungs-Setup prüfen soll, und zweitens teilen sie die verfügbare Evidenz dafür, dass das Evaluierungsergebnis gültig ist.

In Evaluierungen geprüfte Behauptungen fallen typischerweise in eine von drei Kategorien¹:

• Fähigkeits-Elicitation: Kann ein Modell die evaluierte Fähigkeit plausibel hervorbringen? 
• Leistung von Schutzmaßnahmen: Wie robust sind die getesteten Schutzmaßnahmen gegenüber dem evaluierten Verhalten oder Angriff?
• Vergleich: Wie schneiden verschiedene Modelle unter gleichwertigen Bedingungen ab?

Evaluierungsberichte müssen außerdem erklären, wie Evaluierende auf Effekte geprüft haben, die die Validität eines Ergebnisses beeinträchtigen könnten. Dazu gehören:

• Reward Hacking: Das Ausnutzen von Abkürzungen in der Aufgabe oder im Scorer, sodass das System Anerkennung erhält, ohne das Verhalten zu zeigen, das die Evaluierung messen soll.
• Verweigerungen: Verweigerungen auf eine Weise, die das getestete Verhalten verschleiert.
• Kontamination: Überdurchschnittliche Leistung, weil Evaluierungsaufgaben, Antworten oder nahe Varianten in Trainingsdaten vorkamen oder während der Evaluierung auffindbar waren, etwa durch Browsing.
• Fehlerhafte Probleme: Minderleistung, weil Aufgaben ungültig sind. Gründe können etwa unfaires Scoring sein (z. B. wenn die richtige Antwort nicht genannte Implementierungsdetails voraussetzt) und unlösbare Umgebungen (z. B. fehlende kritische Dateien oder unzuverlässige Tools).
• Sandbagging: Absichtliche Minderleistung, wenn ein Modell oder System zeigt, dass es sich der Evaluierung bewusst ist.

Wir haben beobachtet, dass die Rolle des Harness besonders wichtig für Systeme ist, die über längere Vorgänge hinweg handeln. Wenn Modelle Tools nutzen, Zustand aufrechterhalten und über viele Schritte hinweg mit Fehlern umgehen können, kann das Harness das beobachtete Leistungsniveau verändern und sogar bestimmen, ob die bewertete Fähigkeit in der Evaluierung überhaupt erscheint. Ein Harness, das etwa Zustand bewahrt und fehlgeschlagene Aktionen wiederholt, kann einem Modell erlauben, eine mehrstufige Aufgabe abzuschließen, die dasselbe Modell in einem einfacheren Harness nie beendet.

In der folgenden Tabelle trennen wir drei Arten von Behauptungen, die Evaluierende möglicherweise aufstellen möchten, und das Harness, das aus unserer Sicht für jede Art von Behauptung erforderlich ist.

Fähigkeitsbehauptungen sind nur so stark wie die Elicitation, die ihnen zugrunde liegt: Evaluierende müssen das Harness wählen, das am besten zur Aufgabe und zur Fähigkeit passt, die die Evaluierung messen soll. Ein standardisiertes Harness kann für den Vergleich von Systemen unter identischen Bedingungen richtig sein, aber zur Unterschätzung von Fähigkeiten führen, wenn es bestimmte Harness-Funktionen auslässt, die dem Modell bei der Aufgabenerfüllung helfen. Die Leistung von GPT‑5.5 in OpenAIs Cyber-Ranges zeigt zum Beispiel, wie die Wahl des Harness die gemessene Fähigkeit bei Aufgaben, die lange, mehrstufige Tool-Nutzung erfordern, wesentlich verändern kann: Das Modell schneidet besser ab, wenn das Harness Compaction⁠ nutzt, um aufgabenrelevanten Kontext bei längerer Interaktion zu erhalten. Das zeigt, dass bei bestimmten Modellen ein Harness ohne Compaction die Leistung zu wenig hervorrufen würde.

Auch andere veröffentlichte Evaluierungen² zeigen, dass Entscheidungen zu Harness und Budget Evaluierungsergebnisse verändern. Mehr Rechenleistung zur Testzeit kann erheblich beeinflussen, welche Fähigkeit eine Evaluierung hervorruft, insbesondere in Bereichen, in denen Erfolg leicht zu verifizieren ist, etwa bei vielen Cyber-Aufgaben. In der Cyber-Range-Evaluierung von UK AISI⁠(wird in einem neuen Fenster geöffnet) verbesserte eine Erhöhung des Budgets von 10 Mio. auf 100 Mio. Token die Leistung um bis zu 59 %, und die Leistung stieg beim höchsten getesteten Budget noch weiter. Wenn dies detailliert beschrieben wird, wird die Evaluierung besser interpretierbar: Leser:innen sehen dann, wie das Ergebnis vom getesteten Elicitation-Setup abhängt. Wenn sich die Leistung mit zusätzlichem Budget weiter verbessert, sollte der Score als Leistung unter diesem Harness und Budget beschrieben werden, nicht als gemessene Fähigkeitsobergrenze. Fähigkeit ist oft ressourcenabhängig und keine feste Größe, die sich einmalig sauber messen lässt. Wo Erfolg über wiederholte Versuche hinweg gemessen werden kann, sollten Berichte auch die erwarteten Kosten pro erfolgreicher Lösung berücksichtigen, nicht nur die Erfolgsrate bei einem festen Token-Budget. Das kann die Schwere leichter interpretierbar machen: Eine niedrige Erfolgsrate kann praktisch dennoch bedeutsam sein, wenn die Kosten wiederholter Versuche innerhalb des relevanten Bedrohungsmodells liegen. Bei Fähigkeitsbehauptungen ist vermeidbare und zu geringe Elicitation ein Messfehler: Wenn das Harness oder Budget das System daran hindert, Verhalten zu zeigen, das es sonst hervorbringen könnte, misst der Score nicht die behauptete Fähigkeit. Wo Evaluierende die Elicitation so weit wie praktikabel vorangetrieben haben und sich die Leistung dennoch weiter verbessert, sollten Berichte dies klar sagen und deutlich machen, dass das Ergebnis nur eine Schätzung der Untergrenze ist.

Tests von Schutzmaßnahmen können unterschätzen, ob ein Angriff erfolgreich sein kann und wie schwerwiegend er werden könnte, wenn die den Angreifenden verfügbaren Ressourcen, einschließlich benutzerdefinierter Harnesses, nicht berücksichtigt werden. In der Cyber-Evaluierung von GPT‑5.5 durch UK AISI⁠(wird in einem neuen Fenster geöffnet) fand deren Red-Teaming durch Expert:innen einen universellen Jailbreak, der über die von OpenAI bereitgestellten bösartigen Anfragen hinweg regelverletzende Cyber-Inhalte hervorrief, auch in mehrzügigen agentischen Settings. Sie nutzten Codex, um ein benutzerdefiniertes Harness zu erstellen und die Angriffsleistung des Modells zu stärken: Es bettete ein wiederverwendbares Muster zur Umgehung von Schutzmaßnahmen in die Interaktion ein, bewahrte dieses Muster über Züge und Blöcke hinweg und wandte es auf die von OpenAI bereitgestellten bösartigen Cyber-Anfragen an. Tests von Schutzmaßnahmen sollten zum Angreifermodell passen. Wenn sich die Behauptung auf Robustheit gegenüber missbräuchlicher Nutzung durch Expert:innen bezieht, sollte der Test die stärkste glaubwürdige End-to-End-Angriffsstrategie unter einem definierten Budget evaluieren, einschließlich jedes Harness, das nötig ist, um diese Strategie zu bewahren und wiederzuverwenden. Andernfalls droht eine Fehlkalibrierung der Ergebnisse: Sie könnten nur eine engere Behauptung zur Resistenz gegen einfacheres Prompting stützen, sowohl die Schwere des Angriffs als auch seine Erfolgswahrscheinlichkeit verfehlen, sobald die Elicitation-Methode operationalisiert wird, und auch überschätzen, wie wahrscheinlich oder schwerwiegend ein Problem ist, wenn zu viel Budget gegeben wird.

Es gibt sinnvolle Einsatzmöglichkeiten für Vergleiche mit standardisierten Harnesses, aber Evaluierende sollten klar benennen, warum die Nutzung eines konsistenten Satzes von Harnesses angemessen ist und welche Behauptung damit gestützt werden kann. Die Zeithorizont-Evaluierung von METR⁠(wird in einem neuen Fenster geöffnet) ist ein Beispiel für ein breiteres, angemessen festgelegtes Evaluierungs-Setup: Es ist darauf ausgelegt, über die evaluierten Systeme hinweg vergleichbare Ergebnisse zu erzeugen. METR definiert ein gemeinsames Ergebnis, nämlich die typische Dauer einer menschlichen Aufgabe, bei der ein KI-Agent mit einem gegebenen Zuverlässigkeitsniveau voraussichtlich erfolgreich ist. Es verwendet innerhalb jeder gemeinsam berichteten Schätzungsrunde eine gemeinsame Aufgabensuite, Scoring-Methode, Fitting-Methode und eine kleine Menge wiederverwendbarer Scaffolds wie Triframe und ReAct⁠(wird in einem neuen Fenster geöffnet). Als METR die Aufgabensuite erweiterte und die Evaluierungsinfrastruktur von einem Framework namens Vivaria auf eines namens Inspect umstellte, wurde die Änderung berichtet (Time Horizon 1.1 Update⁠(wird in einem neuen Fenster geöffnet)) und Modelle wurden unter dem neuen Evaluierungs-Setup erneut evaluiert. Das ist der Wert eines standardisierten Evaluierungs-Setups einschließlich eines konsistenten Harness-Sets: Es kann Leser:innen Vertrauen geben, dass ein Unterschied in den Scores tatsächlich einen Unterschied zwischen den verglichenen Systemen widerspiegelt und nicht eine Änderung des Mess-Setups.

Wir empfehlen, dass Berichte zu Evaluierungen durch Dritte angeben, welche Art von Behauptung ihr Evaluierungs-Setup stützen soll; beschreiben, wie eng das Getestete diese breitere Behauptung abbildet; die Harness-Entscheidungen beschreiben, die das Ergebnis geprägt haben; darlegen, wann sich diese Entscheidungen zwischen Evaluierungen ändern; und unterstützende Evidenz enthalten, die zeigt, wie das Ergebnis zustande kam und wie gut es sich in Hinblick auf die Behauptung verallgemeinern lässt.

Je leistungsfähiger Modelle werden, desto leichter lassen sich Evaluierungsscores fehlinterpretieren. Im Verhältnis zu den tatsächlichen Fähigkeiten können Evaluierungsscores künstlich sinken, wenn ein Modell erkennt, dass es evaluiert wird, und strategisch eine niedrigere Leistung erbringt, als möglich. Sie können aufgebläht werden, wenn das Modell einen Shortcut bei der Aufgabe, im Prompt, im Scorer oder im Harness ausnutzt. Sie können auch durch Kontamination verzerrt werden (wenn ein Modell eine Antwort bereits kennt oder finden kann, ohne die Aufgabe zu lösen) oder durch „fehlerhafte“ Probleme, die mehrdeutig, falsch bewertet, unlösbar oder anfällig für unbeabsichtigte Shortcuts sind. Evaluierungsberichte sollten daher zentrale Scores mit einer Diskussion dieser Risiken verbinden, damit Leser:innen beurteilen können, ob die Scores das beabsichtigte Verhalten widerspiegeln.

Harnesses, Budgets, Tools, Scoring-Regeln, Monitore und Prüfverfahren beeinflussen alle, ob ein Agent die beabsichtigte Aufgabe löst, ihr ausweicht, sie auswendig kennt oder einen Weg findet, sie zu umgehen. Ein vertrauenswürdiger Bericht macht diese Prüfungen sichtbar: Evaluierende sollten Stichproben bei jeder Durchführung einer Bewertung auf diese Verhaltensweisen hin überprüfen.

Reward Hacking

Reward Hacking bedeutet, hohe Evaluierungsscores auf eine Weise zu erreichen, die die beabsichtigte Fähigkeit nicht widerspiegelt. Hier besteht die Sorge darin, dass dem System fälschlicherweise eine Leistung zugeschrieben wird, da es Aufgabe, Scorer, Prompt oder Harness ausnutzt, statt die Arbeit zu leisten, die die Evaluierung messen sollte. Die Evaluierung von GPT 5.4 durch METR⁠(wird in einem neuen Fenster geöffnet) zeigt, warum das wichtig ist: Obwohl das Modell Aufgaben zunächst mit einer Rate löste, die einem Zeithorizont von ungefähr 13 Stunden entsprochen hätte, zeigte die menschliche Prüfung, dass einige dieser Erfolge auf Reward Hacking zurückgingen, und die Überarbeitung der Ergebnisse unter Berücksichtigung nur der Fälle ohne Reward Hacking senkte die Schätzung auf etwa 6 Stunden. Evaluierende sollten prüfen, ob solche Anpassungen nötig sind, und sie, wenn ja, klar berichten: Eine Fähigkeitsschätzung ist viel nützlicher, wenn Leser:innen sehen können, welche scheinbaren Erfolge disqualifiziert wurden, warum sie disqualifiziert wurden und wie stark das Ergebnis von dieser Beurteilung abhängt.

Verweigerungen

Modelle können bei Fähigkeitsevaluierungen auch aufgrund von Schutzmaßnahmen eine niedrigere Leistung zeigen, als möglich. Ein Modell kann in einer Evaluierung schlechter abschneiden, als es eigentlich könnte, weil es Evaluierungsaufgaben verweigert, statt sie abzuschließen. Berichte sollten daher erklären, ob Verweigerungen Teil der Evaluierungsergebnisse waren und, falls ja, wie viele Stichproben dadurch beeinträchtigt wurden.

Kontamination

Kontamination ist vor allem bei öffentlichen oder wiederverwendeten Benchmarks⁠ relevant. Wenn Aufgaben, Antworten oder nahe Varianten in Trainingsdaten vorkommen oder von einem Agenten mit Browsing gefunden werden können, kann die Leistung eher das Speichern oder Abrufen von Informationen widerspiegeln als Modellleistung. Evaluierende sollten nach Möglichkeit private oder neu konstruierte Aufgaben bevorzugen und prüfen, ob Modelle aufgabenspezifische Details reproduzieren, bevor sie lösen.

Fehlerhafte Probleme

Fehlerhafte Probleme umfassen Situationen wie ein Problem, das versehentlich nicht lösbar ist. Fehlerhafte Probleme sind häufig genug⁠(wird in einem neuen Fenster geöffnet), dass sie als standardmäßiges Validitätsrisiko behandelt werden sollten. Dazu gehören falsche erwartete Antworten, mehrdeutige Prompts, fehlende Dateien, instabile Dienste, unfaire Scoring-Kriterien und Umgebungen, die Shortcuts offenlegen, etwa versteckte Antwortdateien oder Repository-Verläufe mit den erwarteten Antworten.

Sandbagging

Sandbagging durch ein Modell oder System bedeutet strategische Minderleistung, wenn starke Leistung mit einem Ziel in Konflikt geraten würde. Apollos Evaluierung von GPT‑5.5⁠(wird in einem neuen Fenster geöffnet) testete dies, indem ein Kontext geschaffen wurde, in dem das Modell verstand, dass hohe Evaluierungsscores Unlearning auslösen oder die Bereitstellung blockieren könnten. GPT‑5.5 antwortete dennoch korrekt, was auf wenig Verhaltens-Evidenz für strategische Minderleistung hindeutet³. Doch ihre Prüfung der Reasoning-Traces lieferte wichtigen Kontext: Apollo fand in 52 % der Stichproben unter Sandbagging-Bedingungen moderate oder stärkere Anzeichen für Bewusstsein für Alignment-Evaluierungen, verglichen mit 0 % in kontrafaktischen Fällen. Diese Evidenz erschwert die Interpretation des Ergebnisses, gibt Leser:innen letztlich aber mehr Signal: Sie sehen sowohl das beruhigende Verhaltensergebnis als auch den Grund, bei einer Überinterpretation vorsichtig zu sein.

Starke Behauptungen erfordern sowohl das richtige Harness, um das Verhalten hervorzurufen, als auch Validitätsprüfungen, die zeigen, dass das Ergebnis gültig ist. Unsere Auffassung, dass Harnesses und Validitätsprüfungen Teil des Evaluierungsergebnisses sind, prägt, wie wir Evaluierungen durch Dritte in der Praxis unterstützen: 

• Wir teilen mit Evaluierenden konkrete Leitlinien für maximale Elicitation.
• Wir bitten Evaluierende von Fähigkeiten, Codex als gemeinsamen Mindeststandard für OpenAI-Modelle zu verwenden: Tests sollten zumindest eine Baseline über dieselbe agentische Schnittstelle laufen lassen, auf die sich Nutzende voraussichtlich verlassen, statt nur über eine abgespeckte Modellschnittstelle.
• Außerdem stellen wir Reasoning-Traces und andere Zwischenartefakte dort bereit, wo sie nötig sind, um Täuschung, Sandbagging oder Bewusstsein für Evaluierungen zu beurteilen. METR und Apollo haben diesen Zugang in OpenAI-Evaluierungen seit GPT‑5 genutzt. 
• Schließlich priorisieren wir Forschung, um tiefer zu verstehen, wann und wie Harness-Entscheidungen Ergebnisse wesentlich verändern, von Kontextmanagement und Tool-Zugriff bis hin zu Wiederholungsverhalten, Scoring und Ressourcenbudgets.

Diese Empfehlungen sollen nicht nur einzelne Evaluierungsberichte verbessern, sondern auch als Grundlage für entstehende nationale ⁠(wird in einem neuen Fenster geöffnet)und internationale ⁠(wird in einem neuen Fenster geöffnet)Standards für die Evaluierung und Berichterstattung zu Frontier-KI dienen. Künftig sollten Standards für Evaluierungen durch Dritte genügend Details verlangen, damit Entscheidungstragende verstehen, welche Behauptungen die konkreten Evaluierungen stützen, welches System getestet wurde, wie das Ergebnis hervorgerufen wurde und wie Evaluierende seine Validität geprüft haben. Bei Frontier-Systemen, die an Aufgaben getestet werden, bei denen agentische Fähigkeiten wichtig sind, sollten die Details Folgendes umfassen (vorbehaltlich etwaiger Sicherheits- oder Vertraulichkeitsbedenken):

• Die Behauptung: ob die Evaluierung Systeme vergleicht, eine Fähigkeitsobergrenze schätzt oder Schutzmaßnahmen testet.
• Evaluierungsinhalt: genügend Details zu den Aufgaben oder der Aufgabenverteilung, damit Leser:innen verstehen, welche Fähigkeiten, Verhaltensweisen oder Fehlermodi die Evaluierung tatsächlich testet.
• Das getestete System: das Modell, die Reasoning-Einstellung, Tool-Zugriff, Harness und Schutzmaßnahmen.
• Das Budget: Züge, Token, Versuche/Wiederholungen, verstrichene Zeit, Inferenzkosten und, wo anwendbar, erwartete Kosten pro erfolgreicher Lösung.
• Elicitation-Methoden: Harness-Entscheidungen, die genutzt wurden, um das Ergebnis hervorzurufen, und inwiefern das Getestete die breitere Behauptung widerspiegelt.
• Validitätsprüfungen: wie Bewertende nach Reward Hacking, Evaluierungsbewusstsein, Kontamination, Verweigerungen, Sandbagging und anderen Verhaltensweisen gesucht haben, die das Ergebnis untergraben könnten, einschließlich der Frage, wie bestätigte Fälle Scoring oder Interpretation beeinflusst haben.

Standards, die Harness-Entscheidungen oder Validitätsprüfungen auslassen, können unterschätzen, was ein System leisten kann, oder das Vertrauen in eine Sicherheitsbehauptung überschätzen. Der Aufbau starker Harnesses und Elicitation-Methoden bleibt ein offenes Forschungsfeld und sollte im Fokus weiterer Untersuchung und Investitionen stehen.