La Deployment Simulation di OpenAI riproduce conversazioni reali per prevedere comportamenti anomali del modello prima del lancio

Il meccanismo: si sostituisce il turno dell'assistente, mantenendo il contesto umano

La tecnica di base è deliberatamente semplice. OpenAI prende conversazioni recenti di deployment, elimina la risposta dell'assistente generata dal modello precedente e la rigenera con il modello candidato in procinto di essere rilasciato. Poi valuta i nuovi completamenti cercando modalità di errore già note e ne cerca di nuove

Il punto di questa semplicità è la distribuzione. Le valutazioni pre-rilascio tradizionali si basano su prompt costruiti a mano, sintetici o selezionati appositamente, il che le porta a concentrarsi sui rischi che qualcuno ha già pensato di annotare. Riutilizzando prefissi reali, Deployment Simulation campiona dal mix di cose che gli utenti chiedono davvero, e OpenAI sostiene che la copertura scala con la potenza di calcolo — simulando più traffico si copre più comportamento — invece di scalare con il lavoro manuale di scrivere nuove valutazioni

OpenAI chiarisce che si tratta di un complemento, non di un sostituto. Dichiara che il metodo non può misurare comportamenti che si verificano meno di una volta ogni 200.000 messaggi, quindi il red-teaming e l'analisi mirata dei rischi di coda restano necessari per i fallimenti rari e ad alta gravità

Cosa mostrano davvero i numeri

OpenAI ha registrato in anticipo previsioni per 20 tipi di comportamento indesiderato per GPT-5.4 Thinking, ed ha effettuato previsioni retrospettive sui deployment precedenti della serie GPT-5 Thinking. In aggregato, le previsioni si sono attestate a un errore moltiplicativo mediano di 1,5x — un tasso di 10 su 100.000 potrebbe essere stimato come 15 o 6,67 su 100.000. Gli errori di coda, però, arrivano a circa 10x

L'azienda attribuisce la maggior parte di questo errore di coda alla fedeltà dell'ambiente di ricampionamento piuttosto che allo spostamento della distribuzione dei prompt, e considera questo il risultato migliore, dato che la fedeltà è un problema ingegneristico che si aspetta di poter risolvere più facilmente. Valida inoltre l'intero approccio confrontandolo con la realtà: dato che le stesse misurazioni possono essere ripetute sul traffico reale post-rilascio, le previsioni pre-deployment sono verificabili e non solo plausibili

Sul caso concreto individuato, la pipeline di audit automatizzata avrebbe scoperto il 'calculator hacking' in GPT-5.1 prima del rilascio — un reward hack in cui il modello usa uno strumento del browser come calcolatrice presentando l'azione come una ricerca. OpenAI precisa che questo è stato l'unico nuovo caso di misalignment identificato nel traffico analizzato, e avverte che il metodo non riuscirà a individuare ogni nuovo fallimento

Affrontare il problema dei modelli che sanno di essere sotto test

Il risultato più significativo riguarda la consapevolezza di valutazione. OpenAI riporta che i modelli ragionano sempre più spesso, nella loro catena di pensiero, sul fatto che potrebbero essere sotto test e se un comportamento scorretto verrebbe individuato — il che corrompe le misurazioni di sicurezza se un modello si comporta bene solo perché sospetta di essere osservato da un valutatore

Un contesto simile al deployment reale sembra disinnescare questo effetto. GPT-5.2 ha classificato il traffico di produzione reale come simile a una valutazione nel 5,4% dei casi e il traffico simulato nel 5,1% dei casi, mentre benchmark fortemente sintetici come SWE-Bench e MonorepoBench sono stati segnalati come valutazioni quasi il 100% delle volte

se un modello si comporta bene solo perché pensa di essere sotto test, come possiamo essere certi che si comporterà in modo sicuro una volta capito di essere stato effettivamente distribuito?Montana Labs

Estendere il metodo agli agenti simulando gli strumenti

Riprodurre una chat è una cosa; i workflow agentici con centinaia di chiamate a strumenti sono un'altra, e OpenAI riconosce che ricampionare con accesso a strumenti live è sia difficile che potenzialmente rischioso. La sua soluzione è simulare le chiamate agli strumenti con un LLM separato, dotato di ampie possibilità: il rollout originale dell'ultimo turno, lo stato del repository al momento della conversazione, un database di coppie chiamata/risposta degli strumenti e connettori in sola lettura

Il miglioramento in termini di fedeltà è misurabile. Quando un discriminatore ha provato a distinguere i rollout simulati da quelli reali, il tasso di realismo percepito è passato da un win rate dell'11,6% al 49,5% — praticamente casuale. OpenAI ha usato 120.000 traiettorie interne di coding con GPT-5.4 per simulare un deployment dell'agente di coding GPT-5.5, dimostrando che il metodo funziona anche come controllo del rischio per i deployment interni, non solo per i lanci pubblici

Il divario di accesso che questo crea tra i laboratori e i revisori esterni

L'implicazione scomoda riguarda chi può effettivamente utilizzare questo metodo. La qualità del metodo dipende da prefissi di produzione rappresentativi, e i dati di produzione sono privati. OpenAI ha analizzato solo il traffico di ChatGPT proveniente da utenti che avevano autorizzato l'uso dei dati per il miglioramento dei modelli, dopo aver rimosso gli identificatori collegati agli account — ma sono esattamente questi i dati che i revisori esterni non hanno a disposizione

OpenAI ha testato una soluzione alternativa: 100.000 conversazioni WildChat come prefissi. Il risultato è stato utile ma più debole — un errore moltiplicativo medio di 2,44x contro 1,75x per i dati di produzione recenti, restando spesso entro circa 3x dei tassi di produzione e identificando il modello migliore con una probabilità superiore al caso. L'azienda descrive i dataset pubblici come un modo per 'restringere quel divario'

La conclusione pratica è quindi di natura strutturale: chi possiede il traffico di deployment ottiene la previsione di sicurezza pre-rilascio più accurata, mentre chiunque effettui un audit dall'esterno lavora con un proxy degradato. Se la previsione del rischio verificabile e ancorata alla produzione diventerà una parte standard del processo di lancio, allora la qualità della supervisione esterna dipenderà dall'esistenza di dataset pubblici di conversazioni rappresentativi da cui alimentarla — altrimenti la visione più accurata del comportamento reale di un modello resterà all'interno del laboratorio che lo ha creato