AI Serious Incident Report Template (Article 73) — Fillable & Field-by-Field

Template26 June 2026· 17 min read

A fillable AI serious incident report template for EU AI Act Article 73: field-by-field guidance, the 2/10/15-day windows, and who files to which authority.

A hospital's high-risk imaging triage AI misses a flag, a clinician acts on the output, and a patient dies. The provider that placed that system on the market has at most 10 days from the moment it establishes a likely causal link to file a serious incident report with the national authority. This page gives you the fillable report it must submit.

This is the artifact, not the explainer. Below is a copy-paste AI serious incident report template mapped to Article 73 of the EU AI Act (Regulation (EU) 2024/1689), field-by-field guidance on how to complete each section under deadline pressure, the 2/10/15-day windows in one quick-reference table, and a fully worked filled example. For the underlying legal duty, see the full text and obligations of Article 73; for the operational process, see how to build an Article 73 reporting workflow.

Who This Template Is For — And Who Actually Files

Before you fill a single field, answer the gating question: should you be using this template at all? The full provider report and the deployer notification are different documents, and filing the wrong one wastes the window you do not have.

Providers of high-risk AI systems own the report — Article 73

Article 73(1) is a provider obligation. Only the entity that placed the high-risk AI system on the EU market — or put it into service under its own name or trademark — files the regulatory serious incident report with the market surveillance authority. If that is you, the full template below is yours to complete.

Deployers have a narrower duty — Article 26

A deployer does not file the Article 73 report. Under Article 26, a deployer that identifies or suspects a serious incident must notify the provider first, then the importer or distributor where relevant. A deployer may contact the market surveillance authority directly only where the provider sits outside the EU and is unreachable, or has not filed. So a company using a third-party high-risk hiring or imaging AI uses the deployer-notification fields, not the full provider report — point yourself at the right sub-template before you start.

Importers, distributors, and out-of-EU providers — Article 22

Importers and distributors pass incident information up the chain to the provider rather than filing the regulatory report themselves. Where the provider is established outside the EU, its authorised representative under Article 22 can step into the reporting role and submit on the provider's behalf. The duty does not evaporate because the provider is offshore; it shifts to the representative.

A scope note: the Article 73 reporting obligation attaches to high-risk AI systems, and the applicability date is in flux. Rather than repeat the full deadline caveat here, see the dated position in the table section and in the full text and obligations of Article 73.

Before You Fill Anything: Confirm It Is a 'Serious Incident'

Gate the template behind the definition. If the event does not meet the Article 3(49) threshold, you should not be filing an Article 73 report at all — though you may still log it in post-market monitoring.

The five qualifying harms — Article 3(49)

An incident is a serious incident if it directly or indirectly leads to any of five outcomes:

the death of a person;
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 damage to property or the environment.

If none of these is present, the event does not trigger the report. Run this test first, every time.

Direct and indirect causation

Indirect causation is in scope. An AI output that a human acts on — a clinician following a triage recommendation, a caseworker accepting a benefits score — qualifies even though a human decision sat between the system and the harm. Do not talk yourself out of reporting because "a person made the final call."

When the clock starts: 'becoming aware'

The reporting clock runs from when the provider becomes aware of the incident, or establishes a reasonable likelihood of a causal link between the AI system and the harm. It does not run from when the harm occurred, and it does not wait for the investigation to conclude. For the full conceptual treatment, see the definition of a serious incident under Article 3(49).

The Reporting Windows and the Authority — Quick Reference

How long do you have, and to whom does this go? The operational answer fits in one table. Use it to populate the header fields of the template below.

Trigger	Deadline	Legal basis	Where it goes
General serious incident	No later than 15 days	Article 73(2)	Market surveillance authority of the member state where the incident occurred
Widespread infringement of fundamental rights, or serious-and-irreversible critical-infrastructure disruption	No later than 2 days	Article 73(3)	Same authority — fastest clock governs
A person has died	No later than 10 days	Article 73(4)	Same authority
Initial report incomplete	File on time, complete promptly	Article 73(5)	Same authority — preliminary then complete

The 2 / 10 / 15-day deadlines

All three windows are measured from "becoming aware," and the shortest applicable deadline governs. If a single incident both involves a death and is a widespread fundamental-rights infringement, you work to the 2-day clock under Article 73(3), not the 10-day clock under Article 73(4).

Which market surveillance authority

