Googles Doppelblind-Test für Gemini soll KI-Benchmarks glaubwürdiger machen

Google DeepMind hat einen Weg erprobt, ein proprietäres Frontier-Modell extern testen zu lassen, ohne der Modellanbieterin die vertraulichen Testfragen zu überlassen oder den Prüfern Zugriff auf die Modellgewichte zu geben. Beim am 27. August 2026 vorgestellten Pilotprojekt wurde Gemini 2.5 Flash-Lite gemeinsam mit dem Singapore AI Safety Institute, OpenMined, AVERI und MLCommons evaluiert. Google bezeichnete das Verfahren als erste Doppelblind-Evaluierung eines proprietären Frontier-KI-Modells. 1213

Die Grundidee ist einfach: Beide Seiten bringen ihre sensiblen Daten in eine geschützte Umgebung ein, ohne die Geheimnisse der jeweils anderen Seite im Klartext zu erhalten. Das ist relevant, weil herkömmliche Sicherheitstests häufig vor einem Dilemma stehen. Erhält der Entwickler die privaten Prompts, könnten sie protokolliert, absichtlich oder versehentlich für späteres Training genutzt oder auf andere Weise in künftige Tests eingeschleust werden. Erhalten die Prüfer dagegen die Modellgewichte, bekommen sie wertvolles geistiges Eigentum und möglicherweise sicherheitsrelevante Fähigkeiten zu sehen.

Was im Gemini-Pilotprojekt getestet wurde

Für den Versuch kam eine kleine private Auswahl aus der MLCommons-Benchmarkfamilie AILuminate zum Einsatz. Laut AVERI waren die Prompts Google DeepMind zuvor nicht zugänglich. Sie sollten das Sicherheitsverhalten des Modells unter anderem bei Hilfestellungen zu Cyberangriffen, chemischen und biologischen Gefahren, Hassrede, Selbstverletzung und dem Anstiften zu Gewaltkriminalität untersuchen. 1

Die Benchmark-Inhalte blieben während der gesamten Evaluierung vertraulich. AVERI verschlüsselte die Prompts, die geschützte Umgebung führte Modell und Testprozess aus, und die daraus entstandenen Ausgaben wurden anschließend entschlüsselt und anhand der vereinbarten Kriterien bewertet. Der Pilot sollte vor allem die Methode demonstrieren – nicht eine gewöhnliche öffentliche Rangliste liefern. Weder zentrale Modellwerte noch die zugrunde liegenden Prompts wurden veröffentlicht. 1

So funktionierte das Doppelblind-Verfahren

Die Evaluierung lief in Googles Cloud-Umgebung Confidential Space auf einer A3 Confidential VM. Laut dem technischen Bericht verschlüsselte und isolierte Intel TDX den Speicher des Hosts. Eine vertrauliche NVIDIA-H100-GPU schützte die Modellgewichte im Grafikspeicher mit hardwarebasierter Verschlüsselung. Verschlüsselte Verbindungen transportierten die Prompts der Prüfer und Googles Modellressourcen in die geschützte Umgebung. 13

Zusätzlich kamen Kontrollen zum Einsatz, die den Handlungsspielraum der Arbeitslast und die zurückgegebenen Daten begrenzen sollten. Dazu gehörten verschlüsselte Datenpfade, Hardware-Firewalls, ein nur für die jeweilige Ausführung bestehender Enklaven-Lebenszyklus sowie die Policy-Schicht PySyft von OpenMined. Modell, Inferenzcode, Prompts und Evaluierungscode wurden erst innerhalb der freigegebenen Enklave zusammengeführt. Dort konnte nur die zuvor vereinbarte Berechnung ausgeführt werden; nach außen gelangten lediglich begrenzte Ergebnisse. 13

Warum die Remote-Attestierung wichtig war

Verschlüsselung allein zeigt den Beteiligten noch nicht, welche Software tatsächlich ausgeführt wird. Hier sollte die sogenannte Remote-Attestierung helfen. Bevor sie ihre geschützten Daten freigaben, konnten Google und die Prüfer die deklarierte Arbeitslast prüfen und ein Attestierungszitat verifizieren, das die Hardware und die Konfiguration der Enklave auswies. Erst danach wurden die verschlüsselten Prompts und Modellressourcen für die Umgebung freigeschaltet. 13

Nach Abschluss des Durchlaufs gab die Enklave die erlaubten Evaluierungsergebnisse zurück und wurde anschließend stillgelegt. Im vorgesehenen Vertrauensmodell konnte Google die Prompts innerhalb der Enklave nicht lesen; die externen Prüfer konnten die Modellgewichte nicht herauslösen. Das ist ein stärkerer Schutz als die alleinige vertragliche Zusage, Daten weder zu protokollieren noch wiederzuverwenden. Alle Vertrauensannahmen beseitigt das Verfahren jedoch nicht. 13

Welches Problem der Ansatz lösen soll

Die Verunreinigung von Benchmarks – auf Englisch „benchmark contamination“ – ist ein dauerhaftes Problem bei KI-Evaluierungen. Ein Test verliert an Aussagekraft, wenn ein Modell seine Prompts bereits im Training, beim Fine-Tuning oder in früheren Tests gesehen hat. MLCommons zufolge brauchen vertrauenswürdige Benchmarks saubere Daten, nachvollziehbare Herkunft, sorgfältige Stichproben und genügend Transparenz, damit andere verstehen können, wie Ergebnisse zustande gekommen sind. 2024

