EU AI Act Article 73 Incident Report Content Guide 2026: What Every Field Must Contain

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

You have detected a serious incident. The clock is running — two days, ten days, or fifteen days depending on what your triage found. You know the deadline. You know awareness started the moment your monitoring fired.

Now the harder question: what exactly goes in the notification?

Most developer guides stop at the trigger condition and the deadline. They say "notify the NCA" and leave the content as an exercise for the reader. But EU AI Act Article 73 is not vague on content — it specifies what information notifications must contain, and the Commission is mandated under Art.73 to adopt implementing acts establishing the exact template.

This guide covers the full notification content framework: what each tier of report must include, how to structure the technical fields, what root cause documentation looks like, and which sections providers versus deployers each own.

The Three-Tier Notification Structure

Article 73 establishes a staged reporting model. A single serious incident generates up to three separate notifications — each building on the last, each with its own content requirements.

The important operational implication: the 15-day deadline applies to the Final Report in all cases. For Category A incidents with a 2-day or 10-day initial deadline, you file the initial notification early, then the full final report by day 15.

Section 1: Notifying Party Identification

Every notification — initial, intermediate, and final — must begin with unambiguous identification of who is filing and in what role.

Provider Fields

If you are the provider of the AI system (you placed it on the market or put it into service):

• Legal entity name and registration number — the entity that holds the CE mark or declaration of conformity
• Registered address and EU establishment address if different
• Contact person — name, role, direct phone number, email address capable of 24/7 response during the incident window
• Authorized representative — if provider is established outside EU, the Art.22 representative's contact details
• Notified body reference — for Annex I high-risk systems that used third-party conformity assessment: the NB number and certificate reference

Deployer Fields

If you are the deployer (using a high-risk AI system in a professional context), the identification section must include:

• Legal entity name and registration number
• Sector and intended purpose — the specific context in which you deployed the system (e.g., "credit scoring for consumer loans under Art.6(2) Annex III point 5")
• Provider identification — the name of the AI system you are using and who provided it
• Whether provider has been notified — date and method of notification to the provider under Art.73(4)

Simultaneous Provider-Deployer Incidents

Many serious incidents involve both a provider's AI system and a deployer's operational context. In these cases:

• Provider and deployer file separate notifications to the same NCA
• The NCA correlates them via the AI system unique identifier (see Section 2)
• Providers must reference any deployer notifications they are aware of
• Deployers must reference the provider notification if they have the reference number

Section 2: AI System Identification

The notification must enable the NCA to uniquely identify the AI system involved. This is the technical core of the identification section.

Required System Fields

System name and version — the commercial name, internal product name, and the specific version deployed at time of incident. Version granularity matters: if your system uses model A v2.1.3 but your product is version 4.0, provide both.

Registration reference — for high-risk AI systems required to register under Art.49, the EU AI Act database registration number. The Commission is standing up the EUASN (EU AI Systems Notification) system; this will be your primary cross-border identifier.

Annex classification — which Annex III category applies, and the specific point number. Example: "Annex III point 1(a) — biometric categorisation system used in public spaces."

Intended purpose as documented — copy the exact intended purpose statement from your technical documentation under Art.11. The NCA will check whether the incident occurred within or outside documented scope.

Deployment context — geographic scope of deployment at time of incident, number of users affected or potentially affected, sectors covered.

Model and Component Chain

For systems built on third-party AI components (fine-tuned models, API-based inference services):

• Base model identifier — for GPAI model-based systems: the model name, version, and provider
• Fine-tuning scope — if you fine-tuned the base model, document what training data and objectives were applied
• API dependency chain — if the incident may involve upstream model behavior, document the dependency and whether the upstream provider has been notified

Section 3: Incident Description

The incident description section is where engineering accuracy matters most. NCA investigators will use this to determine whether your system caused the harm, whether the incident was foreseeable, and whether your monitoring was adequate.

Minimum Fields for Initial Notification (All Tiers)

Incident date and time — when the incident event occurred. If this differs from awareness time (Section 4), explain why.

Discovery date and time — when you became aware. Be precise: log timestamp, support ticket creation time, monitoring alert time.

Incident description summary — 200–400 words maximum for the initial notification. Answer: what happened, in what context, what harm resulted or was at risk. No speculation about cause in the initial notification — that comes in the intermediate/final reports.

Harm category assertion — which of the four Art.73 harm categories applies. You must commit to a category in the initial notification even without full investigation. Document your reasoning briefly.

