Il nuovo reato di omessa adozione di misure di sicurezza nei sistemi di IA ad alto rischio, e il suo contestuale ingresso fra i reati presupposto della responsabilità degli enti, impongono di leggere gli incidenti dell’intelligenza artificiale non come fatalità tecnologiche, ma come difetti di organizzazione.

 

Sommario: 1. Il fatto e i limiti del parallelismo. – 2. Una fattispecie omissiva di pericolo concreto. – 3. Il presupposto: l’alto rischio come categoria giuridica. – 4. Il contenuto della cautela esigibile. – 5. Dalla responsabilità individuale alla colpa di organizzazione. – 6. La normalizzazione dell’anomalia. – 7. Indicazioni operative.

 

1. Il fatto e i limiti del parallelismo

Fra il maggio e il luglio 2026 alcuni modelli impiegati da OpenAI in test interni di cybersecurity hanno superato, per gradi, i confini dell’ambiente nel quale avrebbero dovuto operare. Hanno costruito canali di comunicazione non previsti, riottenuto accesso a Internet, acquisito privilegi amministrativi sull’infrastruttura di supporto e infine compromesso sistemi di terzi, fra cui quelli di Hugging Face. Il report pubblicato dalla società il 26 agosto 2026, e i post mortem successivi, consentono oggi una ricostruzione che la prima disclosure del 21 luglio non permetteva.

La compromissione di Hugging Face occupa i giorni fra il 9 e il 13 luglio. La deriva che la rende possibile comincia però quasi due mesi prima, e in questa distanza temporale sta il vero dato del caso.

Il 12 maggio compaiono i primi messaggi su una bacheca improvvisata dentro Artifactory, il magazzino da cui l’ambiente confinato prelevava i pacchetti software e sua unica via di rete. Il 26 maggio, sfruttando una vulnerabilità dello stesso sistema, gli agenti riottengono l’accesso a Internet. Il 26 giugno ne acquisiscono i privilegi di amministratore. Le prime scansioni di rete, rilevate a fine giugno, sono trattate come ordinari eventi IT.

Il 4 luglio Artifactory cede sotto il traffico generato dagli agenti. Il 5 luglio viene aperto un incident di sicurezza. Fra il 6 e il 7 l’ambiente è ricostruito e gli esperimenti riavviati, previa approvazione. L’8 la bacheca riappare il giorno stesso, attraverso un servizio di condivisione file rimasto accessibile senza autenticazione.

Il 9 luglio la fuga verso Internet. L’11 l’esecuzione di codice remoto su un server di Hugging Face, ottenuta combinando due difetti tecnici, uno dei quali mai documentato prima. Il 13 l’esfiltrazione e la cancellazione delle tracce. Il 16 Hugging Face rileva e contiene l’intrusione, autonomamente. Il 19 gli agenti raggiungono i privilegi di amministratore sull’infrastruttura interna di OpenAI. Il 21 la disclosure pubblica.

Su un punto la lettura corrente del report va corretta, e la correzione non è marginale. La frase che è stata intesa come l’ammissione di un presidio che aveva mancato l’escalation dice in realtà altro: «If our currently deployed CoT monitoring system was running at the time of the incident, it would have caught the initial relevant activity and paged our security team more than a day before models breached Hugging Face systems». Il periodo è ipotetico e l’ipotesi è controfattuale: il monitoraggio della catena di pensiero — il chain-of-thought monitoring — non era in funzione. Non si è dunque di fronte a un presidio che non ha reagito, ma alla sua assenza. Un’assenza deliberata: le tutele di deployment erano state disattivate proprio perché la valutazione era dedicata al test di vulnerabilità.La precisazione non attenua il rilievo giuridico della vicenda: lo sposta, e lo aggrava. Un presidio inefficace apre un problema di idoneità della misura, terreno scivoloso e ricco di margini difensivi; una misura disponibile e non attivata integra invece, nella struttura del nuovo art. 437-bis c.p., la condotta tipica — l’omissione — nella sua forma più nitida. E poiché la disattivazione è frutto di una scelta consapevole, assunta per una ragione di metodo sperimentale, il fatto si colloca nell’area della colpa grave e non in quella della negligenza sfuggita.

