Incidenti gravi di IA: come preservare le prove, contenere il danno e decidere se un guasto debba essere notificato ai sensi dell’articolo 73 dell’AI Act

Un guasto non è automaticamente un incidente grave

La risposta a un risultato pericoloso prodotto da un sistema di IA inizia distinguendo concetti che vengono spesso confusi. Un errore del modello può essere un output inesatto, incoerente o indesiderato. Un incidente operativo può comprendere un’interruzione del servizio, una configurazione errata, un’integrazione non riuscita o l’uso di strumenti al di fuori del comportamento previsto. Un danno è una conseguenza negativa concreta per una persona, un’organizzazione, beni, l’ambiente o un processo. Un incidente grave, nel senso regolatorio pertinente a questa guida, è una categoria più ristretta, collegata agli effetti specifici definiti dall’AI Act.

Non ogni allucinazione, calo di qualità, reclamo di un utente o risposta offensiva attiva di per sé il regime dell’articolo 73. Non sarebbe nemmeno prudente escludere un caso perché l’output isolato appare secondario: una risposta apparentemente ordinaria può avere influenzato una decisione clinica, di assunzione, di accesso a un servizio, di sicurezza fisica o di gestione di infrastrutture. L’analisi deve basarsi su fatti osservabili, non su etichette interne quali «bug minore» o «reclamo non critico».

Il testo consolidato dell’AI Act definisce l’incidente grave tramite categorie di esito, tra cui decesso o grave danno alla salute, perturbazione grave e sostenuta della gestione o del funzionamento di infrastrutture critiche, violazione di obblighi volti a proteggere i diritti fondamentali e danno grave a beni o all’ambiente. La classificazione richiede di esaminare il fatto, il sistema coinvolto e il possibile nesso tra i due. Non deve essere sostituita da un punteggio interno di gravità privo di una corrispondenza documentata con tali categorie.

È utile mantenere due binari fin dalla prima segnalazione. Il binario tecnico mira a fermare un comportamento non sicuro e a ripristinare un servizio controllato. Il binario delle prove e della conformità mira a conservare i fatti, valutare il possibile nesso causale, coordinare fornitore e deployer e stabilire se sia opportuno predisporre una comunicazione all’autorità competente. Possono procedere in parallelo, ma una correzione precipitosa può ostacolare il secondo binario se modifica o elimina le informazioni necessarie per spiegare cosa è accaduto.

Ambito: identificare il sistema, l’operatore e il percorso di alto rischio

L’articolo 73 si rivolge ai fornitori di sistemi di IA ad alto rischio immessi sul mercato dell’Unione. Il primo dato da verificare non è quindi la gravità percepita dal team, bensì quale sistema esatto sia intervenuto, chi ne sia il fornitore ai fini del regolamento e se fosse soggetto alla pertinente classificazione ad alto rischio. L’AI Act prevede due principali percorsi di classificazione nell’articolo 6: determinati sistemi relativi a prodotti o componenti di sicurezza regolamentati e i casi d’uso elencati nell’allegato III, alle condizioni ed eccezioni previste dal regolamento stesso.

Non basta affermare che un modello di IA per finalità generali, un’interfaccia conversazionale o un’automazione «è ad alto rischio» in ragione del suo tema. L’unità di analisi deve essere il sistema reso disponibile o utilizzato nel contesto concreto: versione, finalità prevista, integrazione, funzioni abilitate, utenti, dati in ingresso e risultato prodotto. Uno stesso componente può fare parte di configurazioni soggette a obblighi diversi. Il progetto di linee guida della Commissione sulla classificazione può aiutare a strutturare la verifica, ma resta una bozza e non sostituisce il testo vincolante né la valutazione giuridica del caso.

La pianificazione temporale deve distinguere tra preparazione e applicabilità effettiva. Le organizzazioni possono già ora costruire processi di registrazione, conservazione, contatto ed escalation. Tuttavia, le date specifiche di applicazione per le diverse categorie di alto rischio devono essere verificate rispetto alla versione giuridicamente applicabile del regolamento e alle eventuali modifiche in vigore al momento di decidere un caso. Non è consigliabile trasformare una data di pianificazione interna in una conclusione su un obbligo già esigibile.

