← auditaisdk.com  ·  All articles

EU AI Act Article 73 Serious Incident Reporting: Annex IX Template, Timing Thresholds and Decision Tree for B2B SaaS (2026 Guide)

By Marc Dubois · May 2026 · 14 min read

TL;DR: Article 73 of the EU AI Act binds providers of high-risk AI systems to report serious incidents to the national market surveillance authority under fixed timing thresholds: 2 days for fundamental rights infringement or critical infrastructure disruption, 10 days where death is involved, 15 days for the default residual case. The clock starts on awareness, not on incident occurrence. The four serious-incident categories under Article 3(49) are outcome-driven, not severity-on-the-system driven. The defensible filing package is an Annex IX-aligned eight-block report, a documented internal trigger procedure, an integration with post-market monitoring under Article 72 and the deployer-to-provider notification chain under Article 26(5). The €199 managed audit ships the populated incident report scaffolding and the awareness-clock procedure a B2B SaaS hands procurement and the authority.

Why Article 73 is the post-market obligation that decides whether a high-risk launch survives a real-world incident

Article 73 is the duty B2B SaaS providers most often misread because the timing thresholds look short and the four-category definition under Article 3(49) does not match engineering intuition. Engineers think incident in terms of severity on the system — outage, error rate, regression. Article 73 thinks incident in terms of outcome on the world — death, infrastructure, fundamental rights, property and environment. A high-rate technical regression with no real-world consequence is not a serious incident. A small technical fault with downstream impact on fundamental rights is. The mismatch between engineering severity and regulatory severity is where most 2026 post-market audits find non-compliance.

Three things make Article 73 the procurement and post-launch checkpoint for high-risk AI providers in 2026:

The procurement-stage cost of missing Article 73 in 2026 is the disqualifying gate question: "Describe your serious incident reporting procedure under EU AI Act Article 73. Provide the report template, the awareness-clock procedure and the named accountable contact." A vendor that cannot answer the three sub-questions in one round loses the deal at compliance review.

The text of Article 73 and what it actually requires

ART. 73(1) · REPORTING DUTY

Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred.

ART. 73(2) · 15-DAY DEFAULT

The report shall be made immediately after the provider has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link, and, in any event, not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident.

ART. 73(3) · 2-DAY ACCELERATED

Notwithstanding paragraph 2, in the event of a widespread infringement or a serious and irreversible disruption of management or operation of critical infrastructure, the report referred to in paragraph 1 shall be provided immediately, and not later than 2 days after the provider or, where applicable, the deployer becomes aware of that incident.

ART. 73(4) · 10-DAY DEATH

Notwithstanding paragraph 2, in the event of the death of a person, the report shall be provided immediately after the provider or the deployer has established, or as soon as it suspects, a causal relationship between the high-risk AI system and the serious incident, but not later than 10 days after the date on which the provider or, where applicable, the deployer becomes aware of the serious incident.

The text breaks into five operative components:

  1. Who reports — the provider of the high-risk AI system. Deployer's parallel duty is under Article 26(5) to notify the provider (and the authority where the deployer is a public body).
  2. What is reported — a serious incident as defined in Article 3(49): an incident or malfunctioning that directly or indirectly leads to one of the four outcome categories.
  3. Where — the market surveillance authority of the Member State where the incident occurred. Each Member State designates its authority under Article 70 and publishes its reporting portal from 2 August 2026.
  4. When — 2 days (fundamental rights infringement; serious and irreversible critical infrastructure disruption); 10 days (death); 15 days (default residual). Clocks run from awareness, not from incident occurrence.
  5. What format — Article 73(7) tasks the Commission to publish a standard template; the de-facto baseline in 2026 is the Annex IX-aligned eight-block structure pending the formal Commission template.

The four serious-incident categories under Article 3(49)

The definition is outcome-driven. Each category is independent — a single incident can hit one, two or more categories. The categories are:

(a) Death or serious harm to health

An incident leading directly or indirectly to the death of a person, or to serious damage to a person's physical or mental health. Triggered by AI systems in healthcare diagnosis (misclassification with treatment downstream), workplace safety (false safe state allowing exposure), traffic and mobility (decision causing injury), and any high-risk AI whose output gates a clinical, occupational or safety decision. Timing threshold: 10 days for death, 15 days for serious harm where death is not involved (or 2 days where the harm also constitutes critical infrastructure disruption).

