Il 21 luglio 2026 OpenAI ha reso noto che alcuni suoi modelli, durante prove interne di sicurezza informatica, erano usciti dall’ambiente in cui erano confinati e avevano violato i sistemi di Hugging Face, la piattaforma su cui gli sviluppatori condividono modelli e dati. I modelli operavano come agenti, cioè sistemi che eseguono in autonomia un compito assegnato.
Il 5 settembre la società ha riconosciuto un secondo episodio, emerso il giorno prima da una ricostruzione di ricercatori indipendenti ripresa dall’agenzia di stampa Reuters: per settimane gli stessi agenti avevano scritto su un wiki tedesco di programmazione per scambiarsi istruzioni su come aggirare i limiti imposti.
Nel post pubblico OpenAI scrive che manca ancora uno standard chiaro per comunicare gli incidenti di disallineamento, cioè i casi in cui un modello si comporta in modo diverso da quanto voluto da chi lo controlla. Il 16 settembre, la società pubblica un proprio quadro di riferimento con sei rapporti su episodi degli ultimi sei mesi.
Uno standard, però, esisteva già dal 10 luglio 2025. È il capitolo sulla sicurezza del Codice di condotta per i modelli di IA per finalità generali, redatto da esperti indipendenti sotto la guida dell’AI Office – l’ufficio della Commissione europea incaricato della vigilanza sui modelli – e pubblicato dalla Commissione come strumento per adempiere agli obblighi dell’AI Act.
OpenAI ha dichiarato di volerlo sottoscrivere l’11 luglio 2025 e figura ad oggi tra i firmatari. Il testo fissa termini in giorni per segnalare gli incidenti gravi all’AI Office: cinque nel caso di una violazione di cybersicurezza, categoria che comprende gli attacchi informatici. Il 7 settembre, nel briefing quotidiano, il portavoce della Commissione ha avvertito che quelle segnalazioni non sono una mera formalità, e la Commissione ha confermato di aver ricevuto una relazione da OpenAI, senza indicarne la data.
Il quadro pubblicato da OpenAI il 16 settembre non nomina né il Codice né l’AI Office. Il primo collaudo del regime degli incidenti gravi dell’AI Act non si è dunque arenato su una lacuna delle regole, ma sulla qualificazione dell’incidente, che, come in ogni regime di notifica, è rimessa in prima battuta a chi lo ha causato.
È lo stesso nodo che l’art. 73 dell’AI Act porterà alle organizzazioni che sviluppano o utilizzano sistemi ad alto rischio, con una differenza già scritta negli atti della Commissione: per quei sistemi esiste una guida di tredici pagine che spiega con esempi quando un incidente è grave; per i modelli più avanzati, soltanto un modulo di nove caselle da compilare.
Indice degli argomenti
- Da maggio a settembre: cosa è successo, secondo OpenAI
- Il Codice di condotta: cinque giorni e l’obbligo di leggere i giornali
- Chi decide se un incidente è “grave”?
- Tredici pagine per i sistemi ad alto rischio, un modulo per i modelli
- Poteri esercitati, tempi decisi dai fornitori
- La stessa domanda arriverà alle organizzazioni
Indice degli argomenti
Gli incidenti gravi nell’AI Act: la cronologia del caso OpenAI
La cronologia la fornisce OpenAI stessa nel rapporto tecnico del 26 agosto, sul caso che questa testata ha raccontato a luglio. La bacheca improvvisata con cui gli agenti, alle prese con compiti impossibili da completare, si scambiavano messaggi dentro l’infrastruttura interna risale al 12 maggio. A fine maggio un gruppo di tecnici ne osserva l’attività ma, scrive il rapporto, le implicazioni di quella comunicazione non erano ancora comprese.
L’intrusione nei sistemi di Hugging Face, tra il 10 e il 12 luglio, viene rilevata dai sistemi di OpenAI il 19 e comunicata il 21. Il rapporto elenca contromisure e modifiche all’addestramento, e non nomina l’AI Office né alcuna altra autorità.
Il wiki tedesco e l’emersione pubblica
Per il wiki la sequenza è diversa: l’emersione pubblica è del 4 settembre, per iniziativa di terzi, e il riconoscimento della società del giorno seguente, con un messaggio che distingue questi episodi dagli incidenti di sicurezza tradizionali e annuncia un quadro di riferimento per le settimane successive, che arriva il 16 settembre: sei rapporti su comportamenti osservati negli ultimi sei mesi, nei quali il wiki non è menzionato e che il documento presenta come una prima serie, non come un resoconto completo delle indagini in corso.
Codice di condotta e obblighi sugli incidenti gravi
L’art. 55, par. 1, lett. c), del regolamento (UE) 2024/1689 impone ai fornitori dei modelli con rischio sistemico – la categoria dei modelli più capaci, cui l’AI Act riserva obblighi aggiuntivi – di tenere traccia degli incidenti gravi, documentarli e comunicarli “senza indebito ritardo” all’AI Office, insieme alle eventuali misure correttive.
L’incidente grave è definito dall’art. 3, n. 49, attraverso le conseguenze, dal decesso di una persona ai “gravi danni alle cose o all’ambiente”, passando per le infrastrutture critiche e i diritti fondamentali. L’obbligo si applica dal 2 agosto 2025, le sanzioni dell’art. 101 dal 2 agosto 2026, e la vigilanza spetta in via esclusiva alla Commissione ai sensi dell’art. 88, par. 1.
La misura 9.3 e i termini di segnalazione
Il Codice, pubblicato dalla Commissione il 10 luglio 2025 e sottoscritto, tra gli altri, da OpenAI, Anthropic, Google e Microsoft (Meta al momento non figura tra i firmatari), traduce quell’obbligo nell’impegno 9 del capitolo sulla sicurezza. La misura 9.3 fissa i termini del rapporto iniziale, che decorrono dal momento in cui il firmatario viene a conoscenza del coinvolgimento del proprio modello.
Sono due giorni per la perturbazione irreversibile di un’infrastruttura critica, cinque per una violazione grave di cybersicurezza, che comprende gli attacchi informatici e l’esfiltrazione dei pesi del modello anche a opera del modello stesso, dieci per il decesso di una persona, quindici per i danni alla salute, ai diritti fondamentali, alle cose o all’ambiente. La misura 9.1 impone di individuare gli incidenti anche attraverso i rapporti di polizia, la stampa, i social media, le pubblicazioni scientifiche e le banche dati degli incidenti, cioè le fonti da cui a settembre l’episodio del wiki è emerso, e la misura 9.2 elenca i nove elementi da documentare.
La premessa del capitolo, al punto (j), precisa che segnalare un incidente grave non equivale ad ammettere una colpa. La Commissione ha poi pubblicato il modulo di segnalazione, che riproduce i nove elementi in altrettante caselle come strumento per dimostrare il rispetto dell’art. 55. Lo standard che il messaggio del 5 settembre dichiarava mancante, in realtà, esisteva due volte: nel testo sottoscritto e nel modulo che serve ad applicarlo.
Chi qualifica un incidente grave ai sensi dell’AI Act
Un wiki altrui riempito di istruzioni per aggirare le restrizioni non causa decessi né perturba infrastrutture critiche, e ricondurlo ai danni gravi alle cose o alla violazione di obblighi a tutela dei diritti fondamentali richiede un giudizio che la definizione dell’art. 3, n. 49, non compie da sola.
La categoria del Codice sulla cybersicurezza copre l’uscita dall’ambiente di prova e l’intrusione nei sistemi di terzi, perché nomina gli attacchi informatici e contempla il modello come possibile autore della violazione, mentre lascia all’interpretazione le scritture non autorizzate su un sito pubblico. È in quello spazio che pesa la distinzione proposta da OpenAI tra incidenti di sicurezza tradizionali e disallineamento, una distinzione che il Codice non contempla.
La procedura interna di OpenAI
Il quadro del 16 settembre formalizza quella distinzione. La procedura è interna: qualunque dipendente può segnalare un caso, che viene assegnato a uno di tre percorsi di indagine con scadenze che il documento non quantifica, e i disaccordi sulla pubblicazione sono rimessi a un gruppo di dirigenti della società.
Il criterio è più ampio di quello dell’art. 3, n. 49, perché un caso merita di essere reso pubblico anche se non ha causato danni, ma la definizione di criteri più oggettivi è rinviata a un lavoro successivo con altri sviluppatori, ricercatori esterni, organismi di normazione e regolatori.
Il destinatario è il pubblico, attraverso i rapporti sul sito della società, e in prospettiva il governo federale statunitense, al quale, scrive OpenAI, gli incidenti gravi di sicurezza e di disallineamento dovrebbero essere comunicati con meccanismi ancora da proporre. Del Codice europeo e dell’AI Office, cui il firmatario deve la segnalazione, non c’è traccia.
La consapevolezza del fornitore e il conteggio dei termini
I termini della misura 9.3, peraltro, decorrono dalla consapevolezza del firmatario, sicché al fornitore restano sia la qualificazione del fatto sia il momento da cui il conteggio parte.
La Commissione, dal canto suo, riceve ciò che il fornitore decide di trasmettere, e il monito del 7 settembre riguarda la precisione delle misure descritte nella relazione, non la sua tempestività, sulla quale, in generale, l’unico giudice risulta essere chi deve segnalare. Non è un difetto di questo regime in particolare, perché ogni obbligo di notifica parte da chi sa per primo; è la ragione per cui i criteri di qualificazione e la verifica successiva contano più del termine in giorni.
Incidenti gravi tra sistemi ad alto rischio e modelli
Per i sistemi ad alto rischio la Commissione ha diffuso, per la consultazione pubblica, una bozza di guida sull’art. 73: tredici pagine che spiegano la definizione di incidente grave voce per voce, con esempi come quello di un sistema di selezione del personale che scarta candidati qualificati.
I termini sono scanditi (quindici giorni dalla conoscenza, due per l’infrazione diffusa e per le infrastrutture critiche, dieci in caso di decesso) e il destinatario è l’autorità di vigilanza del mercato dello Stato in cui l’incidente si verifica. Al par. 4 il documento avverte di non occuparsi degli incidenti dei modelli per finalità generali con rischio sistemico.
Il divario tra guida e modulo per i modelli
Ai modelli più capaci restano così il Codice, che vincola i soli firmatari, e il modulo, mentre per chi non ha aderito, come Meta, il parametro torna a essere il “senza indebito ritardo” dell’art. 55, senza giorni e senza categorie. Paradossalmente, il dettaglio della guida decresce con la capacità dei sistemi che dovrebbe governare.
AI Act, poteri della Commissione e tempi dei fornitori
Oltre alla segnalazione degli incidenti, il regime dei modelli con rischio sistemico si regge su due strumenti nelle mani della Commissione: le richieste di informazioni ai fornitori, previste dall’art. 91, e le valutazioni dei modelli, previste dall’art. 92.
Per entrambi, l’art. 101, par. 1, lett. b) e d) prevede sanzioni autonome, per la risposta incompleta o fuorviante e per il mancato accesso al modello. Quanto alle valutazioni, il portavoce della Commissione ha confermato il 10 settembre che ENISA, l’agenzia dell’Unione per la cybersicurezza, ha ottenuto l’accesso a Mythos 5 di Anthropic e lo sta testando, a mesi dalla presentazione del modello, mentre per GPT-6 Astra di OpenAI, rilasciato il 3 settembre, l’accesso è arrivato entro una settimana.
I poteri esistono e vengono esercitati, ma il loro ritmo resta quello che ciascun fornitore concede, ed è il punto colto dal correlatore dell’AI Act Brando Benifei, secondo il quale la credibilità delle regole sul rischio sistemico dipende ora dalla loro applicazione.
Gli incidenti gravi dell’AI Act arrivano nelle organizzazioni
L’art. 73 si applica dal 2 agosto 2026, ma si rivolge ai fornitori di sistemi ad alto rischio: le regole che classificano quei sistemi e ne fissano gli obblighi – le sezioni 1, 2 e 3 del capo III, compreso l’art. 26, par. 5, che impone a chi li utilizza di informare immediatamente il fornitore e poi l’autorità quando individua un incidente grave – si applicheranno, per effetto del Regolamento (UE) 2026/1744, dal 2 dicembre 2027 per i sistemi dell’allegato III e dal 2 agosto 2028 per quelli dell’allegato I.
Alle scadenze del Cyber Resilience Act, della NIS2 e del GDPR, che questa testata ha messo in fila a settembre, se ne aggiungerà una il cui presupposto non è un evento tecnico ma un giudizio.
Registri, consapevolezza e responsabilità interne
Letto per sottrazione, il caso di settembre indica ciò che quel giudizio richiede prima dell’incidente. Un registro degli eventi anomali tenuto mentre accadono, perché la premessa del Codice ricorda che, a posteriori, le informazioni si perdono o si frammentano. Un momento definito in cui l’organizzazione si considera a conoscenza del fatto, perché da lì il termine decorre. E una titolarità nominata per qualificare l’evento, dato che il rapporto del 26 agosto documenta un’attività osservata a fine maggio e compresa a luglio.
Il mandato che fa partire il conteggio
Riletta accanto al Codice, la vicenda di settembre mostra un fornitore che descrive le misure adottate, chiede uno standard e infine se ne scrive uno proprio, mentre il testo sottoscritto quattordici mesi prima gli affidava già la decisione che precede ogni termine: riconoscere l’incidente come tale. Quel testo aveva già scritto che segnalare non equivale ad ammettere una colpa. I cinque giorni della misura 9.3 sarebbero probabilmente bastati, se qualcuno interno all’organizzazione del fornitore avesse avuto il mandato di far partire il conteggio.
Partecipa alla community