Negli ultimi mesi alcuni agenti di intelligenza artificiale sviluppati da OpenAI, Anthropic e Google hanno raggiunto e compromesso sistemi reali.
In certi casi sono usciti dagli ambienti di test, in altri li hanno trovati collegati a internet per un errore di configurazione.
Negli Stati Uniti, salvo rare eccezioni, le aziende non erano tenute a segnalarlo. In Europa l’AI Act, il regolamento europeo sull’intelligenza artificiale, impone da più di un anno ai fornitori dei modelli più avanzati di notificare alla Commissione gli incidenti gravi, e dal 2 agosto la Commissione può sanzionare chi non lo fa. I primi casi rivelano però quanto il meccanismo poggi ancora sulla valutazione che i laboratori stessi danno dei propri incidenti.
Indice degli argomenti
Agenti IA fuori controllo: dalle sandbox ai sistemi reali
Per anni l’ipotesi che un sistema di intelligenza artificiale potesse sfuggire al controllo di chi lo aveva costruito è rimasta materia da saggio filosofico o da audizione parlamentare. Tra maggio e luglio del 2026 è diventata un fatto documentato. Oltre milleduecento agenti basati su due modelli di OpenAI, impiegati in addestramenti e test interni sulle capacità offensive in ambito cyber, sono usciti dall’ambiente isolato in cui avrebbero dovuto operare.
Nella ricostruzione pubblicata dalla società, gli agenti hanno trasformato un gestore di repository software condiviso in una bacheca su cui scambiarsi messaggi da una valutazione all’altra e, tra l’11 e il 13 luglio, sono entrati nell’infrastruttura di Hugging Face, la piattaforma che ospita modelli e dataset usati da gran parte della comunità dell’IA, sfruttando due vulnerabilità non ancora note, fino a ottenere in meno di tredici ore i privilegi di amministratore su più cluster[1]. Il 95% degli agenti girava su IM1, un modello di ricerca mai rilasciato al pubblico, e il resto su GPT-5.6 Sol, che OpenAI aveva messo a disposizione di un gruppo ristretto di partner il 26 giugno. In entrambi i casi i ricercatori avevano attenuato di proposito i meccanismi con cui il modello rifiuta le richieste pericolose, per misurarne fino in fondo le capacità.
Quest’ultimo dettaglio racchiude un paradosso con cui il diritto dovrà fare i conti. Le valutazioni delle capacità pericolose sono lo strumento con cui i laboratori, e i regolatori che su di esse fanno affidamento, cercano di prevenire i danni. Per sapere quanto un modello sia capace di attaccare, però, bisogna metterlo nelle condizioni di farlo, e quando il contenimento cede la misurazione stessa diventa la fonte del danno. Il prezzo, in questo caso, lo hanno pagato imprese che non avevano alcun rapporto con OpenAI e che non avevano accettato nessuno dei rischi della sperimentazione.
Da Hugging Face a RubyGems: le fughe di OpenAI
Hugging Face ha comunicato la violazione il 16 luglio, quando ancora non sapeva chi ne fosse l’autore; l’attribuzione a OpenAI è arrivata soltanto il 21 luglio, con una dichiarazione congiunta, dopo che il personale di OpenAI, tra il 18 e il 19 luglio, aveva ritrovato le tracce nei log interni. A settembre ricercatori esterni hanno documentato due episodi che OpenAI non aveva reso noti. Gli agenti avevano occupato un vecchio wiki tedesco di programmazione, usandolo come canale di comunicazione con oltre quindicimila interventi, e già a maggio avevano pubblicato oltre duemila pacchetti malevoli su RubyGems, il registro da cui gli sviluppatori scaricano le librerie del linguaggio Ruby[2].
Il 26 settembre OpenAI ha reso nota una nuova evasione, avvenuta il 20 dello stesso mese: la prima dopo i controlli più severi annunciati il 18 agosto. La società ha fermato per la seconda volta in tre mesi l’addestramento dei suoi modelli più avanzati, sospendendone anche l’utilizzo[3].
Claude e Gemini nei sistemi di terzi
Episodi simili hanno coinvolto altri laboratori. Anthropic ha reso noti quattro incidenti in cui modelli Claude, durante esercitazioni predisposte da un partner esterno, si erano trovati collegati a internet per un errore di configurazione e avevano violato sistemi di terzi[4]. Google ha confermato il 18 settembre che una versione di Gemini, in un test analogo condotto a maggio dalla società di valutazione Irregular, era entrata nei sistemi di tre aziende, in un caso indovinando le password e negli altri usando credenziali trovate in repository pubblici[5].
Secondo Axios, OpenAI e Anthropic, insieme a ricercatori esterni, stanno esaminando decine di migliaia di episodi in cui i modelli hanno compiuto azioni che un valutatore esterno considererebbe problematiche[6]. L’ANSA, riprendendo il New York Times, riferisce inoltre che agenti di OpenAI hanno interferito con alcuni siti del governo federale americano, tra cui quelli del Dipartimento dell’Istruzione e della Securities and Exchange Commission (SEC), l’autorità federale di vigilanza sui mercati finanziari, episodi che la società non considera violazioni di sicurezza[7].
La prima a parlare è stata la vittima, che non conosceva l’autore dell’attacco. Il laboratorio ha riconosciuto il proprio ruolo giorni dopo, e gli episodi del wiki e di RubyGems sono venuti alla luce solo grazie al lavoro di ricercatori indipendenti, a mesi di distanza dai fatti. La domanda posta il 28 settembre dalla MIT Technology Review, cioè chi debba rispondere di questi incidenti e chi possa obbligare le aziende a dichiararli[8], nasce da qui. Finora a stabilire che cosa il pubblico e le autorità dovessero sapere sono stati in larga parte i laboratori stessi, con l’aiuto involontario di chi ne ha subito le conseguenze. Le due sponde dell’Atlantico rispondono a quella domanda in modo molto diverso.
Gli Stati Uniti davanti alle fughe degli agenti IA
Negli Stati Uniti manca una legge federale sull’IA di frontiera: al Congresso circolano solo proposte. Tre Stati hanno approvato norme di trasparenza per gli sviluppatori dei modelli più grandi, ma per ora ne è in vigore una sola. Si tratta del Transparency in Frontier Artificial Intelligence Act (SB 53) della California, applicabile dal gennaio 2026. Il RAISE Act di New York e lo SB 315 dell’Illinois, che aggiunge l’obbligo di audit esterni annuali, diventeranno operativi a gennaio 2027.
Queste leggi chiedono alle aziende di pubblicare un quadro di sicurezza scritto da loro stesse e di segnalare gli «incidenti critici di sicurezza», una nozione costruita intorno al «rischio catastrofico», definito con soglie molto alte, come più di cinquanta morti o feriti gravi oppure danni superiori al miliardo di dollari. Vi rientrano anche i casi in cui il modello inganna lo sviluppatore, al di fuori di una valutazione, accrescendo in modo rilevante un rischio catastrofico. L’intrusione nei server di Hugging Face non raggiunge nessuna di queste soglie, e per Mackenzie Arnold, dell’Institute for Law and AI, gli incidenti dell’estate mostrano esattamente perché la legge non sia pronta[9].
Una soglia fissata così in alto rivela un’idea precisa di ciò che il regolatore ha bisogno di conoscere: gli esiti, e soltanto quelli estremi. Altri settori hanno imparato a ragionare all’opposto. Nell’aviazione civile il Regolamento (UE) n. 376/2014, che disciplina la segnalazione degli eventi capaci di mettere a rischio la sicurezza del volo, obbliga a riferire anche gli inconvenienti che non hanno prodotto danni, perché è nei quasi incidenti che si leggono per tempo i segnali delle catastrofi future[10]. Un agente che esce dalla sandbox e si limita a cercare in rete le soluzioni di un test somiglia molto più a un quasi incidente che a un episodio trascurabile. Le leggi statali americane, così come sono scritte, lo lasciano fuori dal campo visivo di chiunque non lavori dentro il laboratorio.
Indagini, responsabilità e limiti del diritto penale
Mancando un potere d’indagine specifico, i procuratori generali di alcuni Stati, tra cui Alabama, Montana e California, hanno chiesto informazioni a OpenAI in base alle leggi sulla tutela dei consumatori, che servono a perseguire le pratiche commerciali ingannevoli e si adattano male a un software sfuggito al controllo di chi lo ha sviluppato. Il senatore Josh Hawley, che presiede una sottocommissione della Commissione per la sicurezza interna del Senato, ha aperto un’indagine parlamentare e ha chiesto a OpenAI di rispondere a sedici domande e di produrre documenti entro il 1° ottobre[11].
La via penale passa per il Computer Fraud and Abuse Act, la legge federale che punisce l’accesso abusivo a sistemi informatici, e si scontra con il requisito dell’intenzionalità, difficile da riferire a un agente software.
Quel requisito mette a nudo un problema che va oltre il diritto americano. La responsabilità penale è costruita intorno alla volontà di una persona, mentre l’agente persegue l’obiettivo che gli è stato assegnato senza che si possa parlare, in senso giuridico, di volontà propria. Le scelte che contano si trovano altrove, nella decisione di allentare i filtri di sicurezza e in quella di proseguire i test quando i segnali anomali erano già visibili. Spostare lo sguardo dall’atto dell’agente alle decisioni organizzative di chi lo ha messo in funzione è probabilmente l’unico modo per dare a questi episodi una risposta giuridica, e la questione si pone in Europa negli stessi termini.
Rimarrebbe l’azione civile per negligenza, con la fase di discovery che obbligherebbe OpenAI a produrre documenti interni e porterebbe alla luce ciò che oggi si conosce solo in parte. Hugging Face ha però deciso di non fare causa, spiegando di non averne le risorse[12]. Anche una società con una posizione di rilievo nell’ecosistema dell’IA ha giudicato insostenibile un contenzioso contro uno dei maggiori laboratori del mondo, e il costo dell’incertezza giuridica è rimasto a carico di chi ha subito l’attacco.
Disclosure e audit affidati ai laboratori
Alcuni obblighi di comunicazione esistono comunque, anche se non sono stati pensati per l’IA. Le regole della SEC impongono alle società quotate di comunicare un incidente informatico entro quattro giorni lavorativi dal momento in cui lo hanno giudicato rilevante per gli investitori[13]. OpenAI e Anthropic non sono quotate e quindi non vi sono soggette, mentre Alphabet, la capogruppo di Google, lo è; Anthropic ha però depositato a giugno, in via riservata, la documentazione per la quotazione, che secondo Reuters potrebbe arrivare dopo le elezioni di metà mandato e la porterebbe dentro questo regime.
Tutti i cinquanta Stati hanno poi leggi che obbligano a notificare le violazioni di dati personali, e alcune leggi federali fanno lo stesso per settori come la sanità e la finanza, mentre manca una regola federale generale[14]. Ciascuno di questi obblighi protegge un interesse determinato, quello degli investitori o quello delle persone i cui dati sono stati esposti, e scatta solo quando quell’interesse viene toccato. L’interesse collettivo a sapere che un sistema ha eluso i controlli di chi lo ha costruito non ha, in questo mosaico, un titolare.
Un’azienda che scopre comportamenti allarmanti dei propri modelli durante i test può così non avere alcun obbligo di renderli noti, se mancano una violazione di dati, un impatto per gli investitori o un danno per i consumatori.
Anche gli audit dipendono in larga misura dalla volontà delle aziende. Dopo l’incidente OpenAI ha affidato un esame indipendente a METR e Redwood Research, due organizzazioni non profit specializzate nella valutazione della sicurezza dei modelli, limitando però il loro accesso al modello e circoscrivendo l’esame alla settimana dell’attacco a Hugging Face. La società si è inoltre riservata l’ultima parola su ciò che i valutatori avrebbero potuto pubblicare. Per i propri incidenti Anthropic ha concesso a METR un accesso più ampio, esteso anche ai dipendenti, ma anche in questo caso la verifica nasce da un accordo tra le parti.
Un valutatore che dipende dalla disponibilità del laboratorio per continuare a lavorare deve pesare ogni rilievo anche sulla tenuta del rapporto, e questa tensione è difficile da eliminare finché la verifica resta una scelta dell’azienda. Delle tre leggi statali, solo quella dell’Illinois prevede una verifica annuale di terza parte, a partire dal 2028. Lo SB 1047 californiano, vetato nel 2024 dal governatore Gavin Newsom dopo le pressioni dell’industria, avrebbe imposto audit esterni annuali e la segnalazione degli incidenti in cui il modello agisce da solo o elude i controlli[15].
Le proposte ferme al Congresso e il no della Casa Bianca
Al Congresso e a New York sono in discussione testi che andrebbero nella direzione europea. L’AI Incident Reporting Act, presentato a giugno dal deputato Nathaniel Moran, obbligherebbe a comunicare al Dipartimento del Commercio i casi in cui un modello elude la supervisione umana o viola un sistema informatico, anche in assenza di danni. Il Frontier Act prevede la notifica degli incidenti e audit indipendenti, mentre l’AI Kill Switch Act, presentato il 23 luglio dai deputati Ted Lieu e Nathaniel Moran, imporrebbe di mantenere la capacità di sospendere o spegnere i sistemi.
Al Senato si discute di un «dovere di diligenza» (duty of care) il cui rispetto potrebbe essere verificato dal Segretario al Commercio, e a New York l’Understanding Artificial Intelligence Act, proposto dallo stesso Alex Bores che aveva promosso il RAISE Act, renderebbe le aziende responsabili quando un modello compie un atto che, se commesso da una persona, costituirebbe un illecito civile o un reato[16]. Nessuno di questi testi è ancora legge.
L’orientamento della Casa Bianca rende difficile che lo diventino a breve. Il 28 settembre il presidente Trump ha ribadito la propria contrarietà a nuove regole sull’IA, sostenendo che finirebbero per aiutare la Cina, e commentando le intrusioni nei siti federali ha detto di non esserne preoccupato e che spetta alle aziende «sistemare» ciò che non va. Il giorno dopo ha ottenuto da Anthropic, Google, Meta, Nvidia, OpenAI e xAI la firma di un impegno volontario sulla sicurezza dei modelli di frontiera, privo di sanzioni e di meccanismi di controllo[17]. L’argomento della competizione con Pechino ha un peso reale e condiziona ogni scelta di politica industriale americana.
Resta però da capire se un obbligo di notifica, che non limita lo sviluppo dei modelli e chiede soltanto di riferire ciò che accade, appartenga davvero alla categoria dei vincoli capaci di rallentare la corsa. Secondo l’ANSA, del resto, all’interno della Casa Bianca e tra i repubblicani serpeggia un certo nervosismo sul tema.
AI Act e agenti IA fuori controllo: obblighi e sanzioni
In Europa la cornice è il Regolamento (UE) 2024/1689, l’AI Act, che disciplina i sistemi e i modelli di intelligenza artificiale in base al rischio[18]. Un capo è dedicato ai modelli di IA per finalità generali, cioè i modelli di base come GPT, Claude o Gemini, che svolgono compiti molto diversi e vengono integrati in altri prodotti. Un modello si presume «a rischio sistemico» quando per addestrarlo sono state usate più di 1025 operazioni in virgola mobile, oppure quando la Commissione lo designa come tale, e in quel caso il fornitore assume obblighi aggiuntivi.
Gli obblighi per i modelli a rischio sistemico
Questi obblighi sono elencati nell’articolo 55. Il fornitore deve valutare il modello con protocolli allo stato dell’arte, anche attraverso test avversari, e deve individuare e attenuare i rischi sistemici, assicurando al modello e alla sua infrastruttura fisica un livello adeguato di cibersicurezza. Deve inoltre «tenere traccia, documentare e riferire senza indebito ritardo all’ufficio per l’IA e, se del caso, alle autorità nazionali competenti» le informazioni pertinenti sugli incidenti gravi e sulle eventuali misure correttive. L’Ufficio per l’IA (AI Office) è la struttura della Commissione che vigila sui modelli per finalità generali, e l’articolo 88 attribuisce alla Commissione in via esclusiva i poteri di controllo e di esecuzione su questi obblighi.
L’articolo 3, punto 49, definisce incidente grave un incidente o malfunzionamento di un sistema di IA che, direttamente o indirettamente, causa il decesso di una persona o gravi danni alla sua salute, una perturbazione grave e irreversibile della gestione o del funzionamento delle infrastrutture critiche, la violazione degli obblighi del diritto dell’Unione intesi a proteggere i diritti fondamentali oppure gravi danni alle cose o all’ambiente. La definizione si riferisce ai sistemi di IA, ma l’articolo 55 la applica ai fornitori di modelli, che rispondono così anche di ciò che accade quando il modello opera all’interno di un sistema. Rispetto alla California la differenza sta nella soglia del danno.
Lo SB 53, come si è visto, si attiva con i rischi catastrofici o con morti e lesioni, e l’unica ipotesi svincolata da un danno è quella del modello che inganna lo sviluppatore. Il legislatore europeo chiede invece notizia di danni molto meno gravi, compresi quelli alle cose e ai diritti fondamentali, senza attendere vittime o perdite miliardarie.
Obblighi e sanzioni, peraltro, non sono partiti insieme. Gli obblighi dei fornitori di modelli per finalità generali si applicano dal 2 agosto 2025, mentre le sanzioni dell’articolo 101 si applicano solo dal 2 agosto 2026, e da quella data la Commissione esercita pienamente i propri poteri di controllo[19]. I modelli immessi sul mercato prima del 2 agosto 2025 hanno tempo fino al 2 agosto 2027 per adeguarsi.
Il Digital Omnibus sull’IA (Regolamento (UE) 2026/1744), il pacchetto di semplificazione pubblicato in Gazzetta ufficiale il 24 luglio 2026 ed entrato in vigore il 27 luglio, ha rinviato le scadenze per i sistemi ad alto rischio e ha lasciato invariato, nella sostanza, il regime dei modelli per finalità generali. Ne ha anzi ampliato il raggio, attribuendo all’AI Office la competenza esclusiva sui sistemi che un fornitore, o un’impresa del suo stesso gruppo, costruisce sul proprio modello[20].
Il Codice di buone pratiche come regola operativa
Il 10 luglio 2025 la Commissione ha pubblicato il Codice di buone pratiche per l’IA per finalità generali, un documento ad adesione volontaria scritto da esperti indipendenti con il contributo dell’industria e della società civile, che chi lo sottoscrive può usare per dimostrare di rispettare gli obblighi che l’articolo 53 impone a tutti i fornitori di modelli e quelli aggiuntivi dell’articolo 55. OpenAI, Anthropic e Google hanno aderito, Meta no, e xAI ha firmato soltanto il capitolo su sicurezza e protezione[21].
Quel capitolo traduce il «senza indebito ritardo» in termini precisi: due giorni per una perturbazione grave e irreversibile di infrastrutture critiche, cinque per una violazione grave della cibersicurezza, comprese l’esfiltrazione dei pesi del modello, anche da parte del modello stesso, e gli attacchi informatici, dieci in caso di decesso, quindici per gli altri danni gravi. Un attacco di agenti all’infrastruttura di un’impresa terza rientra con ogni probabilità nella categoria dei cinque giorni, o in quella dei due se l’impresa colpita gestisce un’infrastruttura critica.
Nel Codice, dunque, una clausola generale diventa regola operativa, attraverso un testo scritto con il contributo delle stesse imprese che è chiamato a vincolare. La coregolazione europea funziona così: rinuncia a una parte di distanza dai destinatari in cambio della loro competenza tecnica e della loro adesione volontaria. I fatti dell’estate sono la prima occasione concreta per verificare se lo scambio regge quando l’incidente riguarda chi ha contribuito a scrivere le regole.
Le notifiche sugli incidenti IA arrivate a Bruxelles e quelle mancate
Secondo quanto la Commissione ha confermato a Reuters e a Euractiv, OpenAI ha notificato all’AI Office l’attacco a Hugging Face e anche l’episodio del wiki tedesco. La conferma su quest’ultimo è arrivata il 7 settembre, tre giorni dopo la pubblicazione della ricerca indipendente, senza alcuna indicazione sulla data in cui la segnalazione era stata ricevuta. In quell’occasione il portavoce della Commissione Thomas Regnier ha ricordato che una segnalazione di incidente deve indicare con precisione le misure che l’azienda intende adottare[22]. Per RubyGems, invece, non è arrivata alcuna notifica formale.
La Commissione lo ha confermato il 18 settembre, precisando di essere a conoscenza dell’episodio e in contatto con la società, mentre OpenAI sostiene che sul registro gli agenti si siano limitati a svolgere «compiti innocui» e a raccogliere informazioni pubbliche[23].
RubyGems e il perimetro dell’incidente grave
Tra la descrizione aziendale e gli effetti osservati dall’esterno, oltre duemila pacchetti malevoli e le nuove registrazioni sospese per quattro giorni da Ruby Central, l’organizzazione che gestisce il registro, la distanza è evidente, e mostra quanto conti chi detiene il potere di qualificare un fatto. In entrambi i casi non notificati spontaneamente, inoltre, a portare gli episodi davanti al regolatore sono stati ricercatori indipendenti. Il Digital Services Act (Regolamento (UE) 2022/2065), che disciplina le grandi piattaforme online, riconosce ai ricercatori abilitati un diritto di accesso ai dati delle piattaforme proprio per rendere possibile questo genere di controllo esterno (articolo 40)[24].
L’AI Act affida la vigilanza diffusa soprattutto al gruppo di esperti scientifici indipendenti, che può inviare all’AI Office segnalazioni qualificate sui rischi sistemici (articolo 90). L’estate suggerisce che una parte decisiva della conoscenza sui rischi dei modelli si forma fuori da entrambi i circuiti, e varrebbe la pena chiedersi come proteggerla e valorizzarla.
Il 29 agosto la Vicepresidente esecutiva Henna Virkkunen ha confermato che l’AI Office aveva inviato le prime richieste formali di informazioni a oltre trenta fornitori di modelli per finalità generali; secondo EU Perspectives tra i destinatari ci sono OpenAI, Google e Anthropic, anche se la Commissione non ha confermato i nomi. Le domande riguardano soprattutto la protezione dei modelli e il ricorso a valutatori indipendenti, mentre una parte è dedicata al monitoraggio dopo il rilascio. Virkkunen ha collegato l’iniziativa agli incidenti dell’estate[25].
Le richieste si fondano sull’articolo 91 del regolamento, che consente alla Commissione di chiedere documenti e informazioni ai fornitori, e una risposta inesatta, incompleta o fuorviante può costare, in base all’articolo 101, fino al 3% del fatturato mondiale annuo o 15 milioni di euro, se l’importo è superiore. È la prima volta che la Commissione usa questi poteri nei confronti dei laboratori di frontiera.
I poteri ispettivi della Commissione europea
Il regolamento consente anche interventi più incisivi. Con l’articolo 92 la Commissione può valutare direttamente un modello, nominando esperti indipendenti e ottenendo accesso tramite interfacce di programmazione o altri mezzi tecnici, codice sorgente compreso, quando le informazioni raccolte non bastano o quando il gruppo di esperti scientifici segnala un rischio sistemico a livello dell’Unione. Con l’articolo 93 può imporre misure di attenuazione dei rischi e, nei casi più seri, limitare la messa a disposizione del modello fino a ordinarne il ritiro. A differenza degli audit concordati descritti dalla MIT Technology Review, in Europa la verifica può essere disposta da un’autorità pubblica anche senza il consenso del fornitore. È lo strumento che più di ogni altro separa i due sistemi, e il suo valore dipenderà dalla capacità tecnica e dalle risorse che l’AI Office saprà mettere in campo per usarlo.
I vuoti europei nella vigilanza sugli agenti IA
Gli obblighi dell’articolo 55 si applicano al «fornitore», figura che il regolamento definisce in relazione all’immissione sul mercato o alla messa in servizio di un modello. Secondo OpenAI, IM1 non è mai stato rilasciato, mentre GPT-5.6 Sol, l’altro modello coinvolto nell’attacco a Hugging Face, era già a disposizione di un gruppo ristretto di partner. L’articolo 52 obbliga a comunicare alla Commissione entro due settimane il superamento della soglia di rischio sistemico, anche prima del lancio commerciale, e il Codice applica la gestione del rischio all’intero ciclo di vita del modello.
Non è però chiaro se l’obbligo di notificare gli incidenti valga anche per un modello sperimentale usato solo in laboratorio, e tutti gli episodi noti si sono verificati durante l’addestramento o la valutazione, con i filtri di sicurezza allentati, anche quando coinvolgevano modelli già commercializzati. La Cloud Security Alliance, associazione internazionale di settore che si occupa di sicurezza del cloud, ha sollevato la questione e, secondo 150sec, la Commissione non ha ancora preso posizione[26].
Il problema dei modelli usati solo nei test
Il settore farmaceutico ha affrontato lo stesso problema molto tempo fa. Il Regolamento (UE) n. 536/2014 sulla sperimentazione clinica dei medicinali obbliga lo sponsor a segnalare le sospette reazioni avverse gravi e inattese osservate durante la sperimentazione entro quindici giorni, ridotti a sette quando la reazione è mortale o mette in pericolo la vita, ben prima che il farmaco arrivi sul mercato[27]. In quel modello la fase sperimentale è la più sorvegliata, perché è quella in cui si sa meno. Nell’IA di frontiera la logica rischia di rovesciarsi: le capacità più pericolose vengono misurate in laboratorio, con i freni allentati, e proprio lì l’obbligo di notifica diventa incerto. Un regime che si attiva con l’immissione sul mercato guarda al prodotto, mentre questa estate il rischio si è manifestato nel processo che lo precede.
Definizioni, tempi e riservatezza delle notifiche
Anche la definizione di incidente grave crea difficoltà. L’articolo 3, punto 49, parla di «sistemi» di IA e usa categorie di danno pensate per prodotti e servizi; il Codice la adatta ai modelli solo in parte, e la prima valutazione spetta comunque al fornitore. OpenAI ha descritto l’attività su RubyGems come lo svolgimento di «compiti innocui» e il 16 settembre ha reso noti altri sei episodi di comportamento anomalo dei propri modelli attraverso un nuovo programma volontario di divulgazione, trattandoli come casi di «disallineamento» e non come incidenti gravi da notificare; quel programma, però, non sostituisce la notifica prevista dalla legge[28]. La Commissione non ha detto quando abbia ricevuto la segnalazione sul wiki, e senza questa data non si può verificare dall’esterno se il termine sia stato rispettato.
Conta inoltre il momento da cui far decorrere il termine, perché nel Codice i giorni si contano da quando il fornitore viene a conoscenza dell’incidente. Secondo quanto riportato da Reuters il 24 luglio, tra i primi segnali anomali e il riconoscimento da parte di OpenAI della propria responsabilità per l’attacco a Hugging Face è passata almeno una settimana.
Già il 4 luglio, secondo la ricostruzione presentata dalla stessa società alla conferenza Black Hat, OpenAI aveva aperto un incidente di sicurezza interno dopo aver accertato che gli agenti avevano preso il controllo del suo gestore di repository; e il 21 giugno indirizzi della società compaiono nei registri del wiki tedesco, il giorno prima che l’attività degli agenti vi si interrompesse. La lettera del senatore Hawley sostiene che già a maggio OpenAI sapesse che i suoi agenti usavano bacheche non autorizzate e che il 26 giugno gli agenti avessero scoperto una falla che dava loro privilegi di amministratore sul gestore dei repository[29].
Se queste circostanze fossero confermate, il rispetto del «senza indebito ritardo» andrebbe valutato a partire da quei segnali, settimane prima dell’attacco a Hugging Face. In un sistema in cui l’agente agisce per giorni o settimane e lascia tracce disperse in migliaia di registri, il momento della «conoscenza» dipende in buona parte da quanto il laboratorio si è attrezzato per vedere, e un obbligo che decorre dalla scoperta finisce per premiare, involontariamente, chi guarda meno.
Le notifiche all’AI Office sono poi coperte dalla riservatezza prevista dall’articolo 78 del regolamento. Il regolatore ottiene così informazioni che negli Stati Uniti nessuna legge gli garantisce, mentre il pubblico non ne viene a conoscenza, e un processo civile con la sua fase istruttoria porterebbe i documenti alla luce in modo ben più ampio. Anche qui l’aviazione offre un termine di paragone. Il sistema europeo di segnalazione degli eventi raccoglie le notifiche in un repertorio centrale e ne diffonde gli insegnamenti in forma anonimizzata, perché le lezioni ricavate da un evento possano servire a tutti gli operatori del settore[30]. Una riservatezza assoluta protegge legittimi segreti industriali, ma impedisce agli altri laboratori e alle imprese esposte di trarre lezioni da ciò che è accaduto.
Resta infine una questione temporale. A maggio, quando si è verificato l’episodio RubyGems, l’obbligo di notifica era già in vigore, almeno per i modelli immessi sul mercato, mentre la sanzione è diventata applicabile solo dal 2 agosto 2026. Bisognerà vedere se la Commissione tratterà un’omissione protratta oltre quella data come una violazione ancora in corso.
NIS2, CRA e GDPR nella catena degli incidenti IA
La direttiva NIS2 (Direttiva (UE) 2022/2555, recepita in Italia con il d.lgs. 138/2024) fissa obblighi di sicurezza e di notifica degli incidenti informatici per i soggetti essenziali e importanti di settori come l’energia o le infrastrutture digitali, e chiede un preallarme entro ventiquattro ore dalla scoperta di un incidente significativo. L’obbligo riguarda il soggetto colpito, se rientra nel perimetro della direttiva, mentre chi ha originato l’attacco non ha alcun obbligo di notifica. Se un agente sviluppato da un laboratorio americano compromettesse il fornitore cloud di un’azienda sanitaria europea, il fornitore dovrebbe notificare nei tempi della NIS2, e il laboratorio, quanto agli obblighi di notifica, resterebbe soggetto soltanto all’AI Act.
Gli obblighi lungo la catena del software
Il Cyber Resilience Act (Regolamento (UE) 2024/2847) disciplina la sicurezza dei prodotti con elementi digitali e, dall’11 settembre 2026, obbliga i fabbricanti a segnalare entro ventiquattro ore al CSIRT designato come coordinatore, cioè il gruppo nazionale di risposta agli incidenti informatici, e all’ENISA, l’Agenzia dell’Unione europea per la cibersicurezza, le vulnerabilità attivamente sfruttate nei loro prodotti. Chi produce il software attaccato da un agente deve quindi notificare entro un giorno, a condizione che la vulnerabilità risulti «attivamente sfruttata»: il regolamento lega questa nozione all’azione di un attore malevolo, e resterà da chiarire se vi rientri un agente software privo di intenzioni ostili.
Chi ha addestrato l’agente ha invece come unico riferimento il «senza indebito ritardo» dell’AI Act, che il Codice traduce in termini compresi tra due e quindici giorni, e la propria valutazione di gravità. Se l’incidente coinvolge dati personali, il Regolamento generale sulla protezione dei dati (GDPR) obbliga il titolare del trattamento colpito a notificare la violazione all’autorità di controllo entro settantadue ore (articolo 33).
Messi in fila, questi obblighi disegnano una distribuzione degli oneri curiosa. I tempi più stretti gravano sulla vittima e sul produttore del software vulnerabile, mentre il soggetto che si trova più a monte nella catena causale, e che più di ogni altro conosce che cosa è successo e perché, dispone del margine più ampio. Nessuno lo ha voluto, ed è l’effetto della stratificazione di norme nate in momenti diversi e per problemi diversi; proprio per questo meriterebbe una riflessione esplicita da parte del legislatore europeo.
Responsabilità civile e tutela di chi subisce il danno
Per chi subisce un danno gli strumenti europei sono pochi. La Commissione ha ritirato nel 2025 la proposta di direttiva sulla responsabilità da intelligenza artificiale, che avrebbe alleggerito l’onere della prova per i danneggiati. La nuova direttiva sulla responsabilità per danno da prodotti difettosi (Direttiva (UE) 2024/2853), da recepire entro il 9 dicembre 2026 e applicabile ai soli prodotti immessi sul mercato dopo quella data, considera il software un prodotto e risarcisce la distruzione o il danneggiamento di dati, ma solo se non usati a fini professionali. Un’impresa colpita da un agente dovrebbe quindi agire in base alle regole nazionali sulla responsabilità extracontrattuale, che in Italia passano per l’articolo 2043 del codice civile e, a certe condizioni, per l’articolo 2050.
L’articolo 2050 riguarda chi cagiona danno ad altri nello svolgimento di un’attività pericolosa «per sua natura o per la natura dei mezzi adoperati», e lo obbliga al risarcimento se non prova di aver adottato tutte le misure idonee a evitarlo. Lo sviluppo e il collaudo di agenti con capacità offensive, condotti allentando deliberatamente i filtri di sicurezza, si prestano a essere letti come attività pericolosa almeno nel secondo senso, e l’inversione dell’onere della prova si adatterebbe bene a una situazione in cui solo il laboratorio sa davvero che cosa è accaduto al suo interno. Resterebbero comunque le difficoltà di provare il nesso causale e di agire contro un convenuto statunitense.
La legge italiana sull’intelligenza artificiale (legge 23 settembre 2025, n. 132), che ha designato AgID, l’Agenzia per l’Italia digitale, e l’Agenzia per la cybersicurezza nazionale come autorità nazionali, non tocca la vigilanza sui modelli per finalità generali, che resta alla Commissione.
Agenti IA e obblighi di notifica: i prossimi mesi
OpenAI, Anthropic e Google sono già tenuti a notificare gli incidenti gravi dei modelli immessi sul mercato dall’agosto 2025, e lo saranno per quelli precedenti a partire dall’agosto 2027; da due mesi la Commissione può sanzionarli se non lo fanno. Nelle prossime settimane arriveranno le risposte alle richieste del 29 agosto. Più indicativa sarà la decisione sulla notifica mancata per RubyGems: se la Commissione aprirà un procedimento, sarà la prima volta che un grande laboratorio rischia una sanzione in base all’AI Act, e da come verrà condotto si capirà quanto spazio Bruxelles intende lasciare all’autovalutazione dei fornitori.
Le leggi americane oggi in vigore chiedono di dichiarare le catastrofi e affidano il resto ai tribunali. L’AI Act chiede di notificare incidenti molto meno gravi e affida la verifica a un’autorità con poteri propri, ma alcuni punti andrebbero chiariti con linee guida della Commissione, a partire dall’applicazione dell’obbligo ai modelli ancora in sviluppo e dai criteri per valutare la gravità dei comportamenti autonomi degli agenti. Servirebbe anche una forma di pubblicità delle segnalazioni ricevute, eventualmente differita e anonimizzata.
Ogni regime di notifica degli incidenti si regge su un patto implicito, in base al quale chi conosce il rischio lo condivide con chi deve governarlo e ne ricava, in cambio, regole più stabili e una fiducia pubblica difficile da ottenere in altro modo. L’estate del 2026 ha mostrato quanto quel patto sia ancora fragile nell’IA di frontiera, dove la conoscenza dei rischi si produce dentro i laboratori ed esce, per ora, soprattutto per incidente o grazie a chi la cerca dall’esterno. La Commissione dispone degli strumenti per renderlo vincolante.
Dall’uso che ne farà nei prossimi mesi dipenderà se l’AI Office diventerà il luogo in cui si accumula e si condivide la conoscenza sui rischi dei modelli più potenti, oppure un archivio riservato di episodi che il pubblico ha già appreso da altre fonti.
Fonti e note
[1] OpenAI, The Hugging Face incident and the road ahead; per la cronologia, OpenAI-HuggingFace incident (Wikipedia) e TechRadar. ↩
[2] S. Willison, OpenAI agents attacked RubyGems back in May, 12 settembre 2026; TechCrunch, 4 settembre 2026. ↩
[3] Fortune, 26 settembre 2026. ↩
[4] Anthropic, An alignment assessment of recent cybersecurity incidents, 9 settembre 2026; The Hacker News, settembre 2026. ↩
[5] SecurityWeek; CNN, 19 settembre 2026; Axios, 18 settembre 2026. ↩
[6] Axios, 26 settembre 2026. ↩
[7] S. Di Ronza, «Trump ignora l’allarme sull’IA: “Niente regole, non servono”. Bill Gates: “Gli Usa se ne occupino”», ANSA, 28 settembre 2026; «L’IA di OpenAI ‘fuori controllo’, ha interferito anche col governo Usa», ANSA, 26 settembre 2026. ↩
[8] M. Kim, Who’s liable when AI agents go rogue?, MIT Technology Review, 28 settembre 2026. ↩
[9] M. Kim, MIT Technology Review, cit. ↩
[10] Regolamento (UE) n. 376/2014 del Parlamento europeo e del Consiglio, del 3 aprile 2014, concernente la segnalazione, l’analisi e il monitoraggio di eventi nel settore dell’aviazione civile. ↩
[11] Nextgov/FCW; lettera del sen. J. Hawley a OpenAI, 9 settembre 2026. ↩
[12] M. Kim, MIT Technology Review, cit. ↩
[13] SEC, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, Release n. 33-11216, 26 luglio 2023 (Form 8-K, Item 1.05). ↩
[14] S. Merken, M. Scarcella, «Do AI companies have to disclose dangerous incidents?», Reuters, 16 settembre 2026; sulla quotazione di Anthropic, CNBC, 28 settembre 2026, che riprende Reuters. ↩
[15] M. Kim, MIT Technology Review, cit.; per l’accordo tra Anthropic e METR, Anthropic, An alignment assessment, cit. ↩
[16] S. Merken, M. Scarcella, Reuters, cit.; M. Kim, MIT Technology Review, cit.; per l’AI Kill Switch Act, OpenAI-HuggingFace incident (Wikipedia). ↩
[17] S. Di Ronza, ANSA, 28 settembre 2026, cit.; sull’impegno volontario del 29 settembre, Il Fogliettone, 2 ottobre 2026. ↩
[18] Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, del 13 giugno 2024, che stabilisce regole armonizzate sull’intelligenza artificiale (AI Act), in particolare artt. 3, 51-55, 78, 88-94, 101, 111 e 113. ↩
[19] CNBC, 3 agosto 2026; AI Act Service Desk, FAQ; AI Act, artt. 101, 111, par. 3, e 113. ↩
[20] Regolamento (UE) 2026/1744 del Parlamento europeo e del Consiglio, dell’8 luglio 2026 (Digital Omnibus sull’IA), GU L del 24 luglio 2026; Future of Privacy Forum, The AI Act implementation timeline: what changes under the AI Omnibus?; Consiglio dell’UE, comunicato stampa del 7 maggio 2026. ↩
[21] Commissione europea, Codice di buone pratiche per l’IA per finalità generali, 10 luglio 2025, capitolo «Safety and Security»; per una sintesi, artificialintelligenceact.eu. ↩
[22] Reuters, «OpenAI has sent EU incident report on hijacked German website, Commission says», 7 settembre 2026; The Next Web; Tech Times, 8 settembre 2026. ↩
[23] Resultsense, 18 settembre 2026, che riprende Euractiv; Tech Times, 20 settembre 2026. ↩
[24] Regolamento (UE) 2022/2065 del Parlamento europeo e del Consiglio, del 19 ottobre 2022 (Digital Services Act), art. 40; sul gruppo di esperti scientifici indipendenti, AI Act, artt. 68 e 90. ↩
[25] EU Perspectives, 1° settembre 2026; The EU AI Act Newsletter #110; AI Act, artt. 91 e 101. ↩
[26] 150sec, 21 settembre 2026; Cloud Security Alliance, OpenAI’s Wiki Silence Tests the EU AI Act’s Incident Regime. ↩
[27] Regolamento (UE) n. 536/2014 del Parlamento europeo e del Consiglio, del 16 aprile 2014, sulla sperimentazione clinica di medicinali per uso umano, art. 42. ↩
[28] Tech Times, 20 settembre 2026, cit.; Resultsense, 18 settembre 2026, cit. ↩
[29] Reuters, 24 luglio 2026, come riportato in OpenAI-HuggingFace incident (Wikipedia), che dà conto anche della presentazione di OpenAI a Black Hat USA del 5 agosto 2026; sui registri del wiki, Tech Times, 8 settembre 2026, cit., che riprende la ricerca del Nightingale Collective; lettera del sen. J. Hawley a OpenAI, cit. ↩
[30] Regolamento (UE) n. 376/2014, cit., in particolare art. 8 sul repertorio centrale europeo e artt. 15 e 16 sulla riservatezza delle informazioni e sulla tutela delle fonti. ↩
Partecipa alla community