(b) Disruption of critical infrastructure

A serious and irreversible disruption of the management or operation of critical infrastructure within the meaning of point 8(a) of Annex III — supply of water, gas, heating, electricity, digital infrastructure, road traffic. Triggered by AI systems controlling supply, traffic, network operations, energy grids, telecommunications routing. "Irreversible" is read strictly — a short outage that recovers without lasting impact is not category (b). A cascading failure that takes a regional grid offline is. Timing threshold: 2 days.

(c) Fundamental rights infringement

An infringement of obligations under Union law intended to protect fundamental rights. Covers GDPR violations through AI processing, discrimination under the Race Equality Directive or Employment Equality Directive, denial of social benefits or services traceable to AI decision, refusal of access by automated content moderation, and similar Charter-of-Fundamental-Rights protected outcomes. Most often surfaces in HR, credit scoring, benefits eligibility, content moderation, and law enforcement AI deployments. Timing threshold: 2 days.

(d) Property or environment harm

Serious damage to property or to the environment. Covers AI-controlled industrial processes, autonomous logistics, energy and utility operations where output leads to physical damage. The harm has to be serious — minor property damage with replacement value below the threshold national authorities have flagged in 2026 working groups does not trigger Article 73. Environmental harm reads against EU environmental legislation as the implicit benchmark. Timing threshold: 15 days (or 2 days where the same incident also disrupts critical infrastructure).

The four categories together capture the outcome universe Article 73 cares about. A serious incident is the AI system playing a causal role — direct or indirect — in one of the four outcomes. A near-miss is not a serious incident; a small technical fault inside the AI that does not propagate to one of the four outcomes is not a serious incident. The distinction matters operationally because Article 72 post-market monitoring will surface a steady stream of system-level events; only the subset whose causal chain reaches one of the four outcome categories triggers the Article 73 clock.

The decision tree from event to Article 73 filing

Most 2026 post-market audits find Article 73 non-compliance not in the filing itself but in the upstream decision tree — the documented procedure that takes a system-level event and concludes within hours whether the Article 73 clock is running. Below is the decision tree the auditai SDK audit.serious_incident_assess() hook implements.

Step 1. Did an event involving the AI system happen, or was the AI system malfunctioning in some way that may have contributed to a downstream outcome? — If no, no Article 73 trigger; log under Article 72 if any anomaly remains. If yes, go to step 2.
Step 2. Is there a real-world outcome attached — actual or reasonably likely — that the event contributed to, directly or indirectly? — If no, no Article 73 trigger (near-miss); log under Article 72. If yes, go to step 3.
Step 3. Does the real-world outcome fall into Article 3(49) category (a) death or serious harm to health, (b) serious and irreversible critical infrastructure disruption, (c) fundamental rights infringement, or (d) serious property or environmental damage? — If no, no Article 73 trigger; consider sector-specific incident regimes. If yes to any category, go to step 4.
Step 4. Has the provider become aware of the event with sufficient information to believe, on the basis of available evidence, that the AI system reasonably likely caused or contributed to the outcome? — If no (insufficient information yet), continue investigation, do not start the clock; document the in-progress state. If yes, the Article 73 clock starts at this moment.
Step 5. Determine the applicable threshold: 2 days if category (b) critical infrastructure disruption or category (c) fundamental rights infringement; 10 days if category (a) death; 15 days otherwise (including non-death category (a) serious harm, category (d) property/environment, and residual cases). The shortest applicable threshold governs.
Step 6. File the initial report with the market surveillance authority of the Member State where the incident occurred, using the Annex IX-aligned eight-block template. Follow up with additional information and a final report after investigation closes.

The decision tree is the document procurement and the authority will read first. Without it, the company is exposed to two failure modes: filing every Article 72 event (overreporting) or filing nothing until investigation completes (underreporting). Both fail audit.

The timing-threshold matrix

