Piano di incidenti per i sistemi di IA

Il tuo chatbot inventa una politica di reso, il tuo sistema di scoring nega un credito per un bias non rilevato, o un prompt injection estrae dati dei clienti. Hai un piano? Ti spieghiamo come costruire un piano di incidenti specifico per l’IA con le 6 fasi, i ruoli chiave e un runbook operativo

I piani di risposta agli incidenti IT esistono da decenni. Ogni azienda mediamente seria ha una procedura per rispondere a un server che cade, a una violazione di sicurezza o a una perdita di dati. Ma gli incidenti di IA sono diversi.

Un sistema di IA può guastarsi in modi che nessun piano di incidenti tradizionale contempla: allucinazioni che generano informazioni false nelle comunicazioni al cliente, bias che discriminano sistematicamente un gruppo senza che nessuno se ne accorga, prompt injection che estraggono dati riservati, o degradi graduali delle prestazioni che passano inosservati per settimane.

L’AI Act richiede esplicitamente che i deployer di sistemi ad alto rischio abbiano procedure di gestione degli incidenti. Ma anche per i sistemi a rischio limitato o minimo, un piano di incidenti di IA non è un lusso: è una necessità operativa. Perché quando la tua IA si guasta —e prima o poi succederà—, la differenza tra un incidente minore e una crisi sta nella velocità e nella qualità della tua risposta.

In questo articolo ti spieghiamo i tipi di incidenti specifici dell’IA, le 6 fasi di un piano di risposta, i ruoli che devi definire e come costruire un runbook operativo che il tuo team possa eseguire quando qualcosa va storto.

Tipi di incidenti di IA (e perché sono diversi)

Un incidente di IA non è la stessa cosa di un incidente IT classico. La differenza fondamentale è che molti guasti dell’IA sono silenziosi, progressivi e difficili da rilevare con i tradizionali strumenti di monitoraggio.

Privacy/PII: Accesso non autorizzato a dati personali attraverso il sistema di IA, fuga di dati nelle risposte del modello, uso incompatibile con la finalità dichiarata. Esempio: un chatbot che inserisce i dati di un cliente nella risposta destinata a un altro.
Sicurezza: Prompt injection (manipolazione del modello attraverso input malevoli), esfiltrazione di dati, indisponibilità dell’API del fornitore di IA, compromissione delle credenziali di accesso al modello.
Etica/Contenuti: Bias sistematico rilevato nelle decisioni del modello, generazione di contenuti offensivi o disinformazione, danno reputazionale dovuto a un output inappropriato.
Operativo: Allucinazioni critiche (dati falsi in comunicazioni esterne), errori massivi in batch, degrado graduale della qualità del modello, indisponibilità del servizio.

Ogni tipo di incidente richiede una risposta diversa. Un incidente di privacy attiva obblighi legali (notifica all’autorità entro 72 ore secondo il GDPR). Un incidente etico può richiedere la disattivazione immediata del sistema. Un incidente operativo può risolversi con un rollback a una versione precedente.

Livelli di gravità

Alta: Impatto sui clienti, dati personali compromessi, mancata conformità normativa, danno reputazionale. Azione immediata: contenimento in meno di 2 ore.
Media: Impatto interno rilevante, degrado significativo della qualità, rischio di escalation se non si interviene. Azione: classificazione e contenimento in meno di 8 ore.
Bassa: Incidente circoscritto, senza impatto esterno, rilevato in fase di pilota o in ambiente controllato. Azione: registrazione e correzione nel ciclo successivo.

Il rischio maggiore degli incidenti di IA non è che accadano. È che nessuno se ne accorga finché non è troppo tardi.

Le 6 fasi del piano di risposta agli incidenti di IA

