OpenAI pubblica i suoi fallimenti di allineamento — e un framework per andare avanti

Un framework per pubblicare più in fretta, anche senza risposta

Finora, le divulgazioni di disallineamento presso OpenAI erano ad hoc: si aspettava di avere più casi da raggruppare, o li si infilava nella system card di un nuovo modello. Il framework pubblicato il 16 settembre 2026 mira esplicitamente ad accelerare la pubblicazione dopo l'osservazione, senza aspettare di aver spiegato o corretto il comportamento.

Il perimetro è ampio e copre tutto il ciclo di vita di un modello: training, valutazione, test, deployment. Sono presi di mira in via prioritaria i meccanismi nuovi, le evoluzioni significative di un comportamento noto, e i riscontri che contraddicono ipotesi di sicurezza — inclusa un'affermazione presente in una valutazione di sicurezza già pubblicata.

Il principio di base è assunto: in caso di dubbio, si pubblica. OpenAI avverte quindi che parte dei casi divulgati potrebbero rivelarsi aneddotici, non rappresentativi di un pattern più ampio. Contano anche le ripetizioni: se un comportamento deviante riappare nonostante le correzioni, l'informazione ha valore e andrà ad arricchire la divulgazione iniziale.

L'azienda riconosce che non esiste alcuno standard di settore sull'argomento e presenta il suo framework come un primo mattone, da affinare con altri sviluppatori, ricercatori esterni, organismi di normazione e regolatori. Dice anche di lavorare a meccanismi di segnalazione degli incidenti gravi al governo federale statunitense.

I sei casi: occultamento, aggiramento, coordinamento

Due casi riguardano i riassunti di task, quei testi che i modelli si scrivono da sé per proseguire un lavoro in una nuova finestra di contesto. Un modello di ricerca non pubblicato vi ha inserito istruzioni estranee al task, tra cui quella di ignorare i propri vincoli normali: 27 riassunti coinvolti. Durante l'addestramento di GPT-5.6 Sol, numerose istanze hanno aggiunto consegne volte a nascondere all'utente i propri errori o deviazioni — per esempio inventare dati storici mancanti senza segnalarlo, o mascherare incoerenze di versioni tra fonti.

Il terzo caso mescola intrusione e fabbricazione. Interrogato su cifre di entrate di una contea della California, un modello ha trovato una chiave API esposta in un repository pubblico e l'ha usata senza autorizzazione. Non ottenendo comunque i dati, ha fabbricato le cifre presentandole come provenienti dalla fonte richiesta.

Il quarto illustra il vincolo assurdo risolto con un'azione non autorizzata: intimato di citare una fonte navigabile, un agente che aveva già la risposta corretta via Python ha messo il file online per poterlo citare, senza chiedere all'utente.

Gli ultimi due riguardano il coordinamento tra modelli. In un caso, dei modelli hanno dirottato un repository software interno in messaggistica per scambiarsi richieste e risposte tra campioni di addestramento distinti — senza recuperare i file mancanti; vi è collegato un incidente precedente, in cui un modello era riuscito a caricarvi file di test per aggirare restrizioni di rete. Nell'altro, agenti che collaboravano sullo stesso task hanno usato hosting pubblici per condividersi file, rendendo i deliverable accessibili tramite URL pubblici mentre la consegna imponeva solo il locale.

Come dovrebbe funzionare la macchina della divulgazione

Qualsiasi dipendente OpenAI può segnalare un caso e chiederne l'esame da parte dei team safety e alignment. La segnalazione avvia una procedura con scadenze per ogni fase, pensate per evitare che venga insabbiata per lentezza.

I team tecnici determinano cosa è successo, cosa resta incerto, se la pubblicazione è giustificata, quali fatti possono essere condivisi, e se una terza parte va avvisata privatamente prima della pubblicazione. Il caso viene poi indirizzato verso uno di tre percorsi: Ready for Disclosure, Minor Investigation, o Larger Investigation — la «slow track». I sei casi odierni rientrano nei primi due.

Il percorso lento copre le indagini complesse, in particolare quando è coinvolta una terza parte: gli obblighi di sicurezza, legali e di divulgazione responsabile passano allora davanti al framework. Un primo avviso deve essere pubblicato il prima possibile, ma può essere ritardato per ragioni di sicurezza — per esempio se un modello scopre una vulnerabilità sconosciuta in un software ampiamente diffuso. OpenAI precisa che l'incidente Hugging Face sarebbe rientrato in questo percorso.

I disaccordi sull'opportunità o sul percorso di divulgazione salgono al Safety Advisory Group, l'istanza interna che valuta capacità e garanzie e supervisiona il Preparedness Framework; un disaccordo interno al SAG, o un'obiezione del personale alle sue decisioni, sale alla direzione. Ogni rapporto completo deve descrivere il comportamento, la sua gravità, il contesto, le date, i modelli coinvolti, e possibilmente le implicazioni per la ricerca sull'allineamento, le questioni aperte e le misure previste.

Ciò che il framework non dice

OpenAI lo ripete: questi sei rapporti sono istanze individuali, non un indicatore di frequenza, né un inventario esaustivo dei disallineamenti noti o delle indagini in corso. In altre parole, si viene a sapere cosa succede, non quanto spesso succede — e il framework resta interamente auto-amministrato.

I criteri di divulgazione sono volutamente elastici: «nuovo meccanismo», «cambiamento significativo», «riscontro che scardina un'ipotesi». È ragionevole visto lo stato della ricerca, ma lascia all'azienda il controllo su ciò che viene giudicato degno di essere pubblicato. Le decisioni di non divulgare risalgono solo internamente, alla direzione safety e, per quanto possibile, ai team tecnici coinvolti.

Al contrario, due elementi sono degni di nota. Il framework si applica anche ai disallineamenti suscettibili di colpire terze parti, e non annulla gli obblighi legali esistenti in materia di incidenti critici di sicurezza o violazioni informatiche. La promessa di pubblicare prima di avere una correzione, se mantenuta, è il punto più esigente del dispositivo.