Outcome category Threshold Article 73 sub-paragraph Clock starts at
(c) Fundamental rights infringement (widespread) 2 days Art 73(3) Provider awareness (or deployer-to-provider notification under Art 26(5))
(b) Critical infrastructure serious and irreversible disruption 2 days Art 73(3) Provider awareness
(a) Death of a person 10 days Art 73(4) Provider awareness or suspicion of causal relationship
(a) Serious harm to health (no death) 15 days Art 73(2) Provider awareness
(d) Serious property damage 15 days Art 73(2) Provider awareness
(d) Serious environmental harm 15 days Art 73(2) Provider awareness
Multi-category (combined with critical infrastructure or widespread fundamental rights) 2 days Art 73(3) governs Shortest applicable threshold

Calendar days, not working days. Weekends and public holidays count. Where the threshold expires on a weekend or holiday, the authority's published reporting portal is the receiving channel — most national portals operate 24/7 from 2 August 2026.

The Annex IX-aligned serious incident report template (copyable)

Below is the eight-block report template the auditai SDK populates via audit.export_article_73_report(). The block structure mirrors the Annex IX scope and the medical-devices serious incident reporting structure under Regulation (EU) 2017/745 that has informed the AI Office's draft template.

EU AI ACT ARTICLE 73 SERIOUS INCIDENT REPORT
National market surveillance authority filing

Report version: <initial | follow-up <n> | final>
Report date: <YYYY-MM-DD HH:MM CET>
Reporting party: <provider | deployer (public authority)>
Member State of incident: <ISO-3166-1 alpha-2>
Threshold applied: <2 days | 10 days | 15 days>

BLOCK 1 — PROVIDER IDENTIFICATION
Legal name: <company>
Registered address: <address>
Member State of establishment: <ISO-3166-1 alpha-2>
Accountable contact for Article 73: <name, role, email, phone>
EU representative (if outside Union): <name, address>

BLOCK 2 — AI SYSTEM IDENTIFICATION
Trade name and version: <name v<x.y.z>>
Intended purpose (per Annex IV §1): <description>
High-risk classification basis: <Annex III §<n> | safety component of Annex I product>
Risk-management file reference: <Article 9 RMS ID>
Post-market monitoring plan reference: <Article 72 PMS plan ID>
Date of placing on market or putting into service: <YYYY-MM-DD>

BLOCK 3 — INCIDENT DESCRIPTION
Date and time of incident: <YYYY-MM-DD HH:MM CET>
Location of incident: <city, Member State>
Date of provider awareness: <YYYY-MM-DD HH:MM CET>
Channel of awareness: <deployer notification under Art 26(5) | post-market monitoring under Art 72 | media | authority request | other>
Outcome category (Art 3(49)): <(a) death/health | (b) infrastructure | (c) fundamental rights | (d) property/environment>
Description of the event: <narrative, 5-15 sentences, factual>
Description of the outcome: <narrative, the harm that occurred>
Persons affected: <number, demographic where lawful, deidentified where required>

BLOCK 4 — AI SYSTEM CONTRIBUTION ANALYSIS
Initial assessment: <causal link established | reasonable likelihood of causal link | under investigation>
AI system role: <direct cause | indirect contribution | corroborating factor under investigation>
Component involved: <model | rule layer | data pipeline | oversight layer | integration point>
Mode of failure: <misclassification | drift | data integrity | input handling | oversight bypass | other>
Telemetry attached: <Annex IV §2(g) automatic log excerpt; reference to retained log under Article 12>

BLOCK 5 — DEPLOYER AND SUPPLY CHAIN
Deployer identity: <company or authority>
Deployer role: <regulated deployer | public authority deployer | private deployer>
Deployer notification date (Art 26(5)): <YYYY-MM-DD HH:MM CET, or N/A>
GPAI upstream model used (if any): <model name and provider, or N/A>
Article 25 supplier or distributor involved: <identification, or N/A>

BLOCK 6 — IMMEDIATE CORRECTIVE ACTION
Mitigation applied: <describe rollback, throttle, oversight override, model swap, system pause>
Date of mitigation: <YYYY-MM-DD HH:MM CET>
Affected users notified: <yes | no | scheduled YYYY-MM-DD>
Withdrawal under Article 20 considered: <yes | no | under assessment>
Recall under Article 20 considered: <yes | no | under assessment>

