AI incidents rarely look like outages
During cloud data migration, I paid close attention to jobs that completed successfully but delivered incomplete data. An outage brought people to the problem quickly; a quiet data defect could make its way into a report before anyone noticed. That experience shapes how I think about AI incident response. The runbook needs to cover incorrect or inappropriate results as carefully as it covers an unavailable service.
Enterprise AI is the same. An assistant can stay available while returning information outside a user's scope, presenting stale data as current or claiming an action succeeded when the outcome is uncertain. Define the events that require intervention for your actual workflow and classify them by consequence. An unavailable source, an incorrect explanation and a possible disclosure need different response paths. A single catch-all label leaves operators guessing whether to investigate next week or disable a capability now.
Name the people before you need them
Keep the first runbook short enough to use under pressure. Identify the first responder, the person authorized to pause the workflow and the business owner who decides how users should proceed. Connect it to existing incident management and security reporting. If responsibilities overlap, settle who leads before an incident occurs; two teams each expecting the other to act can lose valuable time.
In my Claude rollouts I push for this before the pilot widens, not after. Security first means identity, permissions and data boundaries are decided up front, and the response plan is part of that boundary.
Rehearse containment, including partial failure
Document how to disable a connection, restrict a user group or stop a single capability, and test it in a controlled exercise. Confirm what users will see and which approved alternatives remain available.
Plan for partial failure. If one source stops responding, the assistant should not quietly assemble a complete-looking answer from what remains when that changes the decision. Tell operators how to detect partial coverage and how the interface communicates it.
Do not confuse technical recovery with business recovery. Restarting a service does not retract a misleading answer already shared in a credit committee or a clinical operations meeting. Track the two as related but separate workstreams with separate owners.
Preserve evidence without creating a second exposure
Identify the minimum records needed to understand an incident: timestamps, configuration, request identifiers, source status and reviewed outputs where policy permits. Do not paste unrestricted prompts or source records into an incident channel. Investigating a possible disclosure should not create another one, a point any HIPAA privacy officer or bank CISO will make quickly.
Separate observed facts from hypotheses in the notes. Early guesses have a way of becoming the official explanation unless the record shows what was known at each stage.
Route privacy, security and regulatory questions to the teams responsible for them. A technical runbook should not invent legal conclusions or promise a notification timeline. Those determinations belong to counsel, compliance and the privacy office.
Practice communication, restoration and learning
Prepare simple user messages for unavailable, limited and restored service, and tell users what they can safely do next. Never show “no exceptions found” when the system could not evaluate the exceptions at all. I consider that the single most important wording rule in any AI runbook.
Before restoring a capability, rerun the relevant evaluation cases and confirm the containment condition is resolved. Record who approved restoration and any temporary limits. If the root cause is still uncertain, the business owner should know that before users resume relying on the workflow.
Run a tabletop on a stale-source scenario: one person plays the user, one the operator, one the business owner. Walk through detection, containment, communication and restoration without touching production, and note every point where people disagree about authority. Then hold a retrospective that produces specific changes with owners. Use the revised runbook in a second walkthrough if the first exposed unresolved responsibilities.