How do we mitigate the risk of hallucinations or errors in customer-facing AI?

6 July 2026

The real risk is not a weird answer. It is an unreviewed answer in the wrong place.

Hallucination is the polite term for an AI system producing an answer that sounds confident but is wrong, unsupported, invented or misleading. In customer-facing AI, that can mean quoting a refund policy that does not exist, giving the wrong delivery instruction, promising a discount, making an inaccurate compliance statement, or mishandling a complaint.

That risk is not theoretical. In January 2024, the BBC reported that DPD disabled part of its chatbot after a customer got it to swear and criticise the company. DPD said the issue followed a system update. That example matters because it was not a futuristic edge case. It was a familiar customer service setting, a known brand, and a public loss of control. BBC News reported the DPD chatbot incident.

The risk is growing because AI use is moving from experiments into ordinary operations. GOV.UK's AI activity research found that around 15% of UK businesses had adopted at least one AI technology, equal to about 432,000 companies. Large companies were already much further ahead, with 68% having adopted at least one AI technology. GOV.UK published the AI activity figures.

Customer-facing AI should therefore be treated like a controlled service channel, not a website widget. The business question is not "can we stop hallucinations completely?" You cannot. The useful question is "what level of error is acceptable, and what controls make that level measurable?"

What controls actually reduce hallucinations?

The first control is scope. A customer service AI should have a written answer boundary: what it can answer, what it must refuse, and what it must escalate. A support bot for an accountancy firm, for example, might answer questions about opening hours, document upload steps and appointment booking. It should not give tax advice, quote HMRC deadlines from memory, or assess whether a client's expense is allowable unless the firm has approved that exact content and accepts the risk.

The second control is grounding. For most business use cases, that means retrieval augmented generation, often called RAG. The AI retrieves relevant passages from an approved knowledge base before answering. It is still a language model, so it can still make mistakes, but it is no longer freewheeling from general training data. It is being pushed towards your policies, your product information, your service terms and your approved answers.

The third control is refusal design. Good customer-facing AI should say "I do not know" more often than a salesperson wants. If the answer is not in the approved knowledge base, it should refuse or escalate. A wrong answer delivered confidently is worse than a slightly disappointing handover to a human.

The fourth control is deterministic behaviour where possible. Not every part of the journey needs generative AI. Use fixed buttons, form fields, rules, validation, CRM lookups and scripted answers for high-volume tasks. Use AI where language flexibility genuinely helps, such as understanding a messy customer query or summarising a case for a human. The less freedom the model has, the fewer ways it has to invent.

The fifth control is risk-tiered human review. You do not need a human to approve every answer about opening hours. You probably do need human review for complaints, refunds, regulated advice, safeguarding issues, legal wording, pricing exceptions, account closures and anything involving vulnerable customers.

A practical UK SME setup usually looks like this:

What should be tested before launch?

Do not test a customer-facing AI by asking it five friendly questions and calling it done. That is not testing. That is a demo.

Before launch, build a test set of at least 100 realistic customer questions for a narrow bot and 300-1,000 for a broader service assistant. Include normal questions, vague questions, angry questions, prompt injection attempts, policy edge cases, typos, ambiguous requests, and questions the AI must refuse. If the system will operate across multiple product lines or customer types, test each one separately.

Track four numbers before launch. First, answer accuracy: how often the answer matches approved policy. Second, unsupported claims: how often it says something that cannot be found in the source material. Third, escalation accuracy: how often it hands off when it should. Fourth, containment quality: how often it solves low-risk questions without a human.

For a genuinely customer-facing system, a sensible pre-launch bar is 95%+ accuracy on low-risk approved questions, 0 critical failures in the test set, and at least 90% correct escalation on high-risk questions. If that sounds strict, it should. A customer-facing bot is cheaper than a trained employee only if it does not create expensive clean-up work.

You should also red-team the system. That means deliberately trying to make it fail. Ask it to ignore previous instructions. Ask it to reveal hidden prompts. Ask it to invent policy. Ask it to compare your company with a competitor. Ask it for legal, medical, tax or financial advice even if your business does not offer those services. Customers will do strange things. Some will do them accidentally. Some will do them deliberately.

Testing costs money. For a simple SME customer service AI, budget £1,000-£3,000 just for proper test design, review and remediation. For a regulated or high-volume deployment, £5,000-£20,000 is normal because the review work involves policy owners, compliance, customer service leads and technical people.

What UK legal and regulatory issues matter?

If your AI processes personal data, UK GDPR matters. The ICO's AI and data protection guidance has a dedicated section on accuracy and statistical accuracy, and it places AI accuracy inside the broader data protection principles. The practical implication is that you need to understand and document how reliable the system is for its intended use, especially where personal data or inferred information is involved. The ICO publishes guidance on AI and data protection.

Do not hide behind "the model made a mistake". The customer contracted with you, complained to you, trusted your brand, and gave data to you. If the AI gives a harmful or misleading answer, the responsibility does not sit with OpenAI, Anthropic, Google, Microsoft, Zendesk, Intercom or whichever platform is under the bonnet. The responsibility sits with the business deploying it.

The UK's AI regulation approach also emphasises safety, security and robustness, appropriate transparency and explainability, fairness, accountability and governance, and contestability and redress. Those are not abstract principles. In customer service terms they mean customers should know when they are dealing with AI, the business should have logs and ownership, and customers should have a route to challenge or escalate an answer. GOV.UK sets out the UK AI regulation principles.

