How to Build an AI Incident Response Plan for the EU AI Act

A serious incident does not wait for your process to be ready. The moment your high-risk AI system contributes to a death, you may have as few as 2 days to notify an authority — and if you invent the procedure on the spot, you will miss the clock. An AI incident response plan is the standing runbook that turns a live malfunction into a controlled, documented, on-time response.

This page is the connective procedure, not the law and not the form. The legal duty lives in the Article 73 serious-incident reporting obligation; the filing artefact is the fillable Article 73 incident report template. What follows sits between them — detect, triage, contain, report, take corrective action, run RCA and feed post-market monitoring — under Regulation (EU) 2024/1689.

---

What an AI Incident Response Plan Is — And What It Is Not

The plan is your standing operational runbook for when a high-risk AI system misbehaves. It is neither the duty nor the form.

Three artefacts, not one

Keep three things distinct. The obligation is the substantive law — who must report, what counts, the deadlines. The template is the structured form you submit field by field. The plan is the procedure that connects the two: it gets your organisation from a malfunction at 02:00 to a filed report and a fixed system without missing a window. No single Article prescribes the runbook, but it sits across Article 73 (report the harm), Article 20 (corrective action) and Article 72 (post-market monitoring) — each presupposing you can act fast and evidence it.

Who owns it

Providers of high-risk AI systems own the heaviest version. Deployers run a lighter variant under Article 26(5) — detection, immediate measures, and notifying the provider — and generally do not file the Article 73 report themselves. A scope note on timing: stand-alone Annex III high-risk obligations attach when Article 6(2) bites, from 2 December 2027 — the date set by the Digital Omnibus, adopted by the European Parliament (16 June 2026) and the Council (29 June 2026), entering into force on Official Journal publication expected before 2 August 2026.

---

Phase 1 — Detection and Triage: Is This an Article 3(49) Serious Incident?

The runbook earns its keep at the front door. Most events are not serious incidents; the discipline is routing each correctly without burning a clock.

Detection sources feed one intake

Signals arrive from everywhere: internal post-market monitoring alerts, deployer notifications under Article 26(5), user complaints, near-miss logs, and external reports. The runbook routes them all into one timestamped intake.

The Article 3(49) test

Triage tests the event against the five qualifying harms in Article 3(49): death; serious harm to a person's health; serious and irreversible disruption of critical infrastructure; infringement of obligations under Union law intended to protect fundamental rights; or serious harm to property or the environment. If none is present, you may still log it, but you do not have a serious incident.

Causation and the awareness clock

The duty attaches where the provider establishes a causal link — or a reasonable likelihood of one — between the AI system and the harm. Direct and indirect causation both count, so an output a human acted on still qualifies. Define 'becoming aware' as the clock-start trigger and timestamp it precisely: every Article 73 deadline runs from that moment.

Build a triage gate

Route each event one of three ways: not an incident (log and monitor); serious incident (escalate to reporting); or non-conformity without harm (Article 20 only). A single event can fire both clocks at once.

---

Phase 2 — Containment and Immediate Measures

Before you report, stop the bleeding.

Limit further harm

Apply immediate measures to limit further harm. For an in-service high-risk system that can mean disabling the affected feature, switching to human-only decisioning, or pausing automated outputs. Map the move to the Article 20(1) remedy toolkit so it aligns with the corrective action ahead.

Preserve evidence in parallel

Freeze the logs, model version and inputs, and lock the Article 12 record-keeping trail so the root-cause analysis and the Article 73 report stay reconstructable. Evidence destroyed in the first hour cannot be recovered.

Fall back to human oversight

Activate Article 14 human oversight as the fallback control while the automated path is contained. Open the incident record immediately — a numbered, timestamped case file every later phase appends to.

---

Phase 3 — The Article 73 Reporting Clocks (15 / 10 / 2 Days)

This is the phase that punishes a missing runbook hardest. The deadlines are short, differentiated, and all measured from one moment.

The 15 / 10 / 2-day deadline table

The shortest applicable deadline governs, and the report goes to the market surveillance authority of the member state where the incident occurred.

Initial vs complete report (Article 73(5))

Article 73(5) expressly permits an incomplete initial report filed inside the window, followed by supplementary information once your investigation matures. File what you have on time and complete it promptly — a good-faith preliminary report you later correct is not misinformation, provided you state plainly which facts are established and which are not.

Parallel reporting regimes the runbook must flag

