Who Is Liable When the AI Sends the Wrong Answer?

Air Canada's lawyers made an argument in 2024 that every support leader should read at least once. The airline's chatbot had told a customer he could apply for a bereavement discount after flying, which was wrong. When the customer took it to a tribunal, Air Canada argued the chatbot was a separate legal entity responsible for its own actions.

The tribunal member called that submission remarkable. A chatbot has an interactive component, he wrote, but it is still just a part of the airline's website, and the company is responsible for all the information on that site whether it comes from a static page or a bot. Air Canada had not taken reasonable care to make its chatbot accurate. Judgment for the customer.

The damages were small. The precedent was not.

The answer is boring, and it was settled before the AI showed up

Who is liable when the AI sends the wrong answer? You are. Not the model provider, not the platform vendor, not the agent as some free-floating actor with its own legal personality. The company whose logo sits at the top of the email.

This isn't a doctrine invented for machines. Negligent misrepresentation has been around for a long time and it asks the same questions it always did: did you owe this person a duty of care, was the representation inaccurate, were you careless in making it, did they reasonably rely on it, and did that reliance cost them something. Putting a language model in the loop changes none of those elements. It changes who typed the sentence.

Which is why the separate-entity defence keeps failing. Tribunals treat customer-facing automation roughly the way they treat a new hire reading from a script the company wrote: the employer picked the script, put the person on the channel, and told customers the channel was trustworthy. Apparent authority does the rest.

A concrete version of the problem

Imagine a subscription business handling 40,000 support emails a month. In March, finance changes the cancellation policy so refunds are prorated from the cancellation date instead of the end of the billing period. Legal signs off. The help centre article gets updated within a week. The internal SOP document in the shared drive, the one the AI agent was pointed at during onboarding, does not.

For the next eleven weeks the agent answers cancellation questions correctly according to a document that is now wrong. The replies are confident, well written, on brand, and they tell roughly 900 customers they'll receive a full billing-period refund. Some of those customers cancel because of what they were told.

Nothing in that story is an AI failure. The model did exactly what it was instructed to do, using the source it was given. The failure is that nobody owned the link between "policy changed" and "agent's sources updated," and no control existed to notice the gap. That is precisely what a tribunal examines when it asks whether a company took reasonable care.

It's also, for what it's worth, the most common problem we find when teams audit their own deployments. Fabrication gets all the attention. Staleness does most of the damage.

What actually changed in 2026

Quite a lot, though less than the headlines suggested.

The EU AI Act's Article 50 transparency obligations went live on 2 August 2026. If a person is interacting with an AI system, they have to be told, unless that's obvious from the context. Anyone running support automation into the EU is inside that requirement now, and it survived the round of deferrals that hit the rest of the Act.

The deferrals were real, and they were substantial. The Digital Omnibus on AI, endorsed by Parliament in June 2026 and approved by the Council at the end of that month, pushed the high-risk obligations for stand-alone Annex III systems from 2 August 2026 out to 2 December 2027, and for AI embedded in regulated products to 2 August 2028. One more date worth writing down: from 2 December 2026, the machine-readable marking requirement in Article 50(2) starts applying to systems that were already on the market.

In the US the movement is at state level. Colorado passed a Chatbot Safety Act in 2026 with duties starting 1 January 2027, making it the first state to regulate conversational AI directly. The obligations include disclosing that the user is talking to AI, running self-harm response protocols, estimating user age and protecting minors, and never presenting bot output as equivalent to advice from a licensed professional. The Attorney General filed proposed implementing rules on 11 August 2026, with a rulemaking hearing scheduled for late October. Colorado's rewritten AI statute, now the Automated Decision-Making Technology Act, takes effect the same day. Utah has required generative AI disclosure in commercial interactions since May 2024. California's SB 243 carved customer service bots out of scope, and a follow-on bill, AB 1609, would put them back in.

Here's the part that matters for liability. None of these laws create your exposure. They add disclosure duties on top of an exposure you already had. A company that hides the fact that its replies are automated now has a disclosure problem and a misrepresentation problem. A company that discloses beautifully and still sends a customer the wrong refund policy has only the second one, and the second one is the expensive one.

Four ways an email agent generates a claim

Support automation fails in more than one way, and the failure modes carry different weight. Three of them are versions of saying something untrue:

• Fabrication. The model produces a policy that never existed. Retrieval missed, the prompt left space, and the agent filled it. This is the failure everyone worries about, and the one that grounding genuinely fixes.
• Staleness. Worse in practice, because it looks correct on review. The agent accurately quotes your return window as of a knowledge base article written fourteen months ago.
• Overreach. The answer is factually fine but commits the company to something the agent had no authority to promise: a goodwill credit outside policy, a delivery date operations can't hit, a waiver of a fee that isn't waivable.

The fourth one is newer, and nobody has litigated it yet

Email agents with write access don't only say things. They do things. They issue the refund, cancel the subscription, change the shipping address, update the account record. When a chatbot gives bad information, the customer still has to act on it before there's a loss. When an agent with write access into your billing system acts on bad information, the loss is already booked before anyone reads the email.

There's no reported decision on that yet. It's coming, and the reasoning will probably be shorter than the Air Canada one, because there's no reliance question left to argue about.

Reasonable care, translated out of legalese

Reasonable care is the standard, and it stays comfortably undefined right up until someone defines it against you. The useful move is to build the record you'd want to hand an investigator before you need it.

