Third-party KI-Evals sind jetzt ein Procurement-Gate — lies sie wie ein Käufer

OpenAI hat gerade ein gemeinsames Playbook für vertrauenswürdige Third-party-Evaluierungen veröffentlicht — ein strukturiertes Framework dafür, wie Frontier-Model-Evals designed, durchgeführt und reportet werden sollten. Für Forscher ist das Methodik. Für CTOs ist es etwas anderes: eine Vorschau auf den Standard, den deine Procurement- und Infosec-Teams in ein bis zwei Quartalen umsetzen müssen. Was die meisten Berichte übersehen: Dieses Dokument gibt Käufern eine Checkliste — und die entscheidende Frage ist, ob du weißt, wie du sie benutzt.

Was sich an der Rahmung von Evaluierungen geändert hat

OpenAIs Guidance gliedert Third-party-Evals in drei separate Tracks: Capability Evaluations (was kann das Modell tatsächlich?), Safeguard Evaluations (welche Verhaltensweisen wurde es trainiert oder angewiesen zu unterdrücken?) und Validity Assessments (messen die Benchmarks wirklich das, was sie zu messen behaupten?). Jeder Track erfordert laut Dokument andere Evaluator-Expertise, anderen Zugang zu Modell-Interna und andere Reporting-Standards.

Das Dokument trifft außerdem eine pointierte Unterscheidung zwischen Evals, die mit Kooperation des Modell-Providers durchgeführt werden, und solchen, die adversarisch oder unabhängig laufen. Kooperative Evals bekommen vollständigeren Zugang, tragen aber das Risiko, Ergebnisse in Richtung der bevorzugten Narrative des Providers zu lenken. Unabhängige Evals wahren die Objektivität, arbeiten aber oft nur auf Modell-Outputs — und verpassen dabei Instruction-Tuning-Artefakte oder System-Prompt-Defaults, die im Produktionseinsatz enorm wichtig sind.

Das ist die Rahmung, die deine Vendor demnächst in ihrer Security-Dokumentation übernehmen werden. Das Timing ist kein Zufall: Die Konformitätsbewertungspflichten des EU AI Acts für Hochrisikosysteme treten dieses Jahr vollständig in Kraft — und mehrere große Enterprise-Procurement-Frameworks, darunter auch US-Federal-Contractor-KI-Guidance, konvergieren auf Third-party-Eval-Anforderungen als akzeptablen Nachweis für Due Diligence.

Warum das die Mathematik beim Vertrauen in Vendor-Safety-Claims verändert

Bis vor Kurzem konnte ein Frontier-Model-Vendor dir eine Model Card hinlegen, ein paar akademische Benchmarks zitieren und es dabei belassen. Diese Ära geht zu Ende. Was OpenAIs Playbook signalisiert — auch wenn unbeabsichtigt — ist, dass die Branche ein gemeinsames Vokabular dafür konsolidiert, wie eine glaubwürdige Eval aussieht. Dieses Vokabular wird in einem Vendor-Review gegen dich verwendet, wenn du es nicht sprichst.

Das eigentliche Problem: Die meisten Eval-Reports, die im Umlauf sind, scheitern an mindestens einem der drei Tracks. Capability-Claims sind häufig benchmark-optimiert — trainiert auf Daten, die sich mit dem Test-Set überschneiden, auf eine Art, die der Report nicht offenlegt. Safeguard-Claims sind fast immer kooperative Evals: Der Modell-Provider hat die Prompts ausgewählt, die Harm-Kategorien definiert und in manchen Fällen die Evaluierung selbst durchgeführt — mit einer nominalen Third-party-Unterschrift auf der Titelseite. Validity ist der Track, den fast jeder Vendor-Report komplett überspringt, weil der Evaluator dabei verteidigen muss, warum sein Benchmark das Verhalten in der realen Welt vorhersagt — ein vertretbares, aber schwieriges Argument.

Für deinen Stack ist das am wichtigsten, wenn du ein Modell in einem Kontext einsetzt, in dem ein Fehler regulatorische, reputationsbezogene oder vertragliche Konsequenzen hat: kundenseitige Automatisierung, juristische Dokumentenverarbeitung, HR-Screening-Tools, medizinischer Informationsabruf. In diesen Kontexten ist ein Capability-Claim ohne Validity-Abschnitt kein Nachweis — es ist Marketing.

