AI incidents are workflow incidents
An AI incident is not only a model behaving badly. It can be a privacy event, harmful output, unsupported recommendation, unauthorised tool action, source failure, model drift, or a workflow where people relied on AI outside its approved purpose.
Incident response should therefore cover both technical evidence and operational impact. The response team needs to know what happened, who was affected, which systems were involved, and how to stop further harm.
Define severity levels
Severity levels help teams respond consistently. A low-severity incident may be a corrected internal answer. A high-severity incident may involve sensitive data exposure, customer impact, safety concerns, legal obligations, or automated action outside approval.
Severity should be based on impact and exposure, not on whether the error looks dramatic in isolation.
- Severity 1: sensitive data, safety, legal, or external harm risk.
- Severity 2: customer-visible error, material workflow failure, or repeated unsafe output.
- Severity 3: internal error corrected before use.
- Severity 4: near miss or weak signal for monitoring.
Capture evidence immediately
Evidence can disappear quickly when prompts, sources, models, tools, or permissions change. Teams should capture the prompt, output, source documents, model version, tool calls, user role, timestamps, logs, reviewer actions, and downstream effects.
Evidence capture should respect privacy controls. Store only what is needed for response, limit access, and redact sensitive fields where possible.
Contain the workflow
Containment can mean disabling a feature, narrowing permissions, rolling back a prompt, removing a source, pausing an agent tool, or requiring manual review until the issue is understood.
The response plan should make containment authority clear. In urgent cases, teams need permission to pause a workflow without waiting for a long approval chain.
Communicate with precision
Incident communication should be specific, measured, and evidence-based. Internal teams need clear instructions on whether to keep using the system, change review behaviour, or route affected cases through manual handling.
External communication depends on impact, contract terms, legal requirements, and user expectations. Avoid broad claims until evidence is complete, but do not hide operational guidance from affected teams.
Turn incidents into controls
The post-incident review should produce product and governance changes: better tests, clearer user interface language, stronger permissions, updated sources, new monitoring, revised risk tier, or narrower approved use.
The best incident response plan is a learning system. Each incident should reduce the chance of repeated failure.
