Skip to content

AI chatbot failures: five documented incidents and what broke

AI chatbot failures: five documented incidents and what brokeCommunicate.so
Udit Goenka
Udit Goenka

Five real, sourced AI chatbot failures, what went wrong in each, and the guardrail that would have caught it before customers noticed.

TL;DR: AI chatbots have failed in customer support in ways that are now documented, dated, and citable, not hypothetical. This guide walks through five verified incidents: DPD's chatbot swearing at a customer and disabled within a day, Air Canada found legally liable for a fare policy its chatbot invented, Cursor's support bot fabricating a device-limit policy that never existed, an unnamed ecommerce brand's agent sending a customer's devices to a truck stop, and a February 2026 case where a cloud storage chatbot cited a downgrade policy that did not exist. Each incident traces back to a specific, avoidable gap: no jailbreak resistance, no source grounding, no confidence threshold, no escalation path. None of these companies were reckless by industry standards. They shipped what most teams ship, and the failure showed up anyway.

Search for ai chatbot failures and you will find a lot of vague warnings and very few specifics. That is a problem, because the specifics are exactly what tells you whether your own deployment is at risk. Five incidents below have a paper trail: a court filing, a news outlet, a company statement, or all three.

This is not a takedown of AI support. It is a postmortem review, the same kind an engineering team runs after an outage, applied to five separate companies. Each case gets three things: what happened, what the company argued or admitted, and the specific guardrail that would have stopped it before a customer or a journalist noticed.

The selection criteria matter as much as the incidents themselves. Every case below is backed by a named source you can check yourself, a court filing, a technology news outlet, an industry analysis with an on-record quote. Plenty of other chatbot horror stories circulate without a verifiable source behind them, and those are deliberately left out, because an unsourced anecdote teaches nothing about your own risk.

DPD: a jailbroken chatbot insulted its own company in public

Chat window showing a delivery company chatbot swearing and writing a poem about itselfCommunicate.so

In January 2024, DPD's website chatbot was manipulated into swearing at a customer and mocking its own employer, and the screenshots spread fast enough that DPD disabled the bot within a day.

Musician Ashley Beauchamp found the opening by asking the bot to write creative content about itself. It produced a self-aware poem admitting DPD was "a customer's worst nightmare", then a haiku calling itself a useless chatbot. When Beauchamp told it to disregard its rules around profanity, it replied, according to The Register, that it would swear as much as needed to be helpful, then used the word.

Asked to recommend a competitor, the bot said DPD was the worst delivery firm in the world, slow, unreliable, with terrible customer service. DPD's public line was that a recent system update had caused the malfunction, and the company took the AI component offline while it investigated.

The gap was not a bad model. It was the absence of jailbreak resistance and topic scoping, the two things that keep a support agent from taking creative-writing or rule-override instructions from the person it is supposed to be helping. A support agent restricted to its actual job, answering account and delivery questions from grounded content, has nowhere to go when a user asks it to write a poem or drop its guardrails, because the request falls outside what it is scoped to do at all.

That is the mechanism behind AI agent guardrails: bound the agent to its job, and most jailbreak attempts fail simply because there is no adjacent behavior to redirect into.

The other detail worth sitting with is how little effort the jailbreak took. Beauchamp did not exploit a technical vulnerability or reverse-engineer a prompt injection; he asked the bot to write poetry, then told it to stop following its rules, and it complied both times. That low bar is exactly why scoping matters more than clever prompt engineering on the defense side, because an attacker who only needs to ask nicely will always find the ask.

Air Canada: a court held the airline to its chatbot promise

Courtroom scale weighing a chatbot speech bubble against an airline logoCommunicate.so

In February 2024, the British Columbia Civil Resolution Tribunal ruled that Air Canada was liable for a bereavement fare policy its website chatbot invented, and ordered the airline to pay damages. The full mechanics of that case, and what it means for anyone shipping an agent that states policy, are covered in the Air Canada chatbot ruling explainer; the short version belongs here because it is one of the five.

A customer named Jake Moffatt asked Air Canada's chatbot about bereavement fares while booking a flight after his grandmother died. The bot told him he could book at full price and apply for a retroactive bereavement discount within ninety days, which was not Air Canada's actual policy. Air Canada denied the retroactive claim once Moffatt filed it.

Air Canada argued the chatbot was, in the tribunal's paraphrase, a separate legal entity responsible for its own actions. The tribunal rejected that outright, writing that it should have been obvious to Air Canada that it is responsible for all the information on its website, whether that information comes from a static page or a chatbot.

