Un incidente causato da un agente AI comprime il normale ciclo di risposta. Il sistema può proporre un'altra chiamata allo strumento, aggiornare una credenziale o avviare un'altra corsa mentre il team sta ancora aprendo un ponte. Questo manuale fornisce al comandante dell'incidente un percorso ordinato: contenere la capacità attiva, preservare la documentazione, ripristinare una versione valida, riconciliare gli effetti collaterali e prendere la decisione di riferire in base a fatti verificati. Associa le prove all'articolo 73 della legge sull'intelligenza artificiale dell'UE senza dare per scontato che ogni agente o incidente rientri in tale disposizione. Solo informazioni operative generali; un consulente qualificato dovrebbe confermare l'ambito legale, le scadenze e le notifiche.
Apri un incidente e avvia gli orologi
Il Profilo AI generativa del NIST raccomanda una proprietà definita, prove regolari, miglioramenti retrospettivi e l'allineamento con la segnalazione delle violazioni, la privacy e altre leggi per i piani di incidenti di AI generativa di terze parti. Revisione 3 del NIST SP 800-61 integra la risposta agli incidenti nelle fasi di preparazione, rilevamento, risposta e ripristino.
Dichiarare un record di incidente prima che i soccorritori effettuino modifiche parallele. Registrare il primo momento di rilevamento, il tempo di sensibilizzazione, il sistema interessato e il rilascio, il comportamento osservato, gli effetti collaterali noti, le persone colpite, gli ambienti, gli agenti e le identità umane e la fonte di ciascun fatto. Mantieni asserzioni, ipotesi e decisioni come campi separati.
Assegna quattro ruoli con nome. Il comandante dell'incidente possiede la sequenza e il contenimento. Il proprietario del sistema gestisce l'agente e i servizi a valle. Il responsabile delle prove conserva i record e la sequenza temporale dell'azione. Il titolare legale decide l'ambito della notifica e si coordina con i team di consulenza, privacy, sicurezza e settore.
- Proprietario gravità: imposta il livello di impatto attuale e l'orario di revisione successivo
- Termine di contenimento: imposta l'ultimo tempo accettabile affinché ogni attuatore kill-switch possa riconoscere
- Proprietario della prova: registra la fonte, l'ora di raccolta, lo stato di integrità e la custodia di ogni artefatto
- Proprietario segnalante: registra ogni possibile regime, trigger legale, autorità, orologio e decisione
Preservare prove volatili prima di cambiamenti ampi
Acquisisci lo stato volatile all'inizio del contenimento: identificatori di esecuzione attiva, lavori in coda, richieste di decisioni aperte, identità di processi e carichi di lavoro, versione corrente, versione di modello e prompt, versione di policy, identificatori di credenziali, connessioni di rete, registro delle chiamate agli strumenti e ID di richieste downstream. Sigillare l'orario di ritiro e l'identità del collezionista.
Per un incidente grave coperto, l'articolo 73(6) della legge UE sull'IA impone al fornitore di indagare, valutare il rischio e adottare azioni correttive. Richiede inoltre al fornitore di informare le autorità competenti prima di modificare il sistema di IA in un modo che possa influenzare una successiva valutazione delle cause dell'incidente. L'avvocato dovrebbe decidere quando si applica tale condizione. Il playbook dovrebbe rendere esplicito il punto di controllo della conservazione delle prove in modo che il contenimento e la conservazione normativa possano procedere insieme.
Copia i log rilevanti in un archivio controllato dagli incidenti con protezione della conservazione. Conserva i record grezzi e crea sequenze temporali derivate separatamente. Gli hash e le firme possono mostrare se i file raccolti sono cambiati dopo l'acquisizione; non possono provare che una fonte omessa non sia mai esistita, quindi il manifesto della raccolta deve elencare le fonti previste e quelle mancanti.
Contenere la capacità
Richiama l'architettura kill-switch dell'agente AI nell'ambito più ristretto che contiene il comportamento osservato. Espandi all'agente, alla versione, al tenant o all'ambiente man mano che i fatti cambiano.
Il contenimento termina quando ogni attuatore richiesto riconosce o il comandante dell'incidente registra un sostituto manuale. Uno stato verde dal servizio flusso di lavoro non può stabilire il contenimento per token, lavori downstream in coda o un lavoratore in esecuzione all'esterno di quel servizio.
| Bersaglio | Azione | Fatto necessario per il contenimento |
|---|---|---|
| Percorsi attivi e recintati | Invia l'annullamento, chiudi le richieste di decisione in sospeso e nega i successivi tentativi di ripresa | Stato terminale e ultimo effetto collaterale impegnato per ogni esecuzione |
| Percorso politico | Installare un blocco con ambito incidente su ogni strumento e cancello di uscita | Versione della policy, prima azione negata e comportamento di chiusura in caso di errore |
| Identità dell'agente | Disabilita l'identità, revoca i token, impedisci l'aggiornamento e ruota i segreti esposti | Finestra di accesso residuo e risultato per ogni classe di credenziali |
| Carico di lavoro | Interrompere o mettere in quarantena l'elaborazione e limitare l'uscita | Inventario del carico di lavoro e riconoscimento dell'isolamento |
| Code e lavori a valle | Annulla il lavoro in sospeso ed elenca le richieste già impegnate | Stato terminale o compensativo per ogni richiesta accettata |
| Accesso ai dati | Congelare i percorsi di scrittura interessati e conservare gli snapshot ove autorizzato | Negozi coperti, ora dello snapshot e scritture osservate dopo la dichiarazione |
Ripristinare il sistema e riconciliare gli effetti
Scegliere il punto di ripristino dalle prove. Registra l'ultima versione valida, il policy pack, il modello e la versione del prompt, il manifest dello strumento, la configurazione del connettore e la generazione del segreto. Verificarne la provenienza prima della promozione.
Un rollback della versione ripristina i byte e la configurazione distribuiti precedenti. Non può richiamare un'e-mail, annullare un trasferimento completato, ripristinare un record esterno eliminato o ritirare dati già divulgati. Aprire una voce di compensazione specifica del sistema per ogni effetto impegnato e assegnare un proprietario e una scadenza.
Attiva il ripristino con nuove credenziali e una lista consentita specifica per l'incidente. Esegui un canary controllato con la negazione dell'incidente ancora attiva per le versioni precedenti interessate. Rilasciare un traffico più ampio solo dopo che il canarino avrà prodotto le decisioni politiche, gli effetti collaterali e le prove attesi.
- Rilascio: ripristina l'artefatto precedente verificato e conserva l'artefatto guasto per l'analisi
- Politica: ripristina la policy precedente verificata mantenendo la negazione con ambito incidente con precedenza più elevata
- Identità: emettere nuove credenziali con una nuova generazione e l'ambito minimo richiesto
- Stato: ripristino da un'istantanea autorizzata solo dopo che il responsabile della prova ne ha registrato la provenienza e l'impatto
- Effetti esterni: compensa, notifica o correggi manualmente ogni azione commessa attraverso il sistema proprietario
- Monitoraggio: aumentare il campionamento e l'avviso per la Release recuperata e definire la soglia di uscita
Costruire il record delle prove dell'incidente
Il record dovrebbe consentire a un revisore indipendente di ricostruire l'evento senza leggere la trascrizione della chat o chiedere agli intervistati di ricordarlo. Conserva la sequenza degli eventi di origine e allega le decisioni come record separati e firmati.
Nel piano di controllo KLA, Lineage Explorer ricostruisce l'esecuzione dell'agente, Audit Trail conserva le azioni di governance e dell'operatore e Evidence Room impacchetta i record selezionati come Sealed Evidence Bundle. Questi percorsi sono implementati nell'ambiente di sviluppo KLA, che è l'unico ambiente attualmente eseguito da KLA. Il pacchetto necessita ancora di un manifesto della raccolta che indichi le fonti previste, le fonti mancanti e l'ambito scelto dal proprietario della prova.
| Gruppo di prove | Campi obbligatori | Risposta alla domanda |
|---|---|---|
| Rilevamento | Segnale, soglia, sorgente, primo tempo di osservazione, primo triage, decisione consapevole | Come e quando l'organizzazione lo ha saputo |
| Esecuzione | Esegui, agente, rilascio, modello, prompt, chiamate allo strumento, argomenti, output, effetti collaterali | Quale capacità ha agito e cosa è cambiato |
| Governo | Versioni delle policy, decisioni, richieste di decisione, approvatori, ruoli, hash degli argomenti | Quali controlli hanno valutato ogni azione consequenziale |
| Contenimento | Comando, ambito, attore, riconoscimenti, effetto collaterale finale, esposizione rimanente | Quando si è fermata la capacità? |
| Recupero | Provenienza nota, Rollback, canary, nuova identità, elementi di compensazione | Come è stato ripristinato il funzionamento sicuro |
| Segnalazione | Regimi applicabili, analisi dei fattori scatenanti, valutazione causale, decisione del difensore, osservazioni | Perché, quando e dove è stato segnalato l'incidente |
Associare i fatti all'articolo 73 della legge dell'UE sull'IA
Il testo ufficiale della legge sull'IA dell'UE limita l'articolo 73 ai fornitori di sistemi di IA ad alto rischio immessi sul mercato dell'Unione. L'articolo 3(49) definisce un incidente grave come un incidente o un malfunzionamento che provoca direttamente o indirettamente la morte o un danno grave alla salute, un'interruzione grave e irreversibile delle infrastrutture critiche, una violazione degli obblighi del diritto dell'Unione che tutelano i diritti fondamentali o un danno grave alla proprietà o all'ambiente.
Il Digital Omnibus sull'intelligenza artificiale, regolamento (UE) 2026/1744, entrato in vigore il 27 luglio 2026., ha modificato le date di applicazione dei requisiti ad alto rischio del capo III in 2 dicembre 2027 per i sistemi dell'allegato III e 2 agosto 2028 per i sistemi dell'allegato I. Le finestre di segnalazione dell'articolo 73 rimangono invariate. L'interazione tra classificazione del sistema, ruolo di fornitore o operatore, diritto di settore, date di transizione e articolo 73 richiede una decisione giuridica specifica per il caso.
Registra quella decisione con i fatti disponibili in quel momento. Un evento di sicurezza che non rientra nel campo di applicazione dell'articolo 73 può richiedere un'azione nell'ambito di un altro regime.
| Fornitura | Regola statutaria | Registro del playbook |
|---|---|---|
| Articolo 73(1) | Un fornitore di un sistema di IA ad alto rischio immesso sul mercato dell’Unione segnala un incidente grave alle autorità di vigilanza del mercato degli Stati membri in cui si è verificato | Classificazione del sistema, identità del fornitore, posizionamento sul mercato, Stati membri, autorità |
| Articolo 73(2) | Segnalare immediatamente dopo aver stabilito un nesso causale o una ragionevole probabilità che ciò accada, con un tetto massimo di 15 giorni dopo la conoscenza | Tempo di sensibilizzazione, versioni di valutazione causale, tempo di segnalazione, motivo del tempo trascorso |
| Articolo 73(3) | Una violazione diffusa o un'interruzione grave e irreversibile delle infrastrutture critiche ha un limite massimo di due giorni dalla presa di coscienza | Categoria di impatto, ambito geografico, tempo di sensibilizzazione, scadenza di due giorni |
| Articolo 73(4) | Una morte viene segnalata immediatamente dopo che la causa è stata stabilita o sospettata, con un tetto massimo di 10 giorni dopo la conoscenza | Danno noto, tempo del sospetto, prova causale, scadenza di dieci giorni |
| Articolo 73(5) | Un rapporto iniziale incompleto può essere seguito da un rapporto completo quando necessario per tempestività | Invio iniziale, lacune note, proprietario dell'aggiornamento, destinazione del report completo |
| Articolo 73(6) | Il fornitore indaga, valuta il rischio, intraprende azioni correttive, collabora e informa le autorità prima di un cambiamento che potrebbe influenzare la successiva valutazione della causa | Piano di indagine, stato preservato, azioni correttive, contatto con l'autorità prima della modifica materiale |
| Articolo 26(5) | Un operatore che identifica un incidente grave informa immediatamente prima il fornitore, poi l’importatore o il distributore e le autorità di vigilanza del mercato competenti | Analisi del ruolo, tentativi di contatto, ordine di notifica, percorso del fornitore non raggiungibile |
Utilizzare una sequenza operativa 24-ora
Impostare il ritmo di risposta interna ben entro i limiti di reporting previsti dalla legge in modo che la revisione legale riceva fatti verificati mentre le prove sono ancora disponibili.
| Tempo trascorso | Obiettivo primario | Esci dalle prove |
|---|---|---|
| Da 0 a 15 minuti | Dichiara l'incidente, assegna ruoli, imposta l'ambito di negazione, invoca il kill switch | ID incidente, tempo di consapevolezza, comando, stato dell'attuatore |
| Da 15 a 60 minuti | Preserva lo stato volatile, revoca l'identità, isola il carico di lavoro, individua l'ambito del lavoro a valle | Manifesto della raccolta, risultato delle credenziali, effetto collaterale finale noto |
| Da 1 a 4 ore | Seleziona stato noto, Rollback, elementi di compensazione aperti, esegui canary controllato | Provenienza del recupero, esito canarino, registro compensi |
| Da 4 a 8 ore | Ricostruire l'evento e classificare danno, ruolo, geografia e possibili regimi | Cronologia con versione, valutazione dell'impatto, elenco delle questioni legali |
| Da 8 a 24 ore | Approvare le notifiche, emettere il primo aggiornamento di stato, definire il piano di monitoraggio e indagine | Decisione di reporting, proposte, aggiornamento delle parti interessate, prossima revisione |
Prova le lacune che appaiono sotto pressione
NIST AI RMF Gestisci le chiamate 4 per piani di risposta, ripristino e comunicazione documentati e monitorati. Il piano di monitoraggio post-market dovrebbe fornire le soglie, la proprietà e i feed di prove che aprono questo playbook.
Esegui esercizi per un'esecuzione attiva, un'attesa di approvazione, una credenziale rubata, un effetto collaterale esterno impegnato, un'origine registro mancante, un fornitore irraggiungibile e un esportatore di prove non disponibile. Registrare il tempo di contenimento, l'effetto collaterale finale post-comando, i riconoscimenti mancanti, la completezza delle prove, il tempo di recupero e il tempo di decisione del rapporto.
Utilizza la guida all'Accountable Autonomy per confermare che la supervisione ordinaria e l'autorità di emergenza hanno nominato i proprietari. Consulta la procedura dettagliata sull'incidente di Hugging Face per un esempio pubblico di azione a velocità macchina, raccolta di credenziali, movimento laterale e ricostruzione da più di 17,000 eventi registrati.
Domande frequenti
Qual è la prima azione in un incidente con un agente AI?
Dichiarare un incidente, assegnare il comandante dell'incidente, il proprietario del sistema, il responsabile delle prove e il proprietario legale, registrare il tempo di sensibilizzazione e impostare l'ambito interessato per negare. Richiama gli attuatori kill-switch preservando l'esecuzione volatile, l'identità, la policy e lo stato downstream.
Come possiamo contenere un agente IA canaglia?
Annulla le esecuzioni attive e controllate, nega le chiamate di nuovi strumenti in un punto di applicazione esterno, disabilita l'identità dell'agente, revoca e ruota le credenziali, isola il carico di lavoro, annulla il lavoro in coda e downstream e mantieni l'incidente aperto finché ogni attuatore richiesto non conferma.
Cosa significa rollback per un incidente dell'agente AI?
Ripristina la versione precedente verificata, la policy, il modello, il prompt, il manifesto dello strumento e la configurazione del connettore con nuove credenziali. Tieni traccia di ogni effetto collaterale esterno commesso attraverso una procedura di compensazione, correzione o notifica specifica del sistema.
Quando l'articolo 73 della legge sull'IA dell'UE richiede una segnalazione?
L'articolo 73 riguarda i fornitori di sistemi di IA ad alto rischio immessi sul mercato dell'Unione quando si verifica un incidente grave ai sensi dell'articolo 3(49). L’orario e l’autorità di segnalazione dipendono dalla valutazione causale, dal tipo di incidente, dallo Stato membro, dal ruolo, dalla sovrapposizione di settori e dalle attuali date di applicazione. Un consulente qualificato dovrebbe confermare l’obbligo specifico del caso.
Quali sono le scadenze per la rendicontazione dell'articolo 73?
L'articolo 73 stabilisce la segnalazione immediata dopo che viene stabilito un nesso causale o una ragionevole probabilità, con un tetto massimo di 15-giorni dopo la conoscenza. Una violazione diffusa o un'interruzione grave e irreversibile delle infrastrutture critiche ha un limite massimo di due giorni. Una morte ha un limite massimo di dieci giorni e un trigger immediato quando viene stabilita o sospettata la causalità. Una relazione iniziale incompleta è consentita quando necessario per tempestività.
Quali prove dovrebbe contenere un record di incidente dell'agente AI?
Conserva i tempi di rilevamento e consapevolezza, identificatori di esecuzione e rilascio, versioni di modello e prompt, chiamate a strumenti, argomenti, decisioni politiche, approvazioni, effetti collaterali, comando e riconoscimenti di contenimento, modifiche delle credenziali, registri conservati, provenienza del rollback, risultati della compensazione, analisi legale e report.
Punti chiave
Un forte playbook dell'incidente stabilisce il controllo prima che la squadra cerchi di spiegare l'evento. Interrompere la funzionalità, preservare lo stato, ripristinare una versione verificata, riconciliare ogni effetto impegnato e prendere la decisione di reporting da un record di prova con versione. Collega il playbook al monitoraggio post-commercializzazione e provalo fino a quando il tempo di contenimento, la completezza delle prove e lo stato di recupero non saranno fatti misurati.