When AI goes wrong: who reports the incident, to whom and by when

The chatbot gave a customer information that cost them money. The scoring model systematically rejected a category of applicants. The predictive maintenance system missed a failure. Blunt question: do you have to report it to anyone? To whom, and by when?

This is the part of the AI Act almost nobody has prepared for, because it comes later — once the system is already in production and something has gone wrong. It is also the only part where deadlines are counted in days, and where the clock starts at a moment that depends on you.

What counts as a 'serious incident' under the AI Act

The definition sits in Article 3(49) of Regulation (EU) 2024/1689: an incident or malfunctioning of an AI system that, directly or indirectly, leads to any of the following:

• the death of a person or serious harm to their health;
• a serious and irreversible disruption of the management or operation of critical infrastructure;
• the infringement of obligations under Union law intended to protect fundamental rights (discrimination, dignity, data protection);
• serious harm to property or the environment.

Two elements deserve attention. The first is 'indirectly': in its draft guidance the Commission clarifies that the causal chain is not broken because a human decision sat in the middle. If the system produced a faulty analysis and a person acted on it, the event is still attributable to the system. The second is the third bullet: infringement of fundamental rights is the widest entry point, and the most underestimated. A model that systematically discriminates is a serious incident even if nobody was physically harmed.

Who reports what, and why the clock starts with you

Article 73 places the reporting duty on the provider of the high-risk system, who must notify the market surveillance authority of the Member State where the incident occurred. But the deadline does not run from the moment the provider finds out: it runs from the moment 'the provider or, where applicable, the deployer' becomes aware.

Translated: if your company spots the problem on Monday and tells the provider on Friday, it has burned five of the fifteen days the provider has.

In every case the report must be made 'immediately after' establishing the causal link or the reasonable likelihood of one: these are ceilings, not budgets to spend. Article 73(5) allows an incomplete initial report followed by a complete one — better to report early and supplement later than to arrive late with everything tidy. And Article 73(6) adds a constraint that companies routinely breach by reflex: the provider must carry out the necessary investigations without altering the system before informing the authorities. The first instinct — 'let's fix it and then see' — destroys the evidence.

Finally, Article 26(6): an organisation deploying a high-risk system must keep the logs automatically generated by it for an appropriate period and in any case no less than six months. Without logs nothing can be reconstructed, and nothing can be proven.

When it actually bites, after the Digital Omnibus

Precision matters here, because the picture has moved. Article 73 applies to providers of high-risk AI systems, and the Digital Omnibus — Regulation (EU) 2026/1744, in force since 27 July 2026 — postponed that regime: 2 December 2027 for 'stand-alone' Annex III systems, 2 August 2028 for those embedded in regulated products (Annex I). The first Article 73 reports will therefore concern systems entering that perimeter from those dates.

Three caveats, though, rule out a relaxed reading:

1. The Commission built its draft guidance and reporting template (published on 26 September 2025, consultation closed on 7 November 2025) around the 2 August 2026 horizon, and the final version has not yet been adopted. The operational framework is still settling: preparing now is cheap, catching up later is not.
2. The Digital Omnibus introduced a derogation on the recipient: providers of high-risk systems under the competence of the AI Office will report to it, and it forwards the information to the national authority.
3. Market surveillance and penalties have been fully operational since 2 August 2026. In Italy, Law 132/2025 assigns market surveillance to ACN, with powers of inspection even without notice. And for GPAI models with systemic risk, the duty to track and report serious incidents (Article 55(1)(c)) has been applicable since 2 August 2025.

The duties that already apply today

While Article 73 matures, three other tracks are already live — and a single AI incident can trigger all of them at once.

• GDPR — where the incident involves a personal data breach: notification to the supervisory authority within 72 hours (Art. 33) and communication to data subjects where the risk is high (Art. 34).
• NIS2 — for in-scope entities (Directive (EU) 2022/2555, transposed in Italy by Legislative Decree 138/2024): early warning within 24 hours, notification within 72 hours, final report within one month, to the national CSIRT.
• Product liability — Directive (EU) 2024/2853 must be transposed by 9 December 2026 and applies to products placed on the market after that date. It expressly qualifies software, AI systems included, as a 'product' and introduces a duty to disclose evidence in proceedings (Art. 9), with presumptions favouring the claimant where the operator fails to produce it or where proof is excessively difficult due to technical complexity (Art. 10). That is the most concrete reason to keep orderly logs: within months they become your defence, not a cost.

The minimum response plan, in six steps

You do not need a multinational's apparatus. You need someone, at 6pm on a Friday, to know what to do.

1. Detect and timestamp. Record the date and time the company became aware of the event: that is when the deadlines start running.
2. Freeze the evidence. Logs, model version, inputs and outputs, configuration. Do not modify the system before informing the relevant parties.
3. Contain. Suspend use or return it to full human oversight, as Article 26(5) requires where the system may present a risk.
4. Qualify the event. Is it 'serious' under Article 3(49)? Is it also a personal data breach? Does it fall within NIS2 scope? The answers are not mutually exclusive.
5. Notify along the matrix. First the provider, then each competent authority with its own deadline. An incomplete initial report beats silence.
6. Close the loop. Root-cause analysis, corrective measures, update of the AI system inventory and the internal policy, and an entry in the incident register.

Where to start

In most SMEs the answer to 'who calls whom, and by when' does not currently exist in writing. An independent gap assessment is designed for exactly this: identifying which AI systems are in use, which will fall inside the high-risk perimeter in 2027-2028, where the logs are, who decides to suspend a system, and how those deadlines interlock with the rest of your compliance. It takes a few weeks, and it turns an incident from an improvised crisis into a procedure you simply execute.