BLOCK 7 — INVESTIGATION PLAN
Investigation owner: <name, role>
Investigation timeline: <YYYY-MM-DD to YYYY-MM-DD>
Methods: <root-cause analysis, log review, model audit, oversight protocol review, human factor analysis>
Cooperation with authority: <named authority, request channel, status>
Follow-up report date(s) projected: <YYYY-MM-DD>
Final report projected: <YYYY-MM-DD>

BLOCK 8 — DECLARATION
This report is filed under Article 73 of Regulation (EU) 2024/1689.
The information provided is true and complete to the best knowledge of
the reporting party as of the report date. Follow-up information will
be provided as the investigation progresses.

Signed: <name, role>
Date: <YYYY-MM-DD>

The initial report can be filed even where blocks 4, 6 and 7 are partially populated — Article 73 anchors the duty on awareness and reasonable likelihood, not on a complete investigation. Annotate any partial block with <under investigation; final report by YYYY-MM-DD>. The authority expects an initial filing within the threshold; follow-up filings layer additional information as investigation advances.

The awareness clock — the most contested clause in 2026 audits

The 2-day, 10-day and 15-day thresholds all run from awareness. Article 73 does not define awareness — the Commission's draft guidance has clarified that awareness arises when the provider has sufficient information to believe, on the basis of available evidence, that an event involving the AI system reasonably likely caused or contributed to a serious-incident-category outcome.

Three operational rules have stabilised in 2026 post-market audits:

RULE 1 · DEPLOYER NOTIFICATION = AWARENESS

Where the provider receives an Article 26(5) notification from a deployer, the awareness clock starts at the moment of receipt. The provider does not get to defer awareness pending its own verification. Verification runs in parallel with the clock. National authorities in 2026 working-group statements have flagged provider attempts to defer awareness until internal verification as a procedural failure.

RULE 2 · MEDIA / EXTERNAL CHANNEL = AWARENESS

Where the provider learns of the event from media, social media, customer complaint or third party rather than the deployer or post-market monitoring, awareness starts at the moment the company gains the information. Awareness is not gated on official channels.

RULE 3 · POST-MARKET MONITORING TRIGGER = AWARENESS

Where the Article 72 post-market monitoring system surfaces a signal that, after triage, the company concludes reasonably likely indicates a serious-incident-category outcome, awareness starts at the conclusion of the triage. The triage itself does not start the clock; the conclusion does. Document the triage decision so the awareness moment is recorded and defensible.

The combined effect is that providers cannot use internal procedure delay to push back the awareness moment. The defensible posture is a documented triage procedure that explicitly times the awareness conclusion and immediately starts the clock from that timestamp.

Six failure modes audited in 2026 Article 73 reviews

Failure 1 — Engineering severity bench, not outcome severity bench. The company has a documented incident severity scale that grades by system metrics (error rate, latency, availability) but no mapping from those grades to Article 3(49) outcome categories. Article 73 audits read this as absence of trigger procedure: the engineering scale is invisible to the regulator, who reads outcome on the world only.
Failure 2 — Awareness deferred to investigation completion. The company waits for root-cause analysis to conclude before declaring awareness. Article 73(2) anchors the duty on the reasonable likelihood of a causal link, not on established causation. The defensible posture is an initial filing within the threshold with the investigation still open and a follow-up report after investigation completes.
Failure 3 — No documented deployer-to-provider notification channel. The company has a high-risk AI feature shipped to regulated deployers (banks, insurers, public authorities) but no published, tested, named contact channel under Article 26(5). Deployers cannot file the notification because the channel does not exist; awareness slips through media or authority-initiated request, which is itself a finding.
Failure 4 — Filing without retained Annex IV automatic logs. Article 12 requires high-risk AI systems to support automatic logging, and Article 73 reports rely on log excerpts in Block 4. A provider whose retained logs do not extend back to the incident window cannot evidence the AI system contribution analysis. The Article 12 retention window has to be at least the projected post-market monitoring window — a year is the defensible floor in 2026.
Failure 5 — Multi-category incident filed under wrong threshold. A single incident hits category (a) serious harm and category (b) critical infrastructure simultaneously; the company files under the 15-day threshold reading the (d) default; the authority reads under the 2-day threshold because of (b). The shortest applicable threshold governs — when in doubt, file under the shortest.
Failure 6 — Withdrawal under Article 20 not considered in Block 6. Block 6 of the report asks whether withdrawal or recall was considered. A provider that does not document the consideration — including a reasoned decision not to withdraw — is exposed under Article 20 separately. The decision not to withdraw has to be documented contemporaneously, not retrofitted.

