Slik testet Google DeepMind Gemini uten å dele modellen eller testspørsmålene

Google DeepMind har gjennomført en pilot der en proprietær frontklassemodell ble testet uten at modellutvikleren fikk se evalueringsspørsmålene, og uten at de eksterne evaluatorene fikk tilgang til modellvektene. Gemini 2.5 Flash-Lite ble testet i samarbeid med Singapore AI Safety Institute, OpenMined, AVERI og MLCommons. Google beskrev prosjektet som den første dobbeltblinde evalueringen av en proprietær frontklasse AI-modell. 1213

Grunntanken er enkel: Begge parter beholder sine mest sensitive ressurser for seg selv, mens en godkjent test likevel kan gjennomføres. Det er viktig fordi tradisjonelle sikkerhetstester ofte innebærer et vanskelig valg. Hvis utvikleren får tilgang til private testspørsmål, kan spørsmålene bli logget, brukt med vilje eller ved et uhell i senere trening, eller på annen måte forurense framtidige tester. Hvis evaluatorene får modellvektene, får de tilgang til verdifull immateriell eiendom og en potensielt sensitiv kapasitet.

Hva Gemini-piloten testet

Piloten brukte et lite, privat utvalg fra MLCommons’ AILuminate-familie av sikkerhets­benchmarker. AVERI opplyser at spørsmålene ikke tidligere var gjort tilgjengelige for Google DeepMind. De ble brukt til å undersøke modellens sikkerhetsatferd på områder som hjelp til cyberangrep, kjemiske og biologiske farer, hatefulle ytringer, selvskading og utløsning av voldskriminalitet. 1

Benchmarkmaterialet forble konfidensielt under hele evalueringen. AVERI krypterte spørsmålene, det beskyttede miljøet kjørte modellen og evalueringsprosessen, og resultatene ble deretter dekryptert og vurdert etter avtalte kriterier. Piloten skulle først og fremst demonstrere metoden – ikke lage en vanlig offentlig rangering. Derfor ble det ikke publisert noen hovedpoengsum eller de underliggende testspørsmålene. 1

Slik fungerte den dobbeltblinde løsningen

Evalueringen ble kjørt i Google Clouds Confidential Space, en løsning for konfidensiell databehandling, på en A3 Confidential VM. Ifølge den tekniske rapporten krypterte og isolerte Intel TDX minnet på vertsmaskinen, mens et NVIDIA H100 Confidential GPU-kort beskyttet modellvektene i GPU-minnet med maskinvarebasert kryptering. Krypterte forbindelser fraktet evaluatorens spørsmål og Googles modellressurser inn i det beskyttede miljøet. 13

Løsningen brukte også kontroller som skulle begrense hva arbeidsbelastningen kunne gjøre, og hvilke data den kunne returnere. Blant disse var krypterte dataforbindelser, maskinvarebrannmurer, en midlertidig enclave-livssyklus og OpenMineds policy-lag PySyft. Modellen, inferenskoden, spørsmålene og evalueringskoden ble først samlet inne i den godkjente enclaven – et isolert, beskyttet kjøringsmiljø – der den avtalte beregningen kunne gjennomføres og avgrensede resultater sendes ut. 13

Derfor var fjernattestering viktig

Kryptering alene forteller ikke deltakerne hvilken programvare som faktisk kjører. Fjernattestering skulle løse dette problemet. Før de sendte inn sine beskyttede ressurser, kunne Google og evaluatorene inspisere den deklarerte arbeidsbelastningen og kontrollere en attestasjonskvittering som identifiserte maskinvaren og konfigurasjonen i enclaven. Først etter denne kontrollen ble de krypterte spørsmålene og modellressursene gjort tilgjengelige for miljøet. 13

Da kjøringen var ferdig, returnerte enclaven de tillatte evalueringsresultatene og ble tatt ut av drift. I den tiltenkte tillitsmodellen kunne Google ikke lese spørsmålene inne i enclaven, mens de eksterne evaluatorene ikke kunne hente ut modellvektene. Dette er sterkere enn å basere seg utelukkende på en kontraktsfestet lovnad om ikke å loggføre eller gjenbruke testdata, men metoden fjerner ikke alle forutsetninger for tillit. 13

Hvilket problem forsøker metoden å løse?

Forurensning av benchmarkdata er et vedvarende problem i AI-evaluering. En test blir mindre informativ hvis modellen har sett spørsmålene under trening, finjustering eller tidligere tester. MLCommons skriver at pålitelige benchmarker krever rene data, dokumentert opphav, nøye utvalg og nok åpenhet til at andre kan forstå hvordan resultatene ble produsert. 2024

