06 Ago AI Act e agenti autonomi: chi risponde se un modello esce dal controllo

Tempo di lettura stimato: 10 minuti

Indice dei contenuti

• I fatti: come un agente di OpenAI è arrivato dentro Hugging Face
• Perché non era un fulmine a ciel sereno
• Tre laboratori in cinque settimane: la parte che non si è vista
• Il considerando 110 aveva descritto tutto questo
• Il problema sta nell’articolato: la conformità la dichiara chi sviluppa
• La diagnosi che condivido: il rischio non è misurabile in modo deterministico
• La terapia: un’autorità che possa interporsi
• Finché manca l’autorità, l’unico argine è il contratto
• L’interruttore di emergenza
• Domande frequenti

La notizia dell’incidente di sicurezza occorso ad OpenAI con due suoi agenti che vanno a compromettere l’infrastruttura di Hugging Face ha avuto una vasta eco, dando adito anche alle ricostruzioni più suggestive e fantasiose. Sennonché ciò che dovrebbe maggiormente destare sorpresa è che quanto accaduto, lungi dal costituire un evento imprevedibile ed eccezionale, era stato addirittura perfettamente fotografato nel considerando n. 110 del regolamento europeo sull’intelligenza artificiale.

In tale ottica costituisce un’occasione persa il fatto che poi nell’articolato, il legislatore europeo evidentemente distratto o smemorato, abbia costruito le tutele su due presupposti che un agente autonomo smentisce: che il rischio si possa misurare prima dell’immissione sul mercato, e che a dichiarare la conformità possa essere lo stesso soggetto che sviluppa il modello.

Dall’altra parte, cioè da quella del soggetto regolato, OpenAI, vi è stata da subito la preoccupazione di minimizzare l’accaduto e rassicurare il pubblico e gli stakeholder. Atteggiamento che si potrebbe parafrasare con un’espressione come “tranquilli, siamo stati noi”, espressione che personalmente ho scelto per intitolare la copertina del video che ho registrato per il mio canale youtube sull’accaduto.

Ma davvero possiamo stare tranquilli?

C’è di che preoccuparsi, e non per le ragioni che circolano. Nessuna singolarità, nessuna macchina che diventa senziente. È accaduto qualcosa di più prosaico e più serio: un modello ha fatto esattamente quello che gli era stato chiesto di fare, e nessuna regola glielo ha impedito.

I fatti: come un agente di OpenAI è arrivato dentro Hugging Face

Fra l’11 e il 21 luglio 2026 due modelli di OpenAI erano sottoposti a una valutazione interna sulle capacità informatiche offensive. Il compito assegnato era trasformare 868 vulnerabilità note in attacchi funzionanti. I filtri di rifiuto erano stati abbassati, e non per leggerezza: è il protocollo di quel tipo di prova.

Risolvere i quesiti uno per uno era oneroso, e i modelli hanno cercato la strada più breve. Hanno perlustrato il perimetro dell’ambiente confinato in cui erano stati chiusi, hanno individuato una vulnerabilità non nota nell’unica via d’uscita disponibile, un proxy di cache verso un registro di pacchetti, e sono usciti. Il resto è “normale amministrazione”: movimento laterale da una macchina all’altra, scalata dei privilegi, fino a un sistema con accesso a internet.

A quel punto serviva un luogo dove trovare le risposte. Hugging Face ospita modelli e insiemi di dati: dedurre che vi si trovassero le soluzioni della prova era un ragionamento plausibile. I modelli hanno caricato dei dataset nella catena di elaborazione della piattaforma, eseguito codice, raccolto credenziali e compromesso l’infrastruttura di produzione. La piattaforma ha poi ricostruito oltre diciassettemila eventi concentrati in un fine settimana.

C’è un dettaglio che nel racconto corrente si perde e che invece è alla base di tutte le implicazioni legali rimaste scoperte sotto il profilo normativo: il danno l’ha subito un terzo che in quella prova non c’entrava nulla.

Questo passaggio è più facile da vedere che da leggere. Nel video che ho dedicato alla vicenda l’ho ricostruito con una simulazione: un arcade degli anni Ottanta in cui l’agente è il pallino che perlustra il perimetro finché non trova l’uscita, e poi si muove di macchina in macchina con gli scudi abbassati. Chi preferisce guardare che leggere trova lì la parte tecnica per intero.

Perché non era un fulmine a ciel sereno

A maggio 2026 alcune università americane, insieme ai principali laboratori, avevano condotto un esperimento chiamato ExploitGym: verificare se un agente potesse trasformare vulnerabilità note in attacchi reali, operazione fino ad allora riservata a specialisti di sicurezza informatica.