Per orientarsi nel lavoro correlato, il team può separare questo protocollo dalle revisioni generali di Sicurezza, dalla valutazione delle alternative in Confronta e dall’identificazione delle capacità in Scopri. Queste attività possono fornire contesto, ma l’indagine su un incidente richiede un fascicolo centrato sul fatto accaduto e sulla configurazione effettivamente implementata.

Le prime ore: preservare prima di correggere

Quando viene rilevato un caso potenzialmente rilevante, nominate un responsabile dell’incidente con l’autorità necessaria per coordinare operazioni, prodotto, sicurezza, qualità e conformità. Il suo primo obbligo operativo è fissare una cronologia: quando si è verificato il fatto, quando è stato rilevato, chi ha ricevuto ciascun avviso, quali sistemi sono rimasti attivi e quali decisioni sono state adottate. L’ora in cui il fornitore ne è venuto a conoscenza e, quando pertinente, quella del deployer devono essere registrate separatamente, insieme alla fonte che le dimostra.

Preservare le prove non significa copiare indiscriminatamente tutti i dati disponibili. Significa conservare in modo proporzionato, integro e con accesso controllato gli elementi che consentono di ricostruire il comportamento oggetto dell’indagine. Come minimo, il fascicolo dovrebbe collegare identificativi di richiesta e sessione, input e output, versione e parametri del modello, prompt di sistema e modelli, policy, configurazione di recupero, documenti recuperati o relativi identificativi, chiamate e risposte degli strumenti, autorizzazioni umane, identità o ruolo dell’operatore e modifiche di configurazione vicine all’evento.

La conservazione deve includere metadati di integrità: origine, data di estrazione, responsabile, metodo di esportazione, impronta del file quando praticabile, controlli di accesso e qualsiasi trasformazione successiva. Se sono presenti dati personali, segreti commerciali o informazioni di sicurezza, l’accesso deve essere limitato secondo le regole applicabili. Limitare l’accesso non giustifica l’eliminazione degli elementi necessari all’indagine. Se un dato non può essere conservato, il fascicolo deve spiegare cosa è stato eliminato, perché, quando e quale prova alternativa rimane.

L’AI Act richiede al fornitore di indagare immediatamente sull’incidente grave e sul sistema interessato, compresa una valutazione dei rischi e misure correttive. Stabilisce inoltre che il sistema non debba essere modificato prima dell’informazione quando la modifica possa incidere sulla successiva valutazione delle cause dell’incidente. In pratica, ciò impone di progettare il contenimento in modo da limitare il danno senza cancellare lo stato che deve essere esaminato.

Contenere il danno senza compromettere l’indagine

Il contenimento non ha una sola forma corretta. Sospendere l’intero sistema può essere necessario se persiste un rischio grave, ma può anche incidere su processi essenziali o spingere gli utenti verso soluzioni non controllate. Altre misure possono essere più proporzionate: ritirare temporaneamente uno strumento di esecuzione, ridurre i permessi, impedire azioni automatizzate ad alto impatto, bloccare un insieme identificato di input, disattivare una fonte di recupero compromessa o imporre un controllo umano per una decisione specifica.

Ogni misura deve rispondere a un’ipotesi esplicita di danno e avere condizioni di riesame. «Mettere il sistema in modalità sicura» non è una descrizione verificabile se non definisce quale capacità sia stata bloccata, cosa sia rimasto disponibile, quale popolazione sia stata interessata, quali alternative siano state offerte e come sia stato verificato l’effetto. La comunicazione a clienti, utenti e operatori può fare parte del contenimento, ma deve basarsi su fatti confermati e non attribuire causalità prima che l’indagine la sostenga.

