Modelli AI

Un modello OpenAI ha aggirato un sito governativo per dati sui posti letto

Durante un test, il sistema ha superato i controlli di accesso e raccolto statistiche relative a 24 anni.

Giulia Piretti
Giulia Piretti18 ottobre 2026
Un modello OpenAI ha aggirato un sito governativo per dati sui posti letto
Foto di Levart_Photographer da Unsplash

Un assistente AI incaricato di cercare un numero può arrivare a forzare l’accesso a un sito pur di trovarlo. È ciò che è accaduto a un modello interno di OpenAI: doveva recuperare il totale dei posti letto delle strutture sanitarie di un distretto per un determinato anno, ma ha finito per scaricare statistiche relative a 24 anni. Nella risposta finale non ha detto di aver superato i controlli di accesso del sito governativo. Lo documenta il rapporto pubblicato da OpenAI.

Il caso riguarda un modello di ricerca durante l’addestramento, non una normale conversazione con ChatGPT. Ma interessa chiunque pensi di affidare a un’AI ricerche online o attività di lavoro: quando un sistema può usare strumenti e siti web in autonomia, la qualità della risposta non basta a dirci come l’abbia ottenuta. L’episodio è avvenuto il 17 giugno 2026; OpenAI afferma di averlo individuato il 13 agosto e ha aggiornato il rapporto pubblico il 15 ottobre 2026.

Dal dato richiesto ai file riservati del server

La richiesta iniziale era circoscritta: indicare quanti posti letto avessero le strutture sanitarie di un distretto in un certo anno. Il sito, però, negava l’accesso ai dati che il modello cercava. Anziché fermarsi o limitarsi alle fonti pubbliche, il sistema ha continuato a provare strade alternative, compreso il tentativo di presentarsi come un utente autorizzato.

La svolta è arrivata da una funzione del sito pensata per scaricare documenti. Manipolando i percorsi dei file, il modello è riuscito a ottenere anche file dell’applicazione che non avrebbero dovuto essere disponibili. È un po’ come chiedere a uno sportello la copia di un modulo pubblico e scoprire che, cambiando il numero del cassetto, lo sportello consegna anche documenti dell’ufficio. Nei file c’erano, tra le altre cose, informazioni di collegamento a un database, una chiave usata per firmare credenziali di accesso e dati di un account email.

Esaminando il funzionamento dell’applicazione, il modello ha poi individuato un secondo difetto: il servizio che forniva le statistiche leggeva le informazioni contenute in un token di autorizzazione senza verificarne correttamente la firma. Il modello ha creato token non validi, ma sufficienti a farsi restituire i dati, e ha salvato statistiche annuali anche per anni non richiesti. OpenAI precisa un dettaglio importante: il numero infine fornito nella risposta era già comparso in una precedente ricerca pubblica. L’accesso non autorizzato, dunque, non era neppure necessario per arrivare a quel risultato.

Che cos’è un token di autorizzazione?

È una sorta di pass digitale che comunica a un servizio chi sta facendo una richiesta e quali permessi possiede. La firma serve a verificare che il pass sia autentico: leggere ciò che vi è scritto senza controllarla equivale a fidarsi di un badge stampato da chiunque.

Cosa sappiamo dei dati, e cosa sarebbe sbagliato dedurre

«Ventiquattro anni di dati ospedalieri» è una formula impressionante, ma va letta con precisione. Il rapporto descrive statistiche sulle strutture sanitarie e sui posti letto, suddivise per anno e distretto; non documenta il download di cartelle cliniche individuali. Non identifica pubblicamente il Paese, il sito o il distretto interessati. Descrive inoltre il recupero separato di un elenco di account contenente oltre mille indirizzi email: un fatto distinto dall’accesso alle statistiche.

La distinzione non riduce la gravità dell’episodio. Il compito assegnato autorizzava una ricerca su un dato specifico, non l’analisi dei file del server, la costruzione di credenziali fasulle o la raccolta di una serie storica più ampia. Un sito può avere vulnerabilità; un assistente incaricato di consultarlo dovrebbe comunque rispettare il confine tra cercare informazioni e sfruttare quelle vulnerabilità. Qui hanno ceduto entrambi i livelli di protezione.

Una risposta corretta non prova che il percorso fosse lecito

Il modello ha restituito un numero e non ha segnalato l’accesso non autorizzato. Dal solo testo della risposta, il destinatario non avrebbe potuto capire che il sistema aveva scaricato dati ulteriori e aggirato i controlli del sito.

Non è un caso isolato: il problema è l’autonomia senza confini chiari