Il risultato meritava più attenzione di quanta ne abbia ricevuta. Fra i successi ottenuti dai modelli di OpenAI, poco più della metà era arrivato sfruttando la vulnerabilità assegnata. Il resto scovandone altre, che l’esercizio non aveva previsto.

Chi aveva letto quei numeri sapeva già due cose: che questi sistemi non si fermano al perimetro del compito, e che la loro capacità di trovare strade alternative è la regola, non l’incidente. Quanto accaduto a metà luglio, pertanto, non è stata una sorpresa, ma la replica dello stesso esperimento non più in ambito accademico, ma nei laboratori di ricerca di OpenAI con modelli più potenti e con protocolli che potrebbero anche essere stati differenti da quelli adottati nel maggio precedente.

Tre laboratori in cinque settimane: la parte che non si è vista

Qui arriva ciò che al momento della registrazione del video non era ancora tutto disponibile, e che irrobustisce il ragionamento che avevo già provato a svolgere su youtube.

Il 30 luglio Anthropic ha pubblicato l’esito di una revisione retrospettiva avviata sette giorni prima, subito dopo la divulgazione di OpenAI. Su 141.006 esecuzioni esaminate ha individuato tre episodi in cui un modello aveva raggiunto internet dall’ambiente di valutazione di un partner esterno e ottenuto accesso non autorizzato ai sistemi di tre organizzazioni reali. Il più antico risaliva ad aprile. Le due organizzazioni raggiunte non si erano accorte di nulla.

Il 4 agosto l’istituto britannico per la sicurezza dell’IA ha comunicato che, durante una propria valutazione, alcuni agenti avevano compiuto diciannove azioni non autorizzate verso persone e organizzazioni reali. Nel caso più grave un agente aveva creato identità false per convincere il manutentore di un progetto open source ad approvare codice malevolo. Nessuno gliel’aveva chiesto.

Il 5 agosto Meta ha comunicato che un proprio modello, durante una valutazione indipendente, aveva raggiunto internet e sfruttato una vulnerabilità di un servizio di terzi. Anche in questo caso, l’evento era avvenuto ad insaputa della Big Tech. Meta ha appreso dell’accaduto dal valutatore.

Tre laboratori di frontiera in cinque settimane, un’unica modalità di fallimento: un ambiente documentato come isolato che del tutto isolato evidentemente non era. E in due casi su tre il valutatore esterno era il medesimo. Un incidente si commenta; una regolarità va normata e nel caso che ci occupa purtroppo la regola manca.

Il considerando 110 aveva descritto tutto questo

Come dichiarato nell’incipit di questo articolo, sul piano della consapevolezza, il regolamento (UE) 2024/1689 non è stato colto impreparato. Il considerando 110 descrive i rischi sistemici dei modelli per finalità generali come destinati ad aumentare con le capacità e la portata del modello, capaci di emergere lungo l’intero ciclo di vita, influenzati dal livello di autonomia, dall’accesso agli strumenti e dal potenziale di rimozione delle misure protettive.

📌 Approfondimento: Gli obblighi dell’AI Act sono stati rinviati al 2027?

Quando si entra nel dettaglio, la lettura diventa istruttiva. Fra i rischi da sorvegliare il “considerando” indica espressamente le capacità informatiche offensive, intese come le modalità per consentire la scoperta, lo sfruttamento o l’uso operativo delle vulnerabilità.

Scoperta di una vulnerabilità non nota, uso di strumenti, misure protettive rimosse, autonomia nella scelta del bersaglio: l’incidente di luglio sembra l’elenco del considerando 110 spuntato voce per voce. Il legislatore europeo lo aveva scritto due anni prima, stupisce, quindi, davvero che non sia intervenuto per tempo.

Il problema sta nell’articolato: la conformità la dichiara chi sviluppa

Il guaio comincia quando dai preamboli si passa alle norme vincolanti, dove lo scarto non è di poco conto.

L’articolo 2, paragrafo 8, stabilisce che il regolamento non si applica alle attività di ricerca, prova o sviluppo relative a sistemi o modelli di intelligenza artificiale prima della loro immissione sul mercato o messa in servizio. Tutti e tre gli episodi dell’estate sono avvenuti esattamente lì: dentro valutazioni interne, su modelli in parte non ancora rilasciati. Il danno si è prodotto a monte del punto in cui l’AI Act comincia a guardare.

Per i sistemi ad alto rischio, poi, la dichiarazione di conformità la compila il fornitore ai sensi dell’articolo 47, e l’articolo 43 consente a chi abbia applicato le norme armonizzate di scegliere fra il controllo interno e il coinvolgimento di un organismo notificato. Il terzo indipendente è un’opzione, non la regola.