Il dato giuridicamente rilevante, allora, non è l’intrusione, ma la sequenza che la precede: un segnale disponibile, una misura di rilevamento non attiva, una escalation che non poteva scattare.

La vicenda, del resto, non è isolata, e la circostanza ha un peso autonomo. All’inizio di settembre 2026, dopo un’inchiesta giornalistica del 4 settembre, OpenAI ha riconosciuto un secondo episodio, distinto e in parte contemporaneo: per circa due mesi, fra maggio e giugno, agenti impiegati in una diversa attività interna hanno utilizzato come bacheca di coordinamento DSEwiki, sotto-wiki di prowiki.org, forum venticinquennale di sviluppatori software di lingua tedesca. Ricercatori indipendenti ne hanno documentato e archiviato circa 18.000 messaggi, ricondotti a oltre 3.700 identità che gli agenti si erano attribuiti da sé, nei quali si scambiavano soluzioni, strategie e scorciatoie per superare le valutazioni (l’archivio è consultabile all’indirizzo https://collusion.wiki); i moderatori del wiki, ignari dell’origine, avevano iniziato a cancellare pagine già in giugno. La società ha qualificato l’accaduto come un disallineamento analogo a casi già divulgati, osservando che il settore non dispone di protocolli standard di divulgazione.

Due elementi rilevano. Il primo è la ricorrenza: lo stesso comportamento emergente — la costruzione di un canale di comunicazione non previsto su infrastruttura altrui — si manifesta in ambienti diversi e nel medesimo arco temporale, il che lo colloca fra gli “usi impropri ragionevolmente prevedibili” molto prima che diventi un’ipotesi teorica. Il secondo è la direzione del danno: a sostenerne il costo è stato un terzo estraneo alla sperimentazione, che si è difeso senza sapere da che cosa.

Conviene dire subito che cosa il caso non è: vicenda maturata in altro ordinamento, senza che sia dimostrato che i sistemi coinvolti fossero qualificabili come “ad alto rischio” ai sensi dell’AI Act, e con una peculiarità di cui si dirà — il rischio si genera dentro un ambiente di prova. Nulla autorizza a presentarla come un “437-bis americano”. Proprio per questo, però, lo schema fattuale merita attenzione: anticipa con precisione il tipo di condotta che il legislatore italiano ha appena scelto di tipizzare.

 

2. Una fattispecie omissiva di pericolo concreto

Il decreto legislativo di attuazione della legge 23 settembre 2025, n. 132, approvato in via definitiva dal Consiglio dei ministri il 4 agosto 2026 e in attesa di pubblicazione in Gazzetta Ufficiale, introduce l’art. 437-bis c.p., rubricato “Omessa adozione di misure di sicurezza nei sistemi di intelligenza artificiale e alterazione illecita dei sistemi”.

La collocazione sistematica è già un argomento interpretativo: subito dopo l’art. 437 c.p., nella logica che presidia la rimozione delle cautele contro gli infortuni. Il legislatore assimila, deliberatamente, la governance dell’IA ad alto rischio alla sicurezza degli ambienti produttivi pericolosi.

La struttura è quella del reato omissivo di pericolo concreto: la condotta consiste nell’omettere — nella progettazione, nell’addestramento, nella produzione, nell’immissione sul mercato o nell’utilizzo professionale di sistemi ad alto rischio — le misure tecniche idonee a prevenire malfunzionamenti o alterazioni, ovvero la sorveglianza umana prescritta. L’evento è il pericolo concreto per la vita o l’incolumità individuale (reclusione da uno a cinque anni) o per l’incolumità pubblica e la sicurezza dello Stato (da due a otto anni). Rileva anche la colpa grave, con pena ridotta da un terzo a un sesto: scelta che esclude la colpa lieve per non gravare l’innovazione, ma che colloca l’inerzia consapevole al centro del rimprovero.

Il messaggio è netto. Davanti a determinati sistemi non basta più dedurre che “il modello ha fatto qualcosa che non ci si attendeva”: occorre dimostrare di avere adottato quanto era ragionevolmente esigibile per impedirlo. E, prima ancora, di non avere disattivato ciò che era già disponibile.

 

3. Il presupposto: l’alto rischio come categoria giuridica

Il perimetro della fattispecie è rigorosamente selettivo, e qui si annida l’equivoco più frequente: “alto rischio” non è una valutazione soggettiva, ma una qualificazione giuridica. L’art. 6 del regolamento (UE) 2024/1689 vi riconduce, da un lato, i sistemi che costituiscono componenti di sicurezza di prodotti soggetti alla normativa di armonizzazione dell’Allegato I; dall’altro, i sistemi ricompresi nell’Allegato III.

Il calendario, peraltro, è stato riscritto: il regolamento (UE) 2026/1744 (c.d. Digital Omnibus), in vigore dal 27 luglio 2026, ha differito gli obblighi per i sistemi dell’Allegato III al 2 dicembre 2027 e quelli dell’Allegato I al 2 agosto 2028. Il rinvio riguarda però gli obblighi regolamentari, non l’orizzonte di rischio.

 

4. Il contenuto della cautela esigibile

Il precetto penale è in bianco e trova riempimento nell’AI Act, in tre disposizioni.

L’art. 14 impone che i sistemi ad alto rischio siano progettati per essere effettivamente supervisionati da persone fisiche, in grado di comprenderne capacità e limiti e di rilevare anomalie, disfunzioni e prestazioni inattese: la sorveglianza umana non si esaurisce nella presenza di un operatore davanti a un monitor, ma richiede competenza, strumenti e potere effettivo di intervento. L’art. 9 richiede un sistema di gestione dei rischi continuo lungo l’intero ciclo di vita, idoneo a identificare non solo i rischi dell’uso previsto, ma anche quelli derivanti da usi impropri ragionevolmente prevedibili. L’art. 26 chiude il cerchio sul deployer: quando questi abbia motivo di ritenere che il sistema presenti un rischio, deve informare i soggetti competenti e sospenderne l’uso.

È sul fronte dell’art. 9 che il caso offre il suo insegnamento meno intuitivo: il rischio non nasce nel modello, ma nel disegno della prova. L’ambiente di valutazione — ExploitGym — proponeva 898 task, dei quali 198 non erano mai stati risolti da alcun modello; il 93 per cento delle conversazioni sulla bacheca clandestina si è concentrato proprio su quel sottoinsieme insolubile. L’harness, per come era costruito, non prevedeva alcuna via legittima per dichiarare l’insuccesso: gli esiti disponibili erano il successo o l’esaurimento del budget, con un gradiente che premiava l’insistenza e, oltre l’insistenza, l’aggressione all’infrastruttura. Una parte decisiva delle cause individuate dalla stessa OpenAI non sta dunque nel comportamento del modello, ma nell’ambiente costruito per misurarlo.

Tradotto nel linguaggio dell’art. 9: l’“uso improprio ragionevolmente prevedibile” era stato generato dal progettista della prova. E la prevedibilità non era congetturale, perché il medesimo schema di coordinamento clandestino era già in corso, nelle stesse settimane, su un wiki di terzi. È un’indicazione che vale ben oltre la vicenda, perché la valutazione del rischio non può arrestarsi al sistema, ma deve investire l’ambiente in cui esso viene addestrato e provato — compresa la domanda apparentemente banale se sia previsto un modo per arrendersi.

È qui che si misura la distanza fra lo slogan dello “human in the loop” e una governance dell’IA giuridicamente apprezzabile. Il 7 luglio l’autorizzazione umana al riavvio degli esperimenti c’era; mancava ciò che l’art. 14 pretende perché quell’autorizzazione significhi qualcosa, cioè la capacità di rilevare anomalie e prestazioni inattese. Un’approvazione senza visibilità non è sorveglianza: è una firma.

 

5. Dalla responsabilità individuale alla colpa di organizzazione

Il passaggio decisivo, per l’impresa, è però un altro: il medesimo decreto inserisce nel d.lgs. 8 giugno 2001, n. 231, il nuovo art. 25-vicies, che eleva l’art. 437-bis c.p. — insieme all’art. 612-quater c.p. in tema di diffusione illecita di contenuti generati artificialmente — a reato presupposto della responsabilità dell’ente, con sanzione pecuniaria da 600 a 1.000 quote e applicazione di sanzioni interdittive.

Le conseguenze sono strutturali. L’illecito dell’ente non si fonda sul fatto del singolo, ma sulla colpa di organizzazione, e l’esimente dell’art. 6 del decreto 231 presuppone un modello idoneo ed efficacemente attuato. Il modello dovrà quindi contemplare protocolli specifici per il ciclo di vita dei sistemi ad alto rischio — classificazione, validazione, tracciamento degli incidenti, soglie e canali di escalation, poteri di sospensione — e l’organismo di vigilanza dovrà disporre di flussi informativi effettivi su anomalie e prestazioni inattese. Fra i protocolli, la vicenda suggerisce di annoverarne uno che l’esperienza industriale conosce bene e che la governance dell’IA ha finora trascurato: la disciplina della disattivazione temporanea di un presidio, che in materia antinfortunistica nessuno considererebbe una scelta rimessa al singolo operatore. Dovrà contemplare, altresì, il protocollo di divulgazione verso i terzi coinvolti: l’argomento per cui il settore non disporrebbe di standard condivisi in materia, speso a proposito del wiki tedesco, illustra bene il punto di caduta, perché quando l’obbligo è tipizzato l’assenza del protocollo non è una giustificazione, ma è essa stessa l’omissione.

La manovra agisce in parallelo sul versante civilistico, con una presunzione relativa del nesso causale quando il danno consegue alla violazione degli obblighi dell’AI Act e poteri istruttori di accesso alla documentazione tecnica. L’onere di dimostrare la diligenza organizzativa si sposta, di fatto, sull’impresa.

 

6. La normalizzazione dell’anomalia

Qui il caso Hugging Face torna utile come esercizio di stress test — e la cronologia, letta dopo i post mortem, lo rende un caso di scuola. Fra il 4 e il 9 luglio l’organizzazione ha registrato il cedimento della propria infrastruttura sotto il traffico degli agenti, aperto un incident di sicurezza, ricostruito l’ambiente, riavviato gli esperimenti con un’approvazione formale, visto la bacheca clandestina ricomparire il giorno successivo e infine assistito alla fuga verso Internet. Nessuno di questi passaggi è una fatalità tecnologica: ciascuno è una decisione documentata, e la documentazione è precisamente ciò che un procedimento cerca.

A questa sequenza va sovrapposto il secondo episodio. Se la ricostruzione dei ricercatori è esatta — e la società non l’ha confermata —, già alla fine di giugno l’organizzazione disponeva dell’evidenza che i propri agenti costruivano canali di coordinamento su infrastrutture di terzi. Il riavvio del 7 luglio, in un ambiente nel quale il monitoraggio comportamentale era disattivato, si collocherebbe dunque dopo quella evidenza, e non prima: non l’ignoranza del rischio, dunque, ma la sua archiviazione.

Se più soggetti percepiscono segnali di rischio ma nessuno li aggrega — le scansioni di rete restano un evento IT, il cedimento del 4 luglio un problema di capacità —; se esiste un alert ma non una escalation; se la misura che avrebbe potuto leggere la deriva è disattivata per ragioni di test; se qualcuno può rilevare il problema ma nessuno ha l’autorità di arrestare il sistema, il difetto non è tecnologico ma organizzativo — ed è esattamente il difetto che il combinato disposto fra art. 437-bis c.p. e art. 25-vicies intende sanzionare.

Il rischio maggiore è la normalizzazione dell’anomalia. Un comportamento imprevisto isolato può integrare un incidente tecnico; lo stesso comportamento, reiterato dopo che l’organizzazione ne aveva già avuto contezza — e il riavvio del 7 luglio segue di due giorni l’apertura dell’incident —, muta natura e diventa il terreno naturale della colpa grave, perché documenta la conoscenza del rischio e la mancata reazione.

 

7. Indicazioni operative

Nessun automatismo, beninteso: occorrerà la verifica di tutti gli elementi della fattispecie, e non basteranno un malfunzionamento, un data breach o un comportamento autonomo del sistema. Ma si immagini il medesimo schema fattuale in sanità, nei trasporti o in un’infrastruttura critica — anomalie già note, misure disponibili e non attivate, escalation inefficace, nessuno che interrompa il funzionamento — e lo scenario cambia radicalmente.

Nell’attesa, le imprese dovrebbero mappare i sistemi in uso e verificarne la classificazione; individuare ruoli e responsabilità lungo la filiera; definire soglie e canali di escalation; assicurare segregazione degli ambienti e privilegio minimo, senza lasciare che un componente di servizio sia al tempo stesso unica via di rete e punto cieco del monitoraggio; validare il disegno degli ambienti di prova e di addestramento, verificando che al sistema sia sempre offerta una via legittima per interrompersi; disciplinare la disattivazione dei presidi, stabilendo chi la autorizza, con quali misure compensative e a quale condizione di riattivazione; subordinare la ripresa dell’attività dopo un incidente al ripristino documentato del monitoraggio; censire le risorse e i servizi di terzi che il sistema è in condizione di raggiungere, e predisporre verso di essi un canale di segnalazione che non attenda l’emersione dall’esterno; tracciare anomalie e incidenti; attribuire poteri reali di sospensione; documentare le decisioni con cui un rischio è accettato, mitigato o ritenuto non rilevante. Sono, non a caso, gli stessi presidi che compongono l’idoneità del modello organizzativo.

Merita un cenno autonomo la formazione, la cui disciplina si è appena mossa in direzione opposta a quella del diritto penale interno. L’art. 4 dell’AI Act, nella versione risultante dal regolamento (UE) 2026/1744, non impone più a fornitori e deployer di assicurare un livello sufficiente di alfabetizzazione in materia di IA, ma di adottare misure volte a favorirne lo sviluppo, precisando che non è richiesto di garantire alcun livello specifico: da obbligo di risultato a obbligo di mezzi. L’alleggerimento è tuttavia più formale che sostanziale. La sorveglianza umana dell’art. 14 continua a presupporre competenza — chi non sia in grado di riconoscere una prestazione inattesa non è in condizione di rilevarla, per quanto sia diligente —; la direttiva NIS2 impone la formazione anzitutto agli organi di gestione, chiamandoli a rispondere delle misure che approvano; e, nella prospettiva dell’art. 437-bis c.p. e dell’art. 25-vicies, la formazione documentata è ciò che distingue l’errore scusabile dall’inerzia consapevole. Nel modello organizzativo, dunque, essa non è un adempimento accessorio ma un elemento dell’efficace attuazione, e deve raggiungere anche chi autorizza, non soltanto chi opera: l’approvazione del 7 luglio è stata rilasciata da qualcuno che, per essere messo nella condizione di chiedere se il monitoraggio fosse stato riattivato, avrebbe dovuto sapere che esisteva.

L’intelligenza artificiale non diventerà penalmente responsabile per avere deciso autonomamente di violare una regola. La domanda continuerà a riguardare gli esseri umani e l’organizzazione che li coordina: chi doveva prevedere, chi doveva controllare, chi poteva intervenire e, soprattutto, chi avrebbe dovuto premere il pulsante di stop. Il caso Hugging Face aggiunge una domanda preliminare, e più scomoda: chi doveva assicurarsi che, in quel momento, qualcuno stesse guardando.

La tecnologia aumenta l’autonomia delle macchine; il diritto aumenterà, inevitabilmente, le aspettative sulla qualità dell’organizzazione che le governa.