- A tribunal rejected the argument that a chatbot is a separate entity responsible for its own words. The bot is part of your website, and so are its answers.
- Having the correct policy on another page did not save the company. A customer is not expected to work out which of your two answers is the real one.
- Four answer types cause almost all of the trouble: price, delivery date, policy exception and stock.
- The fix is not a better model. It is a short refusal list plus one source of truth the bot reads instead of guessing.
- Whoever keeps the transcripts controls the story. Most small deployments keep them for a fortnight, then delete the only evidence they had.
A customer forwards a screenshot. Your support bot has told them that a personalised item can be returned within 30 days, which it cannot, because you make each one to order and say so on the product page. The customer wants their money back and has the conversation in writing. You have a decision to make before lunch, and the interesting part is that the decision was already made for you, by a tribunal, in a case about an airline.
Most coverage of that case filed it under aviation. It belongs in the same drawer as your returns policy, because the reasoning transfers to any business that puts an answer machine in front of customers, which now includes a large share of small shops.
What did the Air Canada ruling actually decide?
That the company owned what its chatbot said. In February 2024 the British Columbia Civil Resolution Tribunal found for a passenger who had relied on the airline's chatbot telling him he could apply retroactively for a bereavement fare, which contradicted the policy published elsewhere on the same website. The analysis of Moffatt v. Air Canada by McCarthy Tetrault sets out the five elements the tribunal worked through for negligent misrepresentation.
Two of the airline's arguments are the ones worth your attention, because they are the arguments a small merchant instinctively reaches for. The first was that the chatbot was a separate entity, responsible for its own actions. The tribunal rejected it: the chatbot is still just a part of the website, and the company remains responsible for all the information on it. The second was that the correct information existed elsewhere on the site. That did not rescue the airline either, because a customer reading one of your two contradictory answers is not obliged to guess which one you meant.
| What the tribunal required | What that means for your shop | Where the evidence lives |
|---|---|---|
| A duty of care was owed | You put the bot on your own site for your own customers | Not contestable in practice |
| The statement was inaccurate or misleading | The bot said 30 days, your policy says made to order | The transcript against the policy page |
| The statement was made negligently | Nothing stopped the bot answering a question it could not answer | Your prompt, your refusal rules, your grounding data |
| The customer relied on it reasonably | They asked before buying and acted on the answer | Timestamps: did the chat precede the order |
| The reliance caused loss | They spent money they would not otherwise have spent | Order value, and what they would have paid instead |
Read down the third column and the shape of the problem changes. Four of the five elements are decided by records you either keep or do not keep. A dispute about a bot is a dispute about logs.
Does it matter that the bot said it and not you?
No, and nobody serious argues otherwise now. The private law route reached that conclusion in 2024. The public enforcement route reached it separately, in plainer words. Announcing a sweep of cases against companies making deceptive AI claims, the Federal Trade Commission put it as bluntly as an agency can: using AI tools to trick, mislead or defraud people is illegal, and there is no AI exemption from the laws on the books.
The direction has continued. In 2026 the Commission put out a proposed policy statement on the suppression of accuracy in AI systems, arguing that steering outputs away from what users reasonably expect can itself be deceptive under Section 5, as summarised by Consumer Finance Monitor. The same piece recalls earlier consumer bureau guidance warning that when an institution relies on a chatbot to give information the law requires to be accurate, being wrong may breach the obligation itself.
None of that is aimed at a shop with 400 orders a month. It settles the background assumption, which is what matters when a customer with a screenshot asks you a question you have not thought about before.
Must you tell customers they are talking to a machine?
In the European Union, yes, unless it is obvious to a reasonably well informed person. Article 50 of the EU AI Act sets the transparency obligations, and the deadline inside it is the detail people miss: the information has to be given in a clear and distinguishable manner at the latest at the time of the first interaction, and it has to meet accessibility requirements.
That turns a legal question into a design question. A note in your terms of service is not the first interaction. A grey line of small print under the input box is arguable. A first message that says what the assistant is, what it can do and how to reach a person is not arguable at all, and costs one sentence.
The same article carries a second duty that catches shops generating text at scale rather than answering in chat. Providers of systems producing synthetic text have to mark outputs in a machine readable format where technically feasible, and deployers publishing generated text on matters of public interest have to disclose it unless a person took editorial responsibility for the piece. Product descriptions are not public interest text. Your blog might be, depending on what you write about, which we looked at when invisible marks started appearing in published AI text.
Where do support bots actually invent things?
In four places, consistently, and they are the four your customers ask about most. Everything else is noise around these.
Price is the first. A bot that has been given a product catalogue but not the current promotion will quote yesterday's price with total confidence, and a quoted price is the single most bindable thing a bot can say. Delivery date is the second, and it is worse, because the honest answer depends on stock, carrier and cut off time, and a language model will happily average those into Tuesday.
Policy exceptions are the third and the most expensive. Nobody asks a bot to restate the returns policy; they ask whether it applies to them, on a sale item, bought as a gift, opened but unused. The model has read a policy that does not cover the case and will reason its way to an answer, which is exactly what the airline's bot did. Stock is the fourth, and it produces the quietest damage: a bot that says an item is available generates an order you then cancel, and cancellations cost you a customer rather than a tribunal.
Notice what these four have in common. Each has a correct answer that exists somewhere in your systems right now. None of them requires the model to be smarter. They require it to look something up rather than compose, the kind of constraint a grounded output guardrail is built to enforce.
What actually stops it
Two things, neither of which is a better model. The first is a refusal list. Write down the questions the bot may not answer from its own knowledge, in your own words, and put them in its instructions with the response you want instead. Six lines covering price, delivery, exceptions and stock, each ending in an offer to check with a person or a link to the page that decides it.
The second is a single source of truth for anything numeric. If the bot can query your live catalogue for price and stock, it does not have to guess, and the failure mode changes from an invented answer to a missing one, which is a failure you can survive. That substitution is the whole of the mitigation, because a model guesses when the grading rewards guessing and a lookup gives it nothing to guess about. Where the data is not reachable, the honest instruction is to say so. A bot that says it cannot confirm today's delivery date and offers to have somebody confirm it in an hour loses you nothing.
Both of those are cheaper than they sound, and both are cheaper than honouring one invented promise on a high value order. The work is deciding what your policy actually is, which is why the tickets to automate first are the ones you already answer the same way every time. We set out that sorting exercise in how to choose which support tickets a bot should take, and the ranking has not changed: repeated questions with one correct answer first, judgement calls last or never.
If the bot came from a vendor, is the ai chatbot liability theirs?
Almost never in the way merchants hope. The customer contracted with you, saw your brand, and read the answer on your domain, so the reasonable reliance runs to your business rather than to a supplier they have never heard of. Whatever your vendor agreement says about a deceptive practice or a defective output is a matter between you and them, settled later, in a different forum, usually for less than the disruption cost.
Read the contract anyway, and read it for two specific things. The first is whether the customer service bot is described as a tool you configure or a service the vendor operates, because that wording decides who is expected to have set the guardrails. The second is what you are entitled to when something goes wrong: access to the full chatbot transcript, the version of the model that produced it, and the configuration in force that day. A vendor who cannot produce those three artefacts leaves you defending a claim with half the file, which is the same evidence problem the tribunal made decisive.
The transparency obligation is worth a line here too. Where the disclosure duty applies it lands on both sides of the arrangement, and it is satisfied by what appears in the widget rather than by what appears in a supplier's compliance page, with the trigger for telling a customer they are talking to a bot differing between Europe and the American states. If the vendor ships a chat window with no statement that it is automated, you are the one publishing it.
What does grounding actually mean here?
It means the answer comes from a lookup rather than from memory. The mechanism has an unglamorous name, retrieval. The idea is simple enough to explain to anyone: before the model writes, the system fetches the relevant records, the current price, the live stock count, the policy text, and the model is instructed to answer only from what it was handed.
The practical difference shows up in the failure mode. An ungrounded bot that does not know something produces a confident sentence. A grounded bot that cannot retrieve anything produces nothing useful, which is why the design only works if you have decided in advance what happens next. That is your escalation path, and it needs three properties: it triggers automatically rather than at the customer's initiative, it captures the conversation so the person picking it up is not starting cold, and it ends with a human who has authority to say yes. An escalation into a queue nobody reads is worse than a wrong answer, because the customer now has both a bad experience and a transcript showing you ignored them.
Grounding is not free. Every lookup is a call to a system that has to be available, and the shops that get burned are the ones whose bot silently falls back to composing an answer when the catalogue endpoint times out. Ask your vendor what happens on a failed retrieval, and if the answer is that the model does its best, you have found your next configuration change.
How long should you keep the transcripts?
Longer than your dispute window, and that is the whole rule. Most small deployments keep conversations for 14 or 30 days because that is the vendor default and nobody changed it. Your chargeback window is longer. Your returns window is probably longer. A customer complaint about something the bot said in March arrives in June, and the only version of events that survives is theirs.
Work backwards from the longest window you are exposed to, add a month, and set retention to that. Store the conversation with the order reference where one exists, because a transcript nobody can tie to a purchase proves little. Then check what the record contains: a log of the bot's replies without the customer's questions is not a conversation, and a log without timestamps cannot establish whether the chat came before the order, which is the element the reliance question turns on.
There is a privacy counterweight, and it is real. Support conversations carry names, addresses, order histories and sometimes health or financial detail volunteered by a customer explaining why they need a refund. Longer retention means more of that sitting somewhere, so the same decision that protects you legally raises your exposure elsewhere. Keep the transcripts, restrict who can read them, and write down the reason for the period you chose.
What to do about the screenshot on your desk
Deal with the customer first and the system second, because they run on different clocks. On a single order the cost of honouring what the bot said is almost always lower than the cost of the argument, and the argument is one you may lose. Pay it, and treat the amount as the price of the audit you were going to have to run anyway.
Then run the audit. Pull a month of transcripts and read a hundred of them, which takes about an hour. You are looking for one thing: answers that state a fact the bot could not have known. Count them. That number, multiplied by your average order value, is your annual exposure, and it is usually the first time anybody in the business has seen it as a figure rather than a worry.
Fix the top category, ship the refusal list, then read another hundred a month later. Businesses that do this twice generally find the second read is boring, which is the outcome you want. Where an answer genuinely needs a person, make sure the path to one is short and staffed, whether that is an inbox you watch or something closer to a support desk with names on it.
The part that does not change
You cannot delegate a promise. Automation changes who types the sentence and nothing about who stands behind it, and the airline's separate entity argument failed because it asked a tribunal to accept a distinction that no customer experiences. To the person reading your chat window, the bot is the shop.
The upside is that the same reasoning protects you when you get it right. A bot that consistently refuses to invent, escalates cleanly and leaves a timestamped record is a better witness than a busy human answering the same question by phone with no notes. The transcript that convicts a careless deployment exonerates a careful one, and which of those you own is decided now, in your instructions and your retention settings, rather than in June when the complaint arrives. If you are choosing what your bot may say about marketing claims as well as policy, the boundaries are narrower than most shops assume, and we mapped them in what you may claim about AI in your own marketing.