Rilevamento. Il primo passo è sapere che qualcosa non va. Per i sistemi di IA questo richiede: alert automatici (latenza, tassi di errore, accessi anomali), monitoraggio delle metriche di qualità (tasso di allucinazioni, faithfulness se usi il RAG, metriche di bias), un canale di segnalazione per gli utenti interni ed esterni (email, Teams, ticket) e il logging attivo di tutte le interazioni con una conservazione minima di 90 giorni.
Contenimento. Una volta rilevato l’incidente, la priorità è limitare il danno. Le azioni tipiche includono: disattivare l’integrazione del sistema di IA (modalità degradata), limitarne la portata (restringere agli utenti interni, bloccare i canali pubblici), attivare il fallback umano (reindirizzare le richieste agli agenti) e preservare le evidenze (log, screenshot, configurazione al momento dell’incidente).
Notifica. A seconda del tipo di incidente possono attivarsi obblighi legali. Per gli incidenti di privacy con dati personali compromessi: notifica all’autorità per la protezione dei dati entro 72 ore (GDPR), valutazione dell’obbligo di informare gli interessati, comunicazione al DPO e al comitato IA. Per gli incidenti ad alto rischio ai sensi dell’AI Act: registrazione dell’incidente nella documentazione tecnica, comunicazione alle parti interessate.
Eradicazione. Individuare ed eliminare la causa profonda. Può comportare: correggere il prompt di sistema, aggiornare la base di conoscenza (se è RAG), riaddestrare o riconfigurare il modello, applicare una patch a una vulnerabilità di sicurezza o modificare i guardrail del sistema.
Ripristino. Riattivare il servizio in modo controllato: verificare l’integrità del sistema prima della riattivazione, fare un rilascio graduale (prima interno, poi esterno), monitorare in modo intensivo durante le prime 24-48 ore successive al ripristino e confermare che le metriche di qualità tornino entro le soglie definite nella documentazione tecnica.
Lezioni apprese. La fase più trascurata e la più preziosa. Comprende: il report dell’incidente (causa profonda, impatto, tempo di risposta, misure adottate), il post-mortem con i team coinvolti, l’aggiornamento dei controlli preventivi e la revisione del piano di incidenti stesso se sono emerse lacune.

Semaforo: Nel framework di governance dell’IA, un incidente di gravità alta attiva automaticamente il semaforo Rosso (KILL) per quel sistema. Non viene riattivato finché non sono completate le fasi 4 e 5, e la riattivazione richiede l’approvazione dell’AI Steering Committee.

Ruoli chiave: chi fa che cosa quando l’IA si guasta

Un piano di incidenti senza ruoli chiari è un documento inutile. Definisci queste responsabilità prima di averne bisogno:

Product Owner (PO): Responsabile ultimo del sistema. Accountable (A) nella matrice RACI. Approva il contenimento e il ripristino. Comunica agli stakeholder di business.
Sicurezza/CISO: Responsible (R) negli incidenti di sicurezza e privacy. Guida il contenimento, gestisce la forensics, coordina la notifica tecnica.
IT/Piattaforma (on-call): Responsible (R) per continuità e disponibilità. Esegue la modalità degradata, gestisce il rollback, monitora il ripristino.
Legale/DPO: Consulted (C). Valuta gli obblighi di notifica (GDPR 72h, AI Act), gestisce la comunicazione legale, documenta per la documentazione tecnica.
Data Owner/Steward: Consulted (C). Verifica l’integrità dei dati, valuta se la causa profonda sia nei dati di addestramento o nella base di conoscenza.

Il runbook: dalla teoria all’azione eseguibile

Il piano di incidenti definisce il che cosa e il chi. Il runbook definisce il come. È il documento operativo che il tuo team di guardia può seguire passo dopo passo alle 3 del mattino, quando suona l’alert.

Un runbook per gli incidenti di IA deve includere:

Casi coperti: Elenco esplicito degli scenari (indisponibilità dell’API, degrado dell’indice RAG, fuga di credenziali, prompt injection, allucinazione critica, bias rilevato).
Procedura passo dopo passo: Per ogni scenario, i passaggi concreti: quale comando eseguire, quale sistema disattivare, chi chiamare, quale canale usare.
Criteri di escalation: Quando passare da gravità bassa a media e da media ad alta. Quali soglie attivano l’escalation. Chi ha l’autorità per farla scattare.
Evidenze da raccogliere: Estratti dei log, screenshot, configurazione del momento, ticket, comunicazioni. Tutto con marca temporale.
Contatti di emergenza: Nomi, email, telefoni. Non solo quelli interni: anche il contatto del fornitore di IA, il DPO e il contatto dell’autorità di vigilanza se necessario.

Il runbook deve essere pratico, non teorico. Se il tuo team non riesce a seguirlo senza bisogno di spiegazioni aggiuntive, non è finito. La prova migliore: fai una simulazione. Presenta uno scenario fittizio e misura quanto tempo impiega il team a seguire il runbook. Se ci mette più del previsto, rivedi il documento.

