EU AI Act Article 73 Serious Incident Definition 2026: What Triggers Your Reporting Obligation

Post #1 in the sota.io EU AI Act Incident Reporting Operations Series

August 2, 2026 is 65 days away. That is the date when EU AI Act enforcement begins for most obligations — including the requirement in Article 73 that providers of high-risk AI systems report serious incidents to national market surveillance authorities. Miss a reporting deadline and you face fines of up to €15 million or 3% of global annual turnover, whichever is higher.

Yet most developer teams deploying AI in their SaaS products have no idea what "serious incident" actually means under the Regulation. Law firms have published summaries. What doesn't exist is a practical engineering guide: what is the exact definition, how does indirect causality work, which incidents definitely cross the threshold, and who exactly must report what to whom?

This post answers those questions. It is the first in our five-part EU AI Act Incident Reporting Operations 2026 series. By the end you will understand the Art.73 trigger precisely enough to decide whether your product requires an incident reporting pipeline before August.

The Regulatory Context: Why Art.73 Exists

The EU AI Act's incident reporting requirement sits within Chapter VIII ("Post-market monitoring, information sharing and market surveillance") alongside Art.72 (post-market monitoring plans) and Art.74 (market surveillance authorities). Together these articles close the loop between deploying a high-risk AI system and learning from real-world failures.

The logic is straightforward: pre-deployment conformity assessment (Art.43) cannot catch every failure mode. Real-world deployment generates incidents that regulators need visibility into, so they can identify systemic problems — a specific AI model failing in a particular medical context, a credit-scoring algorithm systematically misclassifying a demographic group — before the harm compounds.

Art.73 is the mechanism by which this information reaches regulators. It is mandatory, time-bounded, and applies regardless of whether you believe your product caused the harm.

The Statutory Definition of "Serious Incident"

Article 73(1) of Regulation (EU) 2024/1689 defines a serious incident as:

"any incident or malfunction of an AI system that directly or indirectly leads to any of the following: (a) the death of a person or serious harm to a person's health; (b) a serious and irreversible disruption of critical infrastructure as referred to in Article 22(1) of Directive (EU) 2022/2557; (c) a breach of Union law intended to protect fundamental rights; (d) serious damage to property or the environment."

Four elements define the threshold:

1. An incident OR malfunction — the event itself (the system did something, or failed to do something)
2. Causal link — direct or indirect connection between the AI and the harm
3. Of an AI system — the relevant system must qualify as an AI system under Art.3(1)
4. In the context of its use by deployers or other third parties — the incident must occur in real-world deployment, not during internal development or testing

Each element matters. An AI system misbehaving in your dev environment is not a reportable incident. The same malfunction in a customer's production environment — if it causes the right category of harm — is.

The Four Harm Categories Unpacked

Category A: Death or Serious Harm to Health

This is the most severe category and carries the shortest reporting deadline (2 days for death, 10 days for serious health harm — more on timelines below).

"Death of a person" is self-explanatory. What matters for developers is the causal chain. The Commission's draft guidance (expected final August 2026) makes clear that indirect causality is sufficient. If your AI system produces a diagnostic recommendation → a clinician acts on that recommendation → the patient dies as a result → your AI system is linked to a death under Art.73, even if the clinician made the final decision.

This indirect causality principle is the most significant aspect of the definition for SaaS developers. You do not need to have "directly" killed anyone. You need to have contributed to a causal chain that ended in death.

"Serious harm to health" is less defined but includes: hospitalisation, permanent disability, life-threatening conditions, and conditions requiring significant medical intervention. Minor adverse health events — a user experiencing stress, a temporarily worsened chronic condition — do not meet this threshold.

Practical SaaS examples that DO trigger this category:

• An AI-powered medication dosing assistant recommends an incorrect dose; the patient receives it and is hospitalised
• A mental health chatbot fails to escalate a suicide risk; the user attempts self-harm
• A diagnostic imaging AI misclassifies a tumour as benign; the patient's treatment is delayed and condition worsens materially

Practical SaaS examples that do NOT trigger this category:

• A recommendation engine suggests a wrong product; the user is annoyed
• A document classification AI mislabels a contract; the legal team spends extra time reviewing
• A sentiment analysis tool produces incorrect output in a CRM; a salesperson has an awkward call

Category B: Serious and Irreversible Disruption of Critical Infrastructure

Critical infrastructure is defined by reference to the CER Directive (EU) 2022/2557, which covers: energy, transport, banking, financial market infrastructure, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, and health.

"Serious and irreversible" is a high bar. A brief outage is not a reportable incident. Extended disruption that causes lasting harm — an AI system managing power grid routing causing a multi-day blackout, an AI-driven water treatment controller causing contaminated water entering the system — would qualify.

