AI Incident Response Runbooks for Customer-Facing Automation

AI Trust & Governance

29 July 2026 | By Ashley Marshall

Customer-facing AI does not fail like ordinary website copy. A wrong answer from a chatbot, voice bot, quoting assistant or agentic workflow can become a customer complaint, a data protection incident, a financial correction and a reputational problem within minutes.

Treat a bad AI answer as an operational incident

The first mistake is to call a customer-facing AI failure a content issue. If a chatbot gives the wrong refund policy, a voice assistant mishandles a vulnerable customer, a sales agent sends an unauthorised offer or an automated support workflow exposes another customer's context, the problem is not just tone. It is an operational incident with customer impact, evidence requirements and possible legal duties. That is why a runbook matters before the first public failure, not after the social media screenshots have already spread.

The DPD chatbot incident is a useful warning because it was ordinary, visible and fast. The BBC reported in January 2024 that DPD disabled part of its online support chatbot after a system update caused it to behave unexpectedly, including swearing at a customer and criticising the company. DPD said the AI element was immediately disabled and updated. That is exactly the kind of incident UK businesses should plan for: a customer-facing system changed, a customer found the failure mode, and containment had to happen in public.

Customer-facing automation is broader than chatbots. It includes Intercom Fin, Zendesk bots, HubSpot chatflows, Salesforce Einstein features, Microsoft Copilot Studio agents, Google Dialogflow voice flows, ecommerce returns assistants, appointment booking agents, affordability triage tools and AI-assisted complaint drafting. Some systems only suggest an answer to staff. Others send messages, update CRM records, trigger refunds or route customers away from a human. The more direct the customer impact, the more the runbook needs to look like incident response, not moderation.

In practice, define an AI incident as any AI behaviour that creates or could create customer harm, incorrect commitments, privacy exposure, discriminatory treatment, unsafe advice, unauthorised action, service disruption or loss of trust. This sits alongside your wider cyber and operational resilience process. If you have already read our guide on hallucination risks in customer-facing AI, the runbook is the response layer that says what happens when prevention does not hold.

Classify severity around customers, data and time

A runbook that starts with technical severity will miss the point. The first triage question is not whether the model is down. It is whether customers were misled, blocked, exposed, charged, denied service, profiled unfairly or routed away from human help. A broken answer in an internal test environment is low severity. The same answer in live customer support may be high severity if it affects money, health, legal rights, complaints, accessibility needs or vulnerable customers.

UK data protection duties make timing explicit. The ICO's personal data breach guidance says organisations must assess the likely risk to people's rights and freedoms. If a risk is likely, they must notify the ICO as soon as possible and, where feasible, within 72 hours. If the risk to people is high, they must also notify those people without undue delay. An AI incident is not automatically a personal data breach, but the runbook must force the assessment quickly when personal data, account context, support history, payment detail or private inference is involved.

Build a severity matrix with five customer-centred tests. First, scale: how many conversations, calls, quotes, cases or customers are affected? Second, sensitivity: did the automation process personal data, special category data, financial information, complaint data or private account history? Third, consequence: did it make a commitment, refuse help, create a payment, change a record or give advice that a customer could rely on? Fourth, reversibility: can the business correct the outcome quickly without more harm? Fifth, confidence: can you prove what happened from logs, prompts, retrieval records and tool calls?

Assign names, not committees. The incident lead owns the clock. The customer impact lead owns affected customer lists and remediation. The privacy lead owns breach assessment. The product or automation owner owns containment decisions. The communications owner controls external messaging. In a smaller business, one person may hold two roles, but the runbook should still separate the decisions. During an incident, ambiguity is expensive.

Contain the automation before it creates more evidence

Containment has to be specific to the automation. Telling staff to watch the chatbot more closely is not a control if the system is still sending answers faster than humans can review them. The runbook should state exactly who can disable each customer-facing AI pathway, which switch they use, what fallback journey customers see and which connected permissions are revoked or paused. A serious AI runbook has a kill switch, but it also has a graceful fallback.