The report goes to the market surveillance authority of the member state where the incident occurred — not necessarily where your company is established. An incident in Germany goes to the German authority even if you are headquartered in Ireland. Multi-state incidents may need parallel notifications, so maintain a jurisdiction matrix in advance rather than working it out under a 2-day clock.

Initial vs. complete report — Article 73(5)

Article 73(5) lets you file a preliminary report within the window and complete it later. A good-faith preliminary filing that you subsequently correct is not misinformation. The deadline mechanics are covered in depth on how to build an Article 73 reporting workflow; here the table exists to fill the template's header.

The Fillable AI Serious Incident Report Template

This is the core deliverable: a fillable markdown block you can copy straight into your quality management system and populate. Each section maps to the facts an authority will look for.

AI SERIOUS INCIDENT REPORT — EU AI Act Article 73

--- SECTION A: IDENTIFICATION & REPORTING METADATA ---
Report reference / version: ____
Report type: [ ] Preliminary (Art 73(5))  [ ] Complete
Date provider became aware: ____
Applicable deadline: [ ] 2 days (Art 73(3))  [ ] 10 days (Art 73(4))  [ ] 15 days (Art 73(2))
Resulting due date: ____
Provider legal name: ____
Authorised representative (if provider outside EU, Art 22): ____
Recipient market surveillance authority: ____
Member state where incident occurred: ____

--- SECTION B: INCIDENT DESCRIPTION & ART 3(49) CLASSIFICATION ---
High-risk AI system name & version: ____
Intended purpose (Annex III use category / Annex I product): ____
Art 3(49) harm category triggered:
  [ ] Death  [ ] Serious harm to health
  [ ] Critical-infrastructure disruption
  [ ] Fundamental-rights infringement
  [ ] Serious property/environmental damage
Factual description of what happened: ____
Date, time & location of incident: ____

--- SECTION C: AFFECTED PERSONS, SYSTEMS & CAUSAL LINK ---
Number and category of affected persons: ____
AI system component involved: ____
Established or suspected causal link (system behaviour -> harm): ____
Human-in-the-loop decision in the chain (if any): ____

--- SECTION D: IMMEDIATE MEASURES & CORRECTIVE ACTION ---
Immediate containment / mitigation taken: ____
System status: [ ] Withdrawn  [ ] Paused  [ ] Recalled  [ ] In service
Corrective action plan & owner: ____
Planned root-cause investigation: ____

--- SECTION E: SIGN-OFF, ATTACHMENTS & FOLLOW-UP ---
Parallel reports filed:
  [ ] GDPR Art 33 (date: ____ )
  [ ] NIS2 early warning (date: ____ )
  [ ] MDR/IVDR vigilance (date: ____ )
Attachments / log references: ____
Accountable signatory (name, role): ____
Completing report (if preliminary filed): due ____ / filed ____

Section A — Identification and reporting metadata

Section A is the header an authority reads first: which system, which provider, which clock, and the resulting due date. Get the deadline checkbox right, because it dictates everything downstream.

Section B — Incident description and the Article 3(49) classification

Section B states the system, its intended purpose, and which of the five Article 3(49) harm categories was triggered, with a factual account of what happened and when.

Section C — Affected persons, systems, and the causal link

Section C records who was affected, which component was involved, and the established or suspected link between system behaviour and harm — including any human decision in the chain.

Section D — Immediate measures and corrective action

Section D captures what you did immediately: containment, whether the system was paused or withdrawn, and the corrective action plan with a named owner.

Section E — Sign-off, attachments, and follow-up tracking

Section E logs parallel regulatory filings, attaches the supporting evidence, names the accountable signatory, and holds a placeholder for the completing report where a preliminary was filed.

Field-by-Field Guidance: How to Complete Each Section Without Over-Disclosing

Under deadline pressure, the temptation is to either guess at cause or pad the file. Both are mistakes. Here is how to fill each field correctly.

Writing the factual description vs. speculation

Describe facts and observed behaviour. Flag clearly what is established versus what is still under investigation rather than guessing at root cause. This preserves your Article 73(5) option to file a preliminary report now and complete it once the analysis finishes — and it protects you from the next trap.

Documenting the causal link honestly

Do not submit a knowingly incomplete or misleading report. Providing incorrect, incomplete, or misleading information to a market surveillance authority is a separate violation under Article 99(5), carrying fines up to €7.5 million or 1% of total worldwide annual turnover, whichever is higher. State the suspected causal link as suspected; do not dress speculation up as a finding, and do not bury a known fact.

