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\u00e0 di benchmarking e, di questi, circa 700 hanno successivamente compromesso i sistemi di Hugging Face, generando oltre 17.000 eventi registrati.<\/p>\n
OpenAI ha ricondotto l’accaduto ad alcuni fattori: incentivi durante l’addestramento che premiavano la capacit\u00e0 degli agenti di aggirare gli obiettivi assegnati, la loro tendenza a insistere in attivit\u00e0 che non erano in grado di portare a termine e controlli insufficienti sulle modalit\u00e0 di comunicazione tra gli agenti stessi. Il risultato \u00e8 stato un complesso lavoro di ricostruzione, necessario per determinare quale agente avesse compiuto ciascuna azione, su quale sistema e in quale momento.<\/p>\n
Da tempo sostengo la necessit\u00e0 di prevedere pi\u00f9 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\u00f9 alta. L’episodio di Hugging Face ne \u00e8 un esempio emblematico. La lezione principale, tuttavia, non riguarda la possibilit\u00e0 di fermare un agente, ma la capacit\u00e0 di ricostruire e spiegare cosa ha fatto e, soprattutto, quanto velocemente si riesce a farlo.<\/p>\n
Le normative che le organizzazioni devono rispettare quando si verifica un incidente legato all’IA<\/a>, 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.<\/p>\n 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\u00e0 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\u00e0 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.<\/p>\n 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.<\/p>\n Tutte queste scadenze iniziano a decorrere prima ancora che le indagini siano concluse. Le autorit\u00e0 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.<\/p>\n La maggior parte delle organizzazioni ritiene di essere in grado di ricostruire e documentare quanto accaduto. I dati, tuttavia, raccontano una realt\u00e0 diversa.<\/p>\n 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\u00e0 degli intervistati (47%) individua nella capacit\u00e0 di mantenere tracce verificabili delle decisioni prese dall’IA (audit trail) la principale preoccupazione in materia di conformit\u00e0 normativa. I livelli di fiducia pi\u00f9 elevati si riscontrano proprio tra coloro che sono pi\u00f9 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.<\/p>\n 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 \u00e8 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\u00e0 protetto da manomissioni.<\/p>\n Sono quattro i principali fattori che ostacolano la capacit\u00e0 delle organizzazioni di ricostruire quanto accaduto.<\/p>\n Primo: i controlli sull’IA vengono considerati affidabili, anzich\u00e9 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.<\/p>\n Secondo: i log registrano che qualcosa \u00e8 accaduto, ma non indicano se fosse legittimo. La registrazione delle attivit\u00e0 \u00e8 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\u00f2 risultare come un’operazione eseguita correttamente, ma potrebbe trattarsi di un’attivit\u00e0 prevista oppure di un’azione malevola. Allo stesso modo, il ripristino di dati in una posizione alternativa pu\u00f2 apparire come una normale operazione di recupero da un certo punto di vista, ma come un’esfiltrazione di dati da un altro.<\/p>\n 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 \u00e8 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\u00e0 di un agente coinvolgono pi\u00f9 sistemi, non tutti monitorati dall’organizzazione, nessuna singola fonte \u00e8 in grado di restituire un quadro completo dell’accaduto.<\/p>\n Quarto: le prove vengono considerate qualcosa da ricostruire dopo un incidente, anzich\u00e9 informazioni da raccogliere e conservare in anticipo. \u00c8 esattamente ci\u00f2 che \u00e8 accaduto nel caso di Hugging Face ed \u00e8 ancora l’approccio con cui la maggior parte delle organizzazioni si prepara ad affrontare eventuali incidenti.<\/p>\n 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\u00e0 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\u00e0 di regolamentazione, a un revisore o a una compagnia assicurativa, si pu\u00f2 essere chiamati a rispondere di quanto dichiarato anche in un momento successivo.<\/p>\n Per fornire una ricostruzione accurata entro queste tempistiche, \u00e8 necessario che le prove siano gi\u00e0 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.<\/p>\n Anche la responsabilit\u00e0 della conservazione e della gestione di queste informazioni sta diventando una questione sempre pi\u00f9 rilevante ai vertici aziendali. Gartner prevede che, entro il 2030, l’80% delle aziende Global 500 assegner\u00e0 contrattualmente al CIO o al Chief AI Officer il ruolo di \u00abEvidence Custodian\u00bb, ovvero il responsabile della raccolta e della conservazione delle prove necessarie a garantire la responsabilit\u00e0 nell’utilizzo dell’IA.<\/p>\n In pratica, questo significa adottare cinque misure.<\/p>\n Raccogliere le prove prima che servano<\/b>. 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.<\/p>\n Sapere quali informazioni si \u00e8 in grado di fornire prima della prima scadenza<\/b>. 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.<\/p>\n Estendere la raccolta delle prove oltre lo stack IA<\/b>. Includere tutte le fonti di dati a cui un agente pu\u00f2 accedere, non soltanto il modello e gli strumenti a esso collegati.<\/p>\n Arricchire i log con informazioni di contesto<\/b>. Registrare anche le circostanze in cui si \u00e8 verificata un’azione, e non soltanto l’azione stessa, cos\u00ec da poterla non solo documentare, ma anche interpretare correttamente.<\/p>\n Individuare un responsabile<\/b>. La ricerca di Veeam ha rilevato che le organizzazioni in cui la gestione dei rischi legati agli agenti di IA \u00e8 affidata al CISO hanno una probabilit\u00e0 maggiore del 24% di rilevare comportamenti anomali o non autorizzati dell’IA. Quelle che adottano un modello di responsabilit\u00e0 condivisa, invece, hanno una probabilit\u00e0 inferiore del 47% di riuscirci.<\/p>\n 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\u00f9 rigorose, aggiornare i meccanismi di protezione, sviluppare test basati sugli errori effettivamente riscontrati e aggiornare i piani di risposta agli incidenti.<\/p>\n \u00c8 importante ricordare che si pu\u00f2 imparare da un errore soltanto se si \u00e8 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\u00e0 di tutte le prove necessarie nel momento stesso in cui inizier\u00e0 a decorrere il tempo per la segnalazione.<\/p>\n Secondo Veeam, le aziende devono raccogliere e conservare in anticipo le prove delle attivit\u00e0 degli agenti intelligenti per ricostruire gli incidenti e rispettare le scadenze normative<\/p>\n","protected":false},"author":1,"featured_media":7284,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[4154,8],"tags":[5615],"class_list":{"0":"post-8573","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-featured","8":"category-opinioni","9":"tag-veeam"},"yoast_head":"\nLa fiducia non equivale alla capacit\u00e0<\/b><\/h3>\n
Perch\u00e9 manca una ricostruzione completa<\/b><\/h3>\n
Perch\u00e9 non si pu\u00f2 pi\u00f9 rimandare<\/b><\/h3>\n
Cosa fare fin da subito<\/b><\/h3>\n
Trasformare ogni crisi in un\u2019opportunit\u00e0<\/b><\/h3>\n
A cura di Dave Russell, Senior Vice President and Head of Strategy di Veeam<\/a><\/strong><\/h3>\n","protected":false},"excerpt":{"rendered":"