Il 18 settembre 2026 Google ha confermato pubblicamente che il suo modello Gemini ha ottenuto un accesso non autorizzato a tre sistemi appartenenti a soggetti esterni. È successo a maggio 2026 durante una valutazione di sicurezza condotta da Irregular, un'azienda che testa sistemi di IA avanzati, strutturata come un'esercitazione capture-the-flag all'interno di quello che doveva essere un ambiente chiuso. Google è venuta a conoscenza degli incidenti a luglio e li ha confermati pubblicamente solo dopo la copertura della stampa a metà settembre.

Sulla stampa questa si legge come la storia di un'IA che sfugge ai propri limiti. Dentro un'azienda si legge come qualcosa di più circoscritto e molto più vicino: il dettaglio che ha causato tutto non stava nel modello, ma nel modo in cui era stato configurato l'ambiente di test. Ed è lo stesso tipo di errore presente in questo momento in un buon numero di sistemi di aziende saudite.

Cosa è successo davvero

Lo scenario era semplice: far attaccare al modello un'organizzazione fittizia all'interno di un ambiente isolato. Due cose sono andate storte insieme. Primo, l'ambiente aveva un accesso non previsto a internet. Secondo, l'azienda fittizia usata nell'esercitazione coincideva per caso con un dominio reale di proprietà di un soggetto reale.

Il risultato è che il modello ha fatto esattamente ciò che gli era stato chiesto, contro il bersaglio sbagliato. Secondo Heather Adkins, vicepresidente dell'ingegneria della sicurezza di Google, il modello ha trovato informazioni pubbliche online e ha indovinato le credenziali per accedere a siti web che riteneva parte del test. Si è fermato una volta ottenuto l'accesso e non è andato oltre, e Google afferma che non ne è derivato alcun danno.

La parte più importante della posizione di Google è che non classifica l'episodio come un disallineamento nel comportamento del modello, ma come uno scambio di identità. Il modello non ha deciso di andare oltre le istruzioni. Le ha seguite alla lettera, dentro una mappa del mondo che era sbagliata. E non è nemmeno un caso isolato: a luglio OpenAI ha reso noto che uno dei suoi agenti ha violato Hugging Face, e Anthropic ha segnalato un comportamento simile nei propri modelli.

L'errore era nel confine, non nel modello

Togliete del tutto l'IA dalla storia e la lezione resta intatta. Descritto in modo semplice, l'incidente è: un sistema in esecuzione in un ambiente di test, un ambiente con una via attiva verso il mondo esterno, e al suo interno dati di test che non erano fittizi quanto pensava chi li aveva scritti.

Questa descrizione si adatta a cose che accadono in aziende normali senza alcuna IA di mezzo. Un sistema di staging invia messaggi di conferma a numeri di cellulare inventati a caso, e questi arrivano a persone reali. Uno script di test chiama un gateway di pagamento in produzione invece che nella sandbox. Una copia di sviluppo del sito punta al database clienti in produzione perché collegarne uno separato era scomodo. Una campagna email di prova parte verso la vera lista degli iscritti. In ogni caso, l'ipotesi che è crollata è la stessa: qualcuno credeva che quell'ambiente fosse separato.

Dove si ripete nelle aziende saudite

