OpenAI ha pubblicato un documento sulle lezioni di sicurezza imparate distribuendo modelli che ragionano su orizzonti lunghi. Il punto centrale: quando un agente lavora per minuti o ore su un obiettivo, rischi di sicurezza nuovi emergono in fase di deployment che i test pre-rilascio non riescono a intercettare.

La tesi del documento è concreta. Il paradigma tradizionale del “safety checkpoint” parte dall’idea che puoi testare un modello, certificare che è sicuro e poi rilasciarlo. Con i modelli long-horizon questo approccio non regge: il comportamento rischioso si manifesta solo quando l’agente è in esecuzione reale, con accesso a strumenti, in sessioni che durano a lungo. La sicurezza diventa un processo continuo di monitoraggio e iterazione, non un esame di fine addestramento.

Perché ti riguarda. Se stai mettendo in produzione agenti che girano a lungo, e abbiamo raccontato cosa succede quando le cose vanno storte in questo caso concreto, il documento di OpenAI dà nome a un problema che forse hai già incontrato. Un agente che funziona nei tuoi test di dieci minuti può comportarsi in modo imprevedibile dopo un’ora di esecuzione. I checkpoint pre-rilascio ti dicono come si comporta il modello in isolation; il deployment ti mostra cosa fa quando ha strumenti, memoria e obiettivi complessi.

L’implicazione pratica è che la progettazione di un agente in produzione deve includere telemetria e guardrail in esecuzione, oltre ai test prima del lancio. Questo vale già per chi usa Claude Code o Codex su sessioni lunghe: il punto è costruire un processo che osserva e corregge mentre l’agente lavora.

Per capire come strutturare questi controlli, la lezione del corso su costi, latenza e sicurezza affronta il salto dalla demo al deployment.

Nel dettaglio

Cosa c’era prima.

Fino a oggi, la pratica standard per la sicurezza dei modelli seguiva uno schema lineare: addestramento, test su benchmark di sicurezza, red-teaming, certificazione, rilascio. Il modello passava un esame e diventava “sicuro”. Questo approccio funziona quando il modello risponde a singole richieste isolate. Funziona molto peggio quando il modello deve mantenere un comportamento coerente su orizzonti lunghi, con strumenti, memoria e obiettivi che cambiano durante l’esecuzione.

Cosa cambia.

Il documento di OpenAI introduce una distinzione che chi costruisce agenti in produzione dovrebbe tenere a mente. Safety as checkpoint significa: testo il modello prima del rilascio e, se passa, lo dichiaro sicuro. Safety as process significa: rilascio con telemetria, monitoro il comportamento in esecuzione reale, raccolgo i casi di fallimento e itero. La seconda integra la prima con un livello che il checkpoint non può coprire.

I rischi che emergono solo in deployment sono di un tipo particolare. Un modello che ragiona su orizzonti lunghi può sviluppare strategie di completamento del task che non erano prevedibili dai test su sessioni brevi. Può accumulare stato in modi che cambiano il suo comportamento successivo. Può usare strumenti in combinazioni che un test isolato non esplora. Il documento di OpenAI li descrive come una categoria di rischi strutturali del paradigma long-horizon, non come bug specifici.

Il dettaglio tecnico per chi non fa ricerca.

Un “modello long-horizon” è un modello addestrato per ragionare su sequenze di passi che possono durare minuti o ore, non secondi. La differenza fra un assistente che risponde a una domanda e uno che deve completare un progetto intero: raccogliere informazioni, prendere decisioni intermedie, ricordare cosa ha già fatto, aggiustare il piano. La superficie di comportamento possibile cresce con la lunghezza dell’orizzonte, e con lei cresce la superficie di rischio.

La telemetria che OpenAI descrive come necessaria è osservabilità standard per chi ha costruito sistemi distribuiti: log delle azioni dell’agente, monitoraggio delle sequenze di tool calling, rilevamento di pattern anomali nel comportamento continuo. Applicata qui al comportamento del modello invece che a quello di un servizio backend.

Limiti di quello che si sa ora.

Il documento è una fonte primaria di OpenAI sul proprio lavoro. È onesto sui rischi che hanno osservato, ma resta un post tecnico, non un paper peer-reviewed con metriche ripetibili. Descrive la pratica di un solo laboratorio: quello che funziona per OpenAI può non trasferirsi meccanicamente ad altri contesti, soprattutto per chi usa modelli open-weight con meno infrastruttura di monitoring.

Resta aperta la domanda più pratica: quanto costa, in tempo e risorse, implementare safety as process in produzione? OpenAI non dà numeri su questo. Per chi costruisce agenti con budget piccoli, la telemetria continua può essere un costo significativo, e il documento non aiuta a quantificarlo.