Enterprise AI · incident response · evidence
For CIO, CISO, risk, product and platform teams putting AI agents, LLM apps or production AI systems in front of staff or customers: use this runbook to prove who detects, decides, rolls back, communicates and records evidence when AI behaves unexpectedly.
No search ranking, buyer demand, impressions, incident outcome, compliance status or customer use is claimed. This page is a public readiness and indexing asset that gives buyers concrete proof language before procurement, risk review or production rollout.
Related discovery file: llms.txt.
| Evidence area | What must be recorded | Owner question | Unsafe shortcut to avoid |
|---|---|---|---|
| Detection | Alert source, affected workflow, first observed time, model/app version and monitoring signal. | “How did we know something was wrong?” | Relying only on user complaints or chat screenshots. |
| Severity triage | Customer impact, data sensitivity, business process affected, repeatability and whether human review is required. | “Who can declare Sev-1, Sev-2 or low-risk?” | Letting the same builder self-classify every incident without review. |
| Containment | Feature flag, prompt/tool disablement, traffic pause, rate limit, access revocation or model fallback decision. | “What can we safely stop within minutes?” | Debating root cause while the risky path stays live. |
| Rollback | Approved previous version, data migration impact, dependency owner, test evidence and rollback timestamp. | “Can we restore the last known-safe path?” | Assuming prompt edits are reversible without version evidence. |
| Customer and internal comms | Audience, message owner, approval gate, facts known, facts unknown and follow-up cadence. | “Who speaks, and what can they safely say?” | Speculating about legal, privacy or regulatory conclusions. |
| Post-incident review | Root cause hypothesis, control gaps, corrective actions, accountable owner, due date and verification evidence. | “What proof shows this failure mode is less likely now?” | Closing the ticket with no control change or test artifact. |
No real customer, incident, breach, outage, certification, regulator approval, revenue, ranking, testimonial, legal conclusion or compliance status is claimed. This is a buyer-safe operational template, not legal, cybersecurity, insurance, clinical, financial or regulatory advice.
AI systems can fail through prompts, tools, retrieval, model changes, policy gaps, data boundaries and human handoff issues. A generic software incident plan often misses evidence needed to explain, contain and safely roll back those failures.
The accountable owner should be a business or platform leader with named support from security, legal/privacy, product and operations. Ownership should not sit only with the model builder or vendor.
It turns AI assurance from vague governance language into a procurement-ready artifact that risk-aware buyers can evaluate before paying for a diagnostic or managed AI operations engagement.