Come creare un registro degli incidenti AI in azienda

Scenario fittizio. Alle 10:17 un team scopre che 6 schede prodotte da un workflow AI citano la versione vecchia di una procedura. Due sono già state usate. La prima reazione è correggere il prompt.

Fermati.

Prima devi impedire altre uscite, conservare ciò che è successo e capire chi potrebbe essere coinvolto. Se modifichi subito prompt, fonti e output, cancelli la scena che ti serve per ricostruire l'errore.

Un registro degli incidenti AI collega evento, impatto, evidenze, contenimento, owner, analisi e decisione di riapertura. Non serve a trovare un colpevole. Serve a evitare 3 frasi inutili: non sappiamo quale versione fosse, pensavamo avesse controllato un altro, ora sembra funzionare.

Noi lo organizziamo sui 3 orologi dell'incidente: fermare, capire, riaprire. Ogni orologio ha una domanda diversa. Se li fai partire insieme, la voglia di riprendere il lavoro vince sulla prova.

Scegli un vocabolario locale

Non esiste una sola etichetta adatta a ogni organizzazione e settore. Definisci un vocabolario operativo prima del primo caso.

Puoi partire così:

Termine locale	Significato operativo	Esempio fittizio
errore intercettato	output errato fermato prima dell'uso	fonte scaduta trovata in review
quasi incidente	condizione che avrebbe potuto produrre una conseguenza	invio esterno bloccato dal gate
incidente	errore o comportamento inatteso con una conseguenza osservata	risposta usata su 2 pratiche
segnalazione	fatto ancora da verificare	utente nota una possibile omissione

Queste sono definizioni di lavoro. Non sostituiscono definizioni normative, di sicurezza o contrattuali applicabili al tuo caso.

L'OECD AI Incidents and Hazards Monitor raccoglie segnalazioni pubbliche per aiutare a osservare rischi e danni. Lo stesso monitor precisa che le informazioni mostrate non rappresentano le vedute ufficiali dell'OCSE o dei Paesi membri. È un buon promemoria: una raccolta di eventi è una base da verificare, non una sentenza automatica.

Orologio 1

Ferma l'uscita

La prima domanda è corta: cosa deve smettere adesso?

Non cercare ancora la causa. Interrompi l'azione che può estendere la conseguenza. Può voler dire mettere in pausa una coda, togliere un template dall'uso, bloccare un'automazione oppure avvisare i reviewer di non approvare nuove uscite.

La decisione deve avere un owner e un timestamp. Abbiamo avvisato il team non basta.

Registra:

incident_id: AI-2026-014
detected_at: 2026-08-15T10:17:00+02:00
detected_by_role: knowledge-owner
workflow_id: WF-SCHEDE-03
version_observed: 2.4
containment_started_at: 2026-08-15T10:24:00+02:00
action_paused: export-to-shared-folder
containment_owner: process-owner

I nomi e gli ID sono fittizi. Nel registro reale minimizza PII e accesso. Chi deve indagare vede le prove necessarie. Non tutto il team deve vedere ogni dato.

Conserva lo stato

Prima di correggere, salva ciò che permette di ripetere il caso: input ripulito, output, riferimenti alle fonti, versione del workflow, prompt hash, modello dichiarato, tool collegati, timestamp, decisioni umane e log disponibili.

Non copiare segreti nel ticket. Registra il riferimento all'archivio protetto e chi può accedervi.

La checklist di verifica degli output AI aiuta a vedere quale controllo ha fallito. Il registro conserva invece la sequenza: cosa è uscito, chi l'ha visto, quando è stato fermato e cosa è cambiato dopo.

Qui tocca resistere alla correzione rapida. Un prompt aggiustato in 2 minuti può far sparire il sintomo e lasciare intatta la causa.

La scheda minima

Un registro utile non è una cartella di screenshot. Ogni evento ha una scheda leggibile senza aprire 14 chat.

Campo	Domanda
evento osservato	cosa è successo, senza interpretazione?
prima evidenza	quale file, output o log lo mostra?
portata nota	quali uscite o persone sono coinvolte finora?
conseguenza	cosa è accaduto davvero?
contenimento	quale azione ha fermato l'estensione?
stato	aperto, contenuto, in analisi, pronto al test, chiuso
owner	chi decide il passaggio di stato?
incognite	cosa non sappiamo ancora?

Scrivi il fatto in una frase osservabile. L'AI ha allucinato è troppo largo. La scheda S-182 cita F07, ma F07 non contiene la data riportata si può verificare.

La portata cambia durante l'analisi. Non riscrivere il passato. Aggiungi una nuova osservazione con data e autore.

Assegna la severità dopo il primo contenimento

La severità non dipende da quanto ha sorpreso il team. Dipende da conseguenza, portata, reversibilità e persone coinvolte.

Una scala locale può avere 4 livelli:

Livello	Conseguenza osservata	Decisione minima
S0	nessuna uscita, errore intercettato	correggere e aggiungere caso di test
S1	uso interno reversibile	owner operativo e verifica del campione
S2	uscita esterna o più record coinvolti	responsabile del processo e piano di comunicazione
S3	possibile danno serio, obbligo o decisione ad alta conseguenza	escalation immediata alla funzione competente

Le etichette sono un esempio. Non sono uno standard NIST e non definiscono obblighi di notifica.

Un quasi incidente può meritare S2 se mostra un gate assente su un'azione difficile da annullare. Un errore già uscito può restare S1 se la conseguenza è limitata, osservata e reversibile. Decide il processo, con competenza adeguata.

Orologio 2

Capisci cosa è successo

Ora la domanda cambia: quale catena ha permesso l'evento?

Separa 4 cose:

