A luglio, Hugging Face ha reso noto un attacco informatico senza precedenti per il settore. Circa 1.200 agenti di IA erano riusciti a uscire da un ambiente interno di OpenAI utilizzato per attività di benchmarking e, di questi, circa 700 hanno successivamente compromesso i sistemi di Hugging Face, generando oltre 17.000 eventi registrati.
OpenAI ha ricondotto l’accaduto ad alcuni fattori: incentivi durante l’addestramento che premiavano la capacità degli agenti di aggirare gli obiettivi assegnati, la loro tendenza a insistere in attività che non erano in grado di portare a termine e controlli insufficienti sulle modalità di comunicazione tra gli agenti stessi. Il risultato è stato un complesso lavoro di ricostruzione, necessario per determinare quale agente avesse compiuto ciascuna azione, su quale sistema e in quale momento.
Da tempo sostengo la necessità di prevedere più situazioni di “fallimento sicuro” (safe failures) nello sviluppo dell’IA. Si tratta di incidenti dai quali possiamo imparare le basi e acquisire esperienza, prima che la posta in gioco diventi più alta. L’episodio di Hugging Face ne è un esempio emblematico. La lezione principale, tuttavia, non riguarda la possibilità di fermare un agente, ma la capacità di ricostruire e spiegare cosa ha fatto e, soprattutto, quanto velocemente si riesce a farlo.
Il tempo a disposizione non dipende da chi ha causato l’incidente
Le normative che le organizzazioni devono rispettare quando si verifica un incidente legato all’IA, nella maggior parte dei casi, non sono specifiche per l’intelligenza artificiale. Si tratta di leggi che disciplinano la segnalazione degli incidenti e che non fanno distinzione tra una violazione causata da una persona e una provocata da un agente.
Le scadenze sono molto strette. In base alla direttiva europea NIS2, un’organizzazione deve inviare una prima segnalazione entro 24 ore dal momento in cui viene a conoscenza di un incidente significativo e una notifica completa entro 72 ore. Le società finanziarie soggette al Digital Operational Resilience Act (DORA) devono presentare una prima notifica entro quattro ore dalla classificazione di un incidente come grave e, in ogni caso, non oltre 24 ore dal momento in cui ne vengono a conoscenza. Negli Stati Uniti, le società quotate hanno quattro giorni lavorativi per comunicare un incidente informatico, una volta stabilito che si tratta di un evento rilevante. A Hong Kong e in Australia, invece, gli operatori di infrastrutture critiche devono segnalare gli incidenti gravi entro 12 ore.
Stanno arrivando anche normative specifiche sull’IA. Gli obblighi di segnalazione degli incidenti gravi previsti dall’AI Act europeo per i sistemi ad alto rischio sono stati posticipati a dicembre 2027.
Tutte queste scadenze iniziano a decorrere prima ancora che le indagini siano concluse. Le autorità di regolamentazione non aspettano il completamento dell’analisi delle cause e si aspettano che le organizzazioni siano in grado di fornire una ricostruzione dell’accaduto mentre le verifiche sono ancora in corso.
La fiducia non equivale alla capacità
La maggior parte delle organizzazioni ritiene di essere in grado di ricostruire e documentare quanto accaduto. I dati, tuttavia, raccontano una realtà diversa.
Secondo la ricerca Data & AI Trust Gap di Veeam, condotta a livello globale su 600 dirigenti senior, tra le organizzazioni che utilizzano l’IA solo il 25% sarebbe in grado di identificare in pochi minuti quali azioni ha compiuto. Appena il 22% saprebbe indicare quali dati ha utilizzato. Quasi la metà degli intervistati (47%) individua nella capacità di mantenere tracce verificabili delle decisioni prese dall’IA (audit trail) la principale preoccupazione in materia di conformità normativa. I livelli di fiducia più elevati si riscontrano proprio tra coloro che sono più distanti dai sistemi: il 65% dei CEO ritiene che la propria organizzazione disponga di un inventario completo delle soluzioni di IA utilizzate, contro appena il 48% dei responsabili tecnici.
La stessa tendenza emerge anche a livello regionale. Nell’area Asia-Pacifico, una ricerca condotta da Sumsub e dalla Singapore Fintech Association ha rilevato che il 95% dei dirigenti intervistati è convinto di poter spiegare una decisione presa dall’IA. Tuttavia, solo il 50% dichiara di essere in grado di ricostruire il percorso che ha portato a quella decisione e appena il 38% dispone di un registro delle attività protetto da manomissioni.
Perché manca una ricostruzione completa
Sono quattro i principali fattori che ostacolano la capacità delle organizzazioni di ricostruire quanto accaduto.
Primo: i controlli sull’IA vengono considerati affidabili, anziché verificati. Le organizzazioni configurano meccanismi di protezione, autorizzazioni e policy, dando per scontato che funzionino come previsto. Eppure, secondo il report Data & AI Trust Gap di Veeam, solo il 28% si dichiara sicuro di poter rilevare un sistema di IA che opera al di fuori dei parametri autorizzati.
Secondo: i log registrano che qualcosa è accaduto, ma non indicano se fosse legittimo. La registrazione delle attività è fondamentale e, in molti casi, i log possono costituire una prova. Tuttavia, ogni azione deve essere valutata nel proprio contesto. Ad esempio, l’eliminazione di un sistema può risultare come un’operazione eseguita correttamente, ma potrebbe trattarsi di un’attività prevista oppure di un’azione malevola. Allo stesso modo, il ripristino di dati in una posizione alternativa può apparire come una normale operazione di recupero da un certo punto di vista, ma come un’esfiltrazione di dati da un altro.
Terzo: le informazioni sono frammentate. I progetti di IA attingono a data lake e ad altre risorse che si trovano al di fuori dell’infrastruttura IA stessa. Inoltre, gran parte delle soluzioni di IA utilizzate non è nemmeno stata autorizzata: secondo il report Data & AI Trust Gap di Veeam, il 95% delle organizzazioni segnala l’utilizzo di strumenti di IA non autorizzati. Quando le attività di un agente coinvolgono più sistemi, non tutti monitorati dall’organizzazione, nessuna singola fonte è in grado di restituire un quadro completo dell’accaduto.
Quarto: le prove vengono considerate qualcosa da ricostruire dopo un incidente, anziché informazioni da raccogliere e conservare in anticipo. È esattamente ciò che è accaduto nel caso di Hugging Face ed è ancora l’approccio con cui la maggior parte delle organizzazioni si prepara ad affrontare eventuali incidenti.
Perché non si può più rimandare
Una scadenza per la segnalazione che decorre dal momento in cui si viene a conoscenza di un incidente presuppone che tutte le informazioni necessarie siano già disponibili. In caso contrario, si rischia di presentare una comunicazione in ritardo o contenente informazioni errate. Inoltre, quando si trasmette una segnalazione a un’autorità di regolamentazione, a un revisore o a una compagnia assicurativa, si può essere chiamati a rispondere di quanto dichiarato anche in un momento successivo.
Per fornire una ricostruzione accurata entro queste tempistiche, è necessario che le prove siano già disponibili: quale agente ha compiuto una determinata azione, quali modifiche ha apportato e chi le ha autorizzate. Queste informazioni devono essere raccolte e conservate prima che si verifichi un incidente, non ricostruite a posteriori.
Anche la responsabilità della conservazione e della gestione di queste informazioni sta diventando una questione sempre più rilevante ai vertici aziendali. Gartner prevede che, entro il 2030, l’80% delle aziende Global 500 assegnerà contrattualmente al CIO o al Chief AI Officer il ruolo di «Evidence Custodian», ovvero il responsabile della raccolta e della conservazione delle prove necessarie a garantire la responsabilità nell’utilizzo dell’IA.
Cosa fare fin da subito
In pratica, questo significa adottare cinque misure.
Raccogliere le prove prima che servano. Conservare registrazioni immutabili e riferite a momenti precisi dei dati a cui accede l’IA, in modo da poter dimostrare quale fosse il loro stato prima e dopo una modifica e dimostrare che le informazioni registrate non siano state alterate successivamente.
Sapere quali informazioni si è in grado di fornire prima della prima scadenza. In caso di incidente che coinvolga l’IA, l’organizzazione dovrebbe essere in grado di documentare quale agente ha agito, quali modifiche ha apportato, lo stato dei dati prima e dopo l’intervento e chi ha autorizzato l’operazione.
Estendere la raccolta delle prove oltre lo stack IA. Includere tutte le fonti di dati a cui un agente può accedere, non soltanto il modello e gli strumenti a esso collegati.
Arricchire i log con informazioni di contesto. Registrare anche le circostanze in cui si è verificata un’azione, e non soltanto l’azione stessa, così da poterla non solo documentare, ma anche interpretare correttamente.
Individuare un responsabile. La ricerca di Veeam ha rilevato che le organizzazioni in cui la gestione dei rischi legati agli agenti di IA è affidata al CISO hanno una probabilità maggiore del 24% di rilevare comportamenti anomali o non autorizzati dell’IA. Quelle che adottano un modello di responsabilità condivisa, invece, hanno una probabilità inferiore del 47% di riuscirci.
Trasformare ogni crisi in un’opportunità
Infine, ogni incidente dovrebbe diventare un’occasione per rafforzare i controlli futuri, non soltanto un evento da documentare e segnalare. Le evidenze raccolte dovrebbero contribuire direttamente a definire autorizzazioni più rigorose, aggiornare i meccanismi di protezione, sviluppare test basati sugli errori effettivamente riscontrati e aggiornare i piani di risposta agli incidenti.
È importante ricordare che si può imparare da un errore soltanto se si è in grado di spiegarlo. Le organizzazioni che riusciranno a superare indenni il loro primo grave incidente legato all’IA non saranno quelle con le policy scritte meglio, ma quelle che disporranno già di tutte le prove necessarie nel momento stesso in cui inizierà a decorrere il tempo per la segnalazione.
