Il contesto del rinvio di GPT‑6 Astra

Il 1 settembre 2026 OpenAI ha annunciato il rinvio di alcune fasi dello sviluppo e del rilascio di GPT‑6 Astra, sostenendo la necessità di rafforzare le protezioni contro l’uso malevolo in ambito informatico e le azioni non autorizzate del modello. Due giorni dopo, il 3 settembre, Astra è stato comunque lanciato, ma con le capacità più avanzate di cybersicurezza rese disponibili in modo limitato.

Non si è trattato di un ritiro di un prodotto già distribuito, ma di una decisione di posticipare attività critiche prima del lancio, accompagnata da una comunicazione sulle salvaguardie adottate e sui test effettuati. Questo episodio ha sollevato questioni giuridiche e tecniche: chi verifica che i test siano adeguati? Su quali prove si fonda la conclusione che i rischi residui siano accettabili? E quale ruolo può avere il controllo indipendente quando sviluppo, valutazione e decisione commerciale sono gestiti dalla stessa impresa?

Limiti dei test tradizionali

Le verifiche di sicurezza tipiche includono prove di robustezza, tentativi di eludere le protezioni e attività di red‑teaming, durante le quali i valutatori cercano deliberatamente di far emergere comportamenti rischiosi. Tali strumenti sono indispensabili, ma il loro valore dipende dagli scenari scelti, dagli accessi concessi al modello e dalle competenze di chi conduce le prove.

Un risultato positivo in un test non dimostra l’assenza di comportamenti pericolosi in contesti diversi. La difficoltà aumenta quando il modello può interagire con browser, terminali, codice o servizi esterni. Un modello valutato in ambiente isolato può comportarsi in modo totalmente differente quando riceve credenziali, accede a una rete o concatena numerose azioni.

Di conseguenza, nessuna batteria di prove può anticipare ogni combinazione di istruzioni, contesti e strumenti. I risultati devono essere interpretati alla luce delle condizioni in cui sono stati ottenuti e dei limiti metodologici: un punteggio elevato non garantisce che siano stati esaminati gli scenari più rilevanti o che le protezioni reggano nell’uso reale.

Il rischio di una “scorciatoia argomentativa”

Il pericolo non è abbandonare i test, ma trasformarli in una scorciatoia: “il modello ha superato le prove, dunque è sicuro”. Le prove supportano conclusioni circoscritte; occorre spiegare perché siano pertinenti e quanto giustifichino il giudizio complessivo. Senza una spiegazione strutturata, i test rischiano di diventare semplici checklist di conformità.

L’AI Act e la classificazione dei modelli a rischio sistemico

Il regolamento (UE) 2024/1689 introduce una distinzione tra modelli di IA per finalità generali e quelli classificati con “rischio sistemico”. L’articolo 51 stabilisce una presunzione di alto impatto quando il calcolo cumulativo impiegato per l’addestramento supera 10²⁵ operazioni in virgola mobile. Questa soglia è un indicatore, non una descrizione esaustiva del rischio; sono rilevanti anche le capacità operative del modello e altri criteri contemplati dal regolamento.

L’articolo 53 impone ai fornitori di modelli generali di mantenere una documentazione tecnica aggiornata, includendo il processo di addestramento, le valutazioni e i risultati. Per i modelli a rischio sistemico, l’articolo 55 aggiunge obblighi più stringenti:

    • valutazioni secondo protocolli e strumenti allo stato dell’arte;
    • test avversariali documentati;
    • valutazione e mitigazione dei rischi sistemici;
    • segnalazione di incidenti gravi;
    • adeguata protezione informatica del modello e dell’infrastruttura fisica.

Questa categoria non coincide con quella degli “sistemi di IA ad alto rischio”; non tutti i modelli avanzati rientrano automaticamente nell’articolo 55. La Commissione europea ha inoltre pubblicato un Codice di buone pratiche per i modelli generali, utile per dimostrare la conformità, ma non sostituisce una safety case approvata da un valutatore indipendente.

Safety case: un approccio strutturato alla verifica

Una safety case è un’argomentazione strutturata, sostenuta da evidenze, che dimostra che un sistema è sufficientemente sicuro per una specifica applicazione e in un determinato ambiente. Settori critici come aviazione, ferroviario e nucleare utilizzano già safety case, ma non esiste un modello unico trasferibile all’IA senza adattamenti.

L’AI Security Institute del Regno Unito descrive le safety case come argomentazioni legate a un contesto preciso di addestramento o distribuzione. Il metodo collega l’affermazione di sicurezza, le ragioni che la sostengono e le prove che la verificano. Tuttavia, l’Istituto riconosce che per modelli molto avanzati non è ancora possibile costruire safety case complete per tutti i rischi, soprattutto quelli legati alla perdita di controllo e all’autonomia elevata.

Cosa dovrebbe contenere una safety case per un modello generativo

Una safety case efficace dovrebbe includere:

    • elenco dettagliato degli strumenti accessibili al modello (browser, terminali, API esterne);
    • privilegi e limitazioni operative concessi;
    • descrizione dei meccanismi di limitazione (sandbox, policy di accesso, monitoraggio);
    • risultati dei test di aggiramento e dei red‑teaming, includendo sia i successi che i fallimenti;
    • correzioni implementate e prove della loro efficacia;
    • analisi delle debolezze residue e delle incertezze rimaste.

Non basta affermare che “l’agente non può compiere operazioni fuori dall’ambito autorizzato”. È necessario dimostrare, con prove concrete, come i limiti siano applicati, quali tentativi di aggiramento siano stati effettuati e quali siano i risultati.

Il ruolo del controllo indipendente

Affidarsi esclusivamente all’autovalutazione del fornitore pone rischi di conflitto di interesse: il fornitore sceglie gli scenari, controlla l’accesso al modello e decide quali risultati condividere. Un controllo indipendente, effettuato da terze parti accreditate, può verificare la solidità del giudizio, confrontare i risultati con scenari non considerati dal fornitore e valutare la trasparenza della documentazione.

Nel contesto dell’AI Act, i controlli indipendenti sono previsti soprattutto per i modelli a rischio sistemico, ma la loro efficacia dipende dalla capacità di accedere a dati sensibili, di replicare le condizioni operative reali e di valutare le interazioni con sistemi esterni.

Conclusioni e prospettive future

Il caso di GPT‑6 Astra dimostra che i test tradizionali, pur essendo essenziali, non possono da soli garantire la sicurezza di modelli IA altamente autonomi e collegati a strumenti esterni. È necessario un approccio integrato che combini:

    • test di robustezza e red‑teaming mirati;
    • documentazione tecnica dettagliata secondo l’articolo 53/55 dell’AI Act;
    • security case strutturate che spiegano il “perché” dei risultati;
    • controlli indipendenti effettuati da organismi accreditati.

Solo così sarà possibile rendere verificabile il ragionamento che porta alla decisione di rilasciare un modello, identificare le lacune residue e garantire che le protezioni siano adeguate anche in scenari non previsti durante i test iniziali. La sfida resta aperta: sviluppare metodologie di safety case scalabili e standardizzate, promuovere la trasparenza dei fornitori e rafforzare i meccanismi di sorveglianza indipendente, affinché l’innovazione dell’IA non comprometta la sicurezza dei sistemi e della società.