→ Buch ein Domani AI Architecture Audit, wenn du gerade mitten im Procurement für ein Frontier Model steckst und eine externe Einschätzung brauchst, ob die Eval-Dokumentation standhält.

Der Montag-Morgen-Move: ein Entscheidungsbaum zum Lesen eines Eval-Reports

Wenn ein Vendor dir einen Eval-Report übergibt — oder wenn du ein Modell für den internen Einsatz prüfst — lass ihn diese Gates durchlaufen, bevor er eine Build-or-Buy-Entscheidung beeinflusst.

Gate 1: Wer hat die Eval durchgeführt, und worauf hatte der Evaluator Zugriff?

• Wenn der Evaluator direkt vom Modell-Provider bezahlt wurde und kein vorregistriertes Protokoll hatte: Capability-Claims als Orientierung behandeln, nicht als Beweis.
• Wenn der Evaluator Zugang zu Weights oder Fine-Tuning hatte: Safeguard-Claims sind vertrauenswürdiger als reine Output-Audits — aber prüf auf Offenlegung von Interessenkonflikten.
• Wenn der Evaluator vollständig unabhängig ohne Provider-Zugang war: Die Validität der Benchmark-Wahl zählt mehr als der Score selbst.

Gate 2: Sind Capability-, Safeguard- und Validity-Claims getrennt oder gebündelt?

• Gebündelte Reports, die einen einzigen Score für alle drei Tracks verwenden, sind fast immer Marketing-Dokumente. Trenn sie manuell, wenn nötig: Finde heraus, wo die Capability-Claims enden und die Safety-Claims beginnen.
• Ein fehlender Validity-Abschnitt ist ein gelbes Flag. Frag den Vendor: Warum sagt dieser Benchmark deinen Produktions-Use-Case vorher?

Gate 3: Was ist der Umfang der Safeguard-Evaluierung?

• Frag explizit: Wurden die Harm-Kategorien vom Evaluator oder vom Provider definiert?
• Frag: Welche Adversarial-Prompting-Methodik wurde verwendet — und war sie konsistent mit deinem Deployment-Kontext (API-Zugang, System-Prompt, Tool Use)?
• Wenn die Safeguard-Eval auf dem Base Model durchgeführt wurde, du aber eine fine-getunte oder system-gepromptete Variante einsetzt: Die Eval gilt nicht für dein Deployment. Fordere eine neue an oder scope deine Haftung entsprechend ein.

Gate 4: Ist der Report reproduzierbar?

• Ist der Benchmark öffentlich? Sind die Prompts offengelegt? Wenn beides nicht: Der Report kann nicht unabhängig verifiziert werden — das solltest du in deine Risikobewertung einpreisen.

Diese Woche: Zieh die Eval-Dokumentation für jedes Frontier Model, das gerade in Procurement ist oder live in deinem Stack läuft. Starte mit Gates 1 und 3 — die fangen den Großteil der Validity-Failures mit dem geringsten Zeitaufwand ab. Alles, was Gate 3 nicht besteht, sofort zur rechtlichen und Compliance-Prüfung eskalieren — vor dem nächsten Deployment-Increment.

Was das kostet — und was es dir spart

Einen Eval-Report kritisch zu lesen kostet 2 bis 4 Stunden pro Vendor in deinem Procurement-Zyklus. Ein unabhängiges Architecture Review gegen einen konkreten Deployment-Kontext in Auftrag zu geben — der nächste Schritt, wenn ein Report Gate 2 oder 3 nicht besteht — dauert 3 bis 6 Wochen und kostet echtes Geld. Das ist keine kleine Forderung in einem Quartal mit Shipping-Druck.

Die Gegenrechnung ist schwerer zu sehen, bis sie eintrifft. Ein Safeguard-Claim, der unter deinem tatsächlichen System-Prompt nicht hält, ist eine Haftungsexposition — kein Vendor-Problem. Regulatorische Durchsetzung unter dem EU AI Act bei Hochrisikosystem-Failures kann bis zu 3 % des globalen Jahresumsatzes erreichen — und "die Eval des Vendors hat es als sicher eingestuft" wurde in keiner veröffentlichten Guidance als Compliance-Verteidigung akzeptiert. Der Montag-Morgen-Move zielt nicht auf Perfektion — sondern darauf, zu wissen, welche Claims in deinem aktuellen Stack tragende Wände sind und welche Dekoration, bevor jemand anderes das herausfindet.