For most SaaS developers this category is unlikely to apply unless your product directly controls or optimises critical infrastructure systems. If it does, you are almost certainly already under NIS2 obligations as well.

Category C: Breach of Union Law Protecting Fundamental Rights

This category is the broadest and most ambiguous. Union law protecting fundamental rights includes: GDPR (right to privacy, data protection), the Charter of Fundamental Rights, the Fundamental Rights Charter's non-discrimination provisions, and sector-specific laws like the ECHR.

What this means in practice: If your AI system is a high-risk AI system (for example: an employment decision-support tool under Annex III, point 4; a creditworthiness assessment under Annex III, point 5; or a law enforcement risk assessment under Annex III, point 6), and it:

• Discriminates systematically against a protected group (Art.21 of the Charter)
• Processes personal data outside its declared basis (GDPR Art.6)
• Makes automated decisions without adequate human review where required (GDPR Art.22)

...and this causes material harm to individuals — that may constitute a serious incident.

This category requires legal assessment, not just engineering assessment. If you suspect a potential fundamental rights breach, involve your legal team before deciding whether to report.

Category D: Serious Damage to Property or Environment

Material property damage or significant environmental harm caused by an AI system. Relevant for AI systems controlling physical processes — autonomous vehicles, industrial robots, AI-driven logistics systems.

For pure software SaaS, this category rarely applies unless your system controls physical machinery.

The Causal Chain Test: Your Most Important Engineering Decision

Whether or not you must report under Art.73 often comes down to the causal chain. Art.73(1) says the incident must "directly or indirectly lead to" harm. The Commission's draft guidance elaborates:

Direct causation: The AI system's output → harm with no meaningful intervening human decision. Example: an autonomous trading system executes a trade that causes a firm to breach capital requirements → client funds at risk → fundamental rights breach.

Indirect causation: The AI system's output → human decision → harm. The key question is whether the human decision was meaningfully independent of the AI's output or whether it was substantially determined by it.

This is the hardest call. Consider three scenarios:

The automation bias problem — humans systematically over-trusting AI recommendations — is explicitly addressed in the draft guidance. A system that produces outputs that clinicians follow 95% of the time without meaningful review is, in regulatory terms, functioning more like an autonomous system than an assistive tool.

For your engineering team: if your Art.26 human oversight implementation (see our Art.14 guide) has identified automation bias risks, those same use cases are your highest-risk scenarios for Art.73 incident reporting.

Who Must Report: The Provider vs Deployer Distinction

This is where many teams get confused.

Art.73 reporting obligation is on PROVIDERS, not deployers. A provider under the AI Act is the entity that:

• Developed the high-risk AI system
• Places it on the market or puts it into service
• Is responsible for its conformity assessment and technical documentation

A deployer is the entity that uses a ready-made high-risk AI system for its own purposes.

But here is the complication: Most SaaS companies occupying the middle layer — building applications on top of foundation models (Claude, GPT-4, Gemini) — are providers of their own high-risk AI system, even though they are deployers of the underlying model. Your application IS the high-risk AI system if it falls under one of the Annex III categories.

Deployer notification duty (Art.26(5)): Deployers who discover a serious incident must:

1. Immediately stop using the AI system if the incident poses a serious risk
2. Notify the provider immediately
3. Notify their national market surveillance authority if the provider is not established in the Union

So the full information flow for a serious incident is:

Deployer discovers incident
  → Notifies Provider (immediately)
  → Provider investigates causal link
  → Provider reports to NCA (within 2/10/15 days of becoming aware)
  → NCA shares information across EADB (European AI Database)

If you are both provider and deployer (the common SaaS scenario), you collapse these steps. You are directly responsible for the NCA notification.

The Reporting Timelines: 2, 10, 15 Days

From the moment you become aware of a serious incident (and establish or have reasonable grounds to suspect a causal link to your AI system), the clock starts:

These are calendar days, not working days. The 2-day window for death-related incidents is extremely short — it means your incident detection and escalation pipeline must be automated enough to surface potential incidents within hours, not days.

"Becomes aware" means the moment at which someone in your organisation (provider) has reasonable grounds to believe that a serious incident has occurred involving your AI system. You do not need to have confirmed the causal link — the obligation to report begins when you have "reasonable likelihood" of a causal link.

This creates an interesting engineering requirement: you cannot wait for a full root cause analysis before reporting. You must report the initial facts within the deadline, then supplement with additional information as your investigation progresses. The Commission's reporting template (covered in Part 3 of this series) accounts for this with initial notification and follow-up report fields.

What Does NOT Qualify as a Serious Incident

Equally important is knowing what falls outside Art.73:

