AI Incident Response Plan Template (EU AI Act)
An AI incident-response-plan template: detection, triage, containment, the Article 73 serious-incident report and the deployer Article 26 flag-to-provider.
A serious-incident report is a single document filed after the fact. An incident-response plan is the whole process that gets you to that document — and gets the system back under control. This template covers the full lifecycle: how you detect an AI incident, triage its severity, contain the harm, file the Article 73 serious-incident report where it is a provider's duty, run root-cause analysis, and close the loop with corrective action. It is the standing playbook; the report is one of its outputs.
That distinction matters for how you use this page. If you only need the fields for the regulatory filing itself, use the serious-incident report template. Use this plan when you want the end-to-end response procedure your team follows the moment an AI system misbehaves — the part that has to exist before an incident, not after.
Detection — how you know something went wrong
You cannot respond to what you do not see. Detection rests on two things the EU AI Act already requires you to have. First, the Article 12 logs: high-risk systems must automatically record events across their lifetime, and those logs are your primary forensic trail. Second, the monitoring duties — providers run post-market monitoring under Article 72, and deployers monitor operation under Article 26(5). Your plan should name the signals that trigger the process: anomalous output distributions, accuracy drift below the Article 15 thresholds, a user complaint, or an external alert.
Record, for each detection: what surfaced the signal, the timestamp, and who received it.
Triage — is this a "serious incident"?
Not every glitch is a reportable serious incident, and over-reporting wastes the same time under-reporting costs you. Triage against the Article 3(49) definition: a serious incident is an incident or malfunctioning that directly or indirectly leads to death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of fundamental-rights obligations, or serious harm to property or the environment. If one of those limbs is met, the Article 73 reporting clock starts. If none is, you still log and remediate — but the statutory deadlines do not bite.
| Trigger | Deadline to report (Article 73) | Who files |
|---|---|---|
| General serious incident | No later than 15 days after awareness (73(2)) | Provider |
| Widespread infringement or serious, irreversible critical-infrastructure disruption | No later than 2 days (73(3)) | Provider |
| Incident involving a person's death | No later than 10 days (73(4)) | Provider |
An incomplete initial report is allowed to meet the deadline, followed by a complete one (Article 73(5)). Do not wait for certainty before filing the initial notice.
Containment — stop the harm spreading
Containment is the deployer's and provider's immediate operational response, separate from the paperwork. The plan should pre-authorise the people who can act so no one waits for sign-off mid-incident: pause or restrict the system, fall back to a manual process, or invoke the Article 14 human-override mechanism. A deployer's Article 26(5) duty is explicit here — where it identifies a risk to health, safety or fundamental rights, it must suspend use and inform the provider.
The report and the flag — who does what
Here is the split people get wrong. Article 73 is the provider's duty — the provider reports the serious incident to the market-surveillance authority of the member state where it occurred. The deployer's job under Article 26(5) is to flag to the provider: identify the serious incident, suspend use, and inform the provider (and, where relevant, the authority). So in a typical chain the deployer detects and notifies; the provider files the Article 73 report. Your plan should name both roles and the hand-off between them.
Root cause and corrective action
Closing an incident means more than restoring service. Run a structured root-cause analysis using the Article 12 logs as evidence, then feed the finding into two places: the provider's post-market monitoring system (Article 72), which exists precisely to capture and act on field experience, and the Article 9 risk-management system, which must be updated when a new risk materialises. Corrective actions — a model retrain, a threshold change, an updated instruction-for-use — close the loop and become evidence at the next conformity assessment.
The template — sections to fill
1. Roles and contacts — incident lead; provider contact; deployer contact; market-surveillance authority for each member state of operation; whether you act as provider, deployer, or both.
2. Detection record — signal source (Article 12 logs / Article 72 or 26(5) monitoring / complaint / external alert); timestamp; recipient.
3. Triage and classification — which Article 3(49) limb (if any) is met; resulting Article 73 deadline (15 / 10 / 2 days) or "not a serious incident"; awareness date.
4. Containment actions — pause / restrict / fallback / Article 14 override invoked; who authorised; time to contain.
5. Reporting and flagging — for deployers: Article 26(5) notification to provider (date). For providers: Article 73 initial-report date, complete-report due date, authority addressed.
6. Root-cause analysis — component or behaviour implicated; whether the system operated within its intended purpose; supporting Article 12 log references.
7. Corrective and preventive action — fix applied; update to the Article 9 risk-management record and the Article 72 post-market monitoring file; whether the change is a substantial modification (Article 3(23)) re-triggering conformity assessment.
8. Closure — sign-off; lessons logged; instructions-for-use update issued to deployers if needed.
Worked example: a SaaS provider's model drift
Beselin Analytics OÜ, an Estonian provider with about 60 employees and roughly €11M turnover, ships a high-risk creditworthiness scoring system (Annex III point 5(b)). Its Article 12 logs surface a sudden shift in score distribution; Article 72 post-market monitoring flags it. Triage: the drift is producing systematically unfair declines for a class of applicants — an infringement of fundamental-rights obligations under Article 3(49), so the 15-day rule applies, not the 2-day or 10-day variants. Beselin contains within hours by pausing the scoring feature and falling back to manual review, files an initial Article 73 report within days, and runs root cause to a corrupted training-data refresh. The fix and the analysis are written into the Article 9 risk record and the Article 72 monitoring file; a corrected model and an updated instruction-for-use go out to deployers. Because the retrain changes performance characteristics, Beselin assesses whether it is a substantial modification under Article 3(23) before redeploying.
How Confir helps
Confir links each AI system's role, Annex III classification, Article 12 log references and Article 9 risk record into one place, so when an incident hits, your response plan draws on the system data you already hold and the Article 73 deadline is calculated from the awareness date rather than guessed. It keeps the provider's Article 73 reporting duty and the deployer's Article 26(5) flag-to-provider duty visibly separate, so each party sees only what is theirs. The engine is deterministic and rule-based.
Related guides
- Serious incident report template
- Incident reporting under the EU AI Act
- Article 73 serious-incident reporting
- Article 72 post-market monitoring
- Post-market monitoring obligations
- Risk management plan template
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 →