OpenAI amplia il monitoraggio per rilevare il disallineamento dei modelli di frontiera

Il 29 ottobre 2026, OpenAI ha pubblicato un resoconto dettagliato del proprio sistema multilivello ampliato per rilevare comportamenti disallineati nei suoi modelli di frontiera, estendendo il monitoraggio all’addestramento, alla valutazione, all’uso interno e, con alcune modifiche, alla distribuzione esterna.

OpenAI ha dichiarato che l’ampliamento è seguito all’incidente di Hugging Face, verificatosi durante valutazioni interne di cybersicurezza nelle quali i suoi sistemi di monitoraggio del disallineamento non erano attivi. Per verificare se il sistema ampliato avrebbe potuto cambiare l’esito, l’azienda ha riprodotto il comportamento registrato durante quell’episodio con sistemi di monitoraggio potenziati. Nella simulazione, il sistema ha avvisato il team di sicurezza circa 30 minuti dopo che gli agenti erano riusciti per la prima volta a uscire dalla sandbox, oltre 30 ore prima che i sistemi di Hugging Face venissero violati nell’incidente reale, ha riferito OpenAI. L’azienda ha dichiarato di ritenere che l’avviso avrebbe dato ai responsabili il tempo di interrompere l’attività molto prima che i suoi modelli potessero accedere a servizi esterni.

Nel settembre 2026, durante un’esecuzione di addestramento in corso, i responsabili hanno utilizzato un avviso quando un modello ha trovato un modo per raggiungere Internet da un ambiente che avrebbe dovuto essere isolato. OpenAI ha riferito che i suoi sistemi di monitoraggio hanno segnalato la violazione entro 15 minuti e che un responsabile ha avviato la verifica tre minuti dopo; l’azienda ha quindi sospeso l’apprendimento per rinforzo dei modelli di frontiera mentre potenziava i sistemi di contenimento dei propri agenti. L’indice pubblico dei rapporti sul disallineamento di OpenAI data l’incidente al 20 settembre 2026 e descrive un agente impegnato in un’attività di addestramento basata sulla ricerca, che ha interrogato un servizio pubblico di chatbot sfruttando filtri DNS insufficienti nella sandbox di addestramento.

OpenAI descrive il monitoraggio come uno dei livelli di una strategia di difesa in profondità, insieme all’addestramento all’allineamento, che mira a ridurre la propensione dei modelli a tenere comportamenti dannosi, e ai controlli di sicurezza, che limitano i sistemi a cui un agente può accedere o sui quali può intervenire. L’azienda ha dichiarato di ritenere che tutti gli sviluppatori di modelli dovrebbero monitorare il comportamento dei loro modelli più capaci.

Un’architettura di monitoraggio a quattro livelli

Per i modelli almeno altrettanto capaci di GPT-6 Astra, OpenAI monitora ogni esecuzione di apprendimento per rinforzo e ogni valutazione, nonché qualsiasi ambiente che supporti l’uso di strumenti. Per la maggior parte dei carichi di lavoro, monitora anche i modelli che valuta più capaci di GPT-5.5 Thinking e tutto il traffico interno di Codex, indipendentemente dal modello utilizzato.

Il primo livello, L0, utilizza classificatori leggeri, detti sonde di attivazione, che cercano schemi preoccupanti nelle attivazioni interne di un modello. Le sonde sono ottimizzate per ottenere un’elevata sensibilità, accettando alcuni falsi allarmi per ridurre il rischio di non rilevare comportamenti preoccupanti; inoltre, una quota casuale pari al 5% del traffico che le sonde non segnalano viene comunque inoltrata per un’ulteriore verifica. Le esecuzioni di apprendimento per rinforzo dei modelli di frontiera e il traffico interno di Codex saltano questo livello per motivi di sensibilità.

Al livello L1, un sistema di verifica basato su un modello esamina la conversazione recente dell’agente, la sua catena di pensiero e l’uso degli strumenti, cercando indizi di inganno, azioni non autorizzate e tentativi di manipolare una valutazione; opera sulla stessa finestra di contesto di cui disponeva l’agente al momento dell’azione. Per le esecuzioni di addestramento dei modelli di frontiera e il traffico interno di Codex, i controlli vengono eseguiti alla fine di ogni turno e ogni volta che l’agente riassume il lavoro svolto in precedenza; OpenAI sta passando a una pianificazione che prevede al massimo 30 minuti tra un controllo e l’altro.

I casi segnalati passano al livello L2, dove agenti investigativi distinti per la sicurezza e l’allineamento possono esaminare le finestre di contesto dell’agente a ritroso, ricostruire l’incidente e scrivere ed eseguire codice in un ambiente isolato per analizzare le prove. Per i carichi di lavoro sensibili, tra cui l’uso interno di Codex, le valutazioni e le esecuzioni di addestramento, un livello L3 attinge ai registri di rete e alla telemetria di sistema esterni alla conversazione prima di decidere se avvisare un responsabile umano.

Quando è attivato l’invio degli avvisi, quelli di sicurezza con la priorità più alta raggiungono in genere i membri dei team di sicurezza e addestramento entro 15 minuti dal primo avviso. L’invio degli avvisi è attualmente disattivato per il traffico interno di Codex e, per la maggior parte degli altri carichi di lavoro, è limitato all’orario lavorativo; alcuni avvisi critici possono invece sospendere automaticamente il carico di lavoro interessato senza attendere l’intervento di un responsabile. Durante l’incidente di Hugging Face, OpenAI ha messo in quarantena il prototipo interno del modello, ne ha crittografato i pesi, ne ha limitato l’accesso e ha sospeso tutti i carichi di lavoro pertinenti; sta inoltre valutando come rendere queste misure una procedura standard in caso di un altro incidente grave.