Article 73 is rarely the only clock. The runbook flags overlapping duties that may run shorter: NIS2 early-warning timelines for significant cyber incidents, and MDR (Regulation (EU) 2017/745) or IVDR (Regulation (EU) 2017/746) vigilance timelines where the AI is a device safety component.

---

Phase 4 — Article 20 Corrective Actions: Bring Into Conformity, Withdraw, Disable, Recall

Reporting the harm does not fix the system. Article 20 runs in parallel; the runbook keeps both tracks live.

Four graduated remedies

Article 20(1) sets out four remedies: bring into conformity (fix and re-verify), withdraw (stop further market supply), disable (render an in-service system inoperative), and recall (retrieve units already with deployers). Apply the 'as appropriate' proportionality test — a documentation gap may be cured by correction; a system producing harmful outputs needs disable or recall.

Two triggers, two clocks

Article 20 is triggered by non-conformity — a defective state, acting immediately with no fixed day-count — where Article 73 is triggered by a harm event with hard deadlines. A serious incident often reveals non-conformity, so one event fires both; run them together.

Duties to inform, and the re-assessment trap

Under Article 20(1), tell distributors, deployers, importers and the authorised representative of the corrective action taken. Where the system presents a risk within the meaning of Article 79(1), Article 20(2) requires you to inform the market surveillance authorities — and the notified body where a certificate was issued. A substantial fix can also amount to a substantial modification, re-opening the Article 43 conformity assessment.

---

Internal Roles and a RACI for Incident Response

A clock is missed when the right person is not paged, not when the law is unclear. Assign ownership before the incident. The runbook activates standing roles: an incident lead (accountable end-to-end), a compliance owner (Article 73 filing), an engineering/model owner (containment and fix), legal, communications, and the human-oversight operator.

A RACI across the phases

The Article 25 role-shift trap

Watch Article 25: a deployer that re-brands, substantially modifies, or changes the intended purpose of a high-risk system becomes a provider — inheriting the full reporting and corrective-action ownership the RACI must anticipate. Set escalation thresholds and on-call expectations so a 2-day clock is never missed, and keep pre-drafted, version-controlled notices ready.

---

Phase 5 — Root-Cause Analysis and Feeding Post-Market Monitoring (Article 72)

Containment ends the emergency; it does not close the loop. This last phase is where the incident makes the system stronger.

Run a structured root-cause analysis

After containment, run a structured root-cause analysis: what failed (data, model, integration, human oversight), why detection was late or timely, and whether the immediate measure was proportionate. Close the loop by verifying the fix re-meets the requirement it failed, documented as audit evidence.

Feed the Article 72 loop and revise the runbook

Feed the findings into the Article 72 post-market monitoring system so the incident updates monitoring signals, thresholds and the Article 9 risk-management system — this is where Article 72 becomes a live loop. Retain the incident record as durable audit evidence under the Article 12 logging and Article 17 quality-management expectations. Then run a post-incident review on the procedure itself — tighten the triage gate, adjust escalation thresholds, update the RACI.

---

Worked Example: Meridian Health Analytics Runs Its Incident Response Plan

Meridian Health Analytics is a fictional ~140-person provider of a high-risk AI system used by EU health insurers to score claimants — an Annex III point 5(d) insurance-triage use case.

The trigger and the Article 3(49) classification

In April 2026, post-market monitoring and a deployer notification reveal the system systematically mis-scored a cohort of claimants, deprioritising care and producing a pathway to serious harm to health. Tested against Article 3(49), serious harm to a person's health is in scope, and indirect causation through a downstream human decision still counts.

Walking the clock

Meridian timestamps 'becoming aware' as the date its safety review establishes a reasonable likelihood of a causal link. No death has occurred and the harm is not a widespread fundamental-rights infringement, so the 15-day window under Article 73(2) applies. Meridian files an initial report inside it, then completes it under Article 73(5) once the cohort analysis finishes.

Walking the corrective action and closing the loop

In parallel, Meridian disables the affected scoring path and brings the system into conformity with a corrected build. It informs distributors and deployers under Article 20(1), and because the mis-scoring presents a risk within the meaning of Article 79(1), escalates to the authority under Article 20(2). The RCA findings then update its Article 72 monitoring plan and Article 9 risk controls.

---

How Confir Helps

