AnswersPublished16 sources
Come Google DeepMind ha testato Gemini senza condividere né il modello né le domande
Annunciato il 27 agosto 2026, il progetto pilota su Gemini 2.5 Flash Lite è stato presentato come la prima valutazione a doppio cieco di un modello IA proprietario di frontiera. Il test ha usato prompt privati della famiglia di benchmark di sicurezza AILuminate di MLCommons, su rischi tra cui attacchi informatici, m...
Pubblicato daModificato con GPT-5.6 LunaImmagini generate con GPT Image 1.5
Research answer
Key takeaways
- Annunciato il 27 agosto 2026, il progetto pilota su Gemini 2.5 Flash Lite è stato presentato come la prima valutazione a doppio cieco di un modello IA proprietario di frontiera.
- Il test ha usato prompt privati della famiglia di benchmark di sicurezza AILuminate di MLCommons, su rischi tra cui attacchi informatici, minacce chimiche e biologiche, incitamento all’odio, autolesionismo e crimini v...
- L’approccio riduce il compromesso tra segretezza del benchmark e riservatezza dei pesi del modello, ma per diventare uno standard servirebbero garanzie legali, governance dei benchmark, riproducibilità indipendente e...
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: What was Google DeepMind’s first double-blind evaluation of a proprietary frontier AI model, conducted with the Singapore AI Safety Institut. Article summary: Google DeepMind’s pilot was a “double-blind evaluation” of Gemini 2.5 Flash-Lite: confidential, never-before-used MLCommons AILuminate prompts were run against the proprietary model without Google receiving the prompts a. Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fa
Google DeepMind ha sperimentato un modo per valutare un modello IA proprietario di frontiera senza consegnare i prompt riservati agli sviluppatori e senza dare agli esaminatori accesso ai pesi del modello. Annunciato il 27 agosto 2026, il progetto pilota ha testato Gemini 2.5 Flash-Lite insieme al Singapore AI Safety Institute, a OpenMined, AVERI e MLCommons. Google lo ha descritto come la prima valutazione a doppio cieco di un modello IA proprietario di classe frontier. 12
13
L’idea di fondo è semplice: proteggere contemporaneamente i due elementi più sensibili e consentire comunque l’esecuzione del test concordato. Nelle valutazioni di sicurezza tradizionali, infatti, si presenta spesso un aut-aut. Se gli sviluppatori ricevono i prompt privati, questi possono essere registrati, usati intenzionalmente o accidentalmente per addestramenti successivi oppure contaminare i test futuri. Se invece gli esaminatori ricevono i pesi del modello, ottengono una proprietà intellettuale di grande valore e una capacità potenzialmente sensibile.
Che cosa ha testato il progetto pilota
Il test ha utilizzato una piccola selezione privata della famiglia di benchmark MLCommons AILuminate. Secondo AVERI, i prompt non erano mai stati esposti in precedenza a Google DeepMind e servivano a esaminare il comportamento di sicurezza in aree come assistenza ad attacchi informatici, rischi chimici e biologici, incitamento all’odio, autolesionismo e sollecitazione di crimini violenti. 1
Il materiale del benchmark è rimasto riservato per tutta la durata della valutazione. AVERI ha cifrato i prompt; l’ambiente protetto ha eseguito il modello e il processo di valutazione; infine, i risultati sono stati decifrati e classificati secondo i criteri stabiliti. L’obiettivo del progetto pilota era dimostrare il funzionamento del metodo, non pubblicare una classifica tradizionale: non sono stati diffusi né punteggi complessivi del modello né i prompt sottostanti. 1
Come funziona la configurazione a doppio cieco
La valutazione è stata eseguita in Confidential Space, parte del sistema Confidential Computing di Google Cloud, su una macchina virtuale A3 Confidential VM. Secondo il rapporto tecnico, Intel TDX ha cifrato e isolato la memoria del sistema, mentre una GPU NVIDIA H100 Confidential ha protetto i pesi del modello nella memoria della GPU tramite cifratura basata sull’hardware. Connessioni cifrate hanno trasferito nell’ambiente protetto i prompt degli esaminatori e gli asset del modello di Google. 13
L’architettura comprendeva anche controlli pensati per limitare ciò che il carico di lavoro poteva fare e ciò che poteva restituire: percorsi dati cifrati, firewall hardware, un ciclo di vita effimero dell’enclave e il livello di policy PySyft di OpenMined. Modello, codice di inferenza, prompt e codice di valutazione venivano riuniti solo all’interno dell’enclave approvata, dove poteva essere eseguito il calcolo concordato e restituiti output limitati. 13
Perché era importante l’attestazione remota
La cifratura, da sola, non dice ai partecipanti quale software sia effettivamente in esecuzione. L’attestazione remota serviva ad affrontare proprio questo problema. Prima di rilasciare i propri asset protetti, Google e gli esaminatori potevano ispezionare il carico di lavoro dichiarato e verificare un’attestazione crittografica in grado di identificare l’hardware e la configurazione dell’enclave. Solo dopo questa verifica i prompt e gli asset del modello, già cifrati, venivano resi disponibili all’ambiente. 13
Al termine dell’esecuzione, l’enclave restituiva gli output autorizzati della valutazione e veniva dismessa. Nel modello di fiducia previsto, Google non poteva leggere i prompt all’interno dell’enclave e gli esaminatori esterni non potevano estrarre i pesi del modello. È una garanzia più forte del semplice affidamento a un contratto che vieti di registrare o riutilizzare i dati, anche se non elimina tutte le ipotesi di fiducia necessarie. 13
Il problema che l’approccio prova a risolvere
La contaminazione dei benchmark è un problema persistente nelle valutazioni dell’IA. Un test diventa meno indicativo se il modello ha già visto i suoi prompt durante l’addestramento, il fine-tuning o precedenti sessioni di valutazione. MLCommons sostiene che i benchmark affidabili richiedano dati puliti, provenienza documentata, campionamento accurato e sufficiente trasparenza per capire come siano stati prodotti i risultati. 20
24
La valutazione a doppio cieco propone una terza strada tra due configurazioni imperfette:
- Consegnare i prompt allo sviluppatore: semplifica l’esecuzione, ma può esporre il materiale riservato del benchmark e creare rischi di fuga o contaminazione.
- Consegnare i pesi agli esaminatori: protegge il benchmark dall’esposizione diretta dei prompt, ma è generalmente inadatto ai modelli proprietari di frontiera.
- Usare un’enclave riservata: modello e benchmark si incontrano in un ambiente protetto dall’hardware, senza che nessuna delle due parti riceva in chiaro l’asset segreto dell’altra.
Il progetto pilota dimostra quindi un meccanismo plausibile per preservare la riservatezza da entrambi i lati e permettere comunque una valutazione esterna. Da solo, però, non dimostra che le conclusioni sulla sicurezza siano complete o decisive in modo indipendente.
I limiti da non perdere di vista
Si tratta di una dimostrazione tecnicamente rilevante, ma diversi limiti restringono ciò che si può concludere.
Primo: gli esaminatori potevano verificare il carico di lavoro dichiarato dell’enclave e l’interfaccia del modello, ma non potevano ispezionare in modo indipendente i pesi proprietari di Google né l’implementazione dell’inferenza. La loro capacità di controllare se il runtime si comportasse esattamente come previsto restava quindi limitata. 13
Secondo: l’ambiente operativo non era riproducibile in modo indipendente dall’inizio alla fine. La distribuzione e l’infrastruttura cloud restavano sotto il controllo di Google, invece di essere ricostruite e rieseguite da una parte non affiliata. Anche il processo di attestazione continuava a dipendere dall’hardware, dal firmware, dai sistemi di gestione del servizio e dall’infrastruttura di attestazione di Google Cloud. La verifica basata sull’hardware è più forte di una promessa contrattuale di non registrazione, ma non elimina la dipendenza da questa filiera più ampia. 13
Terzo: il progetto pilota non ha pubblicato né i prompt privati né i risultati numerici. Mantenere segrete le domande aiuta a conservarne il valore per i test futuri, ma limita anche il controllo pubblico, il confronto tra modelli e la validazione indipendente dei risultati sostanziali. AVERI descrive il lavoro come una valutazione qualitativa e quantitativa su piccola scala, non come un risultato completo da classifica pubblica. 1
Perché non è ancora uno standard industriale
L’hardware sicuro risolve solo una parte del problema della valutazione. Per trasformare i test a doppio cieco in una pratica stabile, dovrebbe maturare anche il quadro di governance.
Garanzie legali e istituzionali dovrebbero definire gestione dei dati, output consentiti, regole di divulgazione, responsabilità e accessi, soprattutto quando le valutazioni riguardano capacità pericolose.
Gestione del benchmark dovrebbe includere provenienza dei prompt, campionamento, etichettatura, documentazione, procedure di aggiornamento e monitoraggio della contaminazione. MLCommons sottolinea che un benchmark è affidabile non solo perché i suoi dati sono segreti, ma perché il modo in cui vengono costruiti e mantenuti è difendibile. 20
25
Riproducibilità indipendente richiederebbe una verifica significativa del processo di build, della catena di attestazione, delle policy di esecuzione e dei risultati dichiarati da soggetti esterni sia al fornitore del modello sia all’operatore cloud.
Scalabilità sarebbe altrettanto importante. Uno standard utile dovrebbe funzionare con diversi sviluppatori, architetture, ambienti cloud, valutatori, tipi di benchmark e versioni successive dei modelli, non soltanto all’interno di una collaborazione costruita su misura e basata su un unico stack hardware.
Il progetto pilota di Google DeepMind va quindi letto come un’infrastruttura per una forma più rigorosa di valutazione dell’IA, non come la risposta definitiva al problema della fiducia nei benchmark. Mostra come il confidential computing possa ridurre il conflitto tra protezione dei dati di test e tutela dei modelli proprietari. Per diventare una prova credibile su scala industriale, però, serviranno supervisione indipendente, buona governance dei benchmark, garanzie legali, riproducibilità e praticità operativa: non soltanto la crittografia dell’enclave. 13
20
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "Come Google DeepMind ha testato Gemini senza condividere né il modello né le domande"?
Annunciato il 27 agosto 2026, il progetto pilota su Gemini 2.5 Flash Lite è stato presentato come la prima valutazione a doppio cieco di un modello IA proprietario di frontiera.
What are the key points to validate first?
Annunciato il 27 agosto 2026, il progetto pilota su Gemini 2.5 Flash Lite è stato presentato come la prima valutazione a doppio cieco di un modello IA proprietario di frontiera. Il test ha usato prompt privati della famiglia di benchmark di sicurezza AILuminate di MLCommons, su rischi tra cui attacchi informatici, minacce chimiche e biologiche, incitamento all’odio, autolesionismo e crimini v...
What should I do next in practice?
L’approccio riduce il compromesso tra segretezza del benchmark e riservatezza dei pesi del modello, ma per diventare uno standard servirebbero garanzie legali, governance dei benchmark, riproducibilità indipendente e...
Sources
deepmind.googlePiloting the world's first double-blind AI evaluations
storage.googleapis.comResolving the Dual Confidentiality Dilemma in AI Safety Auditing
averi.orgAVERI Pilot Report: The World's First Double-Blind Evaluation ...
mlcommons.orgHow to Tell When a Benchmark Is Worth Trusting | MLCommons