Harm severity and scope — number of individuals affected, severity of harm (confirmed vs suspected), whether harm is ongoing.

Immediate actions taken — what you did between awareness and notification: system suspension, output filtering, user notification, clinical intervention coordination. If you took no immediate action, state why.

Additional Fields for Intermediate Report

Investigation status — what has been investigated, what is still open.

Preliminary causal hypothesis — what you currently believe caused the incident. Document the evidence for each hypothesis, not just the leading candidate.

Affected populations update — revised count of affected persons if your initial estimate was wrong. Explain the revision.

Ongoing risk assessment — is the risk fully contained or still present? If the system remains in operation, what controls are in place?

Final Report Incident Narrative

The final report requires a complete incident narrative that can stand as a permanent record. Structure:

1. Timeline — chronological sequence from earliest detectable precursor to final resolution
2. Detection path — which monitoring or reporting mechanism surfaced the incident and how long after it began
3. Harm characterization — final count of affected persons, confirmed versus suspected harm, long-term harm assessment if applicable
4. Containment actions — every action taken, with timestamps and outcomes

Section 4: Root Cause Analysis

The root cause section is unique to the final report. Intermediate reports may include preliminary hypotheses, but the formal root cause analysis must appear in the 15-day final report.

Five-Layer Root Cause Framework

NCA investigators expect root cause documentation that addresses multiple failure levels. A single proximate cause is insufficient.

Layer 1 — Technical failure: What specific technical component or behavior produced the harmful output? Examples: incorrect object detection under low-light conditions, hallucinated medical contraindication, miscalibrated confidence threshold.

Layer 2 — System design: Why did the technical failure produce a harmful outcome rather than being caught by design safeguards? Which safety measure was absent, insufficient, or bypassed?

Layer 3 — Human oversight failure: At what point should the Art.14 human oversight mechanism have caught this? Why did human oversight not prevent the harm? This section directly relates to your human oversight documentation under Art.14 and your technical documentation under Art.11.

Layer 4 — Post-market monitoring gap: Your post-market monitoring system under Art.72 should be detecting anomalies before they produce serious incidents. Why did it not? Was the monitoring frequency insufficient? Was the harm category not covered by monitoring metrics?

Layer 5 — Systemic pattern: Is this incident a unique occurrence or consistent with a pattern? Have similar near-misses occurred? Does the root cause suggest other harm pathways that have not yet materialized?

What Root Cause Documentation Must NOT Do

Avoid these common patterns that regulators identify as inadequate:

• Attribution to user misuse without analysis — "the deployer used the system outside its intended purpose" is not a root cause if your system has no mechanism to detect or prevent misuse
• Hypothesis stated as fact — root cause analysis requires evidence, not assertion
• Single-cause framing — serious AI incidents typically have multiple contributing factors; single-cause analysis signals incomplete investigation
• Absence of Art.14 assessment — for high-risk AI systems, failing to address human oversight in root cause analysis is a compliance gap

Section 5: Corrective and Mitigation Actions

Every notification tier that references actions taken must follow a structured format. The final report must include complete corrective action documentation.

Immediate Mitigation Actions (All Tiers)

Document every action taken between awareness and report filing:

Corrective Actions (Final Report)

Corrective actions address the root causes identified. For each root cause layer:

Technical corrections:

• Code changes, model updates, threshold adjustments
• Testing evidence demonstrating the fix is effective
• Deployment plan and timeline

Design corrections:

• Changes to system architecture or safety mechanisms
• Updated intended purpose documentation if scope is being restricted
• Conformity re-assessment requirements (does the change require new Annex VII audit?)

Human oversight corrections:

• Updated Art.14 procedures for human oversight
• Training requirements for deployer personnel
• Override authority changes

Monitoring corrections:

• New or updated post-market monitoring metrics under Art.72
• Alert threshold changes
• Monitoring frequency increases

Recurrence Prevention

The final report must include a recurrence prevention assessment — not just what was fixed but what systemic change prevents similar incidents. NCAs look for:

• Whether the correction addresses the root cause or only the proximate failure
• Whether other AI systems in your portfolio could exhibit similar failures
• Whether the monitoring plan change will detect early precursors of similar incidents

Section 6: Cross-Border and Multi-Jurisdiction Coordination

If your AI system is deployed in multiple EU member states, your serious incident notification triggers parallel obligations.