Malfunctions without downstream harm: An AI system producing incorrect outputs that are caught by quality control before affecting any user. This is a post-market monitoring event (Art.72) but not a reportable serious incident.

AI systems not in Annex III scope: If your AI system is not a high-risk AI system (not in the Annex III categories), Art.73 does not apply. Art.73(1) applies specifically to "AI systems referred to in Article 6" — i.e., the Annex III high-risk list and those subject to Art.6(2).

GPAI model malfunctions at the infrastructure layer: If you are a deployer of a GPAI model (Claude, GPT-4, Gemini) and the underlying model produces problematic outputs but your application's safeguards prevented harm, you likely have an Art.26(5) notification to the model provider but not necessarily a full Art.73 incident report.

Minor adverse events: User-reported errors, incorrect recommendations that did not result in material harm, bugs that degraded performance. These belong in your post-market monitoring plan (Art.72), not in an Art.73 incident report.

Building Your Incident Detection Capability Now

Given the timelines — especially the 2-day window for death-related incidents — you need to invest in detection infrastructure before August 2:

1. Harm detection hooks in your application layer

Instrument every high-risk AI output path with logging sufficient to reconstruct the causal chain. When a recommendation is made, log:

• The input received
• The model version and output
• The confidence score
• Whether human review occurred (and what the reviewer decided)
• The downstream action taken

2. User feedback channels for adverse events

Build in-product mechanisms for users to report adverse outcomes, separate from general bug reports. A "Report a concern about this AI recommendation" path that routes to a dedicated queue — distinct from your general support queue — enables faster triaging.

3. Incident severity classification in your on-call runbook

Add explicit Art.73 triage to your incident severity definitions. Your P1 definition should include: "May have resulted in death, serious health harm, critical infrastructure disruption, or fundamental rights breach involving an AI system." This ensures your on-call team escalates to your Data Protection Officer and Legal team, not just fixes the bug.

4. NCA contact information pre-loaded

Know which national market surveillance authority you report to before you need to report. For AI Act enforcement, NCAs are typically the market surveillance authorities designated under sector-specific law. Post 3 of this series will include an NCA contact list by country.

The Relationship to Your Art.9 Risk Management System

Art.9 requires you to maintain a risk management system for high-risk AI systems throughout their lifecycle. Serious incidents are the most critical inputs to that system — each incident triggers a review of your residual risk assessment and may require you to update your risk mitigation measures.

After an incident report to an NCA, expect:

• A request for your technical documentation (Art.11)
• Questions about your risk management system and why the risk was not identified pre-deployment
• Potentially a suspension order under Art.74(4) if the NCA determines the system poses a serious risk

Having your Art.9 risk management system in place before an incident makes the post-incident regulatory engagement manageable. Going into an NCA investigation without documented risk management is the scenario you most want to avoid.

Incident Reporting for SaaS Providers: A Decision Tree

Step 1: Is your AI system high-risk?
→ Check Annex III. If yes, proceed. If no, Art.73 does not apply (but Art.72 monitoring still does).

Step 2: Did an incident occur in production deployment?
→ If yes, proceed. If the incident was caught in testing, this is a development quality event, not a reportable incident.

Step 3: Is there a causal link (direct or indirect) between your AI system and potential serious harm?
→ Apply the causal chain test above. If yes, proceed. If categorically no (the harm could not plausibly be connected to your AI's output), document your reasoning and file under post-market monitoring.

Step 4: Does the harm fall into one of the four Art.73 categories?
→ Death/health harm / critical infrastructure disruption / fundamental rights breach / property or environmental damage. If yes, determine the applicable timeline.

Step 5: Start the reporting clock.
→ 2 days (death/security breach), 10 days (health), 15 days (other).

What Comes Next in This Series

This post covered the trigger — the statutory definition, the causal chain test, and the four harm categories. Parts 2 through 5 of this series will cover the operational mechanics:

• Part 2: The 15/10/2-day reporting timelines in detail — how to build the alert pipeline that ensures you meet them
• Part 3: The Commission's reporting template — what goes in the initial notification and the follow-up report
• Part 4: AI Act Art.73 vs CRA Art.14 vs NIS2 Art.23 — which reporting regime applies to your incident, and how to build a unified reporting stack
• Part 5: Final incident reporting operations playbook — SIEM integration, PagerDuty runbooks, NCA contact directory, go-live checklist for August 2

If you are running high-risk AI systems on EU infrastructure and want a deployment environment built for compliance from day one, sota.io is an EU-native PaaS designed for exactly this use case — no CLOUD Act exposure, Hetzner Germany infrastructure, 100% GDPR.

This post is for informational purposes. For legal advice on EU AI Act compliance specific to your organisation, consult a qualified legal professional.