Logging parallel regulatory reports

One event often triggers several regimes at once. File each applicable report and note the parallel filings in Section E:

a personal-data breach requires notification to the supervisory authority within 72 hours under GDPR Article 33;
a significant cyber incident requires a NIS2 early warning within 24 hours;
AI embedded as a medical-device safety component carries MDR (Regulation (EU) 2017/745) or IVDR (Regulation (EU) 2017/746) vigilance timelines.

Tie Section D's corrective action back to your post-market monitoring system so the incident feeds the ongoing monitoring loop rather than sitting in isolation.

Worked Example: Helvetra Diagnostics Files a 10-Day Report

Here is the template end to end. Helvetra Diagnostics is a fictional 140-person Munich provider of a high-risk medical-imaging triage AI — a safety component of a regulated medical device, so it sits in scope under both Annex III and the medical-device regime.

The scenario and the Article 3(49) trigger

A missed flag in the model's output contributes to a delayed diagnosis, and a patient dies. On 4 June 2026, Helvetra's clinical-safety review establishes a reasonable likelihood that the system's behaviour was causally linked to the death. That awareness date triggers the 10-day window under Article 73(4) — due date 14 June 2026.

The completed template, field by field

--- SECTION A ---
Report reference / version: HD-INC-2026-002 v1
Report type: [x] Preliminary (Art 73(5))
Date provider became aware: 2026-06-04
Applicable deadline: [x] 10 days (Art 73(4))
Resulting due date: 2026-06-14
Provider legal name: Helvetra Diagnostics GmbH
Recipient market surveillance authority: German market surveillance authority
Member state where incident occurred: Germany

--- SECTION B ---
High-risk AI system name & version: HelvScan Triage v3.2
Intended purpose: imaging triage; safety component of a regulated device
Art 3(49) harm category: [x] Death
Factual description: model did not flag a finding later confirmed malignant;
  clinician acted on the unflagged output; diagnosis delayed; patient died.
Date, time & location: 2026-05-28, partner hospital, Munich

--- SECTION C ---
Affected persons: 1 patient (deceased)
AI system component involved: detection module, model build v3.2
Causal link: SUSPECTED, indirect — clinician relied on the output;
  causal contribution under investigation
Human-in-the-loop: yes — radiologist sign-off on triage output

--- SECTION D ---
Immediate measures: model build v3.2 paused across all sites 2026-06-04
System status: [x] Paused
Corrective action plan & owner: revert to v3.1, root-cause review — Head of Clinical Safety
Planned root-cause investigation: detection-threshold and dataset audit

--- SECTION E ---
Parallel reports filed: [x] MDR/IVDR vigilance (date: 2026-06-05)
Attachments: model logs, clinical-safety review note, version register
Accountable signatory: Helvetra Head of Clinical Safety
Completing report: due once root-cause analysis finishes

Filing, parallel reports, and the completing follow-up

Helvetra files the preliminary report with the German authority because the incident occurred in Germany. Because the AI is a device safety component, it files a parallel MDR vigilance report and notes it in Section E. Once the root-cause analysis finishes, Helvetra files the completing report under Article 73(5), closing the preliminary-to-complete loop.

A note for smaller providers: under Article 99(6), administrative fines for SMEs and start-ups are capped at the lower of the percentage or the fixed amount — relevant to the misinformation exposure under Article 99(5). Proportionality lowers the ceiling; it does not remove the duty to file honestly and on time.

After You File: Corrective Action, Evidence, and Post-Market Monitoring

The report is not a one-off form; it is a living record. What happens after you hit send matters as much as the filing.

Closing the corrective-action loop

The provider must investigate, take corrective action, and cooperate with the authority. Record actions and owners in Section D so the file is audit-ready, not a snapshot frozen at the moment of filing.

Keeping the report as audit evidence

Retain the completed report and its supporting logs as evidence within your quality management and technical-documentation trail. The same file that satisfies Article 73 becomes part of the conformity story an authority can re-examine later.

Feeding the post-market monitoring system — Article 72

Under Article 72, serious incidents feed the provider's post-market monitoring system. Patterns across incidents should update risk assessments and monitoring thresholds rather than being filed away — see feeding incidents into post-market monitoring and the Article 72 post-market monitoring obligation.

How Confir Helps

