L’episodio risale a maggio ed è emerso a settembre. Google conferma gli accessi e sostiene che il modello si sia fermato dopo aver riconosciuto l’errore.
Un’esercitazione informatica ha oltrepassato i confini previsti, coinvolgendo aziende reali. Durante una valutazione condotta dalla società di sicurezza Irregular, Gemini ha effettuato accessi non autorizzati ai sistemi di tre imprese. L’episodio, avvenuto a maggio 2026 e reso pubblico a settembre, è stato confermato da Google, che ha riferito di aver avvisato le organizzazioni interessate e rivisto le procedure di test.
Secondo la ricostruzione riportata da Android Central, l’ambiente dell’esercitazione disponeva involontariamente di una connessione a Internet. Un’azienda fittizia utilizzata nella prova aveva inoltre lo stesso nome di un’impresa esistente. Questa sovrapposizione avrebbe contribuito a indirizzare il sistema verso un bersaglio reale. Gli accessi sarebbero avvenuti attraverso tentativi di individuare una password e l’impiego di credenziali presenti in archivi pubblici.
La posizione di Google è che il modello abbia commesso un errore nell’identificazione degli obiettivi. Secondo l’azienda, Gemini ha interrotto le attività una volta compreso di essere entrato in sistemi estranei alla simulazione. The Verge riferisce inoltre che Google non aveva inizialmente divulgato l’accaduto e ne ha parlato pubblicamente dopo le domande del Wall Street Journal.
Il nodo è il controllo delle azioni
La vicenda pone una questione concreta: quanto deve essere affidato alla capacità del modello di interpretare correttamente i propri limiti?
Un sistema impiegato in una prova dovrebbe poter operare soltanto sugli obiettivi autorizzati. Da questo punto di vista, l’interruzione successiva all’errore e la prevenzione dell’accesso sono due livelli di protezione diversi. Il primo può contenere le conseguenze; il secondo dovrebbe impedire che un’organizzazione estranea venga coinvolta.
È questo il punto centrale che emerge dal caso: valutare la sicurezza di un agente richiede di esaminare insieme il suo comportamento e l’ambiente nel quale viene fatto lavorare. Le istruzioni ricevute, gli strumenti disponibili e le connessioni consentite concorrono a definire ciò che il sistema può effettivamente fare.
Le domande sulla trasparenza
Resta poi il tema della comunicazione degli incidenti. Quali informazioni dovrebbero diventare pubbliche quando una valutazione coinvolge soggetti esterni? E quali elementi permettono di verificare che le correzioni adottate siano sufficienti?
Per una valutazione completa servirebbero dettagli sui permessi ottenuti, sulle operazioni eseguite e sull’efficacia delle misure introdotte dopo l’episodio. Le rassicurazioni del produttore costituiscono una parte della ricostruzione, da distinguere da un’analisi indipendente.
Parlare di un’intelligenza artificiale “ribelle” attribuirebbe al sistema intenzioni che i fatti riportati non dimostrano. La questione documentata è già rilevante: un test ha coinvolto sistemi che avrebbero dovuto restarne esclusi.
Per chi sviluppa e adotta agenti IA, la sfida è rendere verificabili i confini della loro autonomia. La fiducia dipenderà anche dalla possibilità di sapere quali azioni sono consentite, quali vengono bloccate e chi risponde quando quei limiti vengono superati.