Interlocks with other EU AI Act obligations

Article 73 is the report; several adjacent duties feed into it or follow from it.

INTERLOCK · ART. 72 · POST-MARKET MONITORING

Article 72 requires providers of high-risk AI systems to draw up and document a post-market monitoring system proportionate to the risks of the AI system. Article 72 is the upstream surveillance that surfaces the events Article 73 may need to report. The two duties are written to operate together — the post-market monitoring plan should explicitly reference the Article 73 trigger procedure and the named accountable contact. See the compliance tools comparison for the post-market monitoring tooling layer.

INTERLOCK · ART. 26(5) · DEPLOYER NOTIFICATION

Article 26(5) requires deployers of high-risk AI systems to inform the provider without undue delay of a serious incident identified during use, and to inform the market surveillance authority directly where the deployer is a public authority. The deployer's notification opens the provider's Article 73 awareness window. The deployer's notification channel has to be named, published and tested. See the Article 26 deployer obligations walkthrough.

INTERLOCK · ART. 55(1)(c) · GPAI SYSTEMIC RISK

Providers of general-purpose AI models with systemic risk under Article 51 owe an analogous serious-incident tracking and reporting duty under Article 55(1)(c) to the AI Office and national authorities. A downstream B2B SaaS provider whose high-risk system embeds a systemic-risk GPAI model should cross-reference the upstream GPAI provider's incident channel in Block 5 of its own Article 73 report. See the GPAI downstream provider obligations walkthrough.

INTERLOCK · ART. 20 · WITHDRAWAL AND RECALL

Article 20 requires providers to take immediate corrective actions, including withdrawal, disablement or recall, where the high-risk AI system does not conform to the Regulation. Block 6 of the Article 73 report records whether withdrawal under Article 20 was considered. The Article 73 filing does not by itself satisfy Article 20 — Article 20 may require additional notification to distributors, deployers and importers in the supply chain. The two duties are complementary.

INTERLOCK · ART. 12 · AUTOMATIC LOGGING

Article 12 requires high-risk AI systems to support automatic recording of events (logs) over the duration of system operation. The retained logs are the evidence layer Article 73 Block 4 references. The retention window has to extend back at least as far as the post-market monitoring window — a year is the defensible floor in 2026. Shorter retention windows undercut Block 4 of every Article 73 filing the provider may need to make. See the Annex IV technical documentation walkthrough for log-design guidance.

SDK exports for Article 73

The auditai SDK ships four exports tailored to Article 73 evidence:

The four exports together cover the procurement-stage Article 73 conversation end to end and ship the operational scaffolding the company needs the moment a real incident hits.

Roll-out timeline before 2 August 2026

Week Action Output
1 Map AI systems to high-risk under Annex III; identify the in-scope set for Article 73. High-risk AI systems inventory; Article 73 in-scope flag per system.
2 Build the decision tree procedure; map Article 72 monitoring signals to Article 3(49) outcome categories. Documented triage procedure; outcome-category mapping table; named accountable contact for Article 73.
3 Publish the deployer-to-provider notification channel under Article 26(5); test the channel with one named deployer. Published Article 26(5) channel; test notification record; deployer-facing one-pager on notification procedure.
4 Populate the Annex IX-aligned eight-block template; tie Block 4 to retained Article 12 logs and Block 2 to the Annex IV file. Empty-incident template ready to populate; integration tested end-to-end.
5 Run a tabletop exercise: simulate a category (c) fundamental rights incident; clock the team's response against the 2-day threshold. Tabletop after-action report; identified gaps; remediation plan for the gaps.
6 Publish the questionnaire-response paragraph; update the vendor questionnaire library; brief the leadership band under the Article 4 literacy programme. Procurement-ready evidence package live; leadership briefed.