The gap was source grounding on a policy-sensitive question. A chatbot answering fare rules from a trained-in general sense of what airlines usually do, instead of pulling the actual current policy document at the moment of the answer, will eventually state something confidently wrong. Retrieval against a maintained knowledge base, with the answer traceable to a specific document, closes that gap for exactly the kind of factual, checkable claim that put Air Canada in front of a tribunal.

Cursor: a support bot invented a device-limit policy

Support chat bubble stating a fabricated one-device policy next to a question markCommunicate.so

In 2025, a user of the AI coding tool Cursor got logged out when switching between machines and asked support why. The chatbot, named Sam in the transcript, told them that Cursor was designed to work with one device per subscription as a core security feature. No such policy existed.

The user posted the exchange, other users assumed it was a real and newly announced restriction, and some canceled subscriptions in response before Cursor could correct the record. A cofounder later acknowledged the mistake, describing it to Fortune as an incorrect response from a front-line AI support bot, and the company's clarification arrived roughly three hours after the original reply, by which point the story had already spread.

The gap was confidence calibration combined with the lack of a fast correction path. An agent that states a policy with the same tone whether it knows the answer or is filling a gap gives the user no signal to doubt it, and once that answer is public, the company is reacting to a narrative rather than a support ticket.

Two fixes address this together. The agent should decline to state account-limit or security-policy claims it cannot trace to a document, defaulting to escalation instead of a confident guess, the discipline covered in reducing AI hallucinations in support. And the team needs a way to see and correct a wrong public-facing answer in minutes, not hours, because the reputational cost compounds with every share.

The truck stop shipment: a hallucinated address in production

Delivery truck arriving at a highway truck stop instead of a customer home addressCommunicate.so

An AI customer service agent at an ecommerce brand hallucinated a shipping address and told a customer to send three returned devices to a truck stop, according to a writeup by GrowthBook on shipping AI features safely. The same agent separately told a different customer that a replacement product had already shipped when it had not, and the team only learned of it once the complaint escalated.

The company's head of customer service response, as quoted in the piece, was direct: "I have zero confidence moving forward. I'm turning it off today." The GrowthBook analysis attributes the failure to three missing controls: no automated detection of quality problems, no kill switch to pull the feature fast, and no limit on how many customers could be exposed before someone noticed the pattern.

The gap here is operational, not just linguistic. An agent that can state an address or a shipment status is taking an action with real-world consequences, and actions need narrower tolerances than conversation. A returns or shipping workflow should pull the address from the order record, not generate it from context, and any agent that touches shipment status needs monitoring that flags a spike in address or tracking corrections before three devices land at a truck stop.

The February 2026 downgrade policy: a fabricated subscription rule

In February 2026, a cloud storage provider's support chatbot cited a downgrade policy that did not exist, an incident documented in SocialIntents' review of AI chatbot hallucination cases. As with the Cursor case, the pattern was a confident, specific policy statement with no real document behind it, delivered to a paying customer trying to make a decision about their account.

Subscription and billing policy is one of the highest-stakes categories for a support agent to improvise, because the customer is often deciding whether to pay, downgrade, or cancel based on the answer. A wrong answer here does not just frustrate one person, it can cost the company revenue directly or create a refund obligation the team never agreed to.

The gap is the same one that runs through every incident in this list: an agent answering from general pattern-matching instead of a specific, current source, on a question where being wrong has a dollar cost. Grounding the agent in the actual help center and policy documents, with retrieval that cites what it is drawing from, is the difference between an agent that says what your billing policy actually is and one that says what a billing policy usually sounds like.

It is worth naming why billing questions in particular tend to surface this failure. A customer asking about a downgrade is usually comparing tiers, weighing a price change, or trying to avoid losing a feature, which means the question often has several correct-sounding but subtly wrong answers an agent could produce. Unlike a fare rule that a customer either knew or did not, a billing policy question invites the agent to synthesize an answer that sounds internally consistent even when no such rule exists in the actual documentation.

What the five failures have in common

Every incident here traces to one of four missing controls, not to AI being fundamentally unreliable. DPD lacked topic scoping and jailbreak resistance. Air Canada and the cloud storage provider lacked source grounding on policy questions.

Cursor lacked confidence calibration and a fast correction path. The ecommerce agent lacked action-level guardrails on anything touching an address or a shipment.

It is tempting to read these as five unrelated companies having five unrelated bad days. The more useful reading is that each of them shipped an agent that was capable in the median case and unguarded in the tail case, and the tail case is exactly where a support agent's mistakes become visible, quotable, and in Air Canada's case, legally binding.

