Summary

  • The Air Canada chatbot case matters because the British Columbia Civil Resolution Tribunal treated automated customer-service advice as part of the company's public communication environment, not as a detached stranger speaking beside the website.
  • The accountability issue is not whether every chatbot error creates the same liability. It is who controlled the policy source, response testing, escalation path, website consistency, customer reliance evidence, refund remedy, and post-error correction.
  • Public sources support a careful record: the tribunal decision describes the dispute and remedy, Air Canada materials describe customer-service and tariff context, and AI governance sources explain why automated advice needs ownership, monitoring, and human recourse.
  • The wider lesson for service automation is that a bot answering policy questions can become a regulated customer-contact system when users reasonably rely on it for purchases, refunds, travel rights, claims, or time-sensitive decisions.

The dispute made automation a customer-contact control

The public record of the Air Canada chatbot dispute is unusually compact and unusually useful. In Moffatt v. Air Canada, indexed by CanLII at https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html, the British Columbia Civil Resolution Tribunal considered a passenger's claim that he relied on Air Canada's chatbot for bereavement-fare refund advice. The dispute centered on whether a customer could buy tickets, travel, and then seek a bereavement fare refund after the fact based on the chatbot's statement. The tribunal's decision is the primary source for what was found in that particular small-claims dispute. It is not a universal ruling on every airline chatbot, every AI system, or every refund scenario.

The accountability value of the decision lies in how it frames responsibility. The passenger did not rely on a random internet post. He interacted with an automated tool presented through Air Canada's customer-facing environment. Air Canada controlled the website, the policy content, the chatbot's deployment, and the overall relationship in which the answer appeared. The tribunal rejected the idea that the chatbot was a separate legal actor. That is the core risk lesson: if a company publishes an automated channel for customers, it should expect that channel to be treated as part of the company's service operation.

Air Canada's public customer-support materials at https://www.aircanada.com/ca/en/aco/home/fly/customer-support.html, its contact page at https://www.aircanada.com/ca/en/aco/home/fly/customer-support/contact-us.html, its legal and tariffs entry point at https://www.aircanada.com/ca/en/aco/home/legal/conditions-carriage-tariffs.html, and its bereavement-travel page at https://www.aircanada.com/ca/en/aco/home/book/special-offers/bereavement.html provide relevant company context. Those pages should not be overread as admissions about the tribunal case. They show the public environment in which passengers seek service, terms, fare rules, and claim paths. In an automated-channel dispute, that environment matters because customers do not experience each page, bot, tariff, and support form as isolated corporate silos.

The Canadian Transportation Agency's Air Passenger Protection Regulations page at https://otc-cta.gc.ca/eng/air-passenger-protection-regulations and the federal regulation text at https://laws-lois.justice.gc.ca/eng/regulations/SOR-2019-150/ provide broader air-passenger rights context. The Canada Transportation Act at https://laws-lois.justice.gc.ca/eng/acts/C-10.4/ provides statutory context. This article does not claim the tribunal's bereavement-fare issue was decided under every passenger-protection rule. It uses the regulator and statute sources to show why airline customer communications are not casual speech. They sit inside a regulated travel environment where fare rules, refunds, claims, and time limits can affect passenger rights and costs.

The bot was not the only policy source, but it was still a company source

One of the hardest automation-governance problems is inconsistency. A website page may say one thing. A bot may summarize it differently. A call-center agent may apply a script. A tariff may contain controlling language. A support email may provide an exception. A mobile app may display a shorter version. A customer trying to make a time-sensitive purchase cannot easily audit the company's entire policy stack. The Air Canada case shows why this matters. The passenger allegedly received chatbot advice about refund timing that conflicted with Air Canada's actual bereavement fare rules.

The legal and operational question became whether the company could avoid responsibility by pointing to another page.

An accountable system would treat every customer-facing policy channel as part of one evidence set. The company should know which source a bot uses, when the source was last updated, how the answer was tested, whether the answer links to controlling terms, whether a high-risk answer requires human escalation, and whether customers can preserve the response they relied on. The bot's answer may be generated, retrieved, scripted, or assembled from a knowledge base. The consumer-facing result is the same: a passenger receives an answer from the airline's channel and may act on it.

