Incident Reporting

EU AI Act Article 73 requires providers of high-risk AI systems placed on the EU market to report any serious incident to the market surveillance authority of the Member State where that incident occurred. The reporting timeline depends on severity: immediately and not later than 15 days after becoming aware (or 10 days for fatal incidents or widespread infringements, or 2 days for incidents related to critical infrastructure).

A serious incident under Article 3(49) means an incident or malfunctioning of an AI system that directly or indirectly leads to death, serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of obligations under EU law intended to protect fundamental rights, or serious harm to property or the environment.

This regime parallels established medical-device vigilance under MDR Article 87 and cybersecurity incident reporting under NIS2.

Incident-management platforms (some general-purpose like ServiceNow, some AI-specific like ModelOp, Holistic AI, Credo AI) handle the workflow: detection, triage, root cause, containment, regulator notification, and the post-incident review.

Capabilities to look for:

• Connection to production monitoring (Article 72) so incidents originate from real signals.
• Configurable severity matrix aligned to Article 3(49) definitions.
• Timer-tracked notification workflows so the 2 / 10 / 15 day deadlines do not slip.
• Templates aligned to the Commission's incident-reporting template (once published).
• Stakeholder coordination across DPO, legal, communications, and engineering.

• [ ] Define what constitutes a "serious incident" inside your organization, aligned to Article 3(49).
• [ ] Set up monitoring that can detect the precursors to a serious incident.
• [ ] Establish a clear escalation path with named owners.
• [ ] Time-stamp the moment of awareness and start the Article 73 clock.
• [ ] For widespread infringements, fatal incidents, and critical-infrastructure events, file within the shorter deadlines.
• [ ] Capture the incident, root cause, corrective action, and preventive action in a structured record.
• [ ] Update the risk management system and post-market monitoring plan in response.
• [ ] Coordinate Article 73 notification with parallel obligations under GDPR Article 33 and NIS2.

The first gap is the absence of a clear definition of "becoming aware." Engineering may have seen the issue on day one. Compliance heard about it on day five. The clock starts at "becoming aware" by the relevant person in the relevant function, which most organizations have not specified.

The second gap is treating Article 73 in isolation. Many serious incidents will simultaneously trigger GDPR Article 33 (72-hour personal-data breach notification) and NIS2 incident reporting. The teams running each workflow rarely coordinate, leading to inconsistent narratives going to different regulators.

The third gap is no post-incident loop back into Article 9 risk management. The incident happened. The lesson must change the risk register, the documentation, the controls, and ideally the monitoring. Without that loop, the same incident recurs.

• EU AI Act Article 73: Reporting of Serious Incidents
• EU AI Act Article 3(49): Definition of Serious Incident
• GDPR Article 33: Notification of personal data breach — the parallel personal-data regime.
• NIS2 Directive Article 23 — cybersecurity-incident reporting that often co-applies.
• European Commission AI Office serious-incident reporting template — when published, this is the form to use.