Das Doppelblind-Verfahren bietet eine dritte Möglichkeit zwischen zwei unbefriedigenden Standardlösungen:

• Die Prompts an den Entwickler geben: Das vereinfacht die technische Durchführung, kann aber geheime Benchmark-Inhalte offenlegen und Leaks in spätere Trainings- oder Optimierungsprozesse begünstigen.
• Den Prüfern die Modellgewichte geben: Das schützt den Benchmark vor einem direkten Zugriff auf die Testfragen, ist bei proprietären Frontier-Modellen wegen des sensiblen geistigen Eigentums aber in der Regel keine realistische Option.
• Eine vertrauliche Enklave nutzen: Modell und Benchmark treffen in einer hardwaregeschützten Umgebung aufeinander. Keine Seite erhält das geheime Gut der anderen im Klartext.

Der Pilot zeigt damit einen plausiblen Mechanismus, der beidseitige Vertraulichkeit während einer externen Evaluierung ermöglichen kann. Er beweist jedoch nicht automatisch, dass die daraus abgeleiteten Sicherheitsurteile vollständig oder unabhängig entscheidend sind.

Die wichtigsten Grenzen des Pilotprojekts

Technisch war der Versuch bedeutsam. Dennoch schränken mehrere Punkte ein, was sich daraus ableiten lässt.

Erstens konnten die Prüfer zwar die deklarierte Enklaven-Arbeitslast und die Modellschnittstelle überprüfen, nicht aber Googles proprietäre Gewichte oder die vollständige Implementierung der Inferenz unabhängig untersuchen. Dadurch blieb ihre Möglichkeit begrenzt, das Laufzeitverhalten in jeder Hinsicht zu auditieren. 13

Zweitens war die Betriebsumgebung nicht vollständig unabhängig reproduzierbar. Bereitstellung und Cloud-Infrastruktur blieben unter Googles Kontrolle, statt von einer unbeteiligten Partei neu aufgebaut und erneut ausgeführt zu werden. Auch die Attestierung beruhte weiterhin auf der Hardware, Firmware, den Bereitstellungssystemen und der Attestierungsinfrastruktur von Google Cloud. Eine hardwaregestützte Verifikation ist zwar stärker als das Versprechen, nichts zu protokollieren; sie beseitigt aber nicht die Abhängigkeit von dieser umfassenderen Liefer- und Vertrauenskette. 13

Drittens wurden weder die privaten Prompts noch numerische Ergebnisse veröffentlicht. Die Geheimhaltung schützt den Wert der Testfragen für künftige Evaluierungen, begrenzt aber zugleich die öffentliche Kontrolle, den Vergleich mit anderen Modellen und die unabhängige Überprüfung der inhaltlichen Ergebnisse. AVERI beschreibt die Arbeit als qualitative sowie quantitativ begrenzte Untersuchung – nicht als vollständiges öffentliches Benchmark-Ergebnis. 1

Warum das noch kein Industriestandard ist

Sichere Hardware löst nur einen Teil des Evaluierungsproblems. Damit Doppelblind-Tests zu einer dauerhaften Praxis werden können, müsste auch der organisatorische und rechtliche Rahmen weiterentwickelt werden.

Rechtliche und institutionelle Schutzmechanismen sollten den Umgang mit Daten, zulässige Ausgaben, Offenlegungspflichten, Haftung und Zugriffsrechte regeln – besonders bei Tests zu gefährlichen Fähigkeiten.

Eine verantwortliche Benchmark-Pflege müsste Herkunft, Stichproben, Kennzeichnung, Dokumentation, Aktualisierung und die Überwachung möglicher Kontamination abdecken. MLCommons betont, dass ein Benchmark nicht allein deshalb vertrauenswürdig ist, weil seine Daten geheim bleiben. Auch seine Erstellung und laufende Pflege müssen vertretbar und nachvollziehbar sein. 2025

Unabhängige Reproduzierbarkeit würde eine aussagekräftige Prüfung von Build-Prozess, Attestierungskette, Ausführungsregeln und gemeldeten Ergebnissen durch Akteure außerhalb von Modellanbieter und Cloud-Betreiber erfordern.

Skalierbarkeit ist ebenfalls entscheidend. Ein brauchbarer Standard müsste mit unterschiedlichen Modellanbietern, Architekturen, Cloud-Umgebungen, Prüfern, Benchmark-Typen und wiederholten Modellveröffentlichungen funktionieren – nicht nur in einer maßgeschneiderten Kooperation mit einem einzigen Hardware-Stack.

Der Gemini-Pilot von Google DeepMind ist daher am besten als Infrastrukturversuch für eine schwierigere Form der KI-Evaluierung zu verstehen, nicht als abschließende Lösung für vertrauenswürdige Benchmarks. Er zeigt, wie Confidential Computing den Konflikt zwischen dem Schutz von Testdaten und dem Schutz proprietärer Modelle entschärfen kann. Ob daraus belastbare Evidenz im industriellen Maßstab entsteht, hängt jedoch von unabhängiger Aufsicht, guter Benchmark-Governance, rechtlichen Absicherungen, Reproduzierbarkeit und praktikablem Betrieb ab – nicht von Enklaven-Kryptografie allein. 1320