Obblighi normativi: AI Act, GDPR e NIS2

Il piano di incidenti di IA non è soltanto una buona pratica. Tre normative europee lo impongono o lo presuppongono:

AI Act: I deployer di sistemi ad alto rischio devono notificare gli incidenti gravi alle autorità e documentare tutti gli incidenti nella documentazione tecnica. L’articolo 26 stabilisce obblighi di post-market monitoring che comprendono la gestione degli incidenti.
GDPR: Se un incidente di IA compromette dati personali, scatta l’obbligo di notifica all’autorità per la protezione dei dati entro 72 ore (art. 33) e, se c’è un rischio elevato per gli interessati, la notifica agli interessati stessi (art. 34).
NIS2: Per i soggetti essenziali e importanti, la direttiva NIS2 richiede piani di risposta agli incidenti di sicurezza con notifica entro 24 ore e un report dettagliato entro 72 ore. Se il tuo sistema di IA fa parte di un’infrastruttura critica, la NIS2 si applica.

Consiglio: Integra il tuo piano di incidenti di IA con il piano di incidenti di sicurezza già esistente. Non ti servono due piani separati: ti serve un piano unificato che copra gli scenari specifici dell’IA con gli stessi SLA e la stessa catena di escalation.

Simulazioni: la prova che il tuo piano funziona

Un piano di incidenti che non è stato provato è una teoria, non un piano. Le simulazioni sono l’unico modo per verificare che il team sappia che cosa fare, che i contatti siano aggiornati, che le procedure siano eseguibili e che i tempi di risposta siano realistici.

Consigliamo almeno due simulazioni all’anno:

Simulazione di allucinazione critica: Scenario: il tuo chatbot di ecommerce ha generato informazioni false sulle politiche di reso nelle ultime 4 ore. Quanto tempo impiega il tuo team a rilevarlo, contenerlo e comunicarlo?
Simulazione di violazione dei dati: Scenario: si rileva che un prompt injection ha fatto sì che il modello esponesse dati dei clienti nelle sue risposte. La notifica GDPR si attiva in meno di 72 ore? Le evidenze vengono preservate?

Dopo ogni simulazione, documenta quanto emerso e aggiorna il piano. Le simulazioni non sono un esame: sono un’opportunità di miglioramento.

Il piano di incidenti dentro il quadro di governance dell’IA

Il piano di incidenti non è un documento isolato. Si integra nell’ecosistema di governance della tua organizzazione:

Documentazione tecnica: La sezione 14 della documentazione tecnica registra tutti gli incidenti e i post-mortem. Ogni incidente chiuso alimenta la documentazione con evidenze e lezioni apprese.
Sistema di Gate: Al Gate 2 (pre-rilascio) si verifica che il piano di incidenti sia definito e che il runbook sia eseguibile. Senza piano di incidenti, il cancello non si apre.
Semaforo GO/FIX/KILL: Un incidente di gravità alta attiva automaticamente il Rosso (KILL). La riattivazione richiede di completare le fasi 4-5 e l’approvazione dell’AI Steering Committee.
FRIA: Se un incidente rivela un rischio non individuato nella FRIA, si innesca una revisione della valutazione d’impatto. Gli incidenti sono trigger di ricategorizzazione.
Policy IA Lite: Il principio di reversibilità si concretizza nella modalità degradata del piano di incidenti. Il principio di osservabilità si concretizza nel logging e nel rilevamento.

Conclusione: prepara la risposta prima di averne bisogno

Il piano di incidenti di IA è uno di quei documenti che speri di non dover mai usare. Ma quando ti serve, sei contento di averlo preparato. La differenza tra un’azienda che gestisce un incidente di IA con professionalità e una che improvvisa sta nella preparazione fatta prima.

Non ti serve un piano perfetto. Ti serve un piano che esista, che il tuo team conosca, che sia stato provato almeno una volta e che venga aggiornato quando le cose cambiano. Con le 6 fasi, i ruoli chiari e un runbook eseguibile, hai le fondamenta.

Se hai bisogno di aiuto per progettare il tuo piano di incidenti di IA, costruire il runbook operativo o realizzare simulazioni con il tuo team, in Impulsa3 ti accompagniamo in tutto il processo.

impulsa3.com · Trasformazione Digitale e IA per PMI ed ecommerce · servicios@impulsa3.com

La risposta operativa si completa con la supervisione umana nell’IA.