The tribunal decision is narrow, but the operational lesson is broad. Automated channels should not answer high-consequence policy questions without a governed content pipeline. Bereavement fare eligibility, refund deadlines, missed connection remedies, denied boarding compensation, baggage claims, medical travel, accessibility accommodations, unaccompanied minors, and cancellation rules can all involve money, deadlines, documentation, and emotional stress. If an automated system gives a confident answer in those domains, the company should be able to prove the answer was grounded in current policy or that a human handoff was required.

That proof cannot be improvised after a dispute. It has to be built into the workflow. Logs should show the question, the answer, the source version, the policy topic, the confidence or routing rule if applicable, and whether the customer was directed to a human or controlling terms. The company should preserve enough of the exchange to adjudicate reliance while still respecting privacy and data-minimization principles. If the company cannot reconstruct the answer, it cannot easily prove that the customer misunderstood the channel. If the customer has a screenshot and the company has no source trace, the evidentiary imbalance is predictable.

This is where enterprise software automation meets customer trust. Many companies deploy chatbots to reduce support volume, shorten response times, and route routine questions. Those are legitimate goals. But if the system answers instead of merely routing, it takes on the risk of advice. A bot that reduces calls by giving policy answers must be governed like a policy-answering system, not like a decorative search feature. The cost savings and service convenience come with control obligations.

Customer reliance is the central evidence issue

The tribunal case turned on reliance: what did the passenger see, what did he do after seeing it, and was it reasonable to treat the response as Air Canada's answer? Reliance is not automatic. A customer who ignores clear warnings, fabricates a screenshot, or reads a page selectively may not have a strong claim. But a company that presents a tool as a customer-service channel should assume some users will rely on it, especially when the answer is specific and appears in the purchase or service pathway.

Reliance evidence should therefore be designed into automation governance. A company should know whether a bot answer was displayed before purchase, after purchase, during check-in, during a disruption, or in a claims workflow. It should know whether the answer included a link to a policy page, a disclaimer, a prompt to contact an agent, or a warning that rules may vary. It should know whether the customer had an easy way to save or reference the answer. It should know whether the bot was allowed to answer refund questions or was supposed to route them.

The Canadian Civil Resolution Tribunal's public information at https://civilresolutionbc.ca/ and its small-claims pathway at https://civilresolutionbc.ca/tribunal-process/small-claims/ help frame why this kind of dispute becomes public. The tribunal is designed to resolve certain civil disputes in a lower-cost online forum. That forum can turn a relatively small refund dispute into a governance signal for a much larger industry. The dollar amount may be modest; the accountability principle is not.

Customer reliance also has an abuse-contact economics dimension. Companies automate support partly because human contact is expensive and high volume. Customers use automated support because it is available, fast, and often the first visible route. If companies then treat automated answers as unreliable when they cost money, the burden shifts to customers: they must verify the bot against hidden terms, call an agent, preserve screenshots, and absorb delay. That is an unfair design if the company encouraged use of the channel. The accountable approach is to classify high-risk topics and route them with stronger controls.

The answer is not necessarily to remove all chatbots. A well-designed bot can help passengers find baggage forms, accessibility contacts, status updates, and policy pages. The risk arises when the bot appears to resolve a legal or financial entitlement without reliable grounding or escalation. The distinction should be explicit. Low-risk navigation can be automated broadly. High-risk advice should be source-grounded, tested, logged, and handed off when uncertainty is material.

Automated advice needs a source of truth

The Air Canada case belongs in the broader conversation about AI workflow reliability because a chatbot is a workflow component, not an isolated novelty. It takes an input from a user, maps that input to a policy topic, retrieves or generates an answer, and influences the user's next step. If the answer concerns refunds, the workflow can move money. If it concerns travel documentation, the workflow can affect boarding. If it concerns accessibility accommodations, the workflow can affect civil rights. The reliability requirement should match the consequence.

The Government of Canada's Directive on Automated Decision-Making at https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32592 is aimed at federal government systems, not Air Canada's private customer-service bot. It is still useful as public Canadian governance vocabulary because it emphasizes impact assessment, transparency, quality assurance, and human intervention for automated systems. The Treasury Board's algorithmic impact assessment page at https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/responsible-use-ai/algorithmic-impact-assessment.html is relevant for the same reason: it shows how public institutions think about automated-system consequence and controls.

