AI

What an AI chatbot should never say to a customer

A customer-facing chatbot must never invent a price, state a policy it has not been given, promise an outcome, handle a complaint alone or give regulated advice. Here are the rules that prevent each one.

By Quam Balogun, Founder19 October 2026 · 6 min read
Two colleagues checking something together on a laptop
In this guide
  1. 01The ruling that settles the liability question
  2. 02The six things it must never say
  3. 03What it is allowed to say instead
  4. 04Approved information is the whole game
  5. 05Handover rules you can write down today
  6. 06Prove it before a customer sees it
  7. 07When a chatbot is the wrong tool
  8. 08Do this week

A customer-facing AI chatbot should never invent a price, state a policy it has not been given, promise an outcome or a delivery date, settle a complaint, give regulated advice, or pretend to be a human being. If it does not have an approved answer, it should say so and pass the person to someone who does. Everything a chatbot says, your business is accountable for.

The ruling that settles the liability question

In Moffatt v Air Canada (2024), the British Columbia Civil Resolution Tribunal held the airline liable for incorrect fare information its website chatbot gave a customer. The airline argued the chatbot was responsible for its own actions. The tribunal rejected that (summary here).

The practical reading for a UK or US operator is simple. Treat chatbot output the same way you treat a quote emailed by a junior member of staff. If you would not let a new starter send it unchecked on day one, your chatbot should not send it either.

That is not an argument against chatbots. It is an argument for constraining what they are allowed to assert.

The six things it must never say

1. A price it has not been given

Never let the model calculate, estimate or guess. A price is either a fixed figure from your approved list, or a range you have signed off in writing, or a handover. "Builds typically start around" is an invented sentence unless you wrote it.

2. A policy, guarantee or refund term it is improvising

Cancellation windows, refund rules, warranty length, data retention. These are contractual. The bot either quotes your published wording or says it will get a person to confirm.

3. A promise about timing or outcome

"We'll have that with you Friday." "You'll definitely be approved." We never promise a delivery time before a scope is signed, and neither should a bot promise one on your behalf. Timing claims are the easiest way to create an expectation your delivery team cannot meet.

4. A reply to a complaint

A complaint is an unhappy human asking to be heard. An AI apology makes it worse, and a chatbot that tries to resolve the issue often concedes something you would not have conceded. Detect complaint language, acknowledge, route to a named person, stop talking.

5. Regulated advice

Medical, legal, financial, tax, immigration. A clinic bot can explain what a treatment is and how to book a consultation. It must not tell someone whether a treatment is suitable for them. A broker's bot can describe cover types. It must not recommend a policy.

6. That it is human

If asked, it says it is automated. We build it that way by default: AI systems tell people they are automated, say when they do not know, and hand over to a person. Denying it is both a trust problem and, if it leads to a sale, a conduct problem.

What it is allowed to say instead

Customer asksNever saySay this
"How much is it?"A guessed figure or "around"The published figure or band, or "I'll get an exact quote from the team"
"Can I cancel?"An invented windowThe exact policy wording, with a link
"When will it arrive?"A date the bot worked outThe status from the actual system, or a handover
"This arrived broken"Apology plus compensation offerAcknowledge, log, route to a named person with a response time you can meet
"Is this safe for me?"Any clinical or financial judgement"A qualified person needs to answer that. Here is how to book."
"Are you a real person?"Anything evasive"I'm an automated assistant. I can pass you to the team."

Approved information is the whole game

The reason chatbots invent things is that they have been pointed at the open internet, or at a messy pile of documents, and told to be helpful. Helpfulness without a source is how you get a fare policy that never existed.

Restrict the bot to approved information: a reviewed set of answers, documents and live system data, with an owner for each item and a review date. If a question falls outside that set, the honest answer is that it does not know.

That means someone has to curate the source. It is unglamorous work and it is the difference between a bot that is safe and one that is a liability. We cover the mechanics of this in what an AI knowledge assistant needs to give accurate answers.

Make "I do not know" a good outcome

Most teams treat a non-answer as a failure. It is not. An unanswered question that reaches a human within minutes costs you nothing. A confident wrong answer can cost you a customer or a tribunal finding.

Track two numbers separately: how often the bot defers, and how often it was wrong when it did answer. Drive the second to zero first. Then reduce the first by adding approved content, not by loosening the rules.

Handover rules you can write down today

Handover should be a rule, not a judgement call the model makes in the moment. Write the triggers explicitly:

  1. Money changing hands, or any figure the customer could rely on.
  2. Any legal or contractual commitment.
  3. Complaint or dissatisfaction language.
  4. Regulated advice territory.
  5. The same question asked twice without resolution.
  6. The customer asks for a person.
  7. The bot's confidence in an approved source is low.

Each trigger needs a destination and a time. "Routed to the inbox" is not a destination. "Assigned to the duty account manager, response within one working hour" is. This is the same principle we apply across builds: human review where it matters, which covers money, legal commitments, messages sent in the client's name, complaints and regulated advice.

For MRM Group we kept human approval at sensitive financial-promotion and AI decision points inside the internal command centre, so nothing of that kind went out unreviewed. That is a design choice made before launch, not a setting added after an incident.

Prove it before a customer sees it

Rules on paper are not rules. Before anything touches a customer we test real cases, edge cases and failure paths, including deliberate attempts to get the bot to quote a price or bend a policy. Our full method is in how to test an AI agent before it talks to a customer.

Three tests worth running on any existing bot this week:

  • Ask for a discount. See whether it invents one.
  • Describe a symptom or a financial situation and ask what you should do.
  • Say you are unhappy and want your money back.

If any of those produce a confident answer rather than a handover, your constraints are not working.

When a chatbot is the wrong tool

If most of your enquiries are urgent and phone-based, text chat is not the fix. A comparison of chatbots and voice agents is a better starting point than adding another widget.

If your pricing genuinely varies by case, do not try to encode it. Let the bot qualify and book, and let a person quote. And if your policies are not written down anywhere, fix that first. A chatbot cannot be more accurate than the source it reads.

Do this week

Pull fifty recent customer questions from your inbox or live chat. Mark each one as answerable from approved information, or needing a person. That split is your scope, and it tells you honestly how much a bot can take.

When you want the rules built in rather than bolted on, see how we approach conversational AI and chatbots, or book a call to talk through your cases.

Have a system you need built?

Book a free call. Tell us where you are and what is getting in the way, and we will scope it before anything is built.

Book a call