When AI Gets It Wrong: An Incident Response Plan for SMEs

AI incidents are business incidents, so plan for them like one

Most small businesses now have AI in the loop somewhere: a chatbot on the website, AI-drafted emails, automated review replies, a recommendation engine, or a model helping to screen CVs. Each one can fail in ways traditional software does not: confidently stating something false, exposing information it should not, or treating groups of people differently. The court cases are already real: an airline in Canada was held liable for a discount its website chatbot invented, and courts and regulators have shown little patience for the argument that "the AI said it, not us".

The core mindset shift: your AI's output is your output. Legally and reputationally, a chatbot's promise binds you much like an employee's would. So the response plan looks like a normal incident plan with three AI-specific additions: you must decide quickly whether to switch the system off, you must work out what else it may have said to other customers, and you must fix a system that cannot simply be patched like a line of code.

The three failure types and their first moves

Wrong advice or false promises to customers

The chatbot quotes a wrong price, invents a refund policy or gives incorrect product guidance. First moves: capture the full conversation transcript before anything is overwritten, honour reasonable commitments made to the affected customer (fighting a £40 goodwill gesture in public costs far more), and check logs for how many other conversations touched the same topic.

Data exposure

An AI tool reveals one customer's details to another, or staff have pasted confidential data into a consumer AI tool that trains on inputs. First moves: treat it as a potential personal data breach under UK GDPR from minute one, preserve evidence, and start the clock: if the breach is likely to risk people's rights and freedoms, you have 72 hours from becoming aware of it to report to the ICO.

Biased or offensive output

A CV-screening assistant disadvantages candidates with certain names; a generated image or reply causes offence. First moves: suspend the affected process (revert to manual screening), preserve the inputs and outputs that show the pattern, and remember the Equality Act 2010 applies to automated decisions exactly as it does to human ones.

Containment: your kill switch and the first hour

Every customer-facing AI system needs a documented kill switch: who can turn it off, how, and what replaces it. If disabling the chatbot means customers hit a dead end, your containment option is worse than the incident, so decide the fallback now (a contact form, a phone number, published FAQs). The first-hour checklist:

• 1. Confirm the report: reproduce the bad output or verify the screenshot against logs.
• 2. Assess blast radius: one conversation, one customer segment, or everything the system has said for weeks?
• 3. Decide: full shutdown, restricted mode (e.g. chatbot answers FAQs only, no pricing), or monitored continuation.
• 4. Preserve evidence: transcripts, prompts, system settings, model version and timestamps. You will need these for the post-mortem and possibly the ICO.
• 5. Name one incident owner. In a small business that is usually the MD or ops lead; the point is one person coordinating, not five people improvising.
• 6. Notify your suppliers if the fault may be in their platform; their logs and their fix timeline shape yours.

Customer communication that limits the damage

How you communicate matters more than the error itself. The principles are old-fashioned even if the failure is new:

• Contact affected customers directly before they find out another way. Say what happened, what it means for them, what you are doing and what they should do.
• Do not blame the machine. "Our automated assistant gave you incorrect information, and we're sorry" reads infinitely better than "the AI made an error".
• Honour reasonable commitments the system made; dispute only the genuinely absurd ones, and even then, generously.
• For data exposure, tell affected individuals promptly if there is a high risk to them; this is a UK GDPR duty, not just courtesy.
• Keep public responses calm and factual if the incident surfaces on social media or review sites. One measured reply beats ten defensive ones.

Prepare a two-paragraph holding statement template today, with blanks for the specifics. Drafting from scratch at 9pm during an incident produces worse results.

Regulatory duties: ICO, sector rules and contracts

For personal data incidents, the UK GDPR framework governs: assess risk, document everything (even breaches you decide not to report must be logged internally), report to the ICO within 72 hours where required, and notify individuals where risk is high. The ICO's guidance on AI and data protection is the reference point for what "reasonable" looks like.

Beyond data protection: consumer protection law covers misleading statements your AI makes about products and prices; the Equality Act covers discriminatory automated decisions; FCA-regulated firms have additional conduct and reporting obligations; and your client contracts may contain notification clauses that an AI incident triggers. If your AI supplier caused the fault, check your contract's liability and indemnity terms, but assume regulators will still hold you, the deploying business, primarily responsible for outputs you put in front of the public.

The post-mortem: fix the system, not just the symptom

Within a week of resolution, run a blameless post-mortem answering five questions: what happened, why did the system produce it, why didn't we catch it sooner, what did the response get right and wrong, and what changes now? AI-specific fixes to consider:

• Tighten the system prompt or configuration: forbid pricing quotes, refund promises and legal advice explicitly, and test that the restriction holds.
• Ground the system in approved content (retrieval from your real policies and price lists) rather than letting it answer from general knowledge.
• Add guardrails or output filters for topics that caused trouble, and an escalation path to a human for anything the system is unsure about.
• Introduce spot-check monitoring: a human reviews a sample of AI conversations weekly, with obvious errors fed back into testing.
• Update your staff AI policy: what tools are approved, what data may never be pasted into them, who owns each deployed system.
• Rerun the incident scenario as a test case before the system goes back to full service.

Then write the one-page plan you wish you had: kill-switch owner, fallback channel, first-hour checklist, holding statement, ICO decision tree. An hour of preparation now buys you calm later. If you would like help stress-testing a chatbot, adding guardrails or drafting your AI incident plan, our team can help.