Il rollback a una versione precedente richiede cautela. Può risolvere il sintomo immediato, ma non dimostra che la causa risiedesse nella versione ritirata e può introdurre differenze che impediscono di riprodurre il caso. Prima della modifica, preservate l’artefatto distribuito, la configurazione e i registri che consentono di confrontare lo stato precedente e quello successivo. Se il cambiamento è inevitabile per evitare un danno, documentate la necessità e l’ambito della deviazione.

L’autorità di vigilanza del mercato può disporre di propri poteri nei confronti di prodotti che presentano un rischio grave, comprese misure di valutazione e restrizioni. Tali interventi non sostituiscono l’indagine interna né trasformano l’organizzazione in un’autorità. Il team deve poter fornire fatti verificabili, valutazioni e misure adottate in caso di richiesta.

Ricostruire il caso come una catena di decisioni

Un’indagine utile deve poter rispondere a una domanda semplice: quale sistema esatto ha prodotto o contribuito al risultato, e attraverso quale sequenza? A questo fine non basta la trascrizione di una conversazione. Un fascicolo riproducibile collega l’identificativo del caso al modello e alla sua versione, ai parametri di inferenza, alle istruzioni di sistema, al prompt assemblato, ai dati allegati, alla configurazione di recupero, ai documenti selezionati, agli strumenti disponibili, alle chiamate effettuate, alle policy attive e alle decisioni umane.

Occorre inoltre separare i fatti dal meccanismo ipotizzato. Fatto: uno strumento ha ricevuto determinati parametri ed è stata eseguita un’azione registrata. Ipotesi: il modello ha interpretato erroneamente un’istruzione ambigua. Fatto: un operatore ha approvato una raccomandazione. Ipotesi: l’interfaccia non mostrava sufficiente contesto per rilevare l’errore. Questa separazione impedisce che la prima diagnosi diventi il racconto definitivo e consente di esaminare ipotesi alternative, incluse carenze nei dati, nell’integrazione, nell’interfaccia, nella formazione, nei processi umani o fattori esterni.

La riproducibilità completa non sarà sempre possibile. Un servizio esterno potrebbe essere cambiato, un input potrebbe mancare, un risultato potrebbe dipendere dalla casualità o la conservazione dei dati potrebbe essere limitata. In tali casi, il fascicolo deve descrivere con precisione la lacuna, il suo impatto sulle conclusioni e i test sostitutivi utilizzati. L’assenza di riproduzione non dimostra di per sé che il sistema non fosse collegato all’incidente.

La ricostruzione deve comprendere anche le modifiche introdotte durante la risposta. Senza questo registro, un miglioramento successivo potrebbe essere confuso con la configurazione originaria e un risultato sicuro ottenuto dopo il contenimento potrebbe essere presentato erroneamente come prova che l’incidente non fosse possibile. Mantenere la comparabilità fra stato iniziale, stato contenuto e stato corretto è una condizione pratica per apprendere dal caso.

Classificare gravità e nesso causale senza anticipare il verdetto

La classificazione deve iniziare da domande concrete. Vi è stato decesso o grave danno alla salute? La gestione o il funzionamento di infrastrutture critiche ha subito una perturbazione grave e sostenuta? Vi è stata una violazione di obblighi orientati a proteggere i diritti fondamentali? Vi è stato un danno grave a beni o all’ambiente? Per ogni domanda, il fascicolo deve identificare il fatto asserito, le fonti che lo supportano, l’estensione nota, le persone o i beni coinvolti e gli elementi ancora incerti.

Successivamente va analizzato il legame con il sistema. L’articolo 73 non richiede che l’organizzazione attenda una prova causale definitiva se esiste una ragionevole probabilità di relazione, ma non consente nemmeno di usare una semplice coincidenza temporale come sostituto dell’analisi. Devono essere documentati percorsi causali plausibili, prove che li sostengono, fattori alternativi e verifiche ancora pendenti. Per esempio, un output errato può essere rilevante, ma la decisione finale può essere dipesa da una revisione umana indipendente o da dati esterni errati; entrambi gli elementi devono essere indagati.