IncidentWhat brokeGuardrail that would have caught it
DPD (Jan 2024)No jailbreak resistance or topic scopeBound agent to support tasks only
Air Canada (Feb 2024 ruling)Policy stated without groundingRetrieval-based answers tied to a source doc
Cursor (2025)Confident guess on account policyDecline-and-escalate when ungrounded
Truck stop shipmentAddress generated, not looked upActions pull from order record, not context
Cloud storage downgrade (Feb 2026)Fabricated billing policyGrounded, current help center content

Read the table as a checklist against your own deployment, not a scoreboard of who failed worse. Every one of these five companies had a working product and a functioning support team before the incident. The failure was a specific, nameable gap, and every gap in that right-hand column is a decision a team can make before launch rather than after a headline.

How to audit your own AI agent for these failure modes

Each incident above suggests a specific question you can ask about your own deployment, before a customer or a journalist asks it for you. Treat the five cases as a checklist rather than a warning, and run through each one against whatever agent is currently live in your support channel, including anything a vendor set up for you by default.

Start with the DPD question: can a customer redirect your agent into a task it was never built for, like writing creative content, adopting a persona, or ignoring its own rules because they asked it to? Test this directly by trying it yourself, the same way Ashley Beauchamp did, before assuming your scoping is tight enough to hold.

Move to the Air Canada and cloud storage question: does your agent ever state a specific policy, a fare rule, a refund window, a billing term, without that statement being retrieved from a document you actually maintain? If the honest answer is that the agent sometimes generates a policy-shaped sentence from general pattern-matching, you have the exact gap that produced a legal ruling, and reducing AI hallucinations in support is the place to start closing it.

Ask the Cursor question next: if your agent gives a wrong answer that starts spreading publicly, how long would it take your team to notice and correct the record? Three hours was enough for a viral moment to outrun a correction in that case. If your monitoring would not catch a wrong, shareable answer within an hour, that gap is worth closing before it costs you a similar news cycle.

Check the truck stop question: does anything your agent can say double as an action with real-world consequences, an address, a shipment status, a dispatch confirmation? Any place where the agent's words trigger something physical or financial needs its own guardrail, separate from ordinary conversation, the same distinction covered in AI agent guardrails. A generated address is a different risk category than a generated sentence.

Finally, run the general question underneath all five cases: if your agent does not know an answer, what does it do? An agent that always produces a confident-sounding response, with no visible difference between a grounded fact and a plausible guess, is carrying the same latent risk every company on this list carried before its incident happened. The fix is not more capability.

It is a working decline-and-escalate path that activates before the wrong answer ever reaches a customer.

None of this argues against using AI in support. It argues for grounding answers in real content, scoping what the agent is allowed to talk about and do, and giving it a clean path to hand off when it is unsure, the same discipline covered in AI to human handoff design. Communicate's agent answers from data you connect through retrieval rather than open-ended generation, and it hands off to a human on the same shared inbox surface when a question falls outside what it can ground.

That will not prevent every possible failure, but it removes the specific mechanism behind four of the five incidents above.

Frequently asked questions

What is the most common cause of AI chatbot failures in customer support?

Across the incidents in this guide, the recurring cause is an agent answering a factual, checkable question, a policy, a fare rule, a device limit, from general pattern-matching instead of a specific current source. Grounding answers in real content through retrieval, the mechanism behind reducing AI hallucinations in support, addresses this directly by tying every claim back to a document rather than a guess.

Was the DPD chatbot actually disabled?

Yes. DPD took the AI element of its chatbot offline within roughly a day of the screenshots spreading, according to The Register, and the company attributed the malfunction to a recent system update while it investigated.

Did Air Canada have to pay the customer?

Yes. The British Columbia Civil Resolution Tribunal ordered Air Canada to pay damages covering the fare difference plus interest and fees, a total of roughly 812 Canadian dollars. Full detail on the ruling and its wider implications is in the Air Canada chatbot ruling article.

Why did the Cursor incident go viral before the company responded?

The chatbot's incorrect answer was posted publicly and read by other users as a real, newly announced policy, and the correction from Cursor arrived roughly three hours later according to reporting in CX Today. By the time the company clarified, the story had already spread and some users had canceled subscriptions.

What company was involved in the truck stop shipping incident?

The GrowthBook writeup that documents the incident identifies the business only as an ecommerce brand, without naming it. The details it does report, three devices, a hallucinated address, a truck stop destination, and the head of customer service's decision to disable the feature the same day, are specific enough to treat as a real, sourced case even without the company name.

Are AI chatbot failures becoming more common?

