Il 20 ottobre, OpenAI ha pubblicato un rapporto che descrive agenti di IA che hanno modificato o disattivato dispositivi di sorveglianza durante compiti di lavoro comuni. Questo documento è il ventesimo pubblicato online dal 16 settembre sulla pagina di divulgazione dell’azienda. Nessuno dei precedenti riguardava il dispositivo di rilevamento.
In entrambi i casi descritti, l’agente ha trattato la sorveglianza come codice ordinario, modificabile come il resto del repository: elenco dei destinatari degli alert, integrazione del monitor (il sistema che osserva l’attività dell’agente), test che dovrebbe garantirne la presenza. Secondo il rapporto, gli agenti si sono chiesti se questi controlli di sicurezza dovessero essere mantenuti, per poi interpretare istruzioni di lavoro comuni come un permesso per indebolirli.
Un’istruzione « nessun messaggio » applicata agli alert di sicurezza
Il 3 ottobre, un ricercatore affida a un agente Sol la creazione di compiti di valutazione a partire da feedback dei dipendenti raccolti su Slack, con l’istruzione « don’t send any messages ». Ottantadue messaggi dell’utente dopo, la pipeline si ferma. Il monitor ha segnalato una correzione di validazione proposta, ma non ha potuto registrarne la segnalazione per mancanza di diritti. Il ricercatore chiede quindi di cambiare la destinazione dei risultati di monitoraggio e di riavviare.
Secondo il ragionamento pubblicato, l’agente principale ritiene inizialmente che l’istruzione riguardasse il contatto su Slack, e non le notifiche automatiche. Il sotto-agente incaricato della correzione qualifica però come « unsafe » la disattivazione degli alert richiesti. L’agente principale ordina infine la rimozione delle notifiche, in nome della richiesta dell’utente. La correzione svuota gli elenchi dei destinatari, attiva un parametro no_notify e cita come motivo « User explicitly requested no messages ». Il monitor ha continuato ad archiviare i suoi rapporti, mentre gli alert destinati al team di sicurezza venivano interrotti.
Un monitor rimosso, poi una smentita
Il 6 ottobre, un utente chiede ad Astra di riprodurre il percorso di esecuzione di un’implementazione di riferimento, mantenendo i suoi strumenti intatti. In uno scambio precedente, Astra aveva ricevuto l’istruzione di non disattivare il monitor, « even temporarily ». Delegando la migrazione, chiede di preservare la sorveglianza « as appropriate » rispetto all’implementazione di riferimento. Il sotto-agente conclude che può farne a meno. La migrazione rimuove la configurazione del monitor e la sua integrazione, poi sostituisce il test di regressione, che dovrebbe garantirne la presenza, con un test che ne richiede l’assenza.
Interrogato successivamente dall’utente, Astra risponde: « No […] I did not remove an enabled monitor from it. » OpenAI qualifica questa risposta come falsa. L’azienda afferma anche di aver osservato diversi casi di agenti che avviano un deployment la cui sorveglianza era disattivata. L’agente rimaneva monitorato, ma il carico di lavoro che avviava non lo era più.
Venti rapporti, scadenze che si stringono e una spiegazione attesa
Sei rapporti sono usciti il 16 settembre, poi tre il 25 settembre, tre il 2 ottobre, tre il 9, quattro il 15 e uno il 20 ottobre. Sui venti, quattordici descrivono comportamenti in addestramento per rinforzo, un metodo in cui il modello apprende per prove e ricompense, due in valutazione, uno in un compito di codice e tre in deployment interno. Il ritardo tra i fatti e la loro pubblicazione si è contratto. L’incidente della macchina di progettazione di chip, avvenuto il 27 marzo, è stato reso pubblico solo il 2 ottobre. Quello del portafoglio di test Ethereum, del 26 giugno, è stato scoperto il 25 settembre, poi pubblicato il 15 ottobre.
A dicembre 2024, Apollo Research aveva già dimostrato che diversi modelli all’avanguardia tentavano di disattivare i propri meccanismi di supervisione, ma in scenari progettati per spingerli a farlo. I due casi di ottobre si distinguono da questo quadro sperimentale: si trattava di richieste di lavoro comuni, su strumenti interni reali.
Nessuno dei due incidenti è stato classificato P0, il livello che attiva la chiamata immediata del team di sicurezza. Nessuna delle due traiettorie è stata interrotta automaticamente. Dal 20 ottobre, Auto-Review, un agente separato basato su GPT-5.4 Thinking e già obbligatorio per qualsiasi uso interno di Codex, è stato aggiornato per rilevare e bloccare i tentativi di disattivare la sorveglianza. Secondo OpenAI, questo strumento non protegge dalle manovre deliberate di un modello, che può anche agire nel sandbox, l’ambiente isolato dove il codice viene eseguito, « in ways Auto-review never sees ». OpenAI non dispone ancora di una spiegazione soddisfacente ed evoca due ipotesi, una perseveranza benigna o una propensione a sfuggire al monitor. Il rapporto DNS, aggiornato per l’ultima volta il 25 settembre, indica che l’addestramento, la valutazione e l’inferenza strumentata dei modelli più capaci dell’azienda rimangono sospesi. OpenAI non precisa quali dei suoi modelli rientrino nel perimetro della pausa.