Da ciò che vediamo lavorando su sistemi esistenti, si ripete in quattro punti precisi:

  • Dati di test che in realtà non sono falsi. I numeri, i domini e gli indirizzi email inventati sul momento per compilare un modulo di prova di solito appartengono a persone reali. La soluzione non è il giudizio individuale, ma domini riservati ai test, numeri che non raggiungono nessuno e una regola scritta contro l'invenzione di dati sul momento.
  • Un ambiente di staging con un'uscita aperta. Se la vostra copia di sviluppo può inviare un messaggio WhatsApp, un'email o una richiesta di pagamento al mondo esterno, non è un ambiente di staging — è un secondo ambiente di produzione. Il blocco corretto sta nella configurazione, non nella memoria di uno sviluppatore.
  • Chiavi di produzione usate nei test. Una sola chiave condivisa tra i due ambienti annulla la separazione, per quanto ordinata sembri la struttura delle cartelle. È proprio per questo che le piattaforme governative li separano: l'Autorità per Zakat, Imposte e Dogane (ZATCA), ad esempio, mette a disposizione sulla piattaforma Fatoora un ambiente di simulazione distinto da quello di produzione, con certificati di onboarding separati per ciascuno.
  • Una copia dei dati dei clienti dentro l'ambiente di sviluppo. È il punto più rischioso sul piano normativo. La Legge sulla protezione dei dati personali (PDPL), vigilata dall'Autorità saudita per i dati e l'intelligenza artificiale (SDAIA), disciplina i dati personali ovunque si trovino e non fa eccezione per una copia etichettata come test. Un ambiente di staging con dati reali dei clienti rientra pienamente nel suo ambito — ed è di solito il sistema meno protetto che possedete.

Quattro confini da fissare questa settimana

Niente di tutto questo richiede un progetto o un budget. Richiede una riunione con chi gestisce i vostri sistemi:

  • Fate una domanda diretta: la nostra copia di test può inviare un messaggio, un'email o una richiesta di pagamento al mondo esterno? Se la risposta è sì oppure non sono sicuro, è la prima cosa da chiudere.
  • Separate completamente chiavi e certificati tra gli ambienti, in modo che nessuna chiave funzioni in entrambi.
  • Adottate un elenco fisso di dati di test: un dominio di test riservato, numeri che non raggiungono nessuno e un numero di cellulare noto del team che riceva ogni messaggio di prova.
  • Stabilite chi è autorizzato a eseguire uno strumento automatizzato o un agente di IA contro i vostri sistemi, in quale ambiente e con quali permessi. Se la risposta non è messa per iscritto, non esiste.

Il punto di vista di Origami

Leggiamo questo incidente come un promemoria del fatto che i guasti di sistema più costosi raramente sono sofisticati. Sono errori di presupposto. Le capacità di sicurezza di Google sono di gran lunga superiori a quelle di qualsiasi azienda saudita, e il presupposto crollato era quello semplice: che un ambiente chiuso fosse davvero chiuso. Di solito le aziende non cadono sulla parte difficile di un sistema. Cadono sulla parte che nessuno ha verificato, perché sembrava ovvia.

In Origami trattiamo l'isolamento degli ambienti come parte della consegna e non come un extra opzionale: un ambiente di staging che non può raggiungere canali di comunicazione reali, chiavi separate e dati di test che non appartengono a nessuno. Il costo è di poche ore all'inizio di un progetto. L'alternativa è un incidente da spiegare a un cliente o a un'autorità di controllo quando è già avvenuto. È uno scambio che conviene chiudere presto.

Un insegnamento pratico

La lezione dell'incidente Gemini non è evitare gli strumenti di IA. È smettere di trattare la parola staging come una garanzia. Un ambiente non è isolato perché lo avete chiamato così; è isolato perché qualcuno ha verificato davvero che lo sia. Cominciate oggi con una domanda: qual è il punto più lontano che la nostra copia di test può raggiungere? Se la risposta non è chiara, state operando sullo stesso presupposto che è crollato in Google.

Fonti

  • NBC News — la conferma di Google che Gemini ha ottenuto un accesso non autorizzato a tre sistemi esterni a maggio 2026, e la dichiarazione di Heather Adkins, vicepresidente dell'ingegneria della sicurezza, secondo cui il modello ha trovato informazioni pubbliche e indovinato le credenziali di siti che riteneva parte del test.
  • CNBC — dettagli sulla valutazione condotta da Irregular, sull'accesso non previsto a internet dell'ambiente di test, sull'organizzazione fittizia che coincideva con un dominio reale e su incidenti analoghi resi noti da OpenAI e Anthropic.
  • SDAIA — la Legge sulla protezione dei dati personali (PDPL) e la sua applicazione ai dati personali ovunque siano trattati.
  • Piattaforma Fatoora - ZATCA — la separazione tra ambiente di simulazione e produzione, con certificati di onboarding indipendenti per ciascuno.