• Ground every factual claim. Answers should be assembled from retrieved source documents rather than model memory, with the sources recorded per response. This is the highest-leverage control there is, and it's the core of how you prevent AI hallucinations in customer email.
• Set a confidence floor and honour it. Below the threshold, the agent drafts and a human sends. Set the floor higher for anything touching money, health information, contractual terms, or legal rights.
• Version and date your policy sources. Give every policy document an owner and a review date, and have the agent decline to answer from a document that's past its review date rather than quoting it with full confidence.
• Cap what the agent can do, not just what it can say. Value limits per action, per customer, per day, with approval gates above the cap.
• Log the reasoning, not just the output. Model version, retrieved sources, confidence score, decision, action taken, record IDs affected. If you can't reconstruct one decision six months later, you can't defend it, which is the whole point of a real audit trail.
• Sample and score. A weekly review of a random sample, scored against policy rather than tone, catches drift that aggregate CSAT hides completely.

None of this is exotic. Most of it is what a well-run support organisation already does with its human agents, written down and applied to a system that can scale a single mistake to nine hundred customers before lunch.

Disclosure is cheap, so do it properly

Article 50 requires it in the EU. Colorado and Utah require versions of it. Even where nothing requires it, disclosure is worth making, because it changes what reasonable reliance means. A customer who has been told they're reading an automated reply, and who has a visible one-click route to a person, sits in a different position from one who believed they were corresponding with an agent named Sarah.

Done badly, disclosure is a grey footer nobody reads. Done properly it's a line in the signature block, an obvious escalation path, and a system that actually routes to a human when asked. Teams skip the third part, and the third part is the one that matters. If your agent says "reply HUMAN to reach a person" and replying HUMAN does nothing for six hours, you've documented your own failure to take care. Getting the boundary right is worth its own conversation about when to resolve and when to route to a human.

What your vendor contract does and doesn't do

Under the EU framework you're the deployer rather than the provider, and the obligations split accordingly. That split matters for regulatory compliance. It does almost nothing for the customer sitting in front of a wrong answer, because your contract with a vendor is invisible to that customer and irrelevant to a misrepresentation claim brought against you.

Indemnity is a recovery mechanism, not a defence. You still lose the claim. You then try to get paid back, subject to a cap that was probably written without reference to the volume of automated replies you're about to send. Read the cap. Compare it to the volume.

Worth negotiating for, in rough order of how much it'll matter when something goes wrong:

• Exportable, tamper-evident logs that you own, retained for as long as your industry requires
• Written notice before model or prompt changes that alter production behaviour
• The right to run your own evaluation set against the agent, on your schedule rather than theirs
• Named accountability for response accuracy in the SLA, not only for uptime

The first 24 hours after a bad answer goes out

Every deployment eventually sends something wrong. The gap between companies isn't whether it happens, it's how the next day goes.

Two instincts are worth resisting. The first is to quietly fix the source document and move on, which leaves you with no record of what was sent, to whom, or how many people it reached. The second is to switch the agent off entirely while someone investigates, which usually creates a bigger customer-facing problem than the one you're solving.

A better sequence looks like this. Pull the list of affected conversations by querying the logs for responses that cited the bad source, which takes minutes if you logged sources per response and is close to impossible if you didn't. Narrow the agent's scope rather than disabling it, so the affected intent routes to humans while everything else keeps running. Correct the source, then re-run your evaluation set against it before the agent goes back to answering that intent. Contact the affected customers proactively, and honour what they were told where the cost of honouring it is smaller than the cost of arguing.

That last point is where a lot of teams get it wrong on economics rather than law. In the Air Canada matter the disputed amount was a few hundred dollars. The company chose to fight it, lost, and turned a fare adjustment into the case that gets cited in every article about AI liability, including this one. Honouring a wrong answer is often the cheapest available option, and it almost never becomes precedent.

Who inside your company actually owns this

Ask three people at a typical company who signs off on what the support AI is allowed to promise, and you'll get three answers. Support ops assumes legal reviewed it. Legal reviewed the vendor agreement and assumed support ops set the guardrails. The person who configured the confidence thresholds left in January.

The fix isn't a committee for its own sake. It's four names:

• Someone owns the source documents the agent answers from, with a review cadence and a named backup.
• Someone owns the action limits and revisits them whenever policy or pricing changes.
• Someone reads the escalation logs weekly, hunting for cases the agent should have escalated and didn't.
• Someone signs off before a model or prompt change reaches production.

Four names, written down, kept current. That list is worth more in a dispute than any volume of vendor documentation, because it's evidence that a human system was paying attention. Formalising it is what an AI governance committee for customer support is actually for.

Where Robylon sits in this

Robylon resolves 60–80% of customer emails autonomously, and that range is validated against your historical tickets during onboarding rather than asserted on a pricing page. The parts relevant to this article: responses are grounded in retrieved sources with per-response citation, confidence thresholds and escalation rules are configurable by intent, human-in-the-loop review can be switched on for any category you choose, and every decision is logged with model version, sources consulted, and actions taken. Teams running AI email support at volume tend to discover they need the logging long before they need the automation rate.

The honest framing is that no vendor removes your liability. What a well-built system does is turn the record of reasonable care into something you can produce in an afternoon, instead of something you reconstruct under pressure while a regulator waits.

Ready to automate email support without inheriting an unmanaged risk? Robylon AI resolves 60–80% of customer emails autonomously with grounded responses, configurable escalation, and full decision logging across Zendesk, Freshdesk, Shopify, Salesforce, and 60+ other integrations. Start free at robylon.ai