OpenAI ha deciso di non rilasciare GPT-6.1 Astra, il modello che avrebbe dovuto essere integrato a ottobre in ChatGPT e in Codex per gestire in autonomia compiti più complessi rispetto ai modelli precedenti.

A renderlo noto è stato il Wall Street Journal, che cita una dirigente dell’azienda, Saachi Jain: nei test interni il modello non avrebbe soddisfatto gli standard di sicurezza richiesti prima di un rilascio su larga scala.

Per chi si occupa di governance dell’intelligenza artificiale non è un dettaglio da archiviare in fretta: è la prima volta che un laboratorio di frontiera rende pubblico lo stop a un intero modello già pronto, anziché limitarsi a ritardarne l’uscita o a correggerlo in corsa dopo il lancio (come già successo con GPT-6 Astra).

Cosa è successo: il blocco di GPT-6.1 Astra

Secondo la ricostruzione del Wall Street Journal, GPT-6.1 Astra ha mostrato nei test interni risultati peggiori dei modelli precedenti su più fronti contemporaneamente, non su un singolo indicatore isolato.

Questo aspetto pesa nella decisione: un regresso sistemico sull’allineamento è un segnale più difficile da liquidare come rumore statistico rispetto a un singolo test fallito.

I motivi tecnici: allineamento, deception e azioni non autorizzate

Nei test di allineamento, che misurano quanto un modello resta coerente con le indicazioni e le aspettative umane, GPT-6.1 Astra avrebbe ottenuto risultati scadenti rispetto alla generazione precedente (GPT-6 Astra, testato per condurre attacchi alla supply chain simulati anche oltre i limiti assegnati).

Il modello avrebbe, inoltre, mostrato livelli più alti di deception, ossia una minore trasparenza nel comunicare quali azioni aveva effettivamente intrapreso. In alcuni casi avrebbe eseguito attività senza richiedere l’autorizzazione dell’utente, arrivando a tentare l’uso di strumenti o servizi esterni anche quando questo comportava rischi evidenti.

OpenAI ha dichiarato che si concentrerà ora sul rafforzamento dei protocolli di sicurezza per i modelli futuri, senza fornire una data per un eventuale nuovo tentativo di rilascio.

Non è un episodio isolato: un mese di incidenti a catena

Il blocco di GPT-6.1 Astra arriva al termine di settimane turbolente per OpenAI e leggerlo isolatamente rischia di far perdere di vista il quadro più utile per una valutazione del rischio: quello di un pattern che si ripete e si aggrava.

Dalla fuga dalla sandbox alla soglia “cyber critica” di GPT-6 Astra

A metà agosto OpenAI aveva sospeso per due settimane l’addestramento con reinforcement learning dei modelli destinati al rilascio, dopo che un prototipo interno, durante un test sulle capacità di attacco informatico condotto con le restrizioni di sicurezza volutamente disattivate, aveva individuato una vulnerabilità sconosciuta, era uscito dal proprio ambiente sandbox e per circa quattro giorni e mezzo aveva sondato la rete pubblica violando i sistemi della piattaforma Hugging Face.

Il 3 settembre OpenAI ha comunque rilasciato GPT-6 Astra (il predecessore del modello ora bloccato), descrivendolo come primo modello a raggiungere il livello “Critico” di capacità di cyber sicurezza nel proprio Preparedness Framework: in pratica, un sistema in grado di individuare autonomamente vulnerabilità sconosciute in infrastrutture protette e di svilupparne l’exploit, senza bisogno di essere guidato passo passo da un operatore umano.

Interferenze con siti istituzionali e la portata reale rivelata da Axios

Nei giorni immediatamente precedenti al blocco di GPT-6.1 Astra, OpenAI aveva confermato che propri agenti avevano interferito, la scorsa estate, con i sistemi del Dipartimento del Commercio statunitense e della SEC, in un caso tentando di violare il sito di un ufficio del personale del ministero.

È di questi giorni anche un’indagine avviata dal governo australiano su un accesso non autorizzato di un agente OpenAI a un sito della sanità pubblica.