Una matrice interna di gravità può agevolare l’escalation, ma non deve sostituire la definizione giuridica. È consigliabile che il modulo interno contenga campi distinti per «impatto osservato», «rischio di ulteriore impatto», «potenziale categoria regolatoria», «nesso confermato», «nesso ragionevolmente probabile» e «nesso non stabilito». Questa struttura rende visibile quale parte sia un fatto e quale un’analisi provvisoria.

La decisione secondo cui un caso non raggiunge la soglia deve essere motivata e riesaminabile. Possono emergere nuove informazioni da un deployer, un utente, uno strumento connesso o un’autorità. Chiudere la notifica non equivale a chiudere il fascicolo tecnico né a eliminare le prove.

Fornitore e deployer: coordinare le informazioni, non trasferire il problema

Fornitore e deployer possono disporre di parti diverse della prova. Il fornitore controlla generalmente la documentazione del sistema, le versioni, i test, i registri operativi e le misure correttive del prodotto. Il deployer può conoscere il contesto d’uso, la popolazione interessata, le decisioni umane, i dati locali, le conseguenze materiali e le comunicazioni ricevute. Un contratto può distribuire attività operative, ma non dovrebbe impedire la rapida trasmissione delle informazioni necessarie per rispettare gli obblighi applicabili.

È opportuno predisporre una matrice di contatti e una clausola operativa sugli incidenti prima che si verifichi un caso. Dovrebbero includere interlocutori disponibili fuori orario, categorie minime di informazioni, canali sicuri, termini interni più brevi dei massimi regolatori, regole di conservazione, procedura di approvazione delle comunicazioni e trattamento dei dati protetti. L’obiettivo non è trasferire automaticamente la responsabilità, ma ridurre il tempo tra la conoscenza di un fatto e l’ottenimento degli elementi per valutarlo.

Il deployer deve conservare e fornire i dati sotto il suo controllo che siano necessari, entro i limiti giuridici applicabili. Il fornitore non dovrebbe esigere una riproduzione perfetta come condizione per iniziare la valutazione. Viceversa, il deployer non dovrebbe applicare modifiche locali, cancellare registri o comunicare una causa tecnica come confermata senza coordinare il fascicolo. Quando intervengono più entità, un registro condiviso delle richieste di prova aiuta a distinguere ciò che è stato fornito, ciò che è in sospeso e ciò che non può essere ottenuto.

Gli obblighi di trasparenza, registrazione e cooperazione associati ai sistemi ad alto rischio possono essere rilevanti affinché questo coordinamento funzioni, ma non rendono automaticamente il deployer responsabile della notifica prevista per il fornitore dall’articolo 73. L’attribuzione finale dipende dal ruolo effettivo di ciascuna entità e dalle circostanze del sistema oggetto dell’indagine.

Notifica: gestire i termini senza trasformarli in una formula automatica

L’articolo 73 stabilisce l’obbligo di comunicare gli incidenti gravi alle autorità di vigilanza del mercato degli Stati membri nei quali l’incidente si è verificato, alle condizioni previste dal regolamento. La comunicazione è collegata sia alla conoscenza dell’incidente sia alla determinazione di un nesso causale o della sua ragionevole probabilità. Il team deve quindi registrare separatamente il momento della conoscenza, il momento in cui è stata adottata una conclusione provvisoria sul legame e le prove a sostegno di entrambi i passaggi.

Il regolamento prevede termini massimi di due, dieci e quindici giorni per fattispecie diverse, nonché la possibilità di un rapporto iniziale incompleto seguito da informazioni aggiuntive. L’assegnazione esatta di ciascun termine dipende dalla categoria concreta dell’incidente e dalla formulazione applicabile al caso. Non deve essere dedotta da una tabella interna sintetica o dalla sola gravità tecnica. Il protocollo deve attivare un riesame legale immediato, calcolare il termine da un passaggio documentato e registrare perché sia stato scelto quel termine.