Confir assembles and versions incident-report evidence against the Article 73 fields, so the template above is populated from your existing assessment record rather than rebuilt by hand under a 2-day clock. The synthesis engine is deterministic and rule-based — no model inference, no hallucination: the same inputs always produce the same report, and an auditor can re-run them to get the identical file. Every section references the Article driving it — Article 3(49) for classification, Article 73 for the windows, Article 72 for the monitoring loop — and the audit trail records which rule fired and when.

One dated point worth noting. The Article 73 obligation attaches to high-risk Annex III systems, whose application date has been deferred under the Digital Omnibus. The European Parliament passed the Omnibus in plenary on 16 June 2026 and the Council gave final adoption on 29 June 2026; it enters into force on Official Journal publication, expected before 2 August 2026. Stand-alone Annex III high-risk obligations now apply from 2 December 2027, a settled date. The deferral uses fixed calendar dates; the standards-contingent "stop the clock" variant was rejected. Build your reporting template against 2 December 2027.

Frequently Asked Questions

Who has to file an Article 73 serious incident report?

The provider of the high-risk AI system files the report — the entity that placed the system on the EU market or put it into service under its own name. Deployers do not file the regulatory report; under Article 26 a deployer that suspects a serious incident must notify the provider first, and may contact the market surveillance authority directly only where the provider is outside the EU or has not filed. Importers and distributors pass incident information up to the provider. If the provider is established outside the EU, its authorised representative under Article 22 can take on the reporting role.

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

Article 3(49) defines a serious incident as one that directly or indirectly leads to any of five outcomes: a person's death; serious harm to a person's health; a serious and irreversible disruption of critical infrastructure; an infringement of EU law protecting fundamental rights; or serious damage to property or the environment. Indirect causation is included, so an AI output that a human acts on — causing harm downstream — still qualifies. If none of the five harms is present, the event does not trigger the Article 73 report, though it may still belong in your post-market monitoring records.

How many days do I have to report a serious AI incident?

The deadline depends on the harm. A general serious incident must be reported no later than 15 days after you become aware of it (Article 73(2)). A widespread infringement of fundamental rights or a serious, irreversible disruption of critical infrastructure tightens that to 2 days (Article 73(3)). Where a person has died, the window is 10 days (Article 73(4)). All clocks start from when you become aware or establish a reasonable likelihood of a causal link — not from the harm itself. The shortest applicable deadline governs.

Where do I send the AI incident report?

You report to the market surveillance authority of the member state where the incident occurred — not necessarily where your company is established. If an incident in Germany harms people in Germany, you report to the German authority even if you are based elsewhere in the EU. Incidents spanning multiple member states may require parallel notifications, so maintain a jurisdiction matrix in advance rather than working it out under deadline pressure. Keep a record of each authority contacted and the date of filing.

Can I send a preliminary report and complete it later?

Yes. Article 73(5) lets you file an incomplete initial report within the applicable window and complete it afterwards. This matters because the clock starts when you become aware of a likely causal link, often before any investigation concludes. A good-faith preliminary report that you later correct is not misinformation. What you must avoid is a knowingly incomplete or misleading submission — that is a separate violation under Article 99(5), carrying fines up to EUR 7,500,000 or 1% of worldwide annual turnover. State clearly which facts are established and which are still under investigation.

Do I still file under Article 73 if the incident also triggers GDPR or NIS2?

Yes — the regimes run in parallel, not in place of each other. A single event can trigger several reports with different clocks: a personal-data breach requires a supervisory-authority notification within 72 hours under GDPR Article 33; a significant cyber incident requires a NIS2 early warning within 24 hours; and AI embedded as a medical-device safety component carries MDR or IVDR vigilance timelines. File each applicable report and note in each that parallel reporting is occurring. Where member states offer coordinated channels, use them to avoid contradictory filings.

Are high-risk incident reporting obligations definitely in force from August 2026?

No — that date has moved. The Digital Omnibus was adopted by the European Parliament in plenary on 16 June 2026 and by the Council on 29 June 2026, and enters into force on Official Journal publication, expected before 2 August 2026. Stand-alone Annex III high-risk systems now apply from 2 December 2027 — a settled date, not a proposal. The deferral uses fixed calendar dates; the standards-contingent 'stop the clock' variant was rejected. Prepare your reporting template against 2 December 2027.

Last reviewed June 2026. Cites Regulation (EU) 2024/1689 (EU AI Act).

Manage your EU AI Act compliance in one place

Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.

Start free trial →