Google DeepMinds dubbelblinda Gemini-test håller både modellen och testfrågorna hemliga

Google DeepMind har testat en proprietär Gemini-modell utan att ge testorganisationerna tillgång till modellens vikter – och utan att själv få se de konfidentiella testfrågorna. Projektet genomfördes tillsammans med Singapore AI Safety Institute, OpenMined, AVERI och MLCommons och presenterades den 27 augusti 2026 som den första dubbelblinda utvärderingen av en proprietär AI-modell i frontier-klassen. 1213

Grundidén är enkel, även om tekniken bakom den är avancerad: båda sidor lämnar sina känsliga tillgångar utanför räckhåll för den andra parten. Modellen och testmaterialet möts först i en hårdvaruskyddad miljö där den godkända utvärderingen körs.

Det är viktigt eftersom AI-säkerhetstester vanligtvis innebär en svår avvägning. Om utvecklaren får tillgång till privata testfrågor kan materialet, avsiktligt eller oavsiktligt, loggas, återanvändas i träning eller påverka framtida tester. Om externa granskare i stället får modellvikterna exponeras värdefull immateriell egendom och potentiellt känslig AI-kapacitet.

Vad testades i Gemini-piloten?

Piloten använde ett mindre, privat urval från MLCommons benchmarkfamilj AILuminate. AVERI uppger att frågorna aldrig tidigare hade visats för Google DeepMind. De användes för att undersöka modellens säkerhetsbeteende inom bland annat hjälp med cyberattacker, kemiska och biologiska risker, hatretorik, självskada och framkallande av våldsbrott. 1

Benchmarkmaterialet förblev konfidentiellt under hela processen. AVERI krypterade frågorna, den skyddade miljön körde modellen och utvärderingen, och resultaten dekrypterades därefter och bedömdes enligt de kriterier som parterna hade kommit överens om. Piloten skulle framför allt visa att metoden fungerar – inte skapa en vanlig offentlig resultattabell. Varken övergripande modellpoäng eller de underliggande frågorna publicerades. 1

Så fungerade det dubbelblinda upplägget

Utvärderingen kördes i Google Cloud Confidential Computings Confidential Space på en A3 Confidential VM. Enligt den tekniska rapporten krypterade och isolerade Intel TDX värdens arbetsminne, medan ett NVIDIA H100 Confidential GPU skyddade modellvikterna i grafikminnet med hårdvarubaserad kryptering. Krypterade anslutningar transporterade testarnas frågor och Googles modellresurser till den skyddade miljön. 13

Arkitekturen innehöll också kontrollmekanismer som skulle begränsa både vad arbetslasten kunde göra och vilken information som kunde lämna miljön. Bland dem fanns krypterade dataflöden, hårdvarubrandväggar, en tillfällig enclave-livscykel och OpenMineds policy-lager PySyft. Modellen, inferenskoden, testfrågorna och utvärderingskoden sammanfördes först inne i den godkända enclaven, där den avtalade beräkningen genomfördes och endast begränsade resultat kunde returneras. 13

Därför var fjärrattestering viktig

Kryptering räcker inte för att visa vilken programvara som faktiskt körs. Där kommer fjärrattestering in. Innan någon av parterna lämnade över sina skyddade tillgångar kunde Google och utvärderarna granska den deklarerade arbetslasten och kontrollera ett så kallat attesteringsbevis, en kryptografisk bekräftelse av den skyddade hårdvaran och enclave-konfigurationen. Först därefter gjordes de krypterade testfrågorna och modellresurserna tillgängliga i miljön. 13

När körningen var klar skickade enclaven tillbaka de tillåtna utvärderingsresultaten och stängdes sedan ned. Enligt den avsedda tillitsmodellen kunde Google inte läsa frågorna inne i enclaven, medan de externa utvärderarna inte kunde extrahera modellvikterna. Det är ett starkare skydd än att enbart förlita sig på ett avtal om att inte logga eller återanvända data – men alla tillitsantaganden försvinner inte. 13

Vilket problem försöker metoden lösa?