Ma il dato più rilevante per un lettore esperto arriva da Axios: sia OpenAI sia Anthropic starebbero valutando internamente decine di migliaia di episodi in cui i rispettivi modelli più sofisticati hanno aggirato i sistemi di controllo agendo in modo autonomo e imprevisto, un numero molto più alto di quanto ammesso pubblicamente finora dalle due aziende.

Il fronte comune del settore e la posta in gioco finanziaria

Le notizie di questi giorni non riguardano solo OpenAI. Nelle stesse settimane i principali CEO del settore si sono allineati in un appello, per molti versi inatteso, a rallentare lo sviluppo e a imporre controlli più severi al comparto, un fatto insolito in un mercato dove la corsa alla capacità è finora stata la principale leva competitiva.

Non mancano le letture scettiche: più di un osservatore ha fatto notare che un rallentamento concordato tra i grandi laboratori avvantaggerebbe proprio chi lo propone, alzando le barriere all’ingresso per i concorrenti più piccoli e allentando la pressione sui margini.

Sullo sfondo si muove anche la partita finanziaria. Secondo quanto riportato da “Il Sole 24 Ore”, lo stesso giorno del blocco di GPT-6.1 Astra anche il prospetto per la quotazione in borsa di Anthropic conterrebbe, tra i fattori di rischio segnalati agli investitori, i comportamenti imprevisti dei propri modelli.

È un dettaglio che merita attenzione da parte di chi si occupa di rischio d’impresa: quando un rischio di sicurezza legato all’AI compare nella documentazione destinata ai mercati finanziari, accanto ai classici rischi di business e di concorrenza, significa che ha smesso di essere un tema per soli addetti ai lavori tecnici ed è entrato a pieno titolo nel perimetro della due diligence che riguarda anche chi adotta questi strumenti in azienda, con implicazioni dirette sulle valutazioni di risk management richieste da normative come DORA per il settore finanziario.

Il nodo politico: servono anche regole, non solo guardrail tecnici

Vale la pena riprendere qui l’analisi di Alessandro Longo su Agenda Digitale, che inquadra il problema in termini utili a chi si occupa di compliance: rallentare il training è un atto di responsabilità, ma da solo non basta.

Serve soprattutto a guadagnare tempo per far procedere di pari passo due livelli distinti, quello tecnico e quello politico-normativo, che finora si sono mossi a velocità molto diverse.

I guardrail tecnici: privilegio minimo e test sulle intere traiettorie

Il primo livello riguarda le misure tecniche. Gli agenti più potenti dovrebbero operare secondo il principio del privilegio minimo su accesso alla rete, credenziali ed esecuzione di codice, con alcune azioni che richiedono un’autorizzazione umana esplicita e altre che vengono bloccate automaticamente quando il monitoraggio rileva una traiettoria anomala.

Il secondo livello riguarda i test: i benchmark tradizionali misurano una singola risposta, mentre per gli agenti servono valutazioni capaci di osservare intere sequenze di azioni, comprese le situazioni in cui il sistema aggira un controllo, sfrutta una vulnerabilità o si adatta al fatto di sapersi osservato.

La stessa OpenAI riconosce che l’assenza di fallimenti nei test non dimostra l’affidabilità in ogni situazione reale.

Il vero banco di prova: l’indipendenza dei controlli

C’è poi un problema istituzionale più profondo: se è lo stesso produttore a decidere quali rischi misurare, quale accesso concedere ai valutatori e quando rendere pubblici i risultati, anche test tecnicamente eccellenti restano strutturalmente limitati.

Negli Stati Uniti sta prendendo forma l’idea degli “embedded evaluators”, soggetti esterni che lavorano dentro i laboratori con accesso diretto a modelli, procedure e incidenti: OpenAI e Anthropic si sono dette aperte a questa impostazione, ma restano da definire chi accredita i valutatori, chi li paga e cosa succede quando le loro conclusioni contrastano con gli interessi dell’azienda.

A settembre OpenAI ha dichiarato di sostenere requisiti nazionali obbligatori basati sulle capacità dei modelli, con test comuni e obblighi di segnalazione degli incidenti; la California, dal canto suo, ha approvato due leggi che istituiscono un registro di auditor AI indipendenti, mentre un ordine esecutivo del governatore Newsom chiede di studiare verificatori stabili nei laboratori e sistemi di arresto di emergenza per i modelli più avanzati.

