EU AI Act Article 73 — the serious-incident reporting playbook

Article 73 of the EU AI Act (Regulation (EU) 2024/1689) fires when a serious incident involves a high-risk AI system that has been placed on the Union market, and it becomes enforceable on 2 August 2026. The primary obligation sits with the provider of the system; the deployer inherits reporting duties where it is the party that becomes aware of the incident.

A serious incident is defined in Article 3(49) as an incident or malfunctioning of an AI system that directly or indirectly leads to one of four outcomes:

• (a) the death of a person, or serious harm to a person's health;
• (b) a serious and irreversible disruption of the management or operation of critical infrastructure (as defined in Directive (EU) 2022/2557);
• (c) the infringement of obligations under Union law intended to protect fundamental rights;
• (d) serious harm to property or the environment.

Which of the four your incident falls under is not a labeling exercise — it sets your filing deadline (next section). What is not in scope here: ordinary malfunctions that do not reach the Article 3(49) threshold; and two carve-outs where only category (c) incidents are notified under this article — AI systems placed on the market as part of medical devices under Regulations (EU) 2017/745 and 2017/746, and AI systems already subject to equivalent reporting duties during real-world testing. Serious incidents involving general-purpose AI models with systemic risk follow their own channel to the AI Office and are out of scope for this playbook.

Every deadline counts from the moment you become aware of the incident, and begins to bind once you have established a causal link — or a reasonable likelihood of one — between the AI system and the harm. Supervisors will test the awareness date you claim against your own logs and alerts, so record it at the first credible signal.

There is not one deadline but three, keyed to the Article 3(49) category:

• 2 days — for a serious and irreversible disruption of critical infrastructure (category (b)) or a widespread infringement. Report immediately, and not later than two days after becoming aware.
• 10 days — where the incident led to a person's death. Report immediately after establishing (or as soon as you suspect) the causal relationship, and not later than 10 days.
• 15 days — the general case for all other serious incidents. Report immediately after establishing the causal link, and not later than 15 days after becoming aware.

The report does not have to be complete on first filing. Article 73(5) lets you file an initial, incomplete report inside the deadline and follow it with a complete report afterwards — so a missing root cause is never a reason to miss the clock.

The first window is about two decisions and one prohibition.

Decide the category. Walk the incident against the four Article 3(49) outcomes and pick the one that applies — it determines whether you are on the 2-, 10- or 15-day clock. When more than one applies, the shortest deadline governs.

Establish the causal link. The clock binds on the causal link between the AI system and the harm, not on the harm alone. Document how you reached that determination (or why it is reasonably likely) — this memo is the spine of the eventual report.

Do not alter the system. Article 73(6) is explicit: before informing the authorities, you must not change the AI system in any way that could affect a later evaluation of the causes. This directly conflicts with the SOC instinct to patch or roll back the model immediately. Freeze the system state and the model version first; capture, then remediate.

First-window checklist:

• Incident timeline started, with the first-signal timestamp recorded.
• Article 3(49) category assigned, so the deadline is known.
• Causal-link determination memo drafted.
• System state and model version frozen and hashed before any change.
• DPO and legal notified in parallel (GDPR / NIS2 / DORA clocks may also be running).

You report to the market surveillance authority of the Member State where the incident occurred — not to the Commission, and not automatically to your lead data-protection authority. Identify that authority first; for a cross-border incident, the place of occurrence governs.

The Commission published draft guidance and a standard reporting template for Article 73 on 26 September 2025 (AI Act serious-incident guidance consultation) — the Incident report for serious incidents under the AI Act (High-risk AI systems) — with the consultation closing on 7 November 2025 and the final version expected to apply from the 2 August 2026 start date. Build your internal report against that template now: it is designed to harmonize what every market surveillance authority receives, and it is aligned with the OECD AI Incidents Monitor and Common Reporting Framework.

Filing checklist:

• Correct market surveillance authority identified (Member State of occurrence).
• Report drafted on the Commission template fields.
• Category, causal-link determination and affected-system identification included.
• Initial report filed inside the 2/10/15-day deadline, even if incomplete.
• Parallel filings logged (see cross-regime notes).

Filing the initial report does not close the obligation. Article 73(6) requires the provider to investigate without delay, including a risk assessment of the incident and corrective action, and to cooperate with the competent authorities (and, where relevant, the notified body). Only after you have informed the authorities may you make changes that would affect a later evaluation.

Closure tasks:

• Complete any report that was filed as initial/incomplete, with verified cause and the corrective action taken.
• Record the corrective action against the system's technical documentation (the Annex III / Articles 9-19 file for the high-risk system).
• Preserve the frozen pre-change system state alongside the post-remediation version, so the before/after is evidentiable.
• Note that the national competent authority notifies the Commission, and relevant national public authorities are informed onward — your filing is the source record for that chain.

Assemble these once; every downstream filing is a different view of the same record. Order them by the gate that consumes them:

• Incident timeline with the first-signal timestamp (the awareness-date evidence).
• Causal-link determination memo — how you connected the AI system to the harm.
• Frozen system state and model version (hashed), captured before any remediation.
• Technical documentation of the high-risk system (Articles 9-19 / Annex III file) proving intended purpose, known limitations and the risk-management record.
• Operational logs of the AI system across the incident window plus the preceding days.
• Corrective-action log with timestamps and approvers.
• Communications log (authorities, affected parties, internal).

The recurring failure here is that this evidence is assembled by hand, from disparate tools, in the middle of a tight clock — and a chronology edited after the fact is exactly what a market surveillance authority will probe. Teams that run continuous, signed-at-write-time evidence shrink the task to export-review-sign-send. Zero Hunt's on-premise appliance does this by construction: every evidence-chain entry is signed at write time and the Trust Center exports an auditor-ready, per-regime package — and because the engine maps the AI Act among the 34 compliance frameworks it covers, the Article 73 view is one of the exports rather than a bespoke scramble.

Patterns seen across peer organizations preparing for the 2 August 2026 start:

• Filing it only as a GDPR or NIS2 incident. The AI Act carries its own clock and its own authority; a GDPR Art. 33 notification to your data-protection authority does not discharge Article 73.
• Patching the model before informing the authorities. This violates Article 73(6) and can destroy the evidence of the cause. Freeze first.
• Misclassifying the Article 3(49) category. Calling a critical-infrastructure disruption a 'general' incident puts you on the 15-day clock when the law gave you 2 — a hard breach, not a paperwork slip.
• Not knowing which market surveillance authority. In many Member States the AI Act authority is newly designated and is not the data-protection authority; find it before the incident, not during.
• No technical documentation ready. Without the Articles 9-19 file you cannot credibly evidence the causal link or the system's intended purpose, and the report stalls.

A single AI-system failure routinely triggers more than one regime, each with its own clock and authority:

• NIS2 Article 23 (24h / 72h / 1-month) where the operator is an essential or important entity.
• GDPR Article 33 (72h) where personal data is affected.
• DORA major-incident reporting where the entity is in financial services.
• Sectoral regimes (medical devices, etc.), which for category-(c) incidents can displace the Article 73 filing entirely.

The Commission's draft guidance explicitly addresses the interplay with other reporting regimes and seeks alignment with international frameworks. The practical consequence is the same as for every incident regime: build one evidence base and export a different summary per regulator, rather than running parallel evidence trails under four simultaneous clocks.