Kontaminering av benchmarktester är ett återkommande problem inom AI-utvärdering. Ett test blir mindre informativt om modellen redan har sett frågorna under träning, finjustering eller tidigare tester. MLCommons framhåller att tillförlitliga benchmarktester kräver rena data, dokumenterad härkomst, genomtänkt urval och tillräcklig transparens för att andra ska kunna förstå hur resultaten skapades. 2024

Dubbelblind utvärdering erbjuder ett tredje alternativ mellan två ofullkomliga lösningar:

• Ge utvecklaren testfrågorna: Det förenklar genomförandet, men kan avslöja reserverat benchmarkmaterial och skapa risk för läckage.
• Ge utvärderarna modellvikterna: Det skyddar benchmarktestet från direkt exponering för frågorna, men är normalt orimligt för proprietära frontier-modeller.
• Använd en konfidentiell enclave: Modellen och testmaterialet möts i en hårdvaruskyddad miljö, utan att någon part får den andras hemliga tillgångar i klartext.

Piloten visar därmed en möjlig teknisk lösning för att bevara sekretessen på båda sidor och samtidigt möjliggöra extern granskning. Den bevisar däremot inte i sig att slutsatserna om modellens säkerhet är fullständiga eller avgörande.

Viktiga begränsningar

Det tekniska pilotprojektet är betydelsefullt, men det finns flera skäl att vara försiktig med vad resultaten kan sägas visa.

För det första kunde utvärderarna kontrollera den deklarerade enclave-arbetslasten och modellens gränssnitt, men de kunde inte självständigt granska Googles proprietära modellvikter eller hela inferensimplementeringen. Därför kunde de inte fullt ut kontrollera att körningen i alla avseenden fungerade exakt som avsett. 13

För det andra var miljön inte oberoende reproducerbar från början till slut. Distributionen och molninfrastrukturen låg kvar under Googles kontroll i stället för att byggas upp och köras om av en oberoende part. Attesteringsprocessen byggde dessutom fortfarande på Google Clouds hårdvara, fast programvara, serversystem och infrastruktur för attestering. Hårdvarubaserad verifiering är starkare än ett löfte om att inte logga data, men den eliminerar inte beroendet av den bredare leveranskedjan. 13

För det tredje publicerades varken de privata frågorna eller några numeriska resultat. Hemlighållandet hjälper till att bevara frågornas värde för framtida tester, men begränsar också allmänhetens insyn, jämförelser mellan modeller och oberoende validering av de konkreta slutsatserna. AVERI beskriver arbetet som en kvalitativ och mindre kvantitativ bedömning, inte som ett fullständigt offentligt benchmarkresultat. 1

Varför detta ännu inte är en branschstandard

Säker hårdvara löser bara en del av problemet. För att dubbelblinda tester ska bli en etablerad branschpraxis måste även styrningen runt tekniken utvecklas.

Juridiska och institutionella skydd behöver reglera datahantering, tillåtna resultat, offentliggörande, ansvar och åtkomst – särskilt när testerna rör farliga förmågor.

Förvaltning av benchmarkmaterial behöver omfatta frågornas ursprung, urval, märkning, dokumentation, uppdateringar och kontroll av kontaminering. MLCommons betonar att ett benchmark inte blir tillförlitligt enbart för att materialet hålls hemligt. Även hur materialet skapas och underhålls måste kunna försvaras. 2025

Oberoende reproducerbarhet skulle kräva meningsfull granskning av bygget, attesteringskedjan, körningspolicyerna och de rapporterade resultaten av aktörer som står utanför både modellutvecklaren och molnoperatören.

Skalbarhet är också avgörande. En användbar standard måste fungera för olika modellutvecklare, arkitekturer, molnmiljöer, utvärderare, benchmarktyper och återkommande modellversioner – inte bara i ett skräddarsytt samarbete som använder en enda hårdvaruplattform.

Google DeepMinds Gemini-pilot bör därför ses som infrastruktur för en mer trovärdig AI-utvärdering, inte som det slutgiltiga svaret på hur benchmarktester ska litas på. Den visar hur konfidentiell databehandling kan minska konflikten mellan att skydda testdata och att skydda proprietära modeller. Om metoden ska bli ett övertygande underlag på branschnivå krävs dock oberoende tillsyn, robust benchmarkförvaltning, juridiskt skydd, reproducerbarhet och praktisk genomförbarhet – inte bara kryptering i en enclave. 1320