When Your AI Gives a Customer the Wrong Answer

It will happen, so plan for the day it does

Every customer-facing AI system will eventually tell someone something wrong. A refund window that does not exist. A delivery date it guessed. A discount nobody authorised. The question is not whether, but how often, how badly and what you do next.

Internal AI tools have a human buffer. Customer-facing ones do not. A wrong answer goes straight to the person you most want to keep happy, and sometimes they screenshot it. Tribunals and regulators have already shown little patience for the argument that the chatbot said it, not the company. Treat what your AI says as what your business says.

Prevention: fence in what the AI may say

Most harmful wrong answers come from the AI answering beyond its knowledge. The most effective prevention is structural, not a better prompt.

• Answer only from retrieved, approved content such as help articles, policies and the customer's own records
• Refuse, or hand over to a person, when retrieval finds nothing relevant
• Pull prices, dates, stock and order status from systems via code, never from the model's memory
• Keep a list of topics the AI must never answer alone: legal, medical, refunds above a value, complaints
• Block commitments in code, so the AI cannot promise a discount or a date the system has not issued

A prompt that says do not offer refunds is a request. A system where the AI has no refund tool is a guarantee.

We go deeper on grounding and refusal patterns in reducing AI hallucination in integrations.

Detection: find wrong answers before customers report them

Most wrong answers are never reported. The customer just leaves, or calls the support line annoyed. You need your own detection.

A customer who asks the same question three different ways is telling you the first answer was wrong or useless. That signal is free and underused. Route those conversations to a review queue daily.

Recovery: what to do when a wrong answer got through

1. Correct it with the customer directly. A person, not the bot, contacts them with the right information and an apology in plain words.
2. Honour reasonable reliance where you can. If the customer acted on the wrong answer in good faith, the goodwill cost of honouring it is usually smaller than the reputational cost of refusing.
3. Find every similar conversation. If it told one customer the wrong returns window, it likely told others. Search the logs.
4. Fix the cause, not the symptom. Was the source content wrong, was retrieval missing, or did the AI answer outside its fence?
5. Add the case to your evaluation set. Every real failure becomes a test that runs before each future change.

Step three is only possible if you log conversations with the retrieved sources attached. Without those logs, you cannot tell how far a mistake spread, and you cannot tell whether a fix worked.

Fixing the root cause

In our experience, wrong answers trace back to a small number of causes, and most are not the model.

• Out-of-date or contradictory help content, where the AI faithfully repeated an old policy
• Retrieval returning the wrong article because two articles use similar words
• Missing data, where the AI was not given the order status and filled the gap
• A question the system was never designed for, answered anyway
• Genuine model error on content it did have, which is the least common of the five

The first cause is surprisingly frequent. Launching an AI assistant is often the first time anyone has read all the help content together, and contradictions that confused human agents for years now reach customers at scale. Fixing the knowledge base is unglamorous and effective.

Being honest with customers upfront

Tell customers they are talking to an AI, which the EU AI Act's phasing-in transparency obligations expect anyway. Make the route to a person obvious and fast. State in the interface that answers about orders come from their account and that anything unclear will be checked by the team.

This does not excuse wrong answers, but it changes how they are received. A customer who knew they could ask for a person and chose not to is more forgiving than one who felt trapped with a bot.

How we set this up

When SpiderHunts builds a customer-facing assistant under our AI chatbot development service, the answer fence, the handover rules and the incident process are written down before any prompt is. We also set alerts for spikes in rephrased questions and human handover requests, using the approach in monitoring and alerting for AI apps. The first week after launch is the riskiest, so we review conversations daily until the patterns settle.

Frequently asked questions