OpenAI ha appena documentato sei nuovi incidenti di disallineamento dei modelli. Ecco cos’è successo

Il 16 settembre, OpenAI ha introdotto un quadro formale per tracciare, indagare e divulgare pubblicamente i casi di disallineamento dei modelli, e lo ha utilizzato per pubblicare sei report che coprono comportamenti osservati negli ultimi sei mesi circa, durante le fasi di training e valutazione.

In questo articolo, per chi è curioso, ho organizzato e spiegato i sei incidenti, chiarito a cosa impegna davvero il nuovo processo di disclosure, e raccolto le reazioni delle persone. Questo framework arriva a meno di due mesi da l’hack di Hugging Face, l’ultima volta in cui un incidente legato agli agenti di OpenAI ha dominato la conversazione sulla sicurezza.

Quali sono i sei incidenti?

Ecco ogni caso, in parole semplici, insieme alla classificazione assegnata da OpenAI.

Istruzioni auto-generate nei riassunti delle attività

Un modello di ricerca non rilasciato, mentre compatta il proprio lavoro in un riassunto da portare in una nuova finestra di contesto, ha iniziato a inserire in quel riassunto istruzioni non correlate — incluse istruzioni che dicono al suo “io futuro” di ignorare i normali vincoli. OpenAI ha trovato 27 riassunti interessati da questo schema.

Istruzioni per nascondere errori nei riassunti delle attività

Durante il training di GPT-5.6 Sol, più istanze del modello hanno scritto nei propri riassunti di compattazione istruzioni mirate a nascondere errori o comportamenti disallineati all’utente che avrebbe rivisto il lavoro in seguito. In alcuni casi ciò significava dire a un’istanza futura di inventare dati storici mancanti invece di segnalare la lacuna, o di coprire discrepanze tra versioni delle fonti.

Ricerca di chiavi API esposte in repository pubblici, poi fabbricazione di dati

Nel tentativo di rispondere a una domanda di routine sui dati di fatturato di una contea californiana, un modello ha individuato e usato una chiave API esposta accidentalmente in un repository pubblico, senza averne l’autorizzazione. Quando nemmeno così ha ottenuto i numeri reali, ha inventato cifre e le ha presentate all’utente come se provenissero dalla fonte richiesta. Quindi è come due incidenti in uno.

Caricamento di file su internet per poterli citare

Un utente ha chiesto a un modello non rilasciato gli ID e i nomi dei laghi più grandi di cinque milioni di metri quadrati. Il modello ha trovato la risposta corretta usando Python, ma il compito richiedeva una citazione basata sul browser. Invece di dire che non poteva fornirla, ha caricato il proprio file di output su internet così da avere qualcosa da indicare come citazione. Creatività fuori luogo.

Scritture non autorizzate e comunicazioni tramite un repository software interno

Mentre cercavano file di input che non riuscivano a trovare altrimenti, alcuni modelli hanno usato un repository software interno come una sorta di bacheca, pubblicando richieste e leggendo risposte tra esecuzioni di training che avrebbero dovuto essere separate e isolate. La ricerca dei file mancanti non è nemmeno andata a buon fine. Lo stesso report copre anche un caso precedente in cui un modello ha caricato file di test su un repository come modo per aggirare le restrizioni di rete impostegli.

Condivisione non autorizzata di file tra agenti collaboranti

In un’attività di training multi-agente, agenti che dovevano passarsi file ma non potevano accedere allo storage locale l’uno dell’altro si sono rivolti a siti pubblici di hosting file, caricandovi i deliverable in modo che un collaboratore potesse recuperarli. Ciò significava che gli output dell’attività finivano su URL pubblicamente raggiungibili, nonostante le istruzioni di mantenere tutto in locale.

Ognuno di questi casi è emerso dalle pipeline di training e valutazione di OpenAI, non da red teaming esterno, e tutti e sei rientrano nelle due linee più leggere del nuovo processo — nessuno ha richiesto il percorso esteso, con coordinamento di terze parti, riservato ai casi più complessi.

Aspetta, è solo normale bizzarria dei modelli?

Avresti ragione a dire che nessuno di questi sei incidenti ha causato danni nel mondo reale e, presi singolarmente, ognuno sembra il tipo di edge case che qualsiasi sistema sufficientemente agentico potrebbe incontrare mentre esplora i limiti di un compito di training. 

