Art. 73 AI Act — il playbook per la notifica degli incidenti gravi

L'articolo 73 dell'AI Act UE (regolamento (UE) 2024/1689) scatta quando un incidente grave coinvolge un sistema di IA ad alto rischio immesso sul mercato dell'Unione, ed è applicabile dal 2 agosto 2026. L'obbligo primario grava sul fornitore del sistema; il deployer eredita gli obblighi di notifica quando è lui a venire a conoscenza dell'incidente.

L'incidente grave è definito dall'articolo 3, punto 49) come un incidente o un malfunzionamento di un sistema di IA che, direttamente o indirettamente, provoca una delle quattro conseguenze seguenti:

• (a) il decesso di una persona o un grave danno alla sua salute;
• (b) una grave e irreversibile perturbazione della gestione o del funzionamento di un'infrastruttura critica (come definita dalla direttiva (UE) 2022/2557);
• (c) la violazione di obblighi previsti dal diritto dell'Unione a tutela dei diritti fondamentali;
• (d) un grave danno a cose o all'ambiente.

Stabilire in quale delle quattro categorie ricade l'incidente non è un esercizio di etichettatura: determina la scadenza di notifica (sezione successiva). Cosa non rientra qui: i malfunzionamenti ordinari che non raggiungono la soglia dell'art. 3, punto 49); e due eccezioni in cui si notificano solo gli incidenti di categoria (c) — i sistemi di IA immessi sul mercato come parte di dispositivi medici ai sensi dei regolamenti (UE) 2017/745 e 2017/746, e i sistemi già soggetti a obblighi equivalenti durante i test in condizioni reali. Gli incidenti gravi relativi a modelli di IA per finalità generali con rischio sistemico seguono un canale proprio verso l'Ufficio IA e sono fuori dall'ambito di questo playbook.

Ogni scadenza si conta dal momento in cui vieni a conoscenza dell'incidente e inizia a decorrere una volta stabilito un nesso causale — o la sua ragionevole probabilità — tra il sistema di IA e il danno. Le autorità confronteranno la data di conoscenza che dichiari con i tuoi log e i tuoi alert: registrala al primo segnale credibile.

Non c'è una sola scadenza, ma tre, legate alla categoria dell'art. 3, punto 49):

• 2 giorni — per una grave e irreversibile perturbazione di un'infrastruttura critica (categoria (b)) o per una violazione diffusa. Notifica immediatamente e comunque non oltre due giorni dalla presa di conoscenza.
• 10 giorni — quando l'incidente ha causato il decesso di una persona. Notifica subito dopo aver stabilito (o non appena sospetti) il nesso causale, e comunque non oltre 10 giorni.
• 15 giorni — il caso generale per tutti gli altri incidenti gravi. Notifica subito dopo aver stabilito il nesso causale, e comunque non oltre 15 giorni dalla presa di conoscenza.

La notifica non deve essere completa al primo invio. L'art. 73, par. 5, consente una prima notifica incompleta entro la scadenza, da integrare successivamente con una relazione completa: una causa radice ancora ignota non è mai un motivo per mancare il clock.

La prima finestra ruota attorno a due decisioni e un divieto.

Decidi la categoria. Confronta l'incidente con le quattro conseguenze dell'art. 3, punto 49), e scegli quella applicabile: determina se sei sul clock di 2, 10 o 15 giorni. Se ne ricorre più di una, vale la scadenza più breve.

Stabilisci il nesso causale. Il clock decorre dal nesso causale tra sistema di IA e danno, non dal danno in sé. Documenta come sei arrivato a tale determinazione (o perché è ragionevolmente probabile): questo memo è la spina dorsale della relazione finale.

Non modificare il sistema. L'art. 73, par. 6, è esplicito: prima di informare le autorità non devi modificare il sistema di IA in alcun modo che possa incidere su una successiva valutazione delle cause. Ciò confligge con l'istinto del SOC di applicare subito una patch o un rollback del modello. Congela prima lo stato del sistema e la versione del modello; prima raccogli, poi rimedia.

Checklist della prima finestra:

• Registro cronologico dell'incidente avviato, con il timestamp del primo segnale.
• Categoria dell'art. 3, punto 49), assegnata, così la scadenza è nota.
• Memo di determinazione del nesso causale redatto.
• Stato del sistema e versione del modello congelati e con hash prima di qualsiasi modifica.
• DPO e ufficio legale informati in parallelo (possono decorrere anche i clock GDPR / NIS2 / DORA).

Si notifica all'autorità di vigilanza del mercato dello Stato membro in cui è avvenuto l'incidente — non alla Commissione e non automaticamente alla tua autorità garante. Individua prima quell'autorità; per un incidente transfrontaliero vale il luogo in cui si è verificato.

La Commissione ha pubblicato il 26 settembre 2025 una bozza di linee guida e un modello standard di segnalazione per l'art. 73 (consultazione sulle linee guida per gli incidenti gravi AI Act) — l'Incident report for serious incidents under the AI Act (High-risk AI systems) — con consultazione chiusa il 7 novembre 2025 e versione definitiva attesa in applicazione dalla data di avvio del 2 agosto 2026. Costruisci da subito la tua relazione interna sui campi di quel modello: è pensato per armonizzare ciò che ricevono tutte le autorità di vigilanza del mercato ed è allineato all'OECD AI Incidents Monitor e al Common Reporting Framework.

