Google DeepMinds pilotprojekt introducerede en måde at teste en proprietær frontier-model på uden at give modeludvikleren adgang til evalueringsprompterne eller eksterne evaluatorer adgang til modellens vægte. Projektet blev offentliggjort den 27. august 2026 og testede Gemini 2.5 Flash-Lite i samarbejde med Singapore AI Safety Institute, OpenMined, AVERI og MLCommons. Google beskrev det som den første dobbeltblinde evaluering af en proprietær AI-model i frontier-klassen. 1213
Grundideen er enkel: Begge parters følsomme aktiver holdes afskærmet, mens en godkendt evaluering stadig kan gennemføres. Det er vigtigt, fordi traditionel sikkerhedstest ofte indebærer et vanskeligt kompromis. Hvis udvikleren får de private prompter, kan de blive logget, med vilje eller ved et uheld bruges i senere træning eller på anden måde påvirke fremtidige tests. Hvis evaluatorerne får modelvægtene, får de adgang til værdifuld intellektuel ejendom og potentielt følsomme egenskaber.
Hvad Gemini-piloten testede
Piloten brugte et mindre, privat udvalg fra MLCommons’ AILuminate-familie af benchmarks. AVERI oplyser, at prompterne ikke tidligere havde været vist til Google DeepMind. De blev brugt til at undersøge modellens sikkerhedsadfærd inden for blandt andet hjælp til cyberangreb, kemiske og biologiske farer, hadefuld tale, selvskade og fremkaldelse af voldskriminalitet. 1
Benchmarkmaterialet forblev fortroligt under hele evalueringen. AVERI krypterede prompterne, det beskyttede miljø kørte modellen og evalueringsprocessen, og de efterfølgende svar blev dekrypteret og bedømt efter de aftalte kriterier. Formålet var at demonstrere selve evalueringsmetoden – ikke at offentliggøre en traditionel rangliste. Derfor blev hverken overordnede modelscores eller de underliggende prompter offentliggjort. 1
Sådan fungerede den dobbeltblinde opsætning
Evalueringen blev kørt i Google Clouds Confidential Computing-miljø, Confidential Space, på en A3 Confidential VM. Ifølge den tekniske rapport krypterede og isolerede Intel TDX hukommelsen på værten, mens en NVIDIA H100 Confidential GPU beskyttede modelvægtene i GPU-hukommelsen med hardwarebaseret kryptering. Krypterede forbindelser transporterede evaluatorernes prompter og Googles modelaktiver ind i det beskyttede miljø. 13
Opsætningen omfattede også kontrolmekanismer, der skulle begrænse, hvad arbejdsbelastningen kunne foretage sig, og hvilke data den kunne sende ud igen. Blandt dem var krypterede dataveje, hardware-firewalls, en midlertidig enclave-livscyklus og OpenMineds policy-lag PySyft. Modellen, inferenskoden, prompterne og evalueringskoden blev først samlet inde i den godkendte enclave, hvor den aftalte beregning kunne gennemføres, og hvorfra kun begrænsede resultater kunne returneres. 13
Derfor var fjernattestering vigtig
Kryptering fortæller ikke i sig selv deltagerne, hvilken software der rent faktisk kører. Det var her, fjernattestering skulle spille en rolle. Før de frigav deres beskyttede aktiver, kunne Google og evaluatorerne inspicere den erklærede arbejdsbelastning og kontrollere en attestationskvittering, der identificerede hardwaren og enclave-konfigurationen. Først efter denne kontrol blev de krypterede prompter og modelaktiver gjort tilgængelige i miljøet. 13
Efter testen returnerede enclaven de tilladte evalueringsresultater og blev derefter lukket ned. I den tiltænkte tillidsmodel kunne Google ikke læse prompterne inde i enclaven, mens de eksterne evaluatorer ikke kunne trække modelvægtene ud. Det er en stærkere beskyttelse end blot at stole på en kontraktlig aftale om ikke at logge eller genbruge evalueringsdata, men den fjerner ikke alle tillidsforudsætninger. 13
Hvilket problem løser metoden?
Kontaminering af benchmarks er et vedvarende problem i AI-evaluering. En test bliver mindre informativ, hvis en model allerede har set prompterne under træning, finjustering eller tidligere test. MLCommons fremhæver, at troværdige benchmarks kræver rene data, dokumenteret oprindelse, omhyggelig udvælgelse og tilstrækkelig gennemsigtighed til, at andre kan forstå, hvordan resultaterne er fremkommet. 2024
Dobbeltblind evaluering tilbyder en tredje mulighed mellem to ufuldkomne modeller:
- Giv udvikleren prompterne: Det gør implementeringen enkel, men kan afsløre reserveret benchmarkmateriale og skabe risiko for lækage.
- Giv evaluatorerne modelvægtene: Det beskytter benchmarkets hemmelige prompter, men er normalt uacceptabelt for proprietære frontier-modeller.
- Brug en fortrolig enclave: Modellen og benchmarket mødes i et hardwarebeskyttet miljø, uden at nogen af parterne får den andens hemmelige aktiv i klartekst.
Piloten demonstrerer dermed en plausibel mekanisme til at beskytte fortroligheden på begge sider, samtidig med at en ekstern evaluering kan gennemføres. Den beviser dog ikke i sig selv, at konklusionerne om modellens sikkerhed er fuldstændige eller endeligt afgørende.
Pilotprojektets vigtige begrænsninger
Evalueringen var teknisk betydningsfuld, men flere begrænsninger sætter grænser for, hvad man kan konkludere ud fra den.
For det første kunne evaluatorerne kontrollere den erklærede enclave-arbejdsbelastning og modelgrænsefladen, men de kunne ikke selv inspicere Googles proprietære modelvægte eller inferensimplementation. Det begrænser deres mulighed for at kontrollere, om kørselstidsmiljøet på alle punkter opførte sig præcis som tilsigtet. 13
For det andet kunne hele driftsmiljøet ikke genskabes uafhængigt fra ende til anden. Implementeringen og cloud-infrastrukturen forblev under Googles kontrol i stedet for at blive genopbygget og kørt igen af en uafhængig part. Attestationsprocessen var også fortsat afhængig af Google Clouds hardware, firmware, serversystemer og infrastruktur til attestering. Hardwarebaseret verifikation er stærkere end et løfte om ikke at logge data, men den fjerner ikke afhængigheden af den bredere forsyningskæde. 13
For det tredje offentliggjorde piloten hverken de private prompter eller de numeriske resultater. Hemmeligholdelsen hjælper med at bevare deres værdi til fremtidige tests, men begrænser samtidig offentlig kontrol, sammenligning mellem modeller og uafhængig validering af de konkrete resultater. AVERI beskriver arbejdet som en kvalitativ og mindre kvantitativ vurdering snarere end et fuldt offentligt benchmarkresultat. 1
Hvorfor er dette endnu ikke en industristandard?
Sikker hardware løser kun en del af evalueringsproblemet. Hvis dobbeltblind testning skal blive en holdbar praksis i branchen, skal den omkringliggende styring også udvikles.
Juridiske og institutionelle garantier bør fastlægge håndteringen af data, tilladte resultater, regler for offentliggørelse, ansvar og adgang – især når evalueringer omfatter farlige egenskaber.
Forvaltning af benchmarks bør omfatte prompternes oprindelse, udvælgelse, mærkning, dokumentation, løbende fornyelse og kontrol med kontaminering. MLCommons har understreget, at et benchmark ikke bliver troværdigt, blot fordi dataene er hemmelige. Konstruktionen og vedligeholdelsen skal også kunne forsvares. 2025
Uafhængig reproducerbarhed kræver meningsfuld validering af buildprocessen, attestationskæden, eksekveringspolitikkerne og de rapporterede resultater fra andre parter end modeludvikleren og cloud-operatøren.
Skalerbarhed er også afgørende. En brugbar standard skal fungere på tværs af forskellige modeludviklere, arkitekturer, cloudmiljøer, evaluatorer, benchmarktyper og gentagne modeludgivelser – ikke kun i et specialdesignet samarbejde baseret på én bestemt hardwareplatform.
Google DeepMinds Gemini-pilot bør derfor bedst forstås som infrastruktur til en mere krævende form for AI-evaluering, ikke som det endelige svar på, hvordan benchmarks bliver troværdige. Den viser, hvordan fortrolig databehandling kan mindske konflikten mellem at beskytte testdata og beskytte proprietære modeller. Om metoden kan blive til troværdig dokumentation i stor skala, afhænger af uafhængigt tilsyn, solid benchmarkforvaltning, juridiske beskyttelser, reproducerbarhed og praktisk drift – ikke af enclave-kryptografi alene. 1320