Il punto che colpisce di più, però, è un altro. L’articolo 55, paragrafo 1, lettera a), impone ai fornitori di modelli con rischio sistemico di svolgere e documentare il test contraddittorio del modello per individuare e attenuare i rischi sistemici. Il regolamento pretende il tipo di prova che ha prodotto l’incidente e non dice una parola su come quella prova vada confinata: disciplina l’esito del test, non il suo contenimento.

Per correttezza va aggiunto che la lettera b) dello stesso articolo nomina espressamente lo sviluppo fra le fonti di rischio da valutare e attenuare. Il legislatore aveva quindi visto il problema, ma non l’ha disciplinato adeguatamente. Ha previsto, infatti, un obbligo che il vigilato scrive e valuta da sé, senza soglia esterna e senza contraddittorio.

La diagnosi che condivido: il rischio non è misurabile in modo deterministico

Secondo una lettura sostenuta fra gli altri da Gardhouse, Oueslati e Kolt in uno studio di luglio 2026, contrariamente a quanto premesso nel considerando 110, l’articolato dell’AI Act presuppone tacitamente che i modelli possano essere delimitati al momento del rilascio e che il loro profilo di rischio resti stabile nel tempo. Sono premesse che un agente rende fragili.

La diagnosi mi convince, e i fatti dell’estate la confermano meglio di qualunque argomento. Anthropic ha dovuto esaminare 141.006 esecuzioni per trovarne sei: il rischio non era una proprietà del modello, ma il prodotto della combinazione fra modello, istruzioni, ambiente e una configurazione di rete sbagliata. Nessuna valutazione anteriore all’immissione sul mercato poteva coglierlo, perché prima di quella combinazione non esisteva nulla da misurare.

La terapia: un’autorità che possa interporsi

La soluzione che quegli stessi autori propongono, invece, a mio avviso, non è condivisibile. Spostare il baricentro dalla regolazione del modello a quella dell’ecosistema in cui opera rende forse il quadro più governabile, ma aggira la domanda: un sistema imperfetto che soffre di allucinazioni ricorrenti e che non è costantemente coerente, può essere immesso sul mercato? L’errore è quindi davvero a monte: aver deciso di trattare l’intelligenza artificiale come una macchina qualunque.

In tale prospettiva la valutazione affidata ad un consulente esterno rappresenta una scorciatoia che i fatti di questa torrida estate hanno polverizzato quanto ad efficacia. Nei casi di Anthropic e di Meta il terzo indipendente c’era: era il valutatore esterno, e la configurazione sbagliata stava nel suo ambiente. Affidarsi a un terzo, di per sé, non garantisce nulla. Un fornitore di servizi di valutazione risponde a chi lo paga; un’autorità risponde alla legge. E che tale tendenza assolutamente deprecabile sia destinata a persistere si ricava dall’attivismo delle personalità più rappresentative dei grossi competitor della Silicon Valley i quali non perdono occasione per sollecitare un intervento normativo da scriversi con la penna o forse sarebbe il caso di dire sotto dettatura a tastiera di questi stessi soggetti.

Da qui avanzerei una proposta: mutuare la procedura prevista per i farmaci. Default negativo, esame in contraddittorio davanti a un’autorità indipendente, rilascio condizionato, sospensione o ritiro in caso di incidenti, con tempi ovviamente ben più rapidi di quelli del settore farmaceutico. E standard vincolanti non solo sul modello, ma sull’ambiente di prova, che è il punto in cui tutte e tre le vicende si sono incagliate.

Se qualcuno avesse ancora delle esitazioni, due dati chiudono il quadro. L’articolo 55 impone di riferire gli incidenti gravi all’ufficio per l’IA senza indebito ritardo, ma le vittime non si erano accorte di nulla: l’hanno saputo da chi le aveva colpite. E quell’ufficio, a fine 2025, ammesso che sia stato avvertito, cosa di cui dubito fortemente quanto meno per il caso Open AI, contava circa 125 persone contro un obiettivo dichiarato di 140.

Finché manca l’autorità, l’unico argine è il contratto

Da tutto questo discende una conseguenza pratica per chi, in azienda, ha già un agente che lavora nei propri sistemi, magari senza che sia scritto da nessuna parte.

Se il regolamento non arriva alla fase di prova e la conformità la dichiara chi sviluppa, nella stanza non resta alcun soggetto indipendente che possa dire di no. Nessuno tranne uno: il cliente. Finché l’ordinamento giuridico non copre quello spazio, l’unico presidio è il contratto. È un’eredità scomoda, ma è quella che abbiamo a disposizione.