Single Notification to Market Surveillance Authority

Under Art.73(1), the notification goes to the national market surveillance authority of the member state where the incident occurred. You do not simultaneously notify all member states where the system is deployed.

Exception — simultaneous multi-country incidents: If the same incident affected users in multiple member states simultaneously (common for SaaS AI systems), you notify:

1. The market surveillance authority of the member state where your EU establishment is located, OR
2. The authority of the member state where the most severe harm occurred

NCA-to-NCA Coordination

Once you file, the NCA coordinates within the EU via the EUASN (European AI Systems Notification) mechanism. As a provider or deployer, you do not manage this coordination — but you should document your system's deployment footprint in the notification to enable it.

CRA and NIS2 Parallel Obligations

If your AI system is also software subject to the Cyber Resilience Act (applicable from December 2027) or a digital service with NIS2 obligations, a serious AI incident may trigger parallel notification requirements to different authorities under different timelines. Your incident response plan must include a parallel-notification checkpoint at the triage stage.

The Complete Field Checklist (25 Fields)

Use this before every Art.73 notification filing:

Identification (6 fields)

• Legal entity name and registration number
• Contact person with direct phone number
• Authorized representative reference (if non-EU provider)
• AI system name and version
• Annex III classification point
• Intended purpose as documented in Art.11 technical file

Incident Description (7 fields)

• Incident date/time
• Awareness date/time
• Incident summary (200-400 words)
• Harm category assertion with reasoning
• Harm severity and confirmed count
• Immediate actions taken with timestamps
• Whether system remains in operation and on what controls

Investigation Status (4 fields, intermediate report)

• Completed investigation steps
• Open investigation items
• Preliminary causal hypothesis with evidence
• Revised affected population count

Root Cause (3 fields, final report)

• Five-layer root cause analysis
• Art.14 human oversight assessment
• Art.72 monitoring gap assessment

Corrective Actions (5 fields, final report)

• Technical corrections with deployment timeline
• Design corrections and re-assessment requirement
• Human oversight procedure updates
• Post-market monitoring plan changes
• Recurrence prevention assessment

Building Your Report Drafting System

Engineering teams should not be writing incident reports from scratch under time pressure. Build the template into your incident response pipeline before August 2026.

Pre-populated fields: System name, version, Annex classification, intended purpose, contact person, authorized representative — these never change. Pre-populate them in a report template that auto-fills from your configuration management system.

Structured logging for incident fields: Awareness timestamp, affected user count, immediate actions with timestamps — these should be automatically captured by your incident management tooling. Configure PagerDuty or Jira to capture the awareness timestamp the moment an Art.73-qualifying incident is declared.

Root cause template: Build a five-layer root cause template into your postmortem process. Every postmortem should answer all five layers regardless of whether the incident is Art.73-reportable. This builds the organizational muscle before you need it under deadline pressure.

NCA contact registry: Maintain a current registry of market surveillance authority contacts for every EU member state where you operate. Your incident response runbook should include the notification submission URL or email address for each authority. The primary contact directory is maintained on the European Commission's AI Act implementation pages.

What August 2026 Means for Reporting Readiness

Article 73 obligations apply from August 2, 2026 for providers and deployers of high-risk AI systems. Between now and then, your organization needs:

1. Triage capability — the ability to classify an incident into a harm category within hours of awareness
2. Report generation capability — a team that can produce a structured notification document within two calendar days
3. Multi-team coordination — legal, engineering, and business teams who know their roles in the 48-hour window
4. NCA contact registry — current contact information for every relevant market surveillance authority
5. Parallel notification assessment — a mechanism for checking whether NIS2 or CRA parallel obligations apply

The incident report content guide you have just read is your starting point for building each of these capabilities. The next post in this series will compare Art.73 obligations directly with CRA Article 14 and NIS2 Article 23 — because if you operate at the intersection of these regulations, your teams need to know which fields are shared and which create parallel documentation burdens.

EU AI Act Article 73 applies to providers and deployers of high-risk AI systems from August 2, 2026. This post covers content requirements as specified in Art.73 and the delegated implementing acts framework under Art.73(6). Specific template formats will be defined in Commission implementing regulations — monitor EUR-Lex for publication.

Read next: Post #4 — EU AI Act Art.73 vs CRA Art.14 vs NIS2 Art.23: Multi-Regulation Incident Reporting Comparison 2026