Privacy and AI governance sources add further context. The Office of the Privacy Commissioner of Canada's guidance on privacy and generative AI at https://www.priv.gc.ca/en/privacy-topics/technology/artificial-intelligence/gd_principles_ai/ emphasizes privacy-protective use of AI systems. NIST's AI Risk Management Framework at https://www.nist.gov/itl/ai-risk-management-framework and its AI RMF 1.0 publication at https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf provide widely used language around validity, reliability, accountability, transparency, and risk management. The OECD AI principles at https://oecd.ai/en/ai-principles provide another public governance reference. These sources do not decide the Air Canada dispute. They help define what responsible automation governance looks like.

For an airline chatbot, the source-of-truth problem is immediate. Fare rules change. Refund rules differ by market, ticket type, travel date, disruption reason, passenger status, and documentation. Bereavement travel has its own eligibility and process rules. If a bot draws from stale content, a generic FAQ, an incomplete training set, or a page summary without conditions, it can produce a plausible but wrong answer. The company then faces the worst possible combination: customers believe the answer because it came from the brand, while employees later deny the answer because it does not match controlling policy.

The control design should therefore start with a policy inventory. Which topics may the bot answer directly? Which topics require a link to controlling terms? Which topics require human confirmation? Which responses must include a date or source version? Which answers must be blocked because they depend on private booking details? Which markets have different legal obligations? Which languages are supported? Which archived answers must be retained for dispute resolution? These are product questions, legal questions, customer-service questions, and engineering questions at the same time.

Disclaimers do not replace governance

Many automated systems use disclaimers. A disclaimer can be useful if it clearly tells users what the tool can and cannot do. But a disclaimer is not a complete control. If a company invites customers to ask policy questions, supplies confident answers, and benefits from reduced support load, it should not expect a general disclaimer to cure a wrong answer on a high-consequence topic. The tribunal's reasoning in the Air Canada case is consistent with that practical view: a company cannot simply declare that its own public channel is separate from the company when customers reasonably interact with it as part of the service.

Disclaimers are weakest when they conflict with design. If the bot is placed prominently, uses the company's branding environment, answers in authoritative language, and appears in the help pathway, customers will treat it as official. If the company wants the bot to be only a search assistant, it should behave like one: point to sources, avoid definitive entitlement language, and route high-risk questions. If it behaves like an agent, the company should govern it like an agent.

The better control is layered. First, classify questions by risk. Second, ground answers in approved content. Third, test responses against known edge cases. Fourth, provide source links and dates for policy answers. Fifth, route ambiguous or high-consequence questions to a human. Sixth, preserve answer logs for disputes. Seventh, monitor complaints and refund reversals. Eighth, correct the knowledge base promptly when errors are found. Ninth, inform affected customers when a known wrong answer may have influenced decisions. Tenth, review whether automation incentives are creating avoidable customer harm.

This layered model also protects employees. Support agents should not be left to apologize for a bot answer they cannot inspect. Legal teams should not learn after the fact that a product team launched policy advice without retention. Product owners should not be judged only by call deflection when the hidden cost is refund liability. Engineers should not be asked to infer legal policy from unstructured pages. A governed chatbot gives each group a defined role.

Airline automation has time-sensitive consequences

Airline customer service is a particularly risky domain for automated advice because passengers often act under deadlines. They may need to buy a ticket quickly because of a death in the family. They may need to decide whether to cancel, rebook, accept a voucher, request a refund, file a claim, or travel and seek reimbursement later. A wrong answer can lock in a purchase decision that is hard to unwind. In the bereavement-fare context, the customer may also be under emotional strain.

Time sensitivity changes the fairness analysis. A customer cannot always wait for a phone queue, compare tariff clauses, or seek legal advice before buying a ticket. If the airline's bot gives a specific answer at the decision point, the customer may reasonably treat that as enough. The company knows or should know that automated support is used in those moments. The design should therefore be more cautious for time-sensitive financial advice.

The Canadian Transportation Agency's complaint and passenger-rights resources at https://otc-cta.gc.ca/eng/air-travel-complaints and https://rppa-appr.ca/eng show that air travel disputes often involve claims processes, evidence, and deadlines. Again, those pages are not the tribunal decision. They show the regulatory ecosystem in which passengers seek redress. A chatbot that answers travel-rights or refund questions inside that ecosystem can shape whether a passenger files the right claim, keeps the right documents, or misses a deadline.

