AI incidents do not always look like traditional outages. A model can be online while producing harmful, biased, or confidential output. Customers may report problems before monitoring alerts fire. An AI tool incident response playbook gives teams shared language for severity, first-hour actions, and who speaks to users, regulators, and vendors.
Teams running AI customer service tools or public-facing AI chatbots should treat quality failures with the same discipline as availability failures. This guide covers incident types, severity levels, containment, notifications, and postmortems without waiting for legal to draft policy from scratch during an active event.
Incident Types: Quality, Privacy, and Availability
Classify AI incidents into quality, privacy, and availability. Quality incidents include wrong answers, toxic output, or automated actions that violate policy. Privacy incidents include training data leaks, prompt injection exposing secrets, or logs sent to the wrong tenant. Availability incidents include API downtime, rate-limit cascades, or feature flags stuck off.
Some events span categories. A hallucinated refund policy is quality until a customer acts on it, then it becomes financial and reputational. A logging misconfiguration can be privacy even when the chat UI still loads. Train on-call staff to pick a primary type for ticketing, then tag secondary types for routing.
| Type | Example signal | First owner |
|---|---|---|
| Quality | Spike in "wrong answer" tags | Product / AI ops |
| Privacy | Secret in model output or log export | Security / DPO |
| Availability | 5xx errors, empty responses | Engineering on-call |
Severity Levels and Response Times
Define severity by customer impact and data sensitivity, not by internal inconvenience. SEV1 affects many customers or involves confirmed data exposure. SEV2 affects a segment or risks exposure without confirmation. SEV3 is limited wrong output with workaround. SEV4 is internal-only or cosmetic. Attach response targets: acknowledge, mitigate, communicate, resolve.
Example targets: SEV1 acknowledge in 15 minutes, disable risky feature in 60 minutes, customer comms in 4 hours. SEV2 acknowledge in 30 minutes, mitigation in 4 hours. Document who can declare severity and who can downgrade it after mitigation. Severity inflation burns out teams; under-classification delays legal involvement when needed.
Post the severity matrix where on-call engineers already work: runbook repo, PagerDuty, or incident tool home screen. Include examples from past incidents so new responders do not debate whether a wrong medical disclaimer is SEV2 or SEV3 during active traffic. Review the matrix quarterly after postmortems and adjust thresholds when business risk profile changes.
Customer support should have a cheat sheet mapping user-visible symptoms to internal severity. "Bot gave wrong price" may be SEV2 while "bot is offline" may be SEV1 or SEV2 depending on revenue impact. Alignment between support and engineering on first triage reduces duplicate tickets and conflicting public statements.
Containment: Disable Feature, Rotate Keys
Containment stops bleeding before root-cause analysis. Common actions: disable the AI feature flag, route traffic to human agents, block the affected model version, rotate API keys and OAuth tokens, and purge cached prompts that may include injected content. Keep a runbook link in the on-call console with one-click toggles where possible.
For privacy incidents, preserve forensic logs according to legal hold policy, but stop further exfiltration immediately. For quality incidents, capture sample prompts and outputs with redaction for the postmortem. Do not delete evidence to "fix" the symptom unless retention policy requires it and counsel approves.
- Stop: Feature off or model pinned to last known good version
- Scope: Identify tenants, regions, and time window affected
- Protect: Rotate secrets; block abusive IPs or accounts if abuse-driven
- Communicate: Internal war room channel with single incident commander
Customer and Regulator Notifications
Notification timing follows policy and jurisdiction, not vendor convenience. Customer support needs approved holding statements before social media discovers the issue. Legal reviews breach notifications when personal data may be involved. Regulator timelines vary; your playbook should reference internal counsel contact, not generic advice.
Template elements: what happened, what data or service was affected, what customers should do, what you already did, and when you will update again. Avoid blaming the model vendor in public copy until facts are verified; coordinate messaging if the vendor shares responsibility. Log every external message version in the incident ticket.
Pre-draft holding statements for the three most likely AI failure modes in your product: offensive output, factual error with financial impact, and suspected data leak. Legal can review templates in calm periods so counsel is not drafting from scratch at 2 a.m. Replace placeholders with incident-specific facts during the event.
First-Hour Actions List for On-Call Responders
Minute 0-15: acknowledge alert, open incident channel, assign commander. Minute 15-30: classify type and severity, start containment (feature off or traffic shift). Minute 30-45: identify blast radius, preserve logs, notify executive sponsor if SEV1. Minute 45-60: draft internal status, loop customer support, schedule first external update if required.
Print this list in the runbook and practice it in tabletops. AI incidents reward fast containment over immediate root-cause analysis. Understanding why the model misbehaved matters, but stopping ongoing harm to customers comes first.
Roles and Responsibilities During AI Incidents
Incident commander owns timeline and severity. Technical lead runs containment and root-cause investigation. Communications lead drafts internal and external messages. Legal and privacy join for data exposure. Customer support lead updates macros and agent scripts. Executive sponsor joins SEV1 bridges and approves customer notifications.
Document contact methods for each role: phone, Slack handle, and backup. AI incidents often start outside business hours when models auto-update or traffic spikes. On-call rotations should include someone who can disable feature flags without waiting for the original developer.
Vendor liaison role matters when the failure is upstream. One person owns the vendor bridge so engineering is not answering duplicate questions. Vendor liaison tracks vendor ticket IDs and ETA in the internal incident channel every thirty minutes during SEV1.
Frequently Asked Questions
What belongs in an AI incident postmortem?
Timeline, detection gap, containment actions, customer impact count, root cause, corrective actions with owners, and whether monitoring or policy should change. Include prompt or config diffs if a deployment triggered the event. Blameless culture still requires accountability for follow-through dates.
How do we coordinate with the AI vendor during an incident?
Open a joint bridge with your account team and their engineering contact. Share request IDs, model IDs, and timestamps in UTC. Ask for written confirmation of their scope and ETA. If the vendor is silent past SLA, escalate through commercial contacts documented in your QBR files.
Should we run tabletop exercises for AI incidents?
Yes, quarterly for customer-facing AI. Scenarios: prompt injection exfiltrating an API key, sudden toxic output after a model upgrade, and regional API outage during a product launch. Tabletops expose missing phone trees and outdated runbooks before real users are affected.
Debrief every tabletop with three improvements: update runbook text, fix alerting gaps, and assign owners with due dates. Tabletops without follow-up become theater. Track improvements in the same incident tool you use for real events so leadership sees closure.
When is a quality issue treated like an outage?
When wrong output reaches customers at scale or triggers automated downstream actions. A single bad answer may be SEV3; a template bug affecting every refund estimate is SEV1 or SEV2. The playbook should list workflow-specific examples so on-call does not debate severity during peak traffic.
Maintain a living register of AI features with customer impact tier. Registration happens at launch, not during the first incident. Features handling payments, medical information, or legal advice default to higher baseline severity regardless of uptime metrics.
Practice the playbook twice before you need it: once in a tabletop, once during a controlled feature disable in staging. Teams that only write runbooks discover missing phone numbers and unclear authority during real events. AI incidents reward preparation because harm can spread through generated text faster than through a traditional service outage.
Link postmortems to backlog items: prompt changes, monitoring alerts, training updates, and vendor requirements. Incidents without tracked follow-up repeat. Sponsors should see incident trends in monthly steering the same way they see adoption metrics.
Customer-facing AI needs communication templates in the same repo as technical runbooks. Support agents should not invent explanations during an active quality incident. Pre-approved language for "we disabled the feature while we investigate" reduces legal risk and aligns messaging across email, chat, and social channels.
Regulator notifications belong in the playbook as decision trees, not prose essays. Legal owns the final call; engineering owns timestamps and scope evidence. Privacy incidents may require different timelines than quality incidents even when both started in the same chat session.
Vendor coordination during incidents requires a single liaison, shared timeline in UTC, and written confirmation of vendor scope. Postmortems should include vendor accountability when upstream model changes caused harm. Feed postmortem actions into QBR prep so recurring vendor failures influence renewal posture before the next contract cycle.
Severity matrices should list example incidents per level so on-call responders classify quickly during stress. Availability failures and quality failures can overlap; pick a primary type for ticketing and tag secondary types for routing. Containment actions (disable feature, rotate keys, shift to human agents) belong in runbooks with one-click toggles where engineering can implement them. Communication templates for customers and regulators should be pre-approved by legal and stored beside technical steps.
Run tabletop exercises quarterly and update the playbook after every SEV1 or SEV2 event. Store playbooks beside on-call runbooks, not in a policy folder nobody opens during outages. AI incident response matures when teams practice containment before customers teach them what went wrong.
