Il chatbot ha dato a un cliente un'informazione che gli è costata denaro. Il modello di scoring ha respinto sistematicamente una categoria di richiedenti. Il sistema di manutenzione predittiva non ha visto un guasto. Domanda secca: devi segnalarlo a qualcuno? A chi, ed entro quando?
È la parte dell'AI Act che quasi nessuno ha preparato, perché arriva dopo — quando il sistema è già in produzione e qualcosa è andato storto. Ma è anche l'unica in cui i termini si contano in giorni, e in cui il cronometro parte da un momento che dipende da te.
Che cos'è un «incidente grave» ai sensi dell'AI Act
La definizione è nell'Art. 3, punto 49 del Regolamento (UE) 2024/1689: un incidente o malfunzionamento di un sistema di IA che, direttamente o indirettamente, provoca uno dei seguenti esiti:
- la morte di una persona o un grave danno alla salute;
- una perturbazione grave e irreversibile della gestione o del funzionamento di infrastrutture critiche;
- la violazione di obblighi del diritto dell'Unione posti a tutela dei diritti fondamentali (discriminazione, dignità, protezione dei dati);
- un grave danno a cose o all'ambiente.
Due elementi meritano attenzione. Il primo è «indirettamente»: nella bozza di linee guida la Commissione chiarisce che il nesso causale non si interrompe perché in mezzo c'è stata una decisione umana. Se il sistema ha prodotto un'analisi sbagliata e una persona ci ha creduto, l'evento resta imputabile al sistema. Il secondo è la terza lettera: la violazione di diritti fondamentali è la porta d'ingresso più larga, e la più sottovalutata. Un modello che discrimina in modo sistematico è un incidente grave anche se non ha fatto male a nessuno in senso fisico.
Chi segnala cosa, e perché il cronometro parte da te
L'Art. 73 mette l'obbligo di segnalazione in capo al fornitore del sistema ad alto rischio, che deve rivolgersi all'autorità di vigilanza del mercato dello Stato membro in cui l'incidente si è verificato. Ma il termine non decorre da quando lo scopre il fornitore: decorre da quando ne viene a conoscenza «il fornitore o, se del caso, il deployer».
Tradotto: se la tua azienda si accorge del problema il lunedì e avvisa il fornitore il venerdì, ha bruciato cinque dei quindici giorni che il fornitore ha a disposizione.
| Evento | Chi segnala | A chi | Entro |
|---|---|---|---|
| Incidente grave (caso ordinario) | Fornitore | Autorità di vigilanza del mercato | 15 giorni dalla conoscenza |
| Decesso di una persona | Fornitore | Autorità di vigilanza del mercato | 10 giorni |
| Perturbazione di infrastrutture critiche o violazione diffusa | Fornitore | Autorità di vigilanza del mercato | 2 giorni |
| Incidente grave rilevato da chi usa il sistema | Deployer (Art. 26, par. 5) | prima il fornitore, poi importatore/distributore e autorità | immediatamente |
In tutti i casi la segnalazione va fatta «immediatamente dopo» aver stabilito il nesso causale o la sua ragionevole probabilità: i termini sono tetti massimi, non scadenze da consumare. L'Art. 73, par. 5 consente di inviare un rapporto iniziale incompleto, seguito da uno completo — meglio segnalare presto e integrare dopo che arrivare tardi con tutto in ordine. E l'Art. 73, par. 6 aggiunge un vincolo che in azienda viene regolarmente violato per riflesso: il fornitore deve svolgere le indagini necessarie senza alterare il sistema prima di aver informato le autorità. Il primo istinto — «rimettiamolo a posto e poi vediamo» — distrugge le prove.
Ricordiamo infine l'Art. 26, par. 6: chi utilizza un sistema ad alto rischio deve conservare i log generati automaticamente per un periodo adeguato e comunque non inferiore a sei mesi. Senza log non si ricostruisce nulla, e non si dimostra nulla.
Quando scatta davvero, dopo il Digital Omnibus
Qui serve precisione, perché il quadro si è mosso. L'Art. 73 si applica ai fornitori di sistemi ad alto rischio, e il Digital Omnibus — Regolamento (UE) 2026/1744, in vigore dal 27 luglio 2026 — ha rinviato l'applicazione di quel regime: 2 dicembre 2027 per i sistemi «stand-alone» dell'Allegato III, 2 agosto 2028 per quelli integrati in prodotti regolamentati (Allegato I). Le prime segnalazioni ex Art. 73 riguarderanno quindi sistemi che entrano in quel perimetro a partire da quelle date.
Tre precisazioni, però, evitano una lettura troppo rilassata:
- La Commissione aveva costruito bozza di linee guida e modello di segnalazione (pubblicati il 26 settembre 2025, consultazione chiusa il 7 novembre 2025) sull'orizzonte del 2 agosto 2026, e la versione definitiva non è ancora stata adottata. Il quadro operativo è in assestamento: prepararsi ora costa poco, inseguire dopo costa molto.
- Il Digital Omnibus ha introdotto una deroga sul destinatario: i fornitori di sistemi ad alto rischio soggetti alla competenza dell'AI Office segnaleranno a quest'ultimo, che trasmette poi all'autorità nazionale.
- Vigilanza e sanzioni sono pienamente operative dal 2 agosto 2026. In Italia la Legge 132/2025 affida la vigilanza di mercato all'ACN, con poteri ispettivi anche senza preavviso. Per i modelli GPAI con rischio sistemico, poi, l'obbligo di tracciare e segnalare gli incidenti gravi (Art. 55, par. 1, lett. c) è applicabile dal 2 agosto 2025.
Gli obblighi che valgono già oggi
Mentre l'Art. 73 matura, altri tre binari sono già attivi — e un incidente di IA può accenderli tutti insieme.
- GDPR — se l'incidente comporta una violazione di dati personali: notifica all'autorità di controllo entro 72 ore (Art. 33) e comunicazione agli interessati se il rischio è elevato (Art. 34).
- NIS2 — per i soggetti in perimetro (direttiva UE 2022/2555, recepita con il D.lgs. 138/2024): preallarme entro 24 ore, notifica entro 72 ore, relazione finale entro un mese, verso il CSIRT Italia.
- Responsabilità da prodotto difettoso — la direttiva (UE) 2024/2853 va recepita entro il 9 dicembre 2026 e si applica ai prodotti immessi sul mercato dopo tale data. Qualifica espressamente il software, sistemi di IA inclusi, come «prodotto» e introduce un obbligo di divulgazione delle prove in giudizio (Art. 9), con presunzioni a favore del danneggiato quando l'operatore non le produce o quando la prova è eccessivamente difficile per complessità tecnica (Art. 10). È il motivo più concreto per tenere log ordinati: fra pochi mesi saranno la tua difesa, non un costo.
Il piano di risposta minimo, in sei passi
Non serve un impianto da multinazionale. Serve che qualcuno, alle 18 di un venerdì, sappia cosa fare.
- Rileva e datare. Registra data e ora in cui l'azienda è venuta a conoscenza dell'evento: è il momento da cui decorrono i termini.
- Congela le prove. Log, versione del modello, input e output, configurazione. Non modificare il sistema prima di aver informato chi di dovere.
- Contieni. Sospendi l'uso o riportalo sotto supervisione umana piena, come impone l'Art. 26, par. 5 quando il sistema può presentare un rischio.
- Qualifica l'evento. È «grave» ai sensi dell'Art. 3, punto 49? È anche una violazione di dati personali? Rientra nel perimetro NIS2? Le risposte non si escludono.
- Notifica secondo la matrice. Prima il fornitore, poi le autorità competenti, ciascuna con il proprio termine. Meglio un rapporto iniziale incompleto che un silenzio.
- Chiudi il ciclo. Analisi delle cause, misure correttive, aggiornamento dell'inventario dei sistemi di IA e della policy interna, annotazione nel registro degli incidenti.
Da dove partire
Nella maggior parte delle PMI la risposta a «chi chiama chi, e con quale scadenza» oggi non esiste in forma scritta. Un gap assessment indipendente serve esattamente a questo: capire quali sistemi di IA sono in uso, quali finiranno nel perimetro ad alto rischio nel 2027-2028, dove sono i log, chi decide di sospendere un sistema e con quali termini si intreccia il resto della compliance. Sono poche settimane di lavoro, e trasformano un incidente da crisi improvvisata in una procedura da eseguire.