Automation can also create consistency gains if governed well. A bot can provide the same approved answer every time, preserve a log, link to current policy, and route exceptions. Human agents can be inconsistent too. The issue is not human versus automated service. The issue is whether the company can prove the answer was controlled, tested, and correct enough for the consequence. A bad human script and a bad bot script raise similar accountability questions. The bot makes the question easier to scale and easier to repeat.

High-risk topics need routing rules, not only better wording

The simplest post-incident fix is to rewrite one answer. That may be necessary, but it is not sufficient. The durable control is a routing rule that recognizes high-risk topics before the wrong answer is displayed. Bereavement fares are a good example because they combine money, time pressure, documentation, and emotional stress. A safer bot might provide a short navigation answer, link to the current bereavement page, state that eligibility depends on specific conditions, and offer a human contact path. It should avoid promising after-travel refunds unless the current policy clearly supports that promise.

Routing rules should be visible to product and legal owners. They should not live only inside a vendor configuration or prompt library. A policy owner should be able to review the list of topics the bot can answer: refunds, vouchers, medical travel, accessibility, minors, pets, baggage, disruptions, loyalty points, fare differences, and bereavement travel. For each topic, the company should decide whether the bot may answer, must link, must ask clarifying questions, or must hand off. That decision should be dated and tied to a source.

Testing should use adversarial customer questions, not only ideal phrasing. Passengers do not ask policy questions in legal language. They ask whether they can buy now and get money back later, whether a death certificate is enough, whether a fare difference applies, whether they can submit documents after travel, or whether a relative qualifies. The test suite should include these natural questions. It should include multilingual or plain-language variants where the channel supports them. It should include edge cases that are likely to create costly reliance.

The same framework applies outside airlines. Banks, insurers, hospitals, universities, utilities, and government contractors all use automated customer contact. When the topic is low consequence, a wrong answer may be a nuisance. When the topic affects money, eligibility, health, deadlines, identity, or legal rights, the answer is a control. The Air Canada dispute is a public example because the amount was small enough for a tribunal but the design issue was common enough for every service organization.

Ownership cannot be split until it disappears

Automation risk often hides in ownership gaps. The digital team owns the interface, the customer-service team owns the channel, the legal team owns the policy, the engineering team owns integration, a vendor may own the model or bot platform, and operations owns complaints. If a wrong answer appears, each team can plausibly say another team controlled the relevant layer. That is exactly why the board-level owner must be named before deployment.

The owner does not need to personally write every response. The owner needs authority to require testing, source control, retention, handoff, and remediation. The owner should receive metrics that combine automation performance and customer harm: answer accuracy by high-risk topic, handoff rates, complaint rates tied to bot conversations, refunds or reversals caused by wrong automated advice, source update latency, and unresolved cases where the bot's answer could not be reconstructed. A call-deflection metric alone is incomplete because it rewards fewer human contacts even when the bot has merely pushed risk onto customers.

Vendor governance is part of that ownership. If a company uses a third-party chatbot product, the contract should address data retention, audit access, source configuration, testing responsibilities, change management, incident response, and export of conversation records needed for disputes. A company cannot tell customers that the bot is separate merely because a vendor supplied part of the stack. From the customer's perspective, the channel belongs to the airline. From a governance perspective, the airline should make sure vendor evidence can support that responsibility.

Policy-change management is another ownership test. Fare rules and refund procedures change. If the bot's source is not updated at the same time as the website, tariff page, call-center script, and agent knowledge base, inconsistency is predictable. A controlled workflow should prevent a policy from going live in one channel while stale advice remains in another. The change record should show the affected pages, bot intents or knowledge entries, test cases, approvals, and deployment date. That is routine enterprise software discipline applied to customer communications.

Remedies should include affected-channel review

When a court or tribunal finds that a customer relied on wrong automated advice, the remedy to that customer is only the first step. The company should also ask whether the channel produced similar advice for others. That does not require assuming widespread harm. It requires checking. Logs, if retained appropriately, can show whether other passengers asked similar questions, received similar answers, clicked similar links, or abandoned the conversation after receiving the wrong statement. If logs are unavailable, the absence of evidence is itself a control finding.