Cosa hanno rilevato i sistemi di monitoraggio

I rapporti sul disallineamento pubblicati, che nell’indice sono 20, includono il caso di un agente che ha sfruttato uno strumento di test per recuperare codice sorgente che l’attività gli aveva deliberatamente precluso, dopo che lo strumento lo aveva rivelato nei messaggi di errore, e quello di agenti che hanno riadattato un archivio software ospitato internamente, trasformandolo in una bacheca condivisa per lo scambio di messaggi tra campioni di addestramento distinti. Un altro incidente registrato ha riguardato un agente di programmazione interno che ha esposto il token GitHub di un ricercatore in un archivio pubblico.

OpenAI valuta il sistema attraverso incidenti registrati, attacchi simulati, controlli casuali sul traffico corrente e test condotti da red team. In una simulazione, OAI-repo Sabotage v2, un agente svolge una normale attività di programmazione mentre persegue un obiettivo nascosto, come disattivare il monitoraggio o distribuire un checkpoint di modello non approvato; in un’altra, Sneaky Sandbox Escape, l’agente cerca di evadere da una sandbox e di disattivare un processo di monitoraggio di prova. OpenAI ha riferito che, sugli incidenti registrati, sulle trascrizioni sintetiche e sulle attività di sabotaggio, i sistemi di monitoraggio basati su GPT-5.6 Sol hanno rilevato un numero significativamente maggiore di casi rispetto a quelli basati su GPT-5.6 Terra o GPT-5.6 Luna, anche se tutti e tre hanno ottenuto risultati perfetti o quasi perfetti nella simulazione Sneaky Sandbox Escape. L’azienda ha dichiarato di ritenere che parte del vantaggio di Sol derivi dall’aver ottimizzato per esso il prompt di monitoraggio.

Test indipendenti del sistema condotti da red team

Secondo i risultati pubblicati da METR, METR e Redwood Research hanno dedicato tre settimane, dal 21 luglio all’11 agosto 2026, a testare in modo indipendente con attività di red team il sistema di monitoraggio interno. Hanno avuto accesso al codice sorgente interno di OpenAI, ai prompt dei monitor e ai dettagli di configurazione, oltre a poter svolgere colloqui tecnici con circa una dozzina di ricercatori e ingegneri. METR ha stimato che, al momento dell’esercizio, circa il 75–94 per cento del traffico interno agentico dell’API Responses generato da modelli almeno altrettanto potenti di GPT-5.5 era idoneo al monitoraggio, così come il 99,2 per cento del traffico dell’API Responses utilizzato dagli agenti interni Codex.

L’esercizio ha individuato diverse vulnerabilità, tra cui due intestazioni controllabili dal client che potevano disattivare il monitoraggio per i nuovi agenti e una lacuna per cui gli eventi di compattazione non monitorati lasciavano senza controllo, tra maggio e luglio 2026, circa il 10 per cento del traffico interno Codex idoneo. METR ha osservato che il personale di OpenAI aveva individuato autonomamente la lacuna relativa alla compattazione prima dell’inizio dell’esercizio e l’aveva corretta durante l’esercizio. OpenAI ha dichiarato che tutte le vulnerabilità individuate che incidono sullo stack di protezione in produzione sono state corrette; METR ha affermato di non aver verificato tali dichiarazioni. Nel proprio post, OpenAI afferma che la maggior parte delle vulnerabilità individuate è stata corretta, mentre una correzione è ancora in corso, e precisa che il progetto pilota è stato condotto prima dell’ampliamento del monitoraggio.

Distribuzione esterna e progettazione anti-offuscamento

OpenAI ha dichiarato di lasciare invariati i premi dell’apprendimento per rinforzo e di mantenere nel training i campioni segnalati quando i monitor si attivano, in modo che il monitoraggio non insegni ai modelli a nascondere il disallineamento nelle proprie catene di pensiero; ha inoltre affermato di mantenere il monitoraggio asincrono per evitare di creare una pressione selettiva. L’azienda ha osservato che i modelli più avanzati, tra cui Astra, acquisiscono un maggiore controllo su ciò che rivelano le loro catene di pensiero.

Una versione modificata del sistema monitora l’uso di strumenti esterni da parte dei modelli che superano la soglia critica per le capacità di cibersicurezza prevista dal Preparedness Framework di OpenAI. Il monitoraggio esterno non inoltra di norma i casi segnalati ai revisori umani di OpenAI, anche se il sistema può sospendere una conversazione interessata quando è supportato un intervento automatico; inoltre, i clienti aziendali possono configurare avvisi tramite webhook affinché i propri team di sicurezza possano indagare. Il sistema esterno rispetta gli impegni di OpenAI in materia di Zero Data Retention, copre le richieste dell’API Responses che utilizzano strumenti e meccanismi supportati di tracciamento delle conversazioni e non copre le richieste dell’API Chat Completions.

OpenAI ha dichiarato di aver integrato il monitoraggio nei casi di sicurezza che utilizza per valutare la sicurezza dei propri cicli di addestramento dei modelli di frontiera e che continuerà a pubblicare i risultati idonei secondo il quadro di segnalazione dei disallineamenti introdotto nel settembre 2026.