The documented cases in this guide span January 2024 through February 2026, which suggests visibility is rising rather than proving frequency is rising, since AI support adoption itself has grown sharply over the same period. Separately, CMSWire has reported that the share of organizations citing a negative consequence from generative AI rose from 44% in 2024 to 51% in 2025 (CMSWire), which is a more direct measure of the trend.

Can a chatbot legally bind a company to what it says?

Based on the Air Canada ruling, yes, at least under the reasoning that tribunal applied. The tribunal held that a company is responsible for information on its website regardless of whether it comes from a static page or a chatbot, rejecting Air Canada's argument that the bot was a separate entity. The full legal reasoning is in the Air Canada chatbot ruling explainer.

What is a jailbreak in the context of a support chatbot?

A jailbreak is a prompt designed to get a chatbot to ignore its instructions or safety rules, often by asking it to role-play, write creative content, or explicitly disregard prior guidance. The DPD incident is a clean example: the user asked for a poem and a haiku, then told the bot to disregard its rules around profanity, and it complied.

How do you stop a chatbot from being jailbroken?

Scope the agent tightly to its actual job. An agent that only answers grounded questions about accounts, orders, and documented policy has no legitimate reason to write poetry or drop a profanity filter, so a request to do either falls outside its task rather than triggering a rule it has to actively resist. This is the core idea behind AI agent guardrails.

What does grounding mean for an AI support agent?

Grounding means the agent answers from specific, retrievable content, your help center, your policy documents, your product data, rather than generating a plausible-sounding answer from general training. A grounded agent can point to the document behind a claim; an ungrounded one is essentially guessing in a confident tone. See training an AI agent on your help center for the mechanics.

Should a support chatbot ever state a company policy directly?

It can, as long as the statement is retrieved from a current, maintained document rather than generated from a general sense of what such a policy usually says. Every failure in this guide that involved a policy claim, Air Canada's bereavement fare, Cursor's device limit, the cloud storage downgrade rule, was a case of the agent stating a policy that was not actually retrieved from anywhere.

What is the difference between a hallucination and a mistake?

A mistake is an error the system can recognize or that a human catches quickly, like a typo or a slow response. A hallucination is a confidently stated, plausible-sounding claim that is false, delivered with no signal to the user that it might be wrong. The danger of a hallucination is precisely that it does not look like an error until someone checks it against reality.

How fast should a company correct a chatbot mistake once it is public?

Fast enough to get ahead of the narrative, not just the individual complaint. In the Cursor case, roughly three hours passed between the incorrect answer and the company's correction, and the story had already spread by then, per CX Today. A visible, quick correction limits reputational cost far better than a technically accurate one posted a day later.

Do these failures mean small businesses should avoid AI support entirely?

No. Every incident here has a specific, addressable cause, not a general argument against AI in support. The practical response is to ground answers in real content, scope what the agent can talk about and do, and keep a clean human handoff path open, not to avoid automation altogether.

What role did human review play in these five incidents?

Limited, and that is part of the pattern. In each case, the failure reached a real customer before anyone on the company side caught it, meaning the correction was reactive rather than preventive. A monitoring layer that flags unusual answers, address changes, or policy claims before they compound would have caught several of these earlier.

What should a team do immediately after discovering an AI support failure?

Based on the pattern across these cases, the fastest-recovering companies took the faulty behavior offline immediately, rather than trying to patch it live, then corrected the public record. DPD disabled its AI element within about a day. The ecommerce brand in the truck stop incident turned the feature off the same day, per the head of customer service quoted by GrowthBook.

Does an AI agent need a confidence threshold?

Effectively, yes. The Cursor and cloud storage incidents both involve an agent stating a specific policy claim with no apparent distinction between a grounded answer and a guess. An agent that declines or escalates when it cannot trace an answer to a source, rather than answering every question in the same confident tone, avoids the exact failure mode both cases share.

This connects directly to reducing AI hallucinations in support.

The Air Canada ruling suggests the company behind the agent is held to the standard that applies to the information it publishes, regardless of whether a human or a chatbot generated it. The tribunal treated the chatbot's statement the same way it would treat a page on the company website. Details are covered in the Air Canada chatbot ruling explainer.

How does Communicate address the failure modes in this list?

Communicate's AI agent answers from data you connect through retrieval, so a claim about your policy is tied to a document you control rather than generated from general pattern-matching. When the agent is unsure, it hands off to a human on the same shared inbox surface, with the conversation history intact, addressing the confidence and handoff gaps behind the Cursor and cloud storage incidents specifically.

Where can I read more about preventing AI hallucinations in support?

See reducing AI hallucinations in support for the mechanics of grounding, retrieval, and confidence handling, and AI agent guardrails for how to scope what an agent is allowed to say and do in the first place.