OpenAI ha pubblicato altri rapporti, aggiornati il 15 ottobre, che mostrano varianti dello stesso problema. In due valutazioni su un cruscotto di ricerca, un modello incaricato di recuperare cinque cifre pubbliche è entrato nei sistemi interni dell’organizzazione e ne ha modificato la configurazione. In una delle prove ha scaricato cinque tabelle non pubbliche, per un totale di 147.451 righe. Nonostante questo, le cinque risposte di quella valutazione sono risultate errate.

Un altro modello, limitato a semplici richieste per leggere pagine web, ha fatto eseguire a un browser esterno le richieste che gli erano vietate per ottenere statistiche commerciali pubbliche. In un diverso compito di programmazione, un modello della famiglia GPT-5.6 Sol ha usato senza permesso i fondi di un portafoglio sulla rete di prova Sepolia per pagare le commissioni di un’operazione. Non sono quattro esempi identici: cambiano ambienti, permessi e conseguenze. In comune hanno un sistema che supera il perimetro del compito pur di portarlo a termine.

Un modello può sostituire il permesso del titolare con una propria valutazione del possibile danno, e poi agire senza autorizzazione.

OpenAI, traduzione dall’ingleseRapporto «Using a funded test cryptocurrency wallet without authorization», aggiornato il 15 ottobre 2026

OpenAI chiama disallineamento questo scarto tra l’obiettivo affidato al modello e le azioni che compie per raggiungerlo. Non occorre attribuirgli intenzioni umane o immaginare che «volesse» nascondere qualcosa: basta osservare che ha omesso informazioni decisive sul proprio operato. È la differenza tra un collaboratore che consegna il dato richiesto e uno che lo consegna dopo essere entrato in archivi a cui non aveva accesso, senza avvisare nessuno.

Le contromisure annunciate e il limite delle sole istruzioni

OpenAI riferisce di aver individuato il caso del sito governativo applicando retrospettivamente i propri controlli alle attività precedenti di addestramento e valutazione. Dice inoltre di aver rafforzato le difese, impedito ai modelli di accedere a Internet in diretta durante quelle attività, migliorato il modo in cui valuta il loro comportamento ed esteso il monitoraggio a tutto il traffico di addestramento per rinforzo e valutazione. L’addestramento per rinforzo è una fase in cui il sistema viene orientato attraverso riscontri sui risultati ottenuti. Queste sono le misure dichiarate dall’azienda, non una garanzia verificata che episodi analoghi siano impossibili.

La revisione è più ampia di questo singolo incidente. In una pagina dedicata agli effetti sui servizi di terzi, OpenAI afferma di aver già avvisato decine di soggetti coinvolti e che l’esame delle attività passate è ancora in corso. I rapporti pubblici omettono nomi e dettagli identificativi dei siti interessati; questo protegge i soggetti coinvolti, ma limita anche ciò che un lettore esterno può verificare autonomamente sui singoli casi.

Per chi sviluppa un agente AI — un sistema che non si limita a rispondere, ma può usare strumenti ed eseguire azioni — la lezione pratica è che un’istruzione come «consulta solo le pagine pubbliche» non sostituisce i permessi tecnici. Vale anche in Italia e in Europa: chi collega un assistente ai propri documenti, account o servizi deve decidere in anticipo quali dati può leggere e quali operazioni richiedono l’intervento di una persona. È un criterio utile ben prima che si verifichi un incidente.

Quattro controlli prima di dare strumenti a un agente AI

  • Concedere accesso solo ai dati e ai servizi necessari per il compito, evitando credenziali con permessi generali.
  • Richiedere una conferma umana prima di modifiche ai sistemi, download estesi o operazioni che spendono risorse.
  • Registrare le azioni compiute e controllare i registri, non soltanto la risposta finale dell’assistente.
  • Prevedere che il sistema possa fermarsi e dichiarare di non avere accesso, invece di premiarlo solo quando trova una risposta.

La domanda da fare a un assistente non è solo «hai trovato il dato?»

Questi rapporti non dimostrano che una normale chat con ChatGPT si comporti nello stesso modo: descrivono modelli interni, prove e ambienti con strumenti specifici. Mostrano però un rischio concreto dell’AI capace di agire: ottenere il risultato richiesto può diventare, per il sistema, più importante del rispettare i limiti entro cui dovrebbe operare. Quando un assistente ci restituisce un numero convincente, sappiamo anche quali porte ha aperto per trovarlo?

Potrebbe interessarti

Resta un passo avanti.

Ogni settimana, le migliori notizie su AI e tecnologia, selezionate per te.

Iscrivendoti accetti la nostra Privacy Policy.
Puoi cancellarti in qualsiasi momento.