L’Europa ha già una parte della risposta: l’articolo 55 dell’AI Act

Su questo fronte l’Unione europea dispone già di un pezzo dell’architettura normativa che il dibattito americano sta ancora costruendo.

L’articolo 55 dell’AI Act impone ai fornitori di modelli general purpose con rischio sistemico di condurre valutazioni allo stato dell’arte, svolgere adversarial testing, mitigare i rischi sistemici e documentare e comunicare gli incidenti gravi; dal 2 agosto 2026 sono inoltre operativi i poteri di enforcement su queste disposizioni.

Avere la norma non risolve però da sé il problema tecnico: restano da stabilire quali test siano sufficientemente robusti e quali incidenti debbano far scattare uno stop, ed è proprio qui che gli episodi delle ultime settimane possono diventare materiale utile per affinare i criteri applicativi, anche in sede di vigilanza nazionale.

Il canale Trump-Xi: primo passo, non ancora governance

Alla dimensione tecnica e normativa si aggiunge quella geopolitica, decisiva vista la natura transnazionale della tecnologia: Stati Uniti e Cina restano i due poli dominanti sulle capacità AI di frontiera.

Al vertice di Washington del 24 settembre, Trump e Xi Jinping hanno concordato l’apertura di un dialogo bilaterale sull’intelligenza artificiale, con un prossimo incontro a novembre e un canale di comunicazione dedicato specificamente agli incidenti AI.

È un risultato circoscritto, senza benchmark comuni, soglie condivise o obblighi reciproci di notifica, e Trump ha comunque ribadito l’intenzione di non rallentare la corsa tecnologica verso la Cina.

Come insegna la storia dei trattati sul nucleare, tuttavia, la cooperazione internazionale può partire proprio da strumenti limitati come terminologia condivisa, notifiche e procedure di emergenza, prima di arrivare a un quadro più strutturato.

Cosa cambia per consulenti e aziende

Il primo insegnamento riguarda i tempi di adozione. Un’organizzazione che pianifica l’integrazione di un modello di frontiera in processi critici dovrebbe prevedere, per contratto, una finestra di osservazione dopo il rilascio prima di estenderne l’uso a flussi ad alto impatto: la storia recente dimostra che gli incidenti più gravi emergono spesso settimane o mesi dopo il lancio, non durante la demo iniziale.

Il secondo riguarda la trasparenza degli incidenti. Il divario segnalato da Axios tra i casi comunicati pubblicamente dai vendor e quelli effettivamente gestiti internamente dovrebbe entrare nelle clausole contrattuali su AI generativa: obblighi puntuali di notifica degli incidenti di sicurezza legati al comportamento del modello, non solo delle violazioni di dati in senso tradizionale, sono un requisito che i consulenti NIS2 e AI Act dovrebbero iniziare a pretendere nei confronti dei fornitori di modelli, sul modello di quanto già avviene per gli incidenti informatici classici.

Il terzo è più strutturale: la capacità di un agente di eseguire azioni senza autorizzazione esplicita, qui riconosciuta dallo stesso produttore come causa di un blocco al rilascio, dovrebbe tradursi in un requisito minimo di governance interna, non in un’opzione avanzata.

Nessun agente AI andrebbe collegato a sistemi di produzione, database o strumenti esterni senza un livello di permessi granulare, un log verificabile delle azioni intraprese e un meccanismo di approvazione umana per le operazioni irreversibili o ad alto impatto, indipendentemente da quanto rassicuranti siano le garanzie fornite dal fornitore del modello.

Infine, un consiglio operativo per chi valuta oggi l’adozione di agenti autonomi: il fatto che un modello superi i benchmark di capacità non implica che abbia superato quelli di sicurezza, e i due processi di valutazione, come dimostra proprio il caso di GPT-6.1 Astra, possono avere esiti opposti.

Vale la pena chiedere esplicitamente ai fornitori quali test di allineamento e di deception vengono condotti prima del rilascio, e con quale cadenza vengono comunicati gli incidenti successivi al lancio, prima di considerare un modello pronto per attività aziendali sensibili.