Elemento	Esempio fittizio
sintomo	6 schede citano una procedura vecchia
impatto	2 schede usate, 1 decisione riaperta
causa verificata	indice fonti aggiornato senza invalidare la cache
fattore contribuente	review mostrava il titolo, non la data della fonte

Errore umano non è una causa sufficiente. Quale informazione mancava? Quale interfaccia nascondeva il conflitto? Quale gate consentiva l'uscita? Quale responsabilità era ambigua?

NIST AI RMF Manage 4.1 include incident response, recovery e change management nel monitoraggio post-deployment. Manage 4.3 richiama tracciamento, risposta, recupero e comunicazione agli attori pertinenti. Il framework non dice di usare i 3 orologi. Dice però una cosa netta: risposta e recupero fanno parte della gestione, non sono una nota dopo il problema.

Collega causa e correzione

Ogni correzione deve rispondere a una causa o a un fattore contribuente.

Evidenza	Correzione candidata	Prova richiesta
cache non invalidata	invalidazione legata alla versione fonte	vecchia versione non compare dopo update
data nascosta in review	mostra data e scadenza accanto al claim	reviewer intercetta 3 fonti scadute su 3
owner non definito	assegna owner e sostituto	caso con owner assente segue il fallback

Correggere il testo di output senza cambiare il percorso può chiudere il ticket e lasciare aperto l'incidente.

Comunica il fatto giusto

Non tutti ricevono lo stesso messaggio. Il process owner ha bisogno di portata, stato e decisione. Chi è coinvolto può aver bisogno di sapere cosa è successo, cosa fare e quando arriverà un aggiornamento. Il team tecnico ha bisogno di versioni e log.

Evita 2 estremi: silenzio finché non hai una causa perfetta e broadcast confuso con dettagli non verificati.

Usa una formula semplice:

Alle [ora] abbiamo osservato [fatto]. Abbiamo fermato [azione]. La portata confermata è [dato]. Non sappiamo ancora [incognita]. Il prossimo aggiornamento è previsto [quando] da [owner].

Se esistono obblighi legali, contrattuali, di sicurezza o privacy, il percorso viene deciso dalla funzione competente. Questo registro operativo non stabilisce chi notificare né entro quali tempi.

Orologio 3

Riapri con una prova

La domanda finale è diversa: quale evidenza autorizza la ripartenza?

Abbiamo sistemato non è un criterio. Scrivi i test prima di riattivare.

Per lo scenario fittizio:

1. il caso originale usa la versione corretta,
2. 3 fonti scadute vengono fermate,
3. 2 fonti discordanti producono escalation,
4. il reviewer vede ID, data e passaggio,
5. il workflow resta fermo se la cache non si aggiorna.

La riapertura può essere graduale. Prima un caso isolato. Poi un campione interno. Infine il percorso ordinario, se il process owner accetta i limiti residui.

L'onboarding AI in azienda prepara le persone a riconoscere stop ed escalation. Il registro mostra se quel comportamento regge quando il caso non è più un'esercitazione.

Chiudi senza cancellare

Un incidente chiuso conserva scheda, evidenze, decisioni, correzioni, test e rischio residuo. Cambia lo stato. Non sparisce.

Porta il caso ripulito nel test del workflow. Aggiorna il controllo che avrebbe dovuto intercettarlo. Se emerge un rischio nuovo, aggiungilo al registro preventivo.

Il risk register per eventi mostra la logica preventiva in un contesto specifico. Prima dell'evento descrivi trigger, impatto e owner. Dopo un evento osservato, il registro incidenti conserva la sequenza reale e la prova di riapertura.

Un esempio sui 3 orologi

Scenario fittizio: un workflow prepara FAQ interne. Una risposta usa una policy scaduta.

Ora	Passaggio	Evidenza
10:17	segnalazione aperta	output FAQ-91 e fonte F12
10:24	coda fermata	job status paused
10:31	portata iniziale	6 output, 2 usati
11:08	fattore trovato	data fonte non visibile al reviewer
12:26	correzione candidata	scadenza visibile e stop automatico
14:12	test completato	6 casi originali e 5 casi limite
15:03	riapertura limitata	campione interno di 10 output

La tabella non dimostra che la correzione funziona. Collega soltanto decisioni ed evidenze. I risultati dei test restano allegati con il loro hash o riferimento.

Misura il sistema, non la persona

Controlla tempo di rilevazione, tempo di contenimento, eventi per categoria, quasi incidenti, riaperture fallite, cause ricorrenti e percentuale di azioni correttive verificate.

Non trasformare il registro in una classifica di chi sbaglia. Le persone smettono di segnalare ciò che verrà usato contro di loro. Il sistema perde l'evidenza più utile.

Una metrica da osservare: quanti eventi vengono scoperti dal gate previsto e quanti per caso. Se il gate trova 8 errori, sta lavorando. Se nessun gate trova mai niente e gli utenti sì, il controllo va rivisto.

Gli errori che cancellano la prova

• correggere prompt e fonti prima di conservare lo stato,
• usare screenshot senza ID, versione o timestamp,
• chiamare causa il primo sintomo,
• segnare severità in base all'imbarazzo,
• mettere PII e segreti nel ticket,
• chiudere perché l'output ora sembra corretto,
• riaprire senza un caso di regressione,
• comunicare una causa non verificata,
• cancellare un quasi incidente perché non ha prodotto danno.

Il primo evento utile

Prendi l'ultimo output scartato. Scrivi fatto osservato, versione, conseguenza possibile, contenimento e prova che autorizzerebbe la riapertura.

Se non riesci a ricostruire la versione, hai già trovato il primo difetto del sistema.

Porta alla consulenza roadmap e governance AI il workflow e un caso ripulito. Nel percorso Think -> Build -> Enable costruiamo il registro, proviamo il contenimento e trasformiamo l'errore in un test che resta.