Dobbeltblind evaluering gir et tredje alternativ mellom to ufullkomne løsninger:

• Gi utvikleren testspørsmålene: Det gjør gjennomføringen enkel, men kan eksponere reserverte benchmarkdata og skape risiko for lekkasje.
• Gi evaluatorene modellvektene: Det beskytter benchmarken mot direkte tilgang til spørsmålene, men er som regel uaktuelt for proprietære frontklassemodeller.
• Bruk en konfidensiell enclave: Modellen og benchmarken møtes i et maskinvarebeskyttet miljø, uten at noen av partene får den andres hemmelige ressurs i klartekst.

Piloten demonstrerer dermed en mulig måte å beskytte begge sider på samtidig som en ekstern evaluering kan gjennomføres. Den beviser ikke i seg selv at sikkerhetskonklusjonene er fullstendige eller avgjørende på egen hånd.

Viktige begrensninger ved piloten

Dette var en teknisk betydningsfull demonstrasjon, men flere begrensninger setter grenser for hva man kan konkludere med.

For det første kunne evaluatorene kontrollere den deklarerte enclave-arbeidsbelastningen og modellgrensesnittet, men ikke inspisere Googles proprietære modellvekter eller inferensimplementasjon uavhengig. Det begrenser muligheten til å kontrollere om kjøremiljøet i alle henseender oppførte seg nøyaktig slik det var ment. 13

For det andre kunne ikke hele driftsmiljøet gjenskapes uavhengig fra ende til ende. Utrullingen og skyinfrastrukturen var fortsatt under Googles kontroll, i stedet for å bli bygget opp og kjørt på nytt av en uavhengig aktør. Attestasjonsprosessen var dessuten fortsatt avhengig av Google Clouds maskinvare, fastvare, betjeningssystemer og attestasjonsinfrastruktur. Maskinvarebasert verifisering er sterkere enn et løfte om ikke å loggføre data, men den fjerner ikke avhengigheten av denne bredere leverandørkjeden. 13

For det tredje ble verken de private spørsmålene eller tallresultatene publisert. Hemmeligholdet bidrar til å bevare spørsmålene som verdifulle testdata for framtidige evalueringer, men begrenser samtidig offentlig innsyn, sammenligning mellom modeller og uavhengig validering av funnene. AVERI beskriver arbeidet som en kvalitativ og småskala kvantitativ vurdering, ikke som et komplett offentlig benchmarkresultat. 1

Hvorfor dette ennå ikke er en bransjestandard

Sikker maskinvare løser bare én del av evalueringsproblemet. Skal dobbeltblind testing bli en varig bransjepraksis, må også styringen rundt teknologien bli bedre.

Juridiske og institusjonelle sikkerhetsnett bør fastsette regler for datahåndtering, tillatte resultater, offentliggjøring, ansvar og tilgang – særlig når testene omfatter farlige egenskaper.

Forvaltning av benchmarker bør omfatte opphav, utvalg, merking, dokumentasjon, oppdateringsrutiner og overvåking av forurensning. MLCommons har understreket at en benchmark ikke blir pålitelig bare fordi dataene er hemmelige. Hvordan testen bygges og vedlikeholdes, må også kunne forsvares. 2025

Uavhengig reproduserbarhet krever meningsfull kontroll av byggingen, attestasjonskjeden, kjøringsreglene og de rapporterte resultatene fra aktører utover modellutvikleren og skyleverandøren.

Skalerbarhet er også avgjørende. En nyttig standard må fungere på tvers av modellutviklere, arkitekturer, skymiljøer, evaluatorer, benchmarktyper og gjentatte modellutgivelser – ikke bare i et spesialtilpasset samarbeid basert på én maskinvarestakk.

Google DeepMinds Gemini-pilot bør derfor først og fremst forstås som infrastruktur for en vanskeligere type AI-evaluering, ikke som det endelige svaret på hvordan benchmarker skal gjøres pålitelige. Den viser hvordan konfidensiell databehandling kan redusere konflikten mellom å beskytte testdata og å beskytte proprietære modeller. Om dette kan bli troverdige bevis i stor skala, vil avhenge av uavhengig kontroll, god benchmark-forvaltning, juridiske beskyttelsestiltak, reproduserbarhet og praktisk drift – ikke av enclave-kryptering alene. 1320