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

3 August 2026

Why do customer-facing AI hallucinations happen?

Customer-facing AI hallucinations happen because large language models generate plausible language, not verified truth. They predict what a helpful answer should look like from patterns in data. That is useful for drafting, summarising and routing, but it becomes dangerous when the customer treats the answer as policy, price, legal position or operational fact.

The UK Government AI Knowledge Hub warns that public AI applications leave you with limited control over both the data entered into the model and the outputs produced by it. That matters for customer service because the model may produce a fluent answer that sounds authoritative even when it has guessed, blended old policy with new policy, or misunderstood the customer's situation. The AI Knowledge Hub security guidance also highlights hallucinations as a specific risk, where a model responds with information that appears truthful but is false.

The Air Canada chatbot case is the cleanest warning example. A customer asked about bereavement fares. The chatbot gave misleading information about claiming a reduced fare after travel, and the airline later argued the customer should have checked the linked policy page. The tribunal rejected that. Pinsent Masons reported that Air Canada was held liable for negligent misrepresentation and that the tribunal called the idea that a chatbot was separately responsible for its own actions a "remarkable submission". The lesson for a UK SME is simple: if the answer appears on your website, your customer will reasonably think it is your answer.

So the first mitigation is mindset. A customer-facing AI system is not a clever FAQ. It is a publishing and decision-support channel. Treat it with the same seriousness as a staff member answering email under your company name.

What controls reduce hallucinations in practice?

The strongest practical control is to restrict the AI to a defined knowledge base. This is usually called retrieval augmented generation, or RAG. Instead of asking the model to answer from memory, the system retrieves relevant approved documents first, then asks the model to answer using those sources only. For a small business, that knowledge base might include current pricing pages, refund rules, product specifications, support procedures, delivery terms, service-level promises, onboarding documents and approved sales scripts.

RAG is not magic. The source material still needs to be accurate, current and well structured. If your refund policy exists in three conflicting PDFs, the AI may still produce the wrong answer. The work is less glamorous than buying the chatbot: clean the knowledge base, remove old documents, label policy dates, write short answerable chunks, and decide which source wins when two documents disagree.

Use four layers of control. First, scope the bot narrowly: "I can answer delivery, appointment, onboarding and support questions" is safer than "Ask me anything". Second, require citations or source references for factual claims shown to staff or customers. Third, use confidence thresholds and refusal rules. If the model cannot find the answer in approved sources, it should say so and escalate. Fourth, prevent the AI from making commitments it is not authorised to make, such as discounts, refunds, contract variations, complaint outcomes or regulated advice.

For most UK SMEs, a sensible first build is not full automation. It is AI-assisted triage, suggested replies and knowledge-base answers with handover. That gives you measurable speed gains while keeping the riskiest decisions with trained people.

Where should a human stay in the loop?

A human should stay in the loop wherever the answer could create financial loss, legal exposure, customer distress, safety risk, discrimination risk, or damage to trust. That does not mean every chatbot message needs manual approval. It means you draw a clear line between low-risk assistance and decisions that bind the business.

Low-risk examples include opening-hours questions, delivery tracking explanations, basic product navigation, appointment availability, document collection, password reset guidance and routing a support ticket to the right team. Medium-risk examples include refund eligibility, service complaints, contract terms, pricing exceptions, warranty questions and vulnerable customer support. High-risk examples include legal advice, financial advice, medical advice, employment decisions, formal complaint outcomes, credit decisions, cancellations with penalties and anything involving special category personal data.

The ICO's AI and data protection guidance puts accuracy, accountability, fairness and transparency at the centre of AI governance. That is not just a compliance nicety. If a customer-facing system uses personal data and produces an inaccurate result, you may have a data protection problem as well as a customer service problem. UK GDPR also gives people rights around their personal data, and automated decision-making duties become more serious where decisions have legal or similarly significant effects.

A practical SME rule is this: AI can draft, classify, summarise and recommend. A named person approves anything that changes a customer's money, rights, access, contract, complaint outcome or formal record. Build that rule into the workflow, not just into a policy document.

How do you test a customer-facing AI before launch?

Do not launch a customer-facing AI system because the demo looked good. Test it like a business process that can fail in public. Start with a risk register: what wrong answers would be embarrassing, expensive, unlawful or hard to reverse? Then create test questions for those exact scenarios.

A useful pre-launch test pack should include at least 100 real customer questions if the bot will answer live traffic. Include common questions, vague questions, angry questions, typos, slang, edge cases, malicious prompts, questions outside scope, conflicting policy questions and requests for discounts or exceptions. If you cannot gather 100 historic questions, launch internally first and collect examples from staff before exposing it to customers.

Measure more than "accuracy" in the abstract. Track whether the answer used the right source, whether it refused when it should, whether it escalated correctly, whether it invented a policy, whether it exposed information it should not, and whether the customer would know how to get human help. Set a pass mark by risk category. A typo in a product description is not the same as a wrong cancellation fee.