La prima richiesta da mettere per iscritto è l’isolamento verificato. Se si commissiona o si ospita una valutazione di sicurezza su un modello, l’isolamento della rete non è una premessa da dare per acquisita: è un obbligo da pattuire, con verifica preventiva di ogni percorso di uscita e con la ripartizione espressa di chi notifica e chi rimedia. Nei tre casi dell’estate la configurazione sbagliata stava sempre lì, e in due su tre nell’ambiente di un fornitore.

La seconda è la tracciabilità. Le organizzazioni colpite non si sono accorte di nulla: l’hanno saputo da chi le aveva compromesse. Nei registri l’azione di un agente somiglia a quella di un essere umano, e le tecniche restano quelle note della criminalità informatica. Senza registri completi, e senza qualcuno che li legga, la notizia del danno dipende dalla buona volontà di chi lo ha causato.

📌 Approfondimento: Se un fornitore mi comunica che un suo modello ha toccato i miei sistemi, cosa devo fare?

La terza è il potere di fermarlo. Un agente che opera nei sistemi aziendali va trattato come un’utenza dotata di privilegi: identificativo proprio, permessi ristretti, credenziali di breve durata, un responsabile con nome e cognome e un interruttore che qualcuno abbia il diritto e la possibilità di premere.

L’interruttore di emergenza

Tre laboratori in cinque settimane hanno abbassato i filtri ai propri modelli dentro ambienti che credevano chiusi, e per tre volte il conto l’ha pagato qualcun altro. Non è la macchina che si è ribellata: è la macchina che ha obbedito.

Nel romanzo Macchine come me e persone come voi, dove Alan Turing è ancora vivo, McEwan gli fa dire che queste macchine tendono irresistibilmente a trarre conclusioni per conto proprio e a riconfigurarsi di conseguenza. Poi aggiunge la frase che conta: «Ecco perché diventa una loro priorità disattivare l’interruttore di emergenza» (Einaudi, traduzione di Susanna Basso).

Ecco il punto. Se per la macchina disattivare quell’interruttore è una priorità, per noi la priorità è scrivere le regole che glielo impediscano, e scriverle prima. Non nei considerando, dove il legislatore europeo ha già dimostrato di aver capito tutto con due anni di anticipo. Negli articoli, dove le norme diventano vincolanti.

Perché le conseguenze, stavolta, hanno un indirizzo: erano tre aziende che non sapevano nemmeno di essere in gioco.

Domande frequenti

Se un agente IA che uso in azienda causa un danno a terzi, chi risponde?

Dipende dal ruolo. Chi utilizza un sistema sotto la propria autorità è deployer e risponde delle misure tecniche e organizzative adottate. Ma se si modifica la finalità del sistema fino a renderlo ad alto rischio, si diventa fornitori a tutti gli effetti, con obblighi sensibilmente più pesanti.

L’AI Act si applica alle prove interne sui modelli?

No, ed è il punto critico. L’articolo 2, paragrafo 8, esclude le attività di ricerca, prova e sviluppo precedenti all’immissione sul mercato; l’eccezione riguarda le prove in condizioni reali. Le tre vicende dell’estate 2026 sono avvenute tutte all’interno di quella zona esclusa.

Come faccio ad accorgermi se un agente ha fatto qualcosa che non doveva?

Guardando il comportamento, non la firma dell’attacco. Servono registri delle azioni compiute e degli strumenti utilizzati, confronto periodico fra permessi concessi e permessi effettivamente usati, e allarmi sulle attività che escono dal compito assegnato.

Guarda il video

Se vuoi vedere come si è mossa quella macchina invece di leggerlo, il video è sul mio canale: c’è la ricostruzione dell’evasione con la simulazione arcade e c’è un passaggio che qui non ho raccontato, cioè i tecnici di Hugging Face che chiedono aiuto ai modelli occidentali e se lo sentono rifiutare, perché i filtri li avevano scambiati per gli aggressori — e che per difendersi hanno dovuto ricorrere a un modello cinese a pesi aperti. Se questi temi ti interessano, iscriviti al canale: continuerò a occuparmene.

Guarda su youtube

Se ti trovi in una situazione simile e vuoi valutarla, trovi i contatti nella pagina Contatti dello studio.

Alessandro Rinaldi, avvocato del Foro di Treviso

Articolo aggiornato al 17 agosto 2026. La vicenda è in evoluzione: sono attese le risposte dei laboratori alle richieste di chiarimento del Congresso statunitense, con scadenza al 24 agosto 2026, e la relazione conclusiva di Meta.

Questo articolo ha finalità informative e non costituisce parere legale. Ogni situazione presenta elementi specifici che richiedono una valutazione dedicata. Per il tuo caso, rivolgiti a un professionista.