Article 73 of the EU AI Act requires providers of high-risk AI systems to report any serious incident to the market surveillance authority of the Member State where it occurred. The report is due immediately once the provider has established a causal link, or the reasonable likelihood of one, between the AI system and the incident, and in any case within 15 days of becoming aware of it. The limit is 10 days if a person died and 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. Those clocks are too short to build an evidence trail after the fact, so the trail has to exist before the incident.
This post covers what counts as a serious incident, who reports, the deadlines, the investigation duty, and what evidence to keep ready. For the response playbook itself, see incident response for AI agent breaches.
When Article 73 applies
Article 73 sits in the post-market monitoring chapter of Regulation (EU) 2024/1689 and applies to high-risk AI systems placed on the EU market. It does not cover every AI incident; a misbehaving internal chatbot that is not high-risk is outside it, although other laws such as GDPR breach notification may still apply.
The timing needs care. The Digital Omnibus, adopted as Regulation (EU) 2026/1744, deferred the Annex III high-risk obligations to 2 December 2027 and the Annex I obligations for AI in regulated products to 2 August 2028; our post on what the Digital Omnibus changed sets out the split. Article 73 itself was not amended and applies from 2 August 2026 under the general rule, but it attaches to systems classified as high-risk. In practice, the reporting duty for a given system starts once the high-risk rules apply to it under those dates, so confirm your system's classification with counsel. The engineering work, a trail good enough to report from, takes longer than the runway either way.
What counts as a serious incident
Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to any of:
- the death of a person, or serious harm to a person's health;
- a serious and irreversible disruption of the management or operation of critical infrastructure;
- an infringement of obligations under Union law intended to protect fundamental rights;
- serious harm to property or the environment.
For agentic systems the "indirectly" matters. An agent that takes a wrong action in a hiring or credit workflow, which then causes a discriminatory outcome, can meet the fundamental-rights limb even though no single call looked dangerous.
Who reports, and the deadlines
The provider reports. A deployer that identifies a serious incident must, under Article 26(5), immediately inform the provider first, and then the importer or distributor and the relevant market surveillance authorities. In practice deployers often see the incident first, so their logs decide how fast the provider can act.
| Situation | Deadline after the provider (or, where applicable, the deployer) becomes aware |
|---|---|
| General rule | Immediately after establishing a causal link or its reasonable likelihood, and no later than 15 days |
| Death of a person | Immediately after establishing or suspecting a causal link, and no later than 10 days |
| Widespread infringement, or serious and irreversible disruption of critical infrastructure | No later than 2 days |
| Information still incomplete | An initial, incomplete report is allowed, followed by a complete report |
Read the deadlines in the article itself before writing them into a runbook; the table is a summary, not legal advice. The Commission is also tasked with issuing guidance on Article 73, so check for the current version.
The investigation duty, and why it constrains you
After reporting, the provider must investigate without delay, including a risk assessment of the incident and corrective action. Article 73 also says the provider must not alter the AI system in a way that could affect a later evaluation of the causes before it informs the authorities.
That creates a real tension for agent teams. The instinct during an incident is to patch the prompt, change the model, or redeploy. Those are changes to the system. Containment, such as suspending the agent or blocking a tool, is usually different from modifying the system, but you need to be able to show what the system looked like at the time. Post-incident forensics for AI agents covers how to preserve that state.
The evidence pack you need before the incident
A report within 2 or 15 days is only possible if the facts can be pulled quickly and trusted. Prepare the following now:
- Agent inventory. Which agents exist, who owns each, which model and version, which tools and data they reach, and whether each is classified as high-risk.
- Event logs. Every action, tool call and policy decision with timestamps, agent identity and outcome. For high-risk systems this overlaps with Article 12 logging.
- Approval records. Which human approved which action, and when.
- Integrity proof. Logs that are hash-chained and signed, so an authority can check they were not changed after the incident. See what makes an audit trail hold up.
- Configuration history. The policies, prompts and tool scopes in force at the time of the incident.
- Contact routes. Which authority in which Member State, and who internally signs off a report.
Article 73 readiness checklist
Where Praesidia fits
Praesidia does not file reports for you, and it is not a high-risk classification tool. It helps with the evidence. It discovers the agents and MCP servers in use, so the inventory exists before you need it. It secures the agent paths routed through it with guardrails that block, redact or warn, human-in-the-loop approvals, and a kill switch, so containment does not require changing the system. And it helps you prove what happened: decisions are recorded in an append-only, hash-chained audit trail, signed under the default configuration, which organisation owners and compliance officers can export for a chosen period and an auditor can verify offline. A signed record shows it was not changed afterwards; it does not show that every action was captured, and calls that do not pass through Praesidia are not recorded.
FAQ
Do deployers report directly to the authority?
A deployer that identifies a serious incident must first inform the provider immediately, then the importer or distributor and the relevant market surveillance authorities, under Article 26(5). Check the exact sequence for your role with counsel.
What if we are not sure the AI system caused the incident?
The 15-day limit runs from awareness, and a reasonable likelihood of a causal link is enough to trigger reporting. File an initial report and complete it as the investigation progresses.
Does Article 73 replace GDPR breach notification?
No. A personal data breach can still require notification under GDPR, with its own 72-hour deadline, alongside any AI Act report.