Six weeks end-to-end is the conservative estimate before 2 August 2026. A focused team running this as a single workstream typically delivers in three weeks if the Annex IV file and the Article 72 post-market monitoring plan are already in place. The blocker in 2026 has rarely been calendar time — it is the absence of the named accountable contact at C-suite level who owns the awareness clock when the clock starts running on a weekend.

Article 73 evidence package, audited and delivered

The €199 managed audit ships the populated triage decision tree, the Annex IX-aligned eight-block report template, the awareness-clock procedure and the questionnaire-response paragraph — sized to the company's high-risk AI systems inventory and reviewed against Article 72 post-market monitoring and Article 26(5) deployer notification.

Get the Article 73 package — €199

FAQ

When did the EU AI Act Article 73 serious incident reporting duty enter into force?

Article 73 applies from 2 August 2026 under Article 113(c), alongside the main high-risk provider obligations. From that date, the provider owes the regime in full — the 2-day, 10-day and 15-day thresholds operate from day one with no phase-in. GPAI providers with systemic-risk models additionally fall under the analogous Article 55(1)(c) duty.

What counts as a serious incident under the EU AI Act?

Article 3(49) defines four outcome categories: (a) death or serious harm to health; (b) serious and irreversible disruption of critical infrastructure; (c) infringement of fundamental rights obligations under Union law; (d) serious harm to property or environment. The definition is outcome-driven, not severity-on-the-system driven. A near-miss with no actual harm is not a serious incident.

What are the timing thresholds for Article 73 reports?

Two days for category (b) critical infrastructure disruption and category (c) fundamental rights infringement; ten days where death is involved; fifteen days for the residual default case. The shortest applicable threshold governs multi-category incidents. Calendar days, not working days. Clocks run from awareness, not incident occurrence.

Who has to file the Article 73 serious incident report?

The provider of the high-risk AI system. Deployers have a parallel duty under Article 26(5) to notify the provider without undue delay (and the authority directly where the deployer is a public body), but the filing duty does not transfer. GPAI providers with systemic-risk models owe an analogous duty under Article 55(1)(c) to the AI Office and national authorities.

Where is the Article 73 report filed?

With the market surveillance authority of the Member State where the incident occurred. Each Member State designates its authority under Article 70 and publishes its incident reporting portal from 2 August 2026. Multi-Member-State incidents are coordinated through the AI Board under Article 73(7).

When does the Article 73 clock start?

At provider awareness — the moment the provider has sufficient information to believe, on the basis of available evidence, that the AI system reasonably likely caused or contributed to one of the four outcome categories. Awareness is not gated on official channels — deployer notification under Article 26(5), media, customer complaint or Article 72 post-market monitoring triage can all open the awareness window. The clock does not wait for investigation completion.

Is there a specific template required for the Article 73 report?

Article 73(7) tasks the Commission with developing a standard template. As of 2026 the de-facto baseline is the Annex IX-aligned eight-block structure that mirrors the medical-devices serious incident reporting regime under Regulation (EU) 2017/745. A defensible filing is built against the eight-block structure pending publication of the formal Commission template.

Does Article 73 apply to non-high-risk AI systems?

Article 73 in its primary form applies to providers of high-risk AI systems. GPAI providers with systemic-risk models fall under the analogous Article 55(1)(c). For minimal-risk and limited-risk AI systems no general Article 73 duty applies, but sector-specific incident regimes (medical devices, financial services, product safety) may still trigger. Article 73 sits on top of, not in place of, those sector regimes.

How does Article 73 interact with Article 72 post-market monitoring?

Article 72 is the upstream surveillance system; Article 73 is what Article 72 triggers when it finds a serious incident. The Article 72 post-market monitoring plan should explicitly reference the Article 73 trigger procedure, the named accountable contact and the outcome-category mapping. Vendor questionnaires that test for Article 72 will test for Article 73 in the same round.

Related reading

This guide is operational analysis from a B2B SaaS engineering perspective, not legal advice. Article 73 is operational and time-pressured, the Commission template remains in draft, and national authorities are publishing incident portals through 2026. Validate the trigger procedure and the named accountable contact with legal counsel and the company's AI compliance owner before launching a high-risk AI system into the Union market. The auditai SDK is open source on GitHub and on PyPI.