What this page gives you
A practical flow from detection to containment, investigation, reporting handoff, and closure.
Prompts for logs, model output, user impact, affected persons, vendor notices, and corrective action.
A bridge to Article 73 serious incident reporting without pretending to decide legal reportability.
Minimum AI incident response flow
| Stage | What to do | Evidence to preserve |
|---|---|---|
| Detect | Capture the trigger, source, system, user, vendor, and first observed harm. | Alert, ticket, model output, user report, screenshots, logs. |
| Triage | Assess seriousness, affected persons, system class, geography, and whether high-risk AI may be involved. | Incident intake record, risk notes, system inventory link. |
| Contain | Stop further harm without destroying evidence or altering the system in a way that blocks later analysis. | Containment action log, change approvals, rollback evidence. |
| Escalate | Notify legal, compliance, security, product, provider/vendor contacts, and leadership using predefined thresholds. | Escalation timestamp, recipients, decisions, owner sign-off. |
| Close | Record root cause, corrective action, monitoring change, and residual risk acceptance. | Closure report, corrective action plan, post-market signal update. |
AI incident response plan starter
Markdown response plan with roles, thresholds, evidence fields, and closure prompts.
Download Markdown starterHow this links to Article 73
The response plan does not decide legal reportability. It creates the facts that qualified reviewers need: system identity, incident timeline, affected persons, harm category, causal link assumptions, containment, and corrective action. Use the Article 73 reporting guide for the reporting handoff.
Recommended supporting artifacts
Record intake, escalation, closure, and evidence status.Post-Market Monitoring Plan
Feed incident signals back into monitoring and corrective action.Human Oversight Evidence Log
Capture human review, override, and escalation decisions.DORA + NIS2 Incident Playbook
Map AI incidents against broader operational resilience duties.
Plan limits
This starter does not replace legal reporting analysis, cybersecurity incident response, product safety procedures, medical-device vigilance, DORA/NIS2 processes, or sector-specific incident rules. Use it as the AI-specific evidence and coordination layer.
FAQ
Is this the same as a serious incident report?
No. It is an internal response plan. A serious incident report is a formal external reporting action that must be assessed against the applicable legal and factual situation.
Who should own the AI incident response plan?
Ownership usually sits across security, compliance, legal, product, risk, and business operations. A single coordinator should own the workflow, but evidence often comes from multiple teams.
Can this be used with an existing cyber incident process?
Yes. The practical approach is to add AI-specific classification, model-output preservation, human oversight, vendor, and Article 73 handoff steps to the existing process.
Source and review note
This page is educational. Review any legal, conformity, reporting, or sector-specific decision against Regulation (EU) 2024/1689, European Commission materials, national authority guidance, sector legislation, and qualified legal or conformity-assessment advice where relevant. EU AI Compass does not provide legal advice or certify compliance.