La sicurezza dell’intelligenza artificiale avanzata non dipende soltanto da ciò che un modello sa fare, ma anche da ciò che può fare quando viene collegato a strumenti esterni e opera con un certo grado di autonomia. Un errore di risposta può essere corretto; un agente che accede a un sistema, modifica codice o avvia operazioni non autorizzate può produrre conseguenze concrete. Prima del rilascio, dunque, non basta misurare le prestazioni: occorre valutare i rischi, l’efficacia delle protezioni e i limiti di ciò che i test consentono di concludere.
La questione è emersa nel caso di GPT-6 Astra. Il 1° settembre 2026 OpenAI ha dichiarato di aver ritardato alcune fasi dello sviluppo e del rilascio per rafforzare le protezioni contro l’uso malevolo in ambito informatico e contro le azioni non autorizzate del modello. Astra è stato poi lanciato il 3 settembre. Non si è trattato, quindi, del ritiro di un prodotto già distribuito, ma di una decisione di rinviare alcune attività prima del lancio. OpenAI ha pubblicato informazioni sui test e sulle salvaguardie adottate, annunciando inoltre che le capacità più avanzate di cybersicurezza sarebbero state rese disponibili inizialmente in modo limitato.
Indice degli argomenti
Sicurezza dei modelli AI: test e controlli prima del rilascio
Il rilievo giuridico va oltre il singolo caso. Chi verifica che i test siano adeguati? Su quali prove si fonda la conclusione che i rischi residui siano accettabili? E quale spazio resta al controllo indipendente quando sviluppo, valutazione e decisione commerciale fanno capo alla stessa impresa? L’AI Act offre già alcune risposte, ma il dibattito sulle safety case permette di chiedersi se gli obblighi attuali rendano davvero verificabile il giudizio che precede il rilascio.
Perché l’assenza di rischi nei test non basta
Le verifiche di sicurezza comprendono 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. Sono strumenti indispensabili, ma il risultato dipende dagli scenari scelti, dagli accessi concessi al modello e dalle competenze di chi conduce le prove. Il fatto che un comportamento pericoloso non si manifesti durante un test non dimostra che sia impossibile in un altro contesto.
La difficoltà aumenta quando il sistema può usare browser, terminali, codice o servizi esterni. Un modello valutato in ambiente isolato può comportarsi diversamente quando riceve credenziali, accede a una rete o concatena numerose azioni. La sicurezza dipende allora non soltanto dal modello, ma anche dai privilegi assegnati, dalle configurazioni, dai controlli sugli strumenti e dalla possibilità di registrare e interrompere le operazioni.
Nessuna batteria di prove può anticipare ogni combinazione di istruzioni, contesti e strumenti. I risultati devono essere letti insieme alle condizioni in cui sono stati ottenuti e ai limiti della metodologia: un punteggio elevato non dice, da solo, se siano stati esaminati gli scenari più rilevanti o se le protezioni reggano nell’uso reale. Il problema non è abbandonare i test, ma evitare che diventino una scorciatoia argomentativa: il modello ha superato determinate prove, dunque è sicuro. Le prove sostengono conclusioni circoscritte; occorre spiegare perché siano pertinenti e quanto giustifichino il giudizio complessivo.
AI Act e tutela dai rischi dei modelli per finalità generali
Il regolamento (UE) 2024/1689 distingue i modelli di IA per finalità generali e prevede obblighi specifici per quelli classificati con rischio sistemico. L’articolo 51 disciplina la classificazione e include una presunzione di capacità ad alto impatto quando il calcolo cumulativo impiegato per l’addestramento supera 10²⁵ operazioni in virgola mobile. La soglia è un indicatore previsto dalla norma, non una descrizione esaustiva del rischio: rilevano anche le capacità del modello e gli ulteriori criteri contemplati dal regolamento.
Gli obblighi di documentazione, test e mitigazione
L’articolo 53 impone ai fornitori di modelli per finalità generali di predisporre e aggiornare la documentazione tecnica, compresi il processo di addestramento, le valutazioni e i relativi risultati. Richiede inoltre informazioni per chi intenda integrare il modello in un sistema di IA, così da comprenderne capacità e limiti. Per i modelli con rischio sistemico, l’articolo 55 aggiunge valutazioni secondo protocolli e strumenti allo stato dell’arte, test avversariali svolti e documentati, valutazione e mitigazione dei rischi sistemici, segnalazione degli incidenti gravi e adeguata protezione informatica del modello e dell’infrastruttura fisica.
Modelli a rischio sistemico e sistemi ad alto rischio
Questa categoria non va confusa con quella dei sistemi di IA ad alto rischio: il regime dei modelli per finalità generali con rischio sistemico è distinto, e non ogni modello avanzato ricade automaticamente nell’articolo 55. La Commissione europea ha inoltre promosso un Codice di buone pratiche per i modelli per finalità generali, che aiuta i fornitori a dimostrare la conformità agli obblighi del regolamento. Si tratta di un riferimento operativo importante, ma non equivale a un obbligo generale di sottoporre ogni modello a una safety case approvata da un valutatore indipendente.
La questione, perciò, non è l’assenza di regole sui test. È capire se la documentazione prevista basti a rendere comprensibile e controllabile la decisione finale: quali rischi sono stati considerati, perché le verifiche sono ritenute adeguate e su quali elementi si fonda l’accettazione del rischio residuo.
Safety case per rendere verificabile la sicurezza dei modelli AI
Una safety case è un’argomentazione strutturata, sostenuta da evidenze, secondo cui un sistema è sufficientemente sicuro per una determinata applicazione e in uno specifico ambiente. Approcci di questo tipo sono presenti, con forme e requisiti diversi, in settori critici quali l’aviazione, il ferroviario e il nucleare. Non esiste però un modello unico da trasferire senza adattamenti all’IA: le capacità dei modelli generativi e l’incertezza dei loro comportamenti richiedono metodi specifici.
Il metodo dell’AI Security Institute
L’AI Security Institute del Regno Unito descrive le safety case come argomentazioni riferite a un contesto preciso di addestramento o distribuzione. Il metodo collega l’affermazione di sicurezza, le ragioni che la sostengono e le prove che permettono di verificarla. L’Istituto considera l’approccio promettente, ma riconosce che non è ancora possibile costruire safety case complete per tutti i rischi associati a modelli molto più avanzati, soprattutto rispetto alla perdita di controllo e all’autonomia elevata.
Dalle prove alle conclusioni verificabili
In concreto, non basterebbe affermare che un agente non può compiere operazioni fuori dall’ambito autorizzato. Occorrerebbe indicare quali strumenti utilizza, quali privilegi possiede, come vengono applicati i limiti, quali tentativi di aggiramento sono stati effettuati e con quali risultati. Andrebbero documentati anche i fallimenti, le correzioni e le prove che ne dimostrano l’efficacia. L’obiettivo non è raccogliere soltanto gli elementi favorevoli, ma rendere visibili le debolezze rimaste e le incertezze.
La differenza rispetto a una semplice raccolta di test è sostanziale: i test producono risultati, mentre la safety case spiega perché quei risultati sostengano una certa conclusione. Deve rendere esplicite le ipotesi, la copertura delle verifiche e le condizioni che potrebbero invalidare il giudizio. Non garantisce innocuità assoluta, ma permette di individuare più facilmente lacune nel ragionamento e conclusioni non supportate da prove sufficienti.
Verifiche indipendenti sui rischi dei modelli AI
Una documentazione accurata non risolve da sola il problema della verifica. Se il fornitore sceglie gli scenari, controlla l’accesso al modello e decide quali risultati condividere, può essere difficile valutare dall’esterno la solidità del giudizio. L’autovalutazione resta indispensabile, perché lo sviluppatore dispone delle conoscenze tecniche più approfondite; nei casi di maggiore rischio, però, è opportuno affiancarle una revisione indipendente, con accesso adeguato alle informazioni e libertà di metodo.
Segreti commerciali e pubblicazione dei risultati
Il tema è emerso anche nel confronto tra imprese e valutatori esterni. Il 13 ottobre 2026 Reuters ha riferito di negoziati tra OpenAI, Anthropic e soggetti incaricati di valutare i modelli, soprattutto sul controllo delle pubblicazioni e sulla protezione dei segreti commerciali. Il problema è concreto: le informazioni necessarie a verificare un rischio possono sovrapporsi a dettagli tecnici riservati. Ma se la riservatezza consente al fornitore di impedire la comunicazione di risultati sfavorevoli, il controllo perde credibilità.
Non occorre necessariamente pubblicare tutti i dati grezzi o i dettagli delle vulnerabilità: una divulgazione indiscriminata potrebbe agevolare abusi. È però necessario distinguere tra l’accesso pieno delle autorità e dei valutatori autorizzati, una sintesi pubblica dei risultati e le informazioni la cui diffusione comporterebbe un rischio concreto. Le omissioni dovrebbero essere motivate e non svuotare di significato le conclusioni. Anche sul piano organizzativo, il valutatore deve poter scegliere metodi adeguati, riportare risultati negativi e dichiarare le limitazioni di accesso senza pressioni improprie.
Dopo il rilascio: come cambia la sicurezza dei modelli AI
Una safety case non può valere per sempre. I modelli vengono aggiornati, collegati a nuovi strumenti o distribuiti in ambienti diversi. Anche senza modificare i parametri del modello, concedergli nuovi privilegi o connetterlo a un servizio esterno può cambiare il profilo di rischio. La valutazione deve quindi identificare la versione esaminata e le condizioni alle quali le conclusioni restano valide.
Quando aggiornamenti e incidenti impongono un riesame
Modifiche sostanziali, vulnerabilità nuove, incidenti o comportamenti inattesi dovrebbero comportare un riesame. Sono essenziali il monitoraggio successivo al rilascio, la registrazione degli eventi rilevanti e la possibilità di interrompere le operazioni. Le informazioni raccolte nell’uso reale devono poter modificare le valutazioni precedenti, non limitarsi a essere archiviate. Se un incidente smentisce un’ipotesi iniziale, occorre chiarire quale parte dell’argomentazione non regga più, quali misure siano state adottate e quali nuove prove sostengano il giudizio aggiornato.
Regole e responsabilità per la sicurezza dei modelli AI
L’AI Act stabilisce già obblighi significativi di valutazione, documentazione e mitigazione, soprattutto per i modelli per finalità generali con rischio sistemico. La sfida è assicurare che le valutazioni siano solide e le conclusioni verificabili. Un modello può superare molte prove senza che ciò dimostri la sua sicurezza in ogni contesto; allo stesso modo, una documentazione ampia può essere poco convincente se non collega rischi, test, misure adottate e decisione finale.
Le safety case possono contribuire a colmare questo spazio, purché non diventino un nuovo adempimento burocratico. Il loro valore sta nel rendere esplicito il ragionamento, esporre le evidenze favorevoli e contrarie e dichiarare le incertezze residue. Per i modelli più capaci, questa argomentazione dovrebbe essere sottoposta a una verifica indipendente proporzionata al rischio.
La regolazione non può eliminare ogni comportamento inatteso; può però stabilire chi debba valutare, quali elementi vadano documentati e che cosa accada quando emergono criticità. La sicurezza non dovrebbe dipendere soltanto dalla dichiarazione del produttore di aver svolto controlli adeguati. Deve risultare da un processo verificabile, aggiornabile e capace di incidere davvero sulla scelta di rilasciare, limitare o sospendere un sistema.
Partecipa alla community