A ruling that made the ownership question concrete
In November 2022, a customer named Jake Moffatt asked Air Canada's website chatbot about bereavement fares after their grandmother died. The chatbot told them they could book a full-price ticket and apply for the reduced bereavement rate within 90 days of the date the ticket was issued. That policy did not exist: the airline's actual bereavement page, which the chatbot's answer linked to, said the reduced rate could not be applied after travel. When the airline refused the refund, Moffatt took the case to the British Columbia Civil Resolution Tribunal, which decided Moffatt v. Air Canada, 2024 BCCRT 149 in their favor in February 2024.
Two things in the short decision matter for anyone deploying customer-facing AI agents. The first is the defense: Air Canada argued it could not be held liable for information provided by its agents, servants, or representatives, including a chatbot. The tribunal read that as suggesting, in effect, that the chatbot was a separate legal entity responsible for its own actions, called it a remarkable submission, and found negligent misrepresentation, writing that it should be obvious that Air Canada "is responsible for all the information on its website," whether from a static page or a chatbot. The second is quieter: the tribunal relied on a screenshot the customer had preserved, and the decision cites no internal transcript from Air Canada. Air Canada was defending what its own system said to its own customer on the customer's evidence, and was ordered to pay CA$812.02 in damages, interest, and tribunal fees.
The award was small. The evidence problem was not: an organization whose agents make statements it cannot reproduce is one screenshot away from defending every disputed conversation on someone else's record. And Air Canada's chatbot only spoke. Action-taking agents add a second question: did the business outcome they promised actually occur?
Support agents act as well as speak
Today's support agents issue refunds and credits, change plans and subscriptions, apply retention offers, and update the CRM. That makes two classes of consequential event. Representations are what the agent told the customer: a statement about a fee, an eligibility rule, or a cancellation window can expose the company to liability the way the bereavement answer did, with no tool called and no system changed. Actions are what the agent did to the customer's account, order, or balance: a wrong one surfaces when the promised refund never settles, lands twice, or hits the wrong account.
Support platforms and agent frameworks often retain these pieces separately: the transcript in the helpdesk, the tool calls in an agent trace, the refund in billing. What they rarely do is connect the transcript, the decision-time policy, the executed action, and the independently confirmed outcome in one record. As the broader case for AI agent audit trails lays out, a trace that stops at the API response answers how the software ran, not what the company told and did to its customer.
Regulators have already said existing obligations still apply
Customer service automation is not a gray zone waiting for new law. In June 2023 the Consumer Financial Protection Bureau published an issue spotlight, Chatbots in consumer finance, estimating that roughly 37 percent of the U.S. population interacted with a bank's chatbot in 2022 and noting that all ten of the largest commercial banks deploy one. Its findings read like a checklist of evidence gaps: chatbots giving inaccurate information and failing to recognize or resolve a dispute. The warning was aimed at the institutions, which risk violating legal obligations and causing consumer harm, because the obligations attach to the answer the customer received, not to the technology that produced it.
The Federal Trade Commission has stated the general principle. Announcing its Operation AI Comply sweep in September 2024, five enforcement actions against companies that used or sold AI deceptively, the agency's chair put it in one sentence: there is no AI exemption from the laws on the books. None of the five cases involved a support agent, so the sweep is not direct evidence about customer service enforcement. It reinforces the broader principle that using AI does not displace existing consumer protection law. When a regulator or a tribunal asks what your agent told a specific customer and what it did to their account, "the model is non-deterministic" is not a responsive answer. A record is.
The record a disputed support interaction needs
A customer service dispute is a small set of factual questions, each answered by one evidence element. The conversation, the policy in force, and the decision have to be captured when the action happens, because they may be difficult or impossible to reconstruct reliably later; the outcome is attached when the system of record can confirm it, which may be minutes or days after the conversation:
| The dispute question | The evidence that answers it |
|---|---|
| What was the customer told? | The agent's statements to the customer, kept in the company's own support platform record at interaction time, so the answer never depends on which screenshots the customer happened to keep. |
| What rules were in force? | A decision-time policy snapshot: the refund thresholds, plan terms, offer conditions, help articles, and prompt instructions the agent was operating under at that moment, not whatever those sources say by the time someone reviews the case. |
| What did the agent decide and do? | The decision, its basis, and the executed action, each recorded as its own event, so a promised credit that was never issued is visible as a gap rather than blended into one log line. |
| Did it actually happen? | The outcome read back independently from the billing platform or CRM where the business recognizes the result, not the agent's report that its tool call returned success. |
| Who looked at the exceptions? | Human review decisions appended to the same record, so the intervention is part of the file rather than a note in a separate ticket. |
Two rows deserve emphasis, because support teams most often assume they already have them. The policy row fails quietly: in support workflows the effective policy is rarely one document. It is help articles, macros, offer matrices, and a system prompt, often edited independently and rarely preserved together as one decision-time policy set. Air Canada's chatbot contradicted the airline's own policy page in the answer that linked to it, and judging that answer six months later requires knowing what both said at that moment. That is what policy snapshots exist to solve, and the test from that guide applies directly: any text that would have changed the agent's answer had it read differently is part of the policy surface for that interaction.
The outcome row fails loudly, but late. "Your refund has been processed" is a second representation, this time about the agent's own action, and a successful API response does not make it true: the refund can be queued, rejected downstream, or misapplied. Confirming it means reading it back independently from the system of record and treating the outcome as pending until that read-back confirms what the agent promised. A mismatch caught by the company's own verification within days is an operations task; the same mismatch surfaced weeks later by the customer, or by a chargeback, arrives with interest.
Why the transcript is not the record
Retaining the transcript answers one of the five questions, and in the disputes that cost money, even when both sides agree on the transcript, they disagree about everything downstream of it. A record becomes business evidence when it connects what the agent saw, the rules that applied, what it decided, what it did, and what verifiably happened, in a form a non-engineer can read. Customer service adds one requirement of its own, courtesy of the screenshot that beat Air Canada: the company's record has to be at least as complete as the customer's, and it has to exist before the dispute does. Exceptions still need people; routing mismatches to a reviewer with that record attached, rather than putting a human in front of every routine action, is the design argument made in human review of AI agent decisions.
How Pruvz approaches customer service evidence
Pruvz is a business evidence layer for production AI agents. For a consequential support action such as a refund, credit, or account change, it creates a supplemental, action-level evidence record that can be linked to the ticket or customer record in the support platform. The conversation stays where the support platform keeps it; the Pruvz record captures the decision-time context the agent acted on, as approved evidence fields, references, or extracts subject to data-minimization and retention controls, together with the exact policy snapshot in force, the agent's decision and claim, and the executed action.
Verification then reads the outcome back independently from systems of record such as billing and CRM. Only that read-back decides the result, never the agent's own report: the verification status remains pending during a defined verification window and is finalized as verified, outcome mismatch, or verification failed. Evidence entries are ordered and append-only with server-assigned sequence numbers, mismatches and evidence gaps land in a review queue, and the reviewer's decision is appended as new evidence without rewriting the original result. This gives support, operations, risk, and compliance one record to review instead of reconstructing the case across a transcript, an agent trace, billing, and CRM. You can inspect a real packet from the product demo, field by field, on the evidence packet page.
Pruvz is non-blocking by design: it records and verifies off the agent's critical path and does not approve or block the action, so the support workflow keeps its speed. It does not replace the support platform or the systems of record, and it does not by itself establish compliance with consumer protection obligations; it supplies the decision-time evidence and independent outcome verification that a defensible record depends on.
Today, the demonstrated read-back runs against live Stripe and HubSpot test environments; ticketing and other production connectors, and the first support workflows, will be selected and developed with founding design partners, and the design-partner program is open now. Building or running an agent that issues refunds, applies credits, or changes customer accounts? Bring one workflow, planned or already live, to a design-partner conversation. The question Moffatt v. Air Canada leaves you with is where it starts: for the last disputed interaction, could you produce a better record than the customer?
This article is general technical and governance information, not legal advice. Your obligations depend on your jurisdiction, industry, and specific use case.