Security also matters because hallucination risk and security risk overlap. A prompt injection attack can make a bot ignore instructions, reveal data, produce unsafe answers or take actions it should not take. GOV.UK's Cyber Security Breaches Survey 2025 found that 43% of businesses reported a cyber breach or attack in the previous 12 months, equal to about 612,000 UK businesses. The same report noted growing awareness that AI impersonation was becoming mainstream. GOV.UK published the Cyber Security Breaches Survey 2025.

How much mitigation is enough?

Enough mitigation depends on the harm a wrong answer can cause. A restaurant booking assistant can tolerate more imperfections than an insurance claims assistant. A B2B software support bot can usually escalate safely. A healthcare, legal, financial, HR or safeguarding bot needs much tighter control and may not be suitable for autonomous answers at all.

Use this blunt test: if a wrong answer would only annoy a customer, you need logging, a knowledge base and a route to a human. If a wrong answer would cost money, break a contract or trigger a formal complaint, you need pre-launch testing, risk-tiered escalation, owner sign-off and weekly monitoring. If a wrong answer could harm someone's rights, health, finances or legal position, the AI should not make the decision. It should collect information and assist a qualified human.

For UK SMEs, the budget usually falls into three bands. A basic controlled FAQ bot is around £3,000-£8,000 to set up properly, assuming the content already exists. A more capable support assistant connected to CRM, ticketing or booking systems is commonly £10,000-£30,000. A regulated, audited or high-volume customer service implementation can easily reach £50,000+ once you include integration, testing, monitoring, governance and staff training.

Cheap tools are not automatically bad. Intercom, Zendesk, HubSpot, Microsoft Copilot Studio and other established platforms can be a sensible starting point. The problem is not the tool. The problem is switching it on with vague website content, no test set, no escalation design and no named owner.

When this does NOT apply

This level of mitigation does not make sense for every AI use. If the system is an internal drafting assistant and every output is reviewed by a competent person, a full customer-facing control framework is probably overkill. You still need privacy, security and staff guidance, but you do not need a formal escalation tree for every answer.

It also may not apply if your customer questions are better solved with traditional automation. If 90% of queries are "where is my order?", "can I book an appointment?" or "what documents do you need?", start with structured forms, rules and integrations. Add generative AI only where it improves the journey.

Finally, it does not apply if you are not willing to maintain the knowledge base. A customer-facing AI with stale source material is worse than no AI at all. If nobody owns policy updates, product changes, pricing changes and complaint feedback, do not launch the bot yet.

The practical implementation checklist

Start with a written risk register. List the top 20 things the AI must not get wrong. Include refunds, pricing, legal wording, eligibility, safety, complaints, personal data, deadlines and anything that has caused customer disputes before.

Then build the knowledge base. Use approved policy pages, service descriptions, terms, pricing notes, product documentation and internal support scripts. Remove contradictions before the AI sees them. If your source material is messy, the AI will faithfully expose that mess to customers.

Next, define answer rules. The system should cite or rely on approved sources, refuse unsupported questions, avoid regulated advice, avoid promises, and escalate emotional or high-risk cases. Add conversation logging and make sure a named person reviews failures every week for the first 90 days.

Finally, measure live performance. Track hallucination reports, escalation rate, complaint rate, correction rate, customer satisfaction and time saved. The first month after launch is not the finish line. It is the point where real testing begins.

If you want to explore whether customer-facing AI makes sense for your business, start with an AI audit or a focused support workflow review. Book a free call and we will tell you honestly whether AI is the right tool, or whether your process needs fixing first.

Is This Right For You?

This approach is right for you if the AI will answer real customers, affect revenue, mention policies, handle personal data, support regulated decisions, or represent your brand in public. If the answer could cost money, create a complaint, mislead a vulnerable customer, or damage trust, you need controls before launch.

This does not apply in the same way if the AI is only used internally for rough drafting, brainstorming, or summarising low-risk information that a trained employee reviews before use. In that case, you still need data protection controls, but you may not need a full customer-facing governance layer.

The honest line is simple: if you would not let a junior employee answer the question without training, supervision and escalation rules, do not let an AI answer it without the same controls.

Frequently Asked Questions

Can hallucinations be eliminated completely?

No. Any generative AI system can produce a wrong or unsupported answer. The goal is to reduce the likelihood, limit the impact, and make failures visible quickly.

Is RAG enough to stop customer-facing AI errors?

No. RAG helps because it grounds answers in approved content, but it is not a complete control system. You still need refusal rules, testing, escalation, monitoring and ownership.

Should a customer-facing AI mention that it is AI?

Yes. Customers should not be tricked into thinking they are speaking to a human. Clear disclosure also sets expectations and supports the UK principle of appropriate transparency.

Who is responsible if the AI gives a wrong answer?

The deploying business is responsible to the customer. Vendors may have contractual responsibilities, but the customer-facing duty sits with the company using the AI.

What questions should customer-facing AI always escalate?

Escalate complaints, refunds, regulated advice, legal or financial decisions, safeguarding concerns, vulnerable customer issues, account closures, pricing exceptions and anything outside the approved knowledge base.

How often should an AI knowledge base be reviewed?

Review it whenever policies, pricing or products change, and at least monthly for an active customer-facing system. During the first 90 days after launch, review failures weekly.

Is it safer to use Microsoft Copilot, Intercom or Zendesk than a custom AI build?

Established platforms can reduce infrastructure risk, but they do not remove operational risk. A poorly scoped bot on a trusted platform can still give bad answers if the content, rules and monitoring are weak.