The UK government's Code of Practice for the Cyber Security of AI gives useful anchors. DSIT says developers and system operators shall create, test and maintain an AI system incident management plan and an AI system recovery plan. It also says system operators shall log system and user actions to support security compliance, incident investigations and vulnerability remediation. The same code notes that the proposed intervention was endorsed by 80 percent of respondents to DSIT's 2024 call for views. That is a clear signal that AI incident planning is no longer a niche security topic.

Containment options should be pre-approved. For a support chatbot, disable autonomous replies and route to human queue. For a quoting assistant, stop sending prices externally and switch to manual approval. For a returns bot, freeze automatic refund decisions. For a voice assistant, transfer sensitive intents to trained staff. For an agent with CRM write access, revoke write permissions while leaving read-only investigation available. For a retrieval augmented generation system, remove or quarantine suspect knowledge base documents, but preserve the version that was live at the time of the incident.

Preserve before you overwrite. Do not immediately clean prompts, delete bad examples, retrain the model or purge traces before evidence is secured. Capture conversation IDs, timestamps, customer identifiers, model and vendor version, system prompt version, retrieval documents, tool calls, staff overrides, webhook payloads and permissions active at the time. If you have already invested in rollback plans and kill switches, this is where that work pays for itself.

Build an evidence log a regulator can read

AI incident evidence is more complicated than a screenshot. Screenshots matter, especially where the customer has seen the output, but they are not enough to explain why the incident happened or prove which customers were affected. A useful evidence log records the customer journey, the automation path, the decision points and the system state at the time. The aim is to let a privacy lead, insurer, solicitor, regulator or board member understand what happened without reverse engineering the whole AI stack from memory.

The NCSC incident management collection frames incident response around preparation and the wider life cycle of identify, protect, detect, respond and recover. It also says the incident response plan should link to disaster recovery, business continuity and crisis management plans. For AI, that linkage is important. A customer-facing bot failure may start in support, but it can touch legal, privacy, cyber security, product, communications, finance and account management within the same hour.

Your evidence log should have two layers. The first is the incident timeline: detection time, reporter, affected channels, first containment action, customer impact assessment, privacy assessment, communications decisions, recovery steps and closure. The second is the AI technical pack: prompt version, model identifier, vendor, deployment environment, retrieval sources, knowledge base version, moderation settings, guardrail configuration, confidence thresholds, tool permissions, API keys or OAuth scopes, human approval settings and relevant logs. Keep enough detail to support root cause analysis, but avoid copying unnecessary personal data into the incident record.

A practical implementation angle: create the evidence template before launch and store it beside the automation's service record. For example, a Zendesk bot should have a linked evidence checklist covering Zendesk conversation IDs, macro IDs, article versions, OpenAI or Anthropic model settings, middleware logs and escalation rules. A Microsoft Copilot Studio workflow should have its topic version, connector permissions, environment, Dataverse records and Power Automate run history. Evidence quality improves when teams know what to collect before the incident.

Communicate without creating a second incident

Customer communication is where many AI incidents get worse. A vague apology that says the system behaved unexpectedly may not be enough if customers relied on the answer, were denied a service, had personal data exposed or were misrouted during a complaint. Equally, over-sharing unverified technical detail can create unnecessary alarm and undermine later investigation. The runbook should set a simple rule: communicate early enough to reduce harm, but only with facts the business can stand behind.

The AI Incident Database's guide to AI incident responses says a useful response should contain reasonably adequate information about what happened, why it happened, what the entity has done or will do to remediate it, and how it will prevent recurrence. That is a good communication frame for customer-facing automation. Customers do not need a lecture on transformers or prompt injection. They need to know whether they were affected, what to do next, whether a human will review the case and whether the company will honour or correct the AI-generated outcome.

The DSIT AI cyber code also matters here because Principle 10 covers communication and processes associated with end-users and affected entities. It says developers and system operators should support end-users and affected entities during and following a cyber security incident to contain and mitigate impacts, and that the process should be documented and agreed in contracts with end-users. Even where the incident is not a cyber attack, the same discipline is useful: define who tells customers, who tells suppliers, who tells enterprise clients and who approves the message.

