/ THE SHORT ANSWER
Define incident classes, severity, detection signals, owners, containment actions, evidence preservation, communication, recovery criteria, and post-incident review before launch. The immediate objective is to reduce harm and stop propagation: pause tools, narrow permissions, switch to a manual path, isolate affected data, or roll back. Preserve prompts, sources, model and system versions, actions, users, and timestamps so the team can understand what happened.
- 01Prepare containment and manual fallback before production.
- 02Preserve enough context to reconstruct the system state.
- 03Turn incidents and near misses into evaluation and control updates.
/ dotSuper point of view
AI incident response must cover the whole socio-technical system. The harmful event may begin in a source, prompt, permission, model, tool, interface, human decision, or missing control.
What the evidence says
NIST’s AI RMF includes governance and management activities for prioritising, responding to, communicating, and learning from AI risks.
OWASP’s LLM risk guidance covers prompt injection, sensitive-information disclosure, supply-chain issues, improper output handling, excessive agency, and unbounded consumption relevant to incident scenarios.
A practical decision framework
The following framework is dotSuper’s operating synthesis of the cited guidance. It is designed to make the decision inspectable, not to imitate a platform ranking formula, certification checklist, or legal test.
- Detect: monitoring, user report, anomaly, evaluation failure, supplier notice, or cost alert.
- Contain: pause, isolate, revoke, restrict, roll back, switch to manual, and preserve evidence.
- Recover: validate the fix, restore gradually, communicate, and monitor heightened signals.
- Learn: root and contributing causes, evaluation cases, control updates, ownership, and follow-up.
| Step | Decision to record |
|---|---|
| 01 | Detect: monitoring, user report, anomaly, evaluation failure, supplier notice, or cost alert. |
| 02 | Contain: pause, isolate, revoke, restrict, roll back, switch to manual, and preserve evidence. |
| 03 | Recover: validate the fix, restore gradually, communicate, and monitor heightened signals. |
| 04 | Learn: root and contributing causes, evaluation cases, control updates, ownership, and follow-up. |
How to put it into practice
Run tabletop exercises for data disclosure, unsafe output, wrong external action, corrupted source, provider outage, runaway cost, and silent quality drift. Include business, technical, security, and communications owners.
Define a minimum incident record with system version, model, prompts, sources, retrieved context, tools, permissions, inputs, outputs, actions, reviewer decision, and consequence.
- Name the accountable owner and the decision this work must enable.
- Record the current evidence, assumptions, exclusions, and next review trigger.
- Measure a useful outcome rather than treating publication or deployment as success.
What this page cannot conclude
- 01Incident obligations vary by sector, contract, geography, and affected data or people.
- 02This runbook does not replace cybersecurity, privacy, safety, legal, or regulatory response plans.
- 03Publication, technical eligibility, or good practice cannot guarantee ranking, referral traffic, citation, adoption, or a business outcome.
Sources
- 01AI Risk Management FrameworkNational Institute of Standards and Technology · accessed Aug 30, 2026
- 02Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence ProfileNational Institute of Standards and Technology · accessed Aug 30, 2026
- 03OWASP Top 10 for LLM Applications 2025OWASP GenAI Security Project · accessed Aug 30, 2026
Make improvement a maintained operating rhythm.
The Optimisation Subscription keeps evaluation, governance, content, workflows, and product improvements moving as small accountable projects.
Explore the subscription