AI Customer Service Risks: Wrong Answers, Liability and Brand Damage
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
AI customer service risk is the chance that an AI agent gives a customer wrong, harmful or off-brand information, or takes a wrong action, and that your company has to answer for it. The key word is your. When a bot speaks on your website, customers and, increasingly, tribunals treat its words as yours.
That is the lesson of the best-known case so far. In February 2024 a Canadian tribunal ordered Air Canada to pay a passenger after its chatbot gave him wrong information about a fare. The amount was small. The reasoning was not. This guide walks through that case and three others, groups the risks into a table you can use as a checklist, and ends with safeguards a support manager can put in place without waiting for a legal team. It's a practical overview, not legal advice, so check anything specific to your market with counsel. For the wider picture of the collection, see AI in customer service.
Key Facts
- On February 14, 2024, British Columbia's Civil Resolution Tribunal ruled in Moffatt v. Air Canada that the airline was responsible for what its chatbot told a customer (Daily Hive).
- The money was modest: $650.88 in damages, $36.14 in interest and $125 in tribunal fees, about $812 in total. The precedent value is far larger than the sum.
- The tribunal rejected the argument that the bot was a separate legal entity, and found Air Canada did not take reasonable care to make sure its chatbot was accurate (Manatt).
- Not every failure is a legal one. DPD's chatbot swore and criticised the company, and screenshots were viewed more than a million times (Yahoo News).
- The US Consumer Financial Protection Bureau warned in 2023 that firms may be liable when chatbots fail to follow consumer finance law (CFPB).
The Four Types of AI Support Failure
Most incidents fall into one of four buckets, and each needs a different safeguard.
- Wrong answers. The AI states a policy, price or rule that isn't true. This is the hallucination problem, and it is the most common.
- Wrong actions. The AI doesn't just talk, it does something: issues a refund, changes an account, promises a delivery date. An error here moves money or creates a commitment.
- Off-brand behavior. The AI swears, insults, jokes about a tragedy or criticises the company. No fact is wrong, but trust takes the hit.
- Trapped customers. The AI keeps customers in a loop with no route to a person, which turns an annoyance into a complaint or a regulatory issue.
The four cases below map onto these. In ACE terms, the first and third come from Generate (a model producing text), while the second adds Execute (the model acting on systems), which is where governance matters most.
Case 1: Air Canada and the Bereavement Fare
Jake Moffatt asked Air Canada's website chatbot about bereavement fares after his grandmother died. The chatbot told him he could apply for the reduced fare retroactively, within 90 days of buying his tickets. Air Canada staff later told him retroactive applications weren't allowed, and its own website policy said bereavement fares did not cover travel already taken (Fox Business). He sought a partial refund of about $880.
Air Canada's defense is the interesting part. It argued it could not be held liable for information provided by its chatbot, and that the accurate policy was available elsewhere on its site. Tribunal member Christopher Rivers rejected both points. The tribunal found that Air Canada owed Moffatt a duty of care, did not take reasonable care to make sure its chatbot was accurate, and had committed negligent misrepresentation (Manatt). It also held that the chatbot is part of the airline's website, and that the airline is responsible for all information on it, whether it comes from a static page or a chatbot (Daily Hive). The case is reported as Moffatt v. Air Canada, 2024 BCCRT 149.
Two caveats keep this honest. It was a small-claims tribunal decision in one Canadian province, so it doesn't bind courts elsewhere. And the claim was narrow: a customer relied on a specific wrong statement and lost money. Still, the practical message travels well. "The bot said it, not us" and "the right answer was on another page" didn't work as defenses here, and you should assume they won't work for you either.
Case 2: DPD and the Chatbot That Went Off Script
In January 2024, a DPD customer named Ashley Beauchamp prompted the delivery company's chatbot to swear and to say "DPD is the worst delivery firm in the world." He posted screenshots on January 18, 2024, and they were viewed more than a million times. DPD said an error followed a system update, that the "AI element was immediately disabled," and that the element had worked successfully for several years alongside human customer service (Yahoo News).
Nobody lost money here. The damage was reputational, and the customer had deliberately prompted the bot. That's the point. Brand risk doesn't need a victim, only a screenshot. Notice also what triggered it: a routine system update. Any change to the model, prompts or settings can undo behavior you tested last month.
Case 3: Cursor and the Invented Policy
In April 2025, users of the coding tool Cursor who asked why they were being logged out across several machines received an email from the company's AI support bot saying this was expected behavior. There was no such policy. Co-founder Michael Truell wrote on Reddit, "Hey! We have no such policy," called the reply an incorrect response from a front-line AI support bot, and apologized. Cursor said AI responses used for email support would now be clearly labeled, and the developer who raised the issue was refunded (The Register).
This is the Air Canada pattern in a different industry: a confident, specific, invented rule. The AI didn't say "I'm not sure." It filled a gap with something plausible. The company's response is also worth studying. A fast public correction, a refund and a label on AI replies is a reasonable playbook for the day it happens to you.
Case 4: NYC's MyCity Chatbot and Illegal Advice
In October 2023, New York City launched an AI chatbot on its MyCity portal to help business owners navigate city rules. In March 2024, The Markup reported that the bot often gave incomplete or wrong answers. It said landlords did not have to accept Section 8 vouchers, that tenant lockouts were legal, that restaurants could go cash-free despite a 2020 city law requiring cash acceptance, and that employers could take a cut of workers' tips. The answers also varied: it told one reporter that landlords must accept vouchers, and told ten other staffers they did not have to. A city spokesperson described the bot as a pilot that would improve (The Markup).
This isn't a company help desk, but it shows the worst version of a wrong answer: advice that, if followed, breaks the law. If your AI answers questions about contracts, pricing law, safety, health or employment, you're in the same territory. The inconsistency is a risk in itself, because the same question can get different answers on different days.
The Risk Table: Risk, Example, Safeguard, Owner
Use this as a starting checklist. "Owner" means the role that should be able to answer for that risk, not the person who does all the work.
| Risk | Example | Safeguard | Owner |
|---|---|---|---|
| Invented policy or price | Air Canada's retroactive fare claim; Cursor's login rule | Answer only from approved sources; refuse when no source is found; label AI replies | Support operations lead |
| Wrong legal or regulatory advice | NYC's bot on tenant and tip rules | Block legal, health and safety topics; hand off to a person with a fixed message | Legal or compliance |
| Off-brand or abusive output | DPD's bot swearing | Output filters, tone rules, regression tests after every update | Support operations lead plus brand |
| Unauthorized action | A bot issuing refunds or promises it shouldn't | Spending limits, approval steps, action logs | Head of support |
| Customer trapped in a loop | The "doom loops" described by the CFPB | Always-visible route to a person; escalate after repeated failures | Support operations lead |
| Silent drift after a change | DPD's error after a system update | Test set run before and after every model, prompt or content change | Support operations lead |
| Privacy and data exposure | Personal data in chat logs | Data minimization and retention rules, covered in customer data privacy in AI support | Security or privacy lead |
| Undisclosed AI | A customer who doesn't know it's a bot | Clear disclosure at the start of the conversation | Legal or compliance |
The last two rows have their own guides because the rules differ by country and change often. Treat this article as the map, and those as the detail.
Why Regulators Care
You don't need a lawsuit to feel the pressure. The CFPB's June 2023 report on chatbots in consumer finance states that chatbots are expected to follow all relevant federal consumer financial laws, and that firms may be liable when they don't. It lists inaccurate information, failure to recognize disputes, "doom loops" with no path to a human, and privacy risks among its concerns. The report says it does not impose new obligations (CFPB). Note that this speaks to financial services in the US. If you operate elsewhere or in another industry, the specifics differ, but the direction is the same: the channel doesn't change the duty.
How to Reduce the Risk: Eight Steps
- Decide what the AI may not do. Write a short list of banned topics and actions: legal advice, medical or safety guidance, anything involving refunds above a threshold. Start from what to automate and what to assist.
- Ground every answer in approved content. The Air Canada page and the chatbot disagreed, and the airline paid for the gap. Keep one current source of truth, and make sure the AI reads from it. Preparing support data for AI covers how.
- Let the AI say "I don't know." Configure it to hand off when no source matches, instead of improvising. A refusal costs a few minutes. An invented policy can cost far more.
- Limit what it can do. For anything that moves money or makes a commitment, set caps, require human approval above them, and log every action with the conversation that triggered it.
- Keep a visible exit. Customers should reach a person without arguing with the bot. What customers expect from AI service explains why this matters beyond compliance.
- Test before and after every change. Build a set of 50 to 100 real questions, including adversarial ones (insults, jailbreak attempts, edge cases from past complaints). Run it whenever the model, prompt or knowledge base changes. DPD's incident followed a system update.
- Review conversations, not just metrics. Sample AI conversations weekly and grade them. AI quality assurance for support covers how to review support conversations. Pair that with an honest resolution measure so a wrong answer doesn't get counted as a success.
- Write the incident plan before you need it. Name who can switch the AI off, who talks to the customer, who publishes a correction, and how refunds are handled. Cursor and DPD both acted fast, and speed was most of their recovery.
If you're rolling this out for the first time, fold these into your launch plan rather than adding them later. The implementation guide shows where each fits.
Pitfalls to Avoid
Relying on a disclaimer. A line saying the bot "may occasionally produce incorrect" content, as the NYC bot's page did, didn't stop the criticism and wouldn't have helped Air Canada. A disclaimer is not a control.
Assuming the accurate page protects you. The tribunal in the Air Canada case didn't accept that a correct webpage excused a wrong chatbot. Your documents and your bot have to agree, because customers will believe whichever one they see first.
Testing once, at launch. Behavior drifts when models, prompts and content change. Treat testing as a recurring job with an owner.
Giving the AI tools before you've given it limits. The jump from answering to acting is where small errors become expensive. Add actions one at a time, each with a cap and a log.
Hiding the AI. Pretending the bot is a person tends to make every error feel like deception. The tone problem is real too: decide how the bot handles a frustrated customer before you give it a personality.
Treating risk as a legal-only topic. Legal can set the rules, but support operations sees the conversations. The owner column in the table above should have a name next to every row.
A Simple Way to Start
If this feels like a lot, begin with three moves this month. First, read 30 recent AI conversations and mark every statement that isn't backed by your own documents. Second, add a hard handoff for the topics you listed in step one. Third, name the person who can turn the AI off at 2 a.m. Those three steps address the failures in all four cases above, and they cost far less than the single bad day they prevent.

Customer Success Operations Manager
On this page
- Key Facts
- The Four Types of AI Support Failure
- Case 1: Air Canada and the Bereavement Fare
- Case 2: DPD and the Chatbot That Went Off Script
- Case 3: Cursor and the Invented Policy
- Case 4: NYC's MyCity Chatbot and Illegal Advice
- The Risk Table: Risk, Example, Safeguard, Owner
- Why Regulators Care
- How to Reduce the Risk: Eight Steps
- Pitfalls to Avoid
- A Simple Way to Start