Prepare three message types. First, a holding message for customers in the affected journey: we are reviewing recent AI-assisted interactions and a human will follow up. Second, an individual remediation message: what happened in this customer's case, what has been corrected and where to get help. Third, a client or partner message for B2B relationships: scope, containment, data protection status, contractual implications and recovery timetable. Do not let the AI system draft and send its own incident communications without human approval. That shortcut is how a first incident becomes a second one.

Rehearse the runbook before the first live failure

The common misconception is that AI incident runbooks are only for banks, insurers or large platforms. That is wrong. Regulated firms have stronger formal obligations, but any UK business putting automation in front of customers needs a proportionate response plan. The question is not whether the company has a security operations centre. The question is whether someone can detect the failure, stop the harm, find the affected customers, preserve evidence, assess duties and recover the service without improvising under pressure.

FCA operational resilience guidance is a useful benchmark even for businesses outside financial services. The FCA says in-scope firms had until 31 March 2025 to ensure they could operate important business services within impact tolerances. It also says firms should identify important business services, set impact tolerances for maximum tolerable disruption, perform mapping and testing, and develop internal and external communications plans for disruption. Customer-facing AI can sit inside exactly that kind of important business service: support, onboarding, claims, renewals, payments, complaints or account access.

Rehearsal should be practical and short. Run a 60-minute tabletop exercise every quarter for high-risk customer-facing automation. Pick one severe but plausible scenario: the bot gives an unlawful refund refusal, the AI assistant leaks another customer's address in retrieval context, a voice bot fails to identify vulnerability, an agent sends a misleading contract term, or a model update changes escalation behaviour. Walk through detection, severity, containment, evidence, customer communication, ICO assessment, supplier escalation and recovery. Capture gaps as backlog items with owners and dates.

For smaller businesses, start with a one-page runbook. List live AI systems, owners, kill switches, fallback journeys, evidence sources, customer impact tests, privacy contacts, supplier contacts and restart criteria. Add a short incident form. Add a review date. As maturity improves, connect the runbook to monitoring, audit trails, supplier contracts and post-incident reviews. The goal is not bureaucracy. The goal is to make customer-facing automation reversible, accountable and trusted enough to use in real business processes.

Frequently Asked Questions

What counts as an AI incident in customer-facing automation?

An AI incident is any AI behaviour that creates or could create customer harm, incorrect commitments, privacy exposure, discriminatory treatment, unsafe advice, unauthorised action, service disruption or loss of trust.

Does every AI chatbot failure need to be reported to the ICO?

No. Reporting depends on whether there has been a personal data breach and whether the breach is likely to risk people's rights and freedoms. The runbook should still force that assessment quickly.

What should be in a basic AI incident response runbook?

Include live systems, owners, severity criteria, kill switches, fallback journeys, evidence sources, privacy assessment steps, supplier contacts, customer communication templates and restart criteria.

Who should own the runbook?

The business owner of the customer journey should own the runbook, with support from technology, privacy, security and customer operations. AI risk is a business process issue, not only an IT issue.

What evidence should we preserve during an AI incident?

Preserve timestamps, conversation IDs, customer impact lists, prompts, model versions, retrieval documents, tool calls, logs, permissions, moderation settings, staff overrides and containment actions.

Should we switch the AI off immediately?

Switch it off or reduce its authority when there is live customer harm, privacy risk or unclear scope. For lower-risk issues, you may route sensitive intents to humans, disable write actions or narrow permissions while investigating.

How often should AI incident runbooks be rehearsed?

High-risk customer-facing automation should be rehearsed at least quarterly or after major model, prompt, supplier or workflow changes. Lower-risk systems can be reviewed less often, but still need an owner and test date.

Is this overkill for a small UK business?

No, if the automation talks to customers, handles personal data or can make commitments. A small business can start with a one-page runbook, named owners and a clear switch-off process.