Budget realistically. A small AI support assistant may have licence costs of only £20 to £60 per user per month, but proper setup, knowledge-base work, testing and governance can easily take 3 to 10 working days internally or cost £3,000 to £12,000 externally for a focused first deployment. If the system touches regulated advice, high-value transactions or sensitive personal data, expect more review time and specialist input.

How do you monitor and fix errors after launch?

Monitoring is where many AI projects fail. Businesses spend money on the launch, then treat the bot as finished. Customer questions change, policies change, products change, staff invent workarounds and the AI system gradually drifts away from reality. You need an operating rhythm.

Log every interaction, subject to your privacy notice and retention policy. Review a sample weekly at first, then monthly once performance is stable. Tag errors by type: wrong source, missing source, hallucinated policy, poor escalation, misunderstood intent, inappropriate tone, data exposure risk, outdated document or user attempted to override instructions. This turns vague concern into a fix list.

Keep an escalation queue. When the AI cannot answer or detects risk, it should create a ticket with the conversation, the customer's intent, the documents retrieved and the reason for handover. Staff should not have to reconstruct what happened from scratch. Also give customers an obvious route to reach a person. Hiding human support behind a bot may reduce visible tickets in the short term, but it usually increases frustration and complaint risk.

Decide who owns the system. Not "IT" in general, and not the software vendor alone. A named operational owner should approve knowledge-base changes, review performance reports, coordinate fixes and decide when the bot must be paused. If the system gives wrong answers for a live promotion, price change or policy update, somebody must have authority to remove the source, update the answer or switch the bot to handover mode quickly.

When this is NOT right for you

Customer-facing AI is not right for you if your policies are undocumented, your pricing changes informally, your team disagrees on how complaints should be handled, or your knowledge base is full of old PDFs nobody trusts. In that situation, the AI will expose the mess faster than a human would. Fix the underlying process first.

It is also not right as a first project if the first use case involves vulnerable customers, regulated advice, high-value contractual commitments, legal rights, medical information, credit decisions, employment decisions or anything where an incorrect answer is hard to unwind. Start with lower-risk internal assistance or staff-facing suggested replies instead.

Do not use AI as a way to remove human service from customers who still need judgement. Some customers need empathy, exception handling or accountability. A bot can help gather context and suggest next steps, but it should not be the only door into the business.

The honest answer is that hallucination risk can be managed, not eliminated. If your business cannot tolerate any wrong answer in the workflow, do not automate the answer. Use AI to help staff find the right source faster, draft a response and check completeness, while the final answer remains human-approved.

Is This Right For You?

This guidance is right for you if you are considering AI for customer service, sales enquiries, website chat, support triage, internal helpdesks that affect customers, or any workflow where a customer may rely on the answer.

It is not right for you if you want a fully autonomous chatbot to handle complex complaints, legal commitments, regulated advice, refund decisions, vulnerable customers, or high-value commercial promises without human review. In those cases, AI may still help, but it should assist staff rather than speak for the business on its own.

Frequently Asked Questions

Can AI hallucinations be completely eliminated?

No. You can reduce hallucinations sharply with retrieval, scope limits, testing, human review and monitoring, but you should not promise zero hallucinations. Design the workflow so wrong answers are contained and corrected quickly.

Is RAG enough to make a customer chatbot safe?

No. RAG helps because the AI answers from approved sources, but it still needs clean documents, access controls, refusal rules, testing, logs and escalation. Poor source material will still produce poor answers.

Should a customer-facing AI show sources to customers?

For factual answers, yes where possible. Showing the source policy, help article or product page makes the answer easier to trust and easier to challenge. For sensitive workflows, sources may be shown to staff rather than directly to customers.

Who is liable if a chatbot gives a customer the wrong answer?

The business should assume it remains responsible for information presented through its own website, app or support channel. The Air Canada case showed how weak it is to argue that a chatbot is somehow separate from the business.

How often should we review AI customer service answers?

Review weekly during pilot and early launch, then move to monthly once stable. Also review immediately after any major policy, pricing, product, legal or service change.

What questions should a customer-facing AI refuse to answer?

It should refuse or escalate questions involving legal advice, financial advice, medical advice, employment decisions, formal complaints, refunds outside policy, contract changes, vulnerable customers, sensitive personal data and anything outside its approved knowledge base.

Can small businesses afford proper AI safety controls?

Yes, if the first use case is narrow. A safe first deployment might cover a small set of support topics, use existing approved documents and hand over anything uncertain. The expensive mistake is trying to automate every customer question at once.

What is the simplest first step before launching a customer AI assistant?

Collect the last 100 real customer questions, decide which ones are safe for AI to answer, write approved source answers for those topics and define handover rules for everything else.