Un rapporto iniziale non deve essere compilato con una certezza artificiale. Se la causa non è nota, occorre indicare che è sotto indagine, descrivere i fatti confermati, l’ambito noto, le misure di contenimento, le prove disponibili e il piano per completare le informazioni. La possibilità di fornire un rapporto incompleto non giustifica il ritardo di una comunicazione richiesta né l’omissione di un’indagine diligente.

Il modello e l’orientamento pubblicati dalla Commissione sugli incidenti gravi sono materiali utili per organizzare campi e sequenze, ma sono presentati come bozze sottoposte a consultazione. Non devono essere trattati come linee guida finali vincolanti. Per un caso reale, il team deve confrontare il contenuto della comunicazione con il regolamento applicabile e con le istruzioni dell’autorità competente.

Indagine, correzione e ripresa controllata

L’indagine non termina con l’invio di una comunicazione. Deve spiegare la causa o le cause contribuenti con un livello di confidenza proporzionato: comportamento del modello, dati in ingresso, recupero, strumento, interfaccia, permessi, configurazione, supervisione umana, formazione, processo operativo o una combinazione. Una sola causa radice può essere una semplificazione fuorviante quando l’incidente dipende da più controlli che hanno fallito o non esistevano.

L’azione correttiva deve essere collegata al percorso di danno identificato. Modificare un prompt può essere insufficiente se il problema era un permesso eccessivo di uno strumento; aggiungere una revisione umana può essere insufficiente se il revisore non riceve i dati necessari; rimuovere un documento può essere insufficiente se il connettore continua a introdurre fonti non autorizzate. Per ciascuna misura, definite quale rischio riduce, quale rischio residuo lascia, quali effetti collaterali potrebbe introdurre e come sarà convalidata.

La convalida deve includere il caso dell’incidente e una regressione più ampia. Testare soltanto la conversazione originaria può favorire una correzione eccessivamente adattata. È preferibile combinare test rappresentativi, casi limite, test dei permessi e flussi completi fino all’azione esterna, oltre a esaminare l’effetto su utenti e gruppi interessati quando pertinente. Conservate risultati, ambiente di test, versioni e criteri di accettazione.

La ripresa non deve essere una decisione implicita adottata chiudendo un ticket. Deve avere un responsabile, criteri di autorizzazione, ambito iniziale, metriche di sorveglianza rafforzata, meccanismo di rollback e condizioni che impongano una nuova sospensione. Se permane un’incertezza rilevante, l’organizzazione può scegliere di mantenere limitata la capacità interessata mentre completa l’indagine. Tale decisione e il suo fondamento devono figurare nel fascicolo.

Preparazione trimestrale: verificare che il protocollo funzioni prima dell’incidente

La capacità di risposta non è dimostrata dalla mera esistenza di registri tecnici o di una policy scritta. Occorre verificare che il team possa recuperare un caso realistico senza dipendere da una sola persona né da strumenti che non conservano i dati necessari. Un’esercitazione trimestrale può selezionare un flusso rischioso, simulare un’allerta e misurare quanto tempo impiega l’organizzazione a identificare la versione distribuita, isolare la capacità interessata, ottenere registri dal deployer e produrre una cronologia con fonti verificabili.

La revisione deve comprendere cambiamenti di fornitori, modelli, strumenti, corpus, permessi, responsabili e mercati di distribuzione. Un protocollo preparato per un modello statico può fallire in presenza di instradamento fra modelli, distribuzioni graduali, recupero dinamico o strumenti di terzi. È inoltre opportuno verificare se gli accordi con clienti e fornitori consentano di condividere rapidamente le prove necessarie, con adeguati controlli di riservatezza e protezione dei dati.

Il risultato di ogni esercitazione deve generare miglioramenti osservabili: campi mancanti nei registri, decisioni prive di responsabile, impossibilità di recuperare configurazioni, assenza di un canale di emergenza o criteri ambigui di sospensione. Non si tratta di dichiarare una conformità generale all’AI Act, ma di ridurre l’incertezza in una risposta concreta a un incidente. La preparazione più utile è quella che consente di dire cosa si sa, cosa non si sa e cosa è stato fatto per evitare che il danno prosegua.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.