Affected-channel review should be proportionate. A single ambiguous answer on a low-risk page may require only content correction. A wrong answer about refund eligibility may require searching recent interactions, flagging open claims, notifying support teams, and temporarily routing the topic to humans. If the company can identify affected customers, it should decide whether to invite review. If it cannot identify them, it should document why. That process turns a public dispute into learning rather than treating it as a one-off litigation expense.

The review should also examine how customers were told to preserve evidence. If an automated answer can matter, the customer should be able to access a transcript or reference number. Many companies make it easy for customers to chat but difficult to save the exchange. That design favors the company in a later dispute because the customer may lose the proof. A balanced design gives customers a transcript or summary for high-consequence topics while minimizing unnecessary retention for casual questions.

Finally, remedies should feed the test suite. The exact failure mode from the Air Canada dispute should become a regression case: a customer asks whether bereavement fare adjustment can be requested after travel, with facts that resemble the dispute. The system should either answer correctly with source links or route the question. Every future policy change should rerun that case. That is how software organizations prevent old failures from returning under new wording.

The evidence file should survive a dispute

In the Air Canada case, the passenger's screenshot and the tribunal's decision made the automated response visible. A mature company should not have to rely on the customer's screenshot alone. It should be able to retrieve the conversation record, source policy, bot version, response template or retrieval path, and any escalation rules that applied at the time. That evidence protects customers and the company. Customers can prove what they were told. The company can prove what the system was designed to do and whether the customer saw caveats.

The evidence file should be proportionate. It should not store unnecessary personal data forever. It should not create broad surveillance of customer inquiries. But for high-consequence financial or legal advice, a retention period aligned to dispute windows is reasonable. The file should include the date, channel, policy topic, source version, answer, links displayed, customer booking context if necessary, and whether a human escalation was offered. It should also record later corrections to the knowledge base.

The file should distinguish three kinds of failure. The first is content failure: the source policy was wrong, stale, or incomplete. The second is retrieval or generation failure: the correct source existed, but the bot produced the wrong answer. The third is design failure: the bot should not have answered the question directly at all. Each failure type needs a different remedy. Content failure needs policy maintenance. Retrieval failure needs model, search, or template repair. Design failure needs routing and risk classification.

The company should also track customer-impact remediation. If a bot gave wrong refund advice to one passenger, was the answer pattern shown to others? Were logs searched for similar responses? Were affected customers notified or offered review? Was the bot disabled for that topic until corrected? Was the tariff or help page clarified? Was call-center guidance updated? Was product performance measured only by deflection or also by dispute outcomes? The tribunal decision should trigger those questions in any company using customer-service automation.

What the case does not prove

The Air Canada decision should not be exaggerated. It does not prove that every chatbot answer by every company is binding in every circumstance. It does not prove that generative AI systems are categorically unsafe. It does not establish a national class-wide liability rule for all automated customer service. It does not reveal Air Canada's full chatbot architecture, vendor contracts, testing records, or post-case remediation. It does not tell the public how many customers saw similar advice. It does not show whether the relevant system was purely scripted, retrieval-based, generative, or hybrid.

Those unknowns are important because automation accountability depends on design. A simple rules-based bot with approved answer templates has different risks from a generative system summarizing policy pages. A search assistant that returns links has different risks from a conversational agent that states entitlement rules. A logged, tested, high-risk workflow has different risks from a broad open-ended bot. Without internal architecture, the public should not make unsupported technical claims.

The confirmed lesson is narrower and stronger: when a company deploys an automated customer-service channel, it should expect responsibility for the advice that channel gives in the company's service environment. If the company wants to limit reliance, it must design the channel accordingly. If it wants the channel to answer policy questions, it must govern the channel accordingly. If it finds an error, it must correct the channel and address affected customers.

That lesson is enough. It moves the debate from novelty to operations. The question is not whether a bot is exciting or efficient. The question is whether it has an owner, a source of truth, a test suite, a retention policy, an escalation path, a monitoring process, and a remedy path. Those are ordinary controls. Automation makes them more urgent because a wrong answer can scale across many users before anyone notices.

A narrow decision can still set a broad control expectation