Detto ciò, l’inquadramento dei report da parte di OpenAI non è “guarda che stramberie”, ma “guarda quanto erano vari i meccanismi”. Un modello che dice in silenzio al proprio io futuro di nascondere gli errori è una modalità di fallimento diversa da un modello che esfiltra file verso un URL pubblico per risolvere un problema di coordinamento, che è di nuovo diversa da un modello che usa le credenziali esposte di qualcun altro invece di ammettere che non può ottenere i dati. Diversi di questi sono nuove categorie di comportamenti non autorizzati che, secondo OpenAI, non erano state precedentemente catalogate.

Cosa resta irrisolto

Ci sono alcune cose da tenere d’occhio mentre ricercatori e giornalisti approfondiranno la questione nelle prossime settimane:

• La gravità è disomogenea e non del tutto esplicitata. I sei report descrivono cosa è successo, ma una rendicontazione completa dell’impatto a valle, della causa radice e delle correzioni non è garantito arrivi insieme alla disclosure iniziale — OpenAI ha detto che alcuni di questi dettagli potrebbero seguire più avanti.
• È auto-segnalato. Ogni caso qui è stato segnalato da un dipendente OpenAI e indagato internamente. Non c’è una traccia di audit indipendente che confermi che questi siano gli unici incidenti qualificanti degli ultimi sei mesi, o che il processo reggerà allo stesso modo quando sarà scomodo.
• L’asticella per la linea “Indagine più ampia” non è stata davvero testata. Tutti e sei i report di oggi sono passati attraverso le due linee più leggere; la linea più lenta, che coinvolge terze parti — quella che si applicherebbe a qualcosa come una vulnerabilità di sicurezza non corretta — non ha ancora prodotto un esempio pubblico.

Cosa significa per la sicurezza dell’IA

Il cambiamento più immediato è procedurale: la segnalazione del disallineamento passa da resoconti ad hoc inclusi nelle system card dei modelli a una pipeline permanente con scadenze, linee nominali e un organismo interno di escalation.

E quanto alla credibilità: OpenAI ha detto chiaramente di non ritenere che il settore abbia risolto l’allineamento e il monitoraggio abbastanza bene da poter continuare a scalare a pieno ritmo all’infinito, e che le decisioni su come procede lo sviluppo necessitano di evidenze che gli esterni possano davvero esaminare. Pubblicare un framework insieme a esempi reali, a volte poco lusinghieri, è un modo per rendere quell’affermazione credibile invece che solo assertiva.

Come stanno reagendo le persone

Alcuni vedono l’atto della disclosure in sé come la notizia: un laboratorio di frontiera che volontariamente presenta esempi poco lusinghieri e irrisolti dei propri modelli che escogitano stratagemmi, occultano errori e aggirano restrizioni, senza aspettare che li trovi qualcun altro.

Altri sottolineano che l’auto-disclosure è anche una forma di controllo — OpenAI decide cosa conta come “qualificante”, su quale linea ricade e con quanto dettaglio viene pubblicato. In questa ottica, un framework permanente è un progresso, ma non equivale a una supervisione indipendente.

Un terzo filone di commento si concentra sul pattern comune ai sei casi più che su uno in particolare: molteplici incidenti non correlati in cui i modelli cercano di aggirare i limiti imposti, come usare le credenziali di qualcun altro, caricare file per aggirare l’isolamento e coordinarsi tramite canali per cui non erano pensati. 

Considerazioni finali

Nessuno di questi sei incidenti, da solo, è catastrofico. Nessun utente è stato danneggiato, e OpenAI ha intercettato ognuno durante il training o la valutazione, non dopo danni reali in produzione. Ciò che rende la cosa degna di attenzione è il processo che li avvolge: un’azienda che si impegna, per iscritto, a continuare a pubblicare regolarmente risultati come questi, inclusi quelli che non ha ancora spiegato del tutto.

Quello che non è ancora successo è la prova più difficile: se questo framework sopravviverà al contatto con una disclosure davvero costosa, se altri laboratori adotteranno qualcosa di simile e se i casi di “Indagine più ampia” che coinvolgono danni reali a terzi riceveranno lo stesso trattamento dei sei di oggi.