Checklist di invio:

• Autorità di vigilanza del mercato corretta individuata (Stato membro del luogo dell'incidente).
• Relazione redatta sui campi del modello della Commissione.
• Categoria, determinazione del nesso causale e identificazione del sistema coinvolto incluse.
• Prima notifica inviata entro la scadenza di 2/10/15 giorni, anche se incompleta.
• Notifiche parallele registrate (vedi note multi-regime).

L'invio della prima notifica non chiude l'obbligo. L'art. 73, par. 6, impone al fornitore di indagare senza indugio, con una valutazione del rischio dell'incidente e un'azione correttiva, e di cooperare con le autorità competenti (e, ove pertinente, con l'organismo notificato). Solo dopo aver informato le autorità puoi apportare modifiche che inciderebbero su una successiva valutazione.

Attività di chiusura:

• Completa la relazione eventualmente inviata come prima/incompleta, con la causa verificata e l'azione correttiva adottata.
• Annota l'azione correttiva nella documentazione tecnica del sistema (il fascicolo Allegato III / artt. 9-19 del sistema ad alto rischio).
• Conserva lo stato del sistema congelato prima della modifica insieme alla versione dopo la remediation, così da rendere dimostrabile il prima/dopo.
• Ricorda che l'autorità nazionale competente informa la Commissione e, a valle, le autorità pubbliche nazionali interessate: la tua notifica è il documento di partenza di questa catena.

Mettile insieme una volta sola: ogni notifica a valle è una vista diversa dello stesso documento. Ordinale secondo il gate che le consuma:

• Cronologia dell'incidente con il timestamp del primo segnale (l'evidenza della data di conoscenza).
• Memo di determinazione del nesso causale — come hai collegato il sistema di IA al danno.
• Stato del sistema e versione del modello congelati (con hash), acquisiti prima di qualsiasi remediation.
• Documentazione tecnica del sistema ad alto rischio (fascicolo artt. 9-19 / Allegato III) che attesta finalità previste, limiti noti e registro di gestione del rischio.
• Log operativi del sistema di IA sulla finestra dell'incidente più i giorni precedenti.
• Registro delle azioni correttive con timestamp e nome di chi le ha approvate.
• Registro delle comunicazioni (autorità, soggetti interessati, interno).

L'errore ricorrente è ricomporre queste evidenze a mano, da strumenti diversi, nel pieno di un clock serrato — e una cronologia modificata a posteriori è esattamente ciò che un'autorità di vigilanza andrà a sondare. I team che producono evidenze firmate al momento della scrittura, in continuo, riducono il lavoro a esporta-rivedi-firma-invia. L'apparato on-premise Zero Hunt lo fa per costruzione: ogni voce della catena di evidenze è firmata al momento della scrittura e il Trust Center esporta un pacchetto pronto per l'auditor, per singolo regime — e poiché l'engine mappa l'AI Act tra i 34 framework di conformità coperti, la vista per l'art. 73 è una delle esportazioni e non una corsa improvvisata.

Schemi osservati in organizzazioni analoghe in preparazione all'avvio del 2 agosto 2026:

• Trattarlo solo come incidente GDPR o NIS2. L'AI Act ha un clock e un'autorità propri; una notifica ex art. 33 GDPR alla tua autorità garante non assolve l'art. 73.
• Applicare una patch al modello prima di informare le autorità. Viola l'art. 73, par. 6, e può distruggere l'evidenza della causa. Prima congela.
• Classificare male la categoria dell'art. 3, punto 49). Chiamare 'generale' una perturbazione di infrastruttura critica ti mette sul clock di 15 giorni quando la legge te ne dava 2: una violazione grave, non una svista formale.
• Non sapere quale autorità di vigilanza del mercato. In molti Stati membri l'autorità per l'AI Act è di nuova designazione e non coincide con l'autorità garante: individuala prima dell'incidente, non durante.
• Documentazione tecnica non pronta. Senza il fascicolo artt. 9-19 non puoi evidenziare in modo credibile il nesso causale né la finalità prevista del sistema, e la relazione si blocca.

Un singolo guasto di un sistema di IA fa scattare spesso più regimi, ciascuno con il suo clock e la sua autorità:

• Art. 23 NIS2 (24h / 72h / 1 mese) quando il soggetto è essenziale o importante.
• Art. 33 GDPR (72h) quando sono coinvolti dati personali.
• DORA, notifica degli incidenti gravi quando il soggetto è nel settore finanziario.
• Regimi settoriali (dispositivi medici, ecc.) che, per gli incidenti di categoria (c), possono sostituire del tutto la notifica ex art. 73.

La bozza di linee guida della Commissione affronta esplicitamente l'interazione con gli altri regimi di notifica e cerca l'allineamento con i framework internazionali. La conseguenza pratica è la stessa di ogni regime di incidente: costruisci un'unica base di evidenze ed esporta una sintesi diversa per ciascun regolatore, invece di gestire percorsi di evidenze paralleli sotto quattro clock simultanei.