Confir turns the plan into a live workflow: intake, triage against Article 3(49), clock tracking for the 15/10/2-day windows, and corrective-action tracking under Article 20. The synthesis engine is deterministic and rule-based — no model inference, no hallucination: it maps an incident's facts to the applicable Article and deadline, and an auditor can re-run the same inputs for the same routing. It generates the audit-ready evidence trail linking detection, report, corrective action and the Article 72 feedback loop, and maintains the RACI, escalation paths and pre-drafted communications so the right owner is paged before a clock expires — positioning the runbook inside the broader compliance system rather than as a standalone document.

One dated point to plan against. The Article 73 obligation attaches to stand-alone Annex III high-risk systems, whose application date the Digital Omnibus has deferred to 2 December 2027 — adopted by the European Parliament (16 June 2026) and the Council (29 June 2026), entering into force on Official Journal publication expected before 2 August 2026. Build your runbook against 2 December 2027.

---

Frequently Asked Questions

What is an AI incident response plan under the EU AI Act?

It is your standing operational runbook for what happens when a high-risk AI system misbehaves: how you detect the event, triage whether it is an Article 3(49) serious incident, contain it, file the Article 73 report within the right deadline, run Article 20 corrective actions, and feed the lessons back into post-market monitoring under Article 72. The Regulation does not prescribe the runbook itself, but Articles 73, 20 and 72 all assume you can act fast and evidence what you did. It is the procedure that connects the legal duties to operational reality.

How is this different from an Article 73 report template?

The Article 73 template is the filing artefact — the structured form you submit to the market surveillance authority, field by field. The incident response plan is the procedure that produces that form and everything around it: detection, triage, containment, role assignments, corrective action and root-cause analysis. The template answers what you file; the plan answers how your organisation gets from a live malfunction to a filed report and a fixed system without missing a clock. You need both, and the plan is what makes the template usable under time pressure.

What are the Article 73 reporting deadlines?

All deadlines run from when the provider becomes aware of the incident, not from the incident date. A general serious incident must be reported no later than 15 days (Article 73(2)). Where a person has died, the window is 10 days (Article 73(4)). For a widespread infringement of fundamental rights or a serious and irreversible disruption to critical infrastructure, it is 2 days (Article 73(3)). An incomplete initial report can be filed within the window and completed later under Article 73(5). Your runbook should timestamp the awareness moment precisely, because that is what starts every clock.

How does Article 20 corrective action fit into incident response?

Article 20 is triggered by non-conformity — a defective state of the system — and requires immediate corrective action with no fixed day-count: bring into conformity, withdraw, disable, or recall, as appropriate to severity. A serious incident often reveals non-conformity, so one event can fire both Article 73 (report the harm to the authority) and Article 20 (fix the defect and inform distributors and deployers) at once. Your runbook should run the two tracks in parallel rather than treating reporting as the end of the response. A substantial fix may also re-open the Article 43 conformity assessment.

Who should own each step of the plan?

Build a RACI. Typically an incident lead is accountable end-to-end; a compliance owner files the Article 73 report; engineering owns containment and the fix; legal and communications handle external correspondence; and a human-oversight operator runs the fallback control. Watch the Article 25 trap: a deployer that re-brands, substantially modifies, or repurposes a high-risk system becomes a provider and inherits the heavier reporting and corrective-action ownership. Set escalation thresholds and on-call expectations so a 2-day clock is never missed because the right person was not paged in time.

Do deployers need an incident response plan too?

Yes, but a lighter one. Under Article 26(5), deployers must monitor operation, and on detecting a serious incident, inform the provider and the relevant authorities and suspend use as appropriate. A deployer's runbook focuses on detection, immediate measures, evidence preservation and prompt notification to the provider — it generally does not file the Article 73 report itself, because that duty sits with the provider. The exception is the Article 25 role-shift: if the deployer has become a provider, it owns the full plan, including the reporting clocks and corrective-action remedies.

How does an incident feed post-market monitoring?

After containment, you run a root-cause analysis and close the corrective-action loop by verifying the fix. The findings then update your post-market monitoring system under Article 72 — adjusting signals, thresholds and what you watch for — and feed the continuous risk-management process under Article 9. This is where Article 72 stops being a static document and becomes a live loop. The incident record is retained as audit evidence under the Article 12 logging and Article 17 quality-management expectations, and the review should also revise the runbook itself so the next response is faster.

---

Related guides

• the Article 73 serious-incident reporting obligation
• the fillable Article 73 incident report template
• Article 73 reporting deadlines explained
• what counts as a serious incident (Article 3(49))
• building a post-market monitoring plan (Article 72)

---

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