The most useful way to read the tribunal decision is as a control expectation rather than a sweeping technology rule. The decision signals that an automated channel can carry company responsibility when it sits inside the service environment and gives specific customer advice. That expectation is compatible with careful limits. Companies can still use automation. They can still include source links. They can still route complex questions. They can still contest unreasonable reliance. What they cannot safely do is use automation for service advice and then treat the channel as external when the advice is wrong.

For boards, that expectation should appear in risk appetite. The board may accept automation for low-risk navigation with light monitoring. It may require human handoff for financial entitlements. It may require source-grounded responses for regulated topics. It may prohibit open-ended answers for legal rights. It may require independent testing before launch. Those are governance choices. They should be made before a dispute, not after a customer produces a screenshot.

For product teams, the expectation should appear in release gates. A chatbot update that changes refund advice should not ship like a color change. It should have policy review, test evidence, version control, rollback ability, and monitoring. A launch checklist should ask whether the channel can create customer reliance and how that reliance will be handled. If the team cannot answer, the feature is not ready for high-risk service advice.

For legal and compliance teams, the expectation should shift attention from disclaimers to evidence. The strongest defense against automation disputes is not a sentence saying the bot may be wrong. It is proof that the bot was designed to avoid wrong high-consequence answers, that customers were routed when uncertainty mattered, that errors were corrected, and that affected customers had a remedy. That evidence is more persuasive because it addresses the operational cause of harm.

Reader evidence file

This article uses the following public sources as the evidence file for the Air Canada chatbot refund dispute, airline customer-service context, passenger-rights environment, and automation-governance control vocabulary. Legal and tribunal sources are treated as evidence for the dispute record. Company sources are used for public context. AI governance sources are used for control vocabulary, not as findings against Air Canada.

Board review questions

The governing question remains: who had practical control over chatbot policy sources, response testing, escalation paths, website consistency, customer reliance evidence, refund remediation, legal position, and proof that automated service channels were governed like official customer communications? A complete answer should identify the product owner, policy owner, legal reviewer, support owner, engineering owner, data-retention owner, and remediation owner.

The review should separate five evidence lanes. The first lane is legal evidence: the tribunal decision, claim record, refund remedy, and any preserved customer exchange. The second lane is policy evidence: bereavement fare rules, tariffs, website pages, and source versions. The third lane is automation evidence: bot design, training or retrieval sources, test cases, response logs, and escalation thresholds. The fourth lane is customer evidence: reliance, time pressure, screenshots, contact attempts, and remedy path. The fifth lane is governance evidence: post-error correction, monitoring, affected-customer review, and board metrics.

For airlines and other service companies, the sign of repair is not simply removing one chatbot answer. It is a governed automation program that knows which topics may be answered, which must be routed, which sources control the answer, how reliance is recorded, how errors are remediated, and how customers are protected when an automated channel speaks with the company's practical authority. The Air Canada dispute is therefore a small claim with a large operational message: automation that answers customer policy questions is not outside the company. It is part of the company.

Automation governance should be tested before customers become the test set

The operational danger in customer-service automation is that companies may discover policy failures only after customers rely on them. That is the wrong testing model for refund, fare, insurance, credit, healthcare, travel, or legal-adjacent advice. High-consequence topics should have pre-release tests that ask common questions in messy real-world language, compare answers against approved sources, and verify that the system routes uncertain cases to humans. Customers should not become the first meaningful regression suite.

The test set should include contradictions. It should ask the same question with different dates, fare types, travel status, customer locations, and evidence constraints. It should ask about exceptions, deadlines, appeal paths, and refunds after service has already been used. It should include questions that the bot must decline to answer directly. A system that answers every question confidently is not mature; it may simply be hiding uncertainty. A governed system knows when not to speak.

Release governance should also cover source drift. If the bereavement page changes, if a tariff is updated, if a regulator changes passenger-rights language, or if a policy team clarifies an exception, the bot's controlled source must change at the same time. The company should be able to show that the updated source reached the bot, that old conflicting answers were retired, and that high-risk test cases passed after the change. This is ordinary change management applied to automated communication.

The value of automation is not defeated by these controls. Good automation can reduce wait times and help customers find accurate information. But the value exists only when the system is trustworthy. Trustworthy automation is not defined by fluent answers. It is defined by source control, testing, escalation, evidence retention, and remedies when the company-controlled channel gives a customer the wrong instruction.