# AI Agents for Customer Support on Customer Data: The Playbook on Rails

AI agents for customer support on customer data do three narrow jobs: brief a service agent, propose a queue and flag objections or complaints. They work at read and propose levels (L1 to L2). They never reply to a customer, promise an outcome or change consent. A customer data platform (CDP) supplies a masked, consent-aware summary. Customer-facing bots belong on the service platform, and that is where this rail ends.

**Who this is for:** heads of customer support, with the DPOs and architects who decide what customer data reaches a service desk. This playbook is part of the [AI agent rails](https://privycdp.org/ai/rails) method: one job, one data scope, one approver, one audit trail. You get a ranked order, a roster, a case flow, condensed rail cards and a 90-day path. Vendor facts were checked on 1 November 2026.

## The customer-data jobs support does today

Customer support teams handle seven customer-data jobs, and many errors stay quiet until a customer or regulator notices. The table is qualitative, so fill in your own baselines before you change anything.

| Job | How often | Where the time goes | Cost of an error |
|---|---|---|---|
| Work out who is asking and what matters about them | Every case | Switching between helpdesk, CRM and billing | Wrong advice, or data shown to the wrong person |
| Sort and route new cases | Every case | Reading, re-queuing, transfers | Urgent cases wait and customers repeat themselves |
| Answer routine questions | Many times a day | Searching knowledge articles | A wrong statement the company may have to stand behind |
| Decide refunds, credits and exceptions | Daily | Checking policy and history | Money lost, unfair treatment, a formal complaint |
| Spot complaints, objections and vulnerable customers | Every case, and easily missed | Reading between the lines | A missed legal clock, or harm to the customer |
| Record a consent or preference change raised in a case | Weekly or more | Re-keying into other systems | Contact after someone asked you to stop |
| Hand a case to another team | Several times a day | Rewriting the history | Lost context and a slower outcome |

## Where agents help in customer support, ranked by value and risk

Agents help most in customer support when they prepare a person to act, and least when they speak for the company. We recommend this order, which starts with the flag that protects a legal clock and ends with the widest data scope.

| Order | Job | Agent | Level | Why here |
|---|---|---|---|---|
| 1 | Flag objections, complaints and possible vulnerability | [Escalation Spotter](https://privycdp.org/ai/rails/agents/escalation-spotter) | L1 | High value and no action path. Helpdesk triage sorts topics, while objection wording needs your own labels. |
| 2 | Propose category, priority and queue | [Case Classifier](https://privycdp.org/ai/rails/agents/case-classifier) | L2 | Easy to measure against history, and a wrong queue costs minutes. Check your helpdesk's own triage first. |
| 3 | Summarise the customer for the service agent | [Context Briefer](https://privycdp.org/ai/rails/agents/context-briefer) | L1 | The most sensitive scope. It needs field projection, masking tests and DPO sign-off, so it comes last despite its low level. |
| Not on this rail | Answer customers, decide refunds | Service-platform bot or a person | Outside these rails | The conversation, transcript and handoff live on the service platform. |

For the full job design of the third row, read [customer context for support agents](https://privycdp.org/ai/rails/use-cases/customer-context-for-support).

## Where does support automation belong, and where does the rail end?

Customer-facing automation belongs on the service platform, because the conversation, knowledge base, handoff and transcript already live there. A CDP's rail ends when a masked summary reaches the service agent's panel. Anything that talks to the customer is a different system, with a different owner and a different risk.

| Question | Service platform | Customer data platform rail |
|---|---|---|
| Who talks to the customer? | A bot or a service agent | Nobody. The rail holds no outbound tool. |
| Knowledge answers | Yes | No |
| Ticket free text | Stored and processed here | Excluded from the Context Briefer's session |
| Customer profile | Reads what the desk needs | Holds the unified record and projects a masked view |
| Consent state | Reads it | System of record; changes arrive through the consent path |
| Refund or credit | Service workflow with its own approval | No tool exists |
| Evidence | Vendor transcripts and logs | Rail ledger for what left the customer data platform |

Two consequences follow. If you run knowledge answers on a helpdesk and need nothing from unified profiles, you may need no rail from the customer data platform side. If a vendor bot does want live profile data, treat that feed as a new rail with its own card. The bot's session would then hold customer text and customer data together, which is exactly the pairing the Rule of Two warns about [6](#source-6).

## Which agents does customer support need on rails?

Customer support needs at most three agents on rails, and none of them sends anything to a customer. Names and levels below follow the roster. The [Orchestrator](https://privycdp.org/ai/rails/orchestrator-agent) can route work to them, and the [Trainer](https://privycdp.org/ai/rails/trainer-agent) keeps their labelled test sets current.

| Agent | Job | Level | Data scope | Gate | Main metric |
|---|---|---|---|---|---|
| Escalation Spotter | Flag possible complaints, legal objections or vulnerable customers | L1 | Case text, treated as untrusted, and case status; no profile data | A team lead reviews each flag | Recall on labelled objections; flag precision |
| Case Classifier | Propose category, priority and queue | L2 | Case text, treated as untrusted, and category definitions; no profile data | A service agent or team lead accepts or changes it; low confidence goes to a person | Precision per category; share changed by people |
| Context Briefer | Give a masked, consent-aware summary | L1 | Masked profile summary, interactions by type, consent flags; ticket free text excluded | The service agent decides what to do with it | Masked-field leaks (target zero); handling time measured by the team |

## How does customer support work on rails?

Customer support on rails keeps every decision with a named role, while agents add a flag, a proposal or a summary beside the case. At L1 and L2 nothing executes, so the people below read and review. They approve no agent action, because no agent action exists.

- **Service agent:** opens the case, reads the summary, accepts or changes the queue, and writes the reply.
- **Team lead:** reviews flags and low-confidence proposals.
- **Rail owner:** the head of customer support owns all three rails. The DPO co-owns the Escalation Spotter's flag definitions.
- **DPO or privacy team:** signs off data scope and handles objections that need judgement.
- **Auditor:** compliance samples the ledger and tests that masked fields stay masked.

**A week in the life (illustrative).** On Monday the team lead reads the weekend's flags and finds two real objections and one false alarm. On Tuesday a billing surge sends many low-confidence proposals to people, which is what the rail is meant to do. On Wednesday a spot check shows a summary missing a recent cancellation, so the rail owner opens a fix. On Thursday the DPO adds two plain-language objection phrases to the test set. On Friday the team reviews override samples by queue, and nobody's name appears.

**One case, end to end (illustrative).** A customer writes: "Your last invoice is wrong, and stop sending me your offers."

| Step | Proposes | Checks | Approves | Logged |
|---|---|---|---|---|
| Case opens | Customer | Helpdesk checks authentication state | Not needed | Case reference |
| Classify | Case Classifier: billing, normal priority, billing queue | Confidence rule sends low scores to a person | Service agent accepts or changes | Proposal, confidence, final category, model version |
| Flag | Escalation Spotter: possible objection, quoting the passage | A keyword rule runs beside the model | Team lead reviews | Flag type, reviewer decision |
| Context | Context Briefer: masked summary with consent flags | Data view enforces field projection | Service agent decides how to use it | Case reference, fields returned, model version |
| Objection | Service agent or privacy team records it | Consent service validates the event; send-time check blocks marketing | Privacy team where unclear | Consent event with provenance |
| Reply | Service agent, perhaps with a vendor draft | Person checks policy and tone | Service agent sends | Helpdesk transcript |
| Close | Service agent | Sampled quality review | Team lead on sampled cases | Case outcome |

## Rail cards for the three support agents

The rail cards below are condensed from the roster, and systems rather than prompts enforce them. A data view limits fields, a tool allow-list removes outbound tools, and a gateway writes the ledger. Copy the structure from the [rail card template](https://privycdp.org/tools/agent-rail-card).

| Field | Escalation Spotter | Case Classifier | Context Briefer |
|---|---|---|---|
| Job | Flag possible complaints, legal objections or vulnerable customers | Propose category, priority and queue | Give a service agent a masked, consent-aware summary |
| Trigger | New or updated case | New case | Case opened by an authenticated service agent |
| Data scope | Case text, untrusted, and status; no profiles | Case text, untrusted, and category definitions; no profiles | Masked profile view, interactions by type, consent flags; no ticket free text |
| Tool scope | Read only; a routing service outside the model posts the flag | Read, plus a proposal; no outbound tools | Read only |
| Output contract | Flag type, the passage that triggered it, team to notify | Proposal, confidence, one-sentence reason | Short summary, consent flags, what it leaves out |
| Gate | Team lead reviews each flag | Person accepts or changes; low confidence goes to a person | Service agent decides |
| Limits | Flags only; no outbound tools | No outbound tools; budget per run | One customer per run; field projection by purpose; no export |
| Ledger | Case reference, flag type, reviewer decision | Case reference, proposal, confidence, final category, model version | Case reference, fields returned, service agent, model version |
| Evaluation | Labelled cases, including objections in plain language | Labelled history, including injection attempts in case text | Spot checks; tests that masked fields stay masked |
| Owner and kill switch | Head of customer support with the DPO; disable flags and existing escalation rules continue | Head of customer support; disable proposals and cases follow the normal queue | Head of customer support; disable the panel and service agents use the normal record view |
| Rule of Two | Untrusted input, and possibly personal data in the text; no state-changing tool | Same | Sensitive data only; no untrusted text and no state-changing tool |

The Rule of Two check explains the split in data scope [6](#source-6). Case text is written by outsiders, so the two sessions that read it get no profile data and no outbound tools. The session that reads profile data gets no case text. A hostile instruction in a ticket therefore cannot reach the masked profile, and it has no tool to send anything anywhere.

## What should customer support not automate?

Customer support should keep commitments, consent and final outcomes with people, because each one binds the company or changes a customer's rights. The [7 things AI agents should never do with customer data](https://privycdp.org/ai/7-things-ai-agents-should-never-do-with-customer-data) set the general limits. These are specific to support:

- Promising an outcome, refund or exception from any agent on these rails.
- Replying unreviewed on regulated topics, complaints or vulnerable customers.
- Reading full personal data beyond what the case needs.
- Recording an objection or consent change from a model's reading of a ticket.
- Closing a case, or marking a complaint as resolved.
- Using support summaries, flags or sentiment labels for marketing.
- Reporting on named service agents from agent output.

## Regulation touchpoints for customer support

Customer support raises regulatory questions at every step: who must be told about AI, who answers for a bot's statement, how objections are handled and what monitoring does to staff. Each paragraph below is a starting point for your counsel, and none is a legal conclusion.

### What does AI Act Article 50 require of a support bot?

EU AI Act Article 50 requires that people are told they are dealing with AI, and the duty has applied since 2 August 2026. Article 50(1) places it on the provider, unless the AI is obvious to a reasonably attentive person [2](#source-2). The Commission's FAQ reads that exception restrictively and asks for disclosure at the start of the first interaction [1](#source-1). Its criteria include that the AI communicates directly, not through a human [1](#source-1). So an internal summary read by a service agent looks different from a chatbot, though counsel should confirm your case. Buying a bot does not end the question. Intercom's terms require the customer to ensure people are told [19](#source-19), and its disclosure guide says some channels need a separate message [18](#source-18). The [EU AI Act guide](https://privycdp.org/regulation/eu-ai-act-marketing-customer-decisioning) explains provider and deployer roles.

### Who is liable when a support bot promises something?

Moffatt v. Air Canada is a widely reported decision on who answers for a chatbot's statement. On 14 February 2024 the British Columbia Civil Resolution Tribunal held the airline liable for negligent misrepresentation after its website chatbot gave wrong bereavement-fare advice [7](#source-7)[10](#source-10). The airline argued the chatbot was a separate entity, and the tribunal called this "a remarkable submission" [7](#source-7). A link to the correct policy did not help [9](#source-9), and customers were not expected to cross-check pages [8](#source-8). The award was small: C$650.88 plus interest and fees [8](#source-8). This is one Canadian tribunal on negligence, so take local advice. The rail lesson is practical. Keep refunds, compensation and legal topics on the service platform's escalation list, ground answers in approved policy and keep the transcript. Summaries need the same care, because a service agent may repeat what a summary implies.

### What happens when a customer objects in a support ticket?

A customer objecting in a support ticket has still exercised a right, even if the words are plain. GDPR Article 21(2) lets a person object to direct marketing at any time, and Article 21(3) says the data may no longer be used for that purpose [3](#source-3). Nobody writes "I object under Article 21". They write "stop sending me your offers". Our [consent withdrawal architecture](https://privycdp.org/email/consent-withdrawal-suppression-architecture) gives the clocks and the propagation design, including this exact test case. On rails, the Escalation Spotter flags the passage and a team lead reviews it. A person or the consent service then records the event, so the agent never writes consent. A keyword rule runs beside the model, because silence from a model does not mean no objection was made. Objections to other processing under Article 21(1) need a judgement, so route them to the privacy team.

### When does a support decision become an automated decision?

A support outcome can become an automated decision when a system decides alone and the effect on the person is significant. GDPR Article 22 covers solely automated decisions with legal or similarly significant effects, and the SCHUFA ruling shows a score can count when others draw strongly on it. Account closures and fraud-driven restrictions need the most care. Read [explainable AI for customer decisions](https://privycdp.org/ai/explainable-ai-customer-decisions) before a service bot gains that power. The three agents here hold no such tool, but a priority score that people always follow deserves the same question.

### Can support data be used for marketing?

Support data used for marketing is a new purpose, so it needs its own check rather than a quiet reuse. GDPR Article 6(4) lists the factors for assessing a new purpose, including the link to the original one, the context, the nature of the data and the consequences [4](#source-4). Ticket text can hold health details, money troubles or family events, and Article 9 restricts special categories. People did not write those words for a campaign. Keep flags, sentiment and summaries out of segments unless your DPO has approved that purpose in writing.

### What do monitoring and sentiment rules mean for support teams?

Support analytics reach employment rules once they evaluate people rather than queues. AI Act Annex III point 4(b) lists systems that "allocate tasks based on individual behaviour or personal traits or characteristics", and systems that monitor and evaluate workers [5](#source-5). Annex III duties apply from 2 December 2027. Routing cases by an individual's past handling times, or ranking staff by acceptance rate, comes close, so take advice. Vendor dashboards make this easy: Zendesk's Copilot reports include acceptance by named agent [17](#source-17). Voice is a separate problem. Our EU AI Act guide records that emotion recognition is prohibited at work, apart from medical or safety reasons. It also notes that draft guidance treats call-centre voice analysis as an example, while sentiment from typed text is not biometric. Keep the Escalation Spotter on text, and report by team and queue.

### What about vulnerable customers?

Vulnerable customers need a person, and a flag can only draw that person's attention. In UK financial services, the FCA's FG21/1 says firms should be able to spot signs of vulnerability and that frontline staff need the skills to respond [11](#source-11). A July 2026 note on that page points readers to the Consumer Duty for current expectations [11](#source-11). The Escalation Spotter can raise a flag from the text. It should not infer a condition, store a label or decide treatment.

## Honest metrics for customer support agents

Honest metrics for customer support agents measure review quality and data exposure, and they are reported by team and rail rather than by named person. The definitions follow the [AI marketing operations roadmap](https://privycdp.org/ai/ai-marketing-operations-roadmap). Take a baseline first. We publish no savings figures, because yours depend on your queues.

| Metric | What it tells you | The trap |
|---|---|---|
| Masked-field leaks | Whether the data view holds | Target zero. One real leak should demote the rail. |
| Recall on labelled objections | Whether plain-language objections get caught | A set shows only what you labelled, so keep adding real wording |
| Flag precision | Whether team leads can trust flags | Low precision causes fatigue, and then real flags get missed |
| Time from objection written to suppression recorded | The whole path, not just the agent | Start the clock at the customer's message, not at the flag |
| Precision per category | Where the classifier is weak | One good average can hide a blind spot in a rare queue |
| Share changed by people | Override rate for the Case Classifier | Near zero may mean people have stopped reading, so sample |
| Handling time, measured by the team | Whether the summary helps | Faster is not better if reopened cases rise |
| Audit coverage | Share of runs with a complete ledger record | Anything below 100% is a defect |
| Cost per accepted task | Inference and review time per used output | Include idle capacity |

## A 30/60/90-day adoption path for support

A 30/60/90-day path for support moves from shadow flags to one masked summary pilot, and a team can stop at any stage. The level ceiling here is L2. A request for agents to reply alone is a service-platform decision with its own owner, not a promotion of these rails. See [rail levels](https://privycdp.org/ai/rails/rail-levels-autonomy-ladder) for how promotion and demotion work.

1. **Days 1 to 30.** Take baselines, name the rail owner and write three rail cards. With the DPO, collect real objection wording and label it. Run the Escalation Spotter in shadow beside your existing rules, with flags visible only to the rail owner.
2. **Days 31 to 60.** Send flags to team leads once recall and precision meet your written bar. Test your helpdesk's triage against a labelled set. Buy it if it is good enough. Otherwise run the Case Classifier at L2 with low confidence going to a person.
3. **Days 61 to 90.** Pilot the Context Briefer on one queue. Get DPO sign-off on the field projection, run masking tests, and drill the kill switch. Compare handling time and reopened cases by team.

Stopping after step 1 or 2 is a good outcome if the summary adds little. Demotion is automatic on an open incident, a serious escaped error, a breached error budget or a model change without a regression pass.

## Vendor agents and when they are enough

Vendor agents are the right answer for most customer-facing support automation, and the table shows what each product's documentation says. All rows were checked on 1 November 2026. "Not stated" means the pages we opened do not say, so ask the vendor.

| Product | What it covers | How review and approval work | Disclosure and data notes | Source |
|---|---|---|---|---|
| Zendesk AI agents and Copilot | Customer-facing agents; auto assist; intelligent triage by topic, sentiment and language | Service agents approve suggestions. Admins can pre-approve actions, typically information gathering; data updates generally need approval. Triage fills fields automatically and agents can change them. Admins build escalation logic with triggers. | AI agents identified in the messaging interface. Zendesk states zero retention with LLM providers. | [12](#source-12)[13](#source-13)[14](#source-14)[15](#source-15)[16](#source-16) |
| Intercom Fin and Copilot | Fin answers from support content, with data connectors for live data; Copilot drafts for teammates | Escalation rules by topic. Copilot changes records with the teammate's approval. | Terms make the customer responsible for telling people. Some channels need a Workflows message. AI providers are sub-processors. | [18](#source-18)[19](#source-19)[20](#source-20)[21](#source-21)[22](#source-22) |
| Salesforce Agentforce Service | Customer-facing agent grounded in CRM data, handing off to Service Cloud with context | The customer defines topics, instructions and escalation conditions. Examples include sensitive language and policy exceptions. | Salesforce's June 2025 FAQ and blog say masking is disabled for Agentforce and zero retention applies. The FAQ says the customer is responsible for agent output. Confirm the current position. | [23](#source-23)[24](#source-24)[25](#source-25) |
| HubSpot customer agent | Answers from chosen content; actions such as password reset; CRM property permissions | Hands off when it cannot answer or the visitor asks. A "no handoff" mode exists. No approval step is described for actions. | AI settings control shared data. Disclosure not stated. | [26](#source-26)[27](#source-27) |
| Freshworks Freddy | Summary generator, reply suggester, auto triage, AI Agent Studio | Not stated. The page is unclear on whether triage recommends or sets values. | Not stated on the page opened. | [28](#source-28) |

Use a vendor agent alone when these hold:

- One helpdesk holds the case and the customer data the desk needs.
- Tickets hold no regulated or special-category data, or the contract covers it.
- The need is knowledge answers and routing, not context across systems.
- You have no team to run private inference.

A rail from the customer data platform adds value when consent and profile data live there, when several channels must treat an objection the same way, or when regulated data cannot reach an external model. A script may beat all of these. A fixed panel with field-level permissions shows tier and consent flags with no model at all, and a keyword rule catches many plain objections. For cost comparisons, see [Agentforce pricing against owned inference](https://privycdp.org/ai/agentforce-pricing-vs-owned-inference).

The Context Briefer should run on a private model inside your environment, with no external model for this data, as the [on-premise LLM guide](https://privycdp.org/ai/on-premise-llm-deployment-marketing-personalization) and the [boundary architecture](https://privycdp.org/ai/ai-agents-on-customer-data-inside-your-boundary) describe. The other two prefer a private model and may use an external one only with masking and contract cover. PrivyCDP offers an MCP-ready interface, bring-your-own-model in the customer environment, and an immutable audit ledger that records each AI-assisted action with the human or system actor that authorised it.

## Checklist before a support agent reads customer data

This checklist covers what a head of customer support should confirm before any agent reads case text or customer data.

- [ ] The rail owner, DPO contact and auditor are named.
- [ ] Each agent has a written rail card and a kill switch that has been drilled.
- [ ] Sessions that read case text hold no profile data and no outbound tools.
- [ ] The session that reads profile data holds no ticket free text.
- [ ] Masked fields are removed by the data view, not by the prompt.
- [ ] A test proves masked fields stay masked, and it runs before every model change.
- [ ] Objection wording is labelled from real cases, and keyword rules run beside the model.
- [ ] An objection enters the consent path with provenance, and no agent can write consent.
- [ ] Customer-facing bots disclose AI at first contact on every channel.
- [ ] Refunds, compensation, complaints and legal topics are on the bot's escalation list.
- [ ] Support flags and summaries cannot reach segments without a separate approved purpose.
- [ ] Reports use team, queue and rail, and show no named staff.

> **Diagram:** Two-lane diagram of one support case. Top lane "Service platform": customer, helpdesk, service agent, vendor bot, transcript. Bottom lane "Customer data platform rail": data view, Context Briefer, consent service, ledger. A vertical line labelled "The rail ends here" sits at the summary panel. Two separate sessions read case text (Case Classifier, Escalation Spotter), with a crossed-out arrow to profile data. Gates drawn as diamonds at team lead review and service agent decision.

Rail level: L1 to L2 · Risk: medium · Function: customer support

By Art Kukharenko
Published: 2026-11-02
Updated: 2026-11-02

## FAQ

### Can AI agents answer customers using customer data?

Yes, but that bot belongs on the service platform with its own controls. It would hold customer text and customer data in one session, and the ability to communicate. That is all three risky properties in the Rule of Two, so limit what the bot can read and do, and keep a person on anything that matters. The agents in this playbook never reply to customers at all.

### Which AI agent should a support team start with?

Start with the Escalation Spotter in shadow mode. It protects a legal clock, holds no action path and teaches the team to label real wording. Then test your helpdesk's own triage before building a Case Classifier. Leave the Context Briefer until the DPO has signed off a field projection, because it reads the most sensitive data.

### Do we have to tell customers they are talking to an AI?

Under EU AI Act Article 50, people must be told they are dealing with AI unless that is obvious, at the latest at first interaction. The Article 50(1) duty sits with the provider, but contracts can pass the work to you, as Intercom's terms do. Check every channel, because disclosure settings can differ between chat, email and messaging apps.

### Is a company liable for what its support chatbot says?

It can be. In Moffatt v. Air Canada, a British Columbia tribunal held the airline liable for wrong bereavement-fare advice from its website chatbot, and it rejected the argument that the bot was a separate entity. That is one Canadian decision on negligent misrepresentation, not a global rule. Keep entitlement topics on an escalation list and take local advice.

### What should happen when a customer objects in a support ticket?

Treat it as an objection, whatever words the customer used. Under GDPR Article 21 the data may no longer be used for direct marketing. A flag or a trained service agent spots it, a person or the consent service records it with provenance, and every channel receives it. A send-time check then blocks any campaign already scheduled. The agent never writes consent itself.

### Can we use support tickets to build marketing segments?

Not as a quiet reuse. Marketing is a different purpose from resolving a case, and GDPR Article 6(4) sets the factors for assessing a new one. Tickets also hold sensitive details that people wrote for a different reason. If you want this, ask your DPO to assess it first, and keep the agents' flags and summaries out of segments until they approve it in writing.

### Do support agents need a private model?

The Context Briefer should use one, because it reads customer data and the roster allows no external model for that scope. The Case Classifier and Escalation Spotter prefer a private model, but case text can go to an external one with masking and contract cover. If your helpdesk vendor already processes those tickets under contract, compare that exposure before you add a second system.

## Sources

1. European Commission, Transparency obligations under Article 50 of the AI Act, FAQ (updated 24 July 2026): https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act
2. EU AI Act, Article 50 (unofficial text): https://artificialintelligenceact.eu/article/50/
3. GDPR Article 21: https://gdpr-info.eu/art-21-gdpr/
4. GDPR Article 6: https://gdpr-info.eu/art-6-gdpr/
5. EU AI Act, Annex III (unofficial text): https://artificialintelligenceact.eu/annex/3/
6. Meta, Agents Rule of Two (31 October 2025): https://ai.meta.com/blog/practical-ai-agent-security/
7. McCarthy Tétrault, Moffatt v. Air Canada, 2024 BCCRT 149: https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot
8. Dentons, Airline ordered to compensate a B.C. man: https://www.dentonsdata.com/airline-ordered-to-compensate-a-b-c-man-because-its-chatbot-provided-inaccurate-information/
9. WeirFoulds, Moffatt v Air Canada (6 March 2024): https://www.weirfoulds.com/moffatt-v-air-canada-bot-betrayal-and-negligent-misrepresentation
10. DWW, BC tribunal finds Air Canada liable for inaccurate advice given by website chatbot: https://www.dww.com/articles/bc-tribunal-finds-air-canada-liable-for-inaccurate-advice-given-by-website-chatbot
11. FCA, FG21/1 Guidance for firms on the fair treatment of vulnerable customers: https://www.fca.org.uk/publications/finalised-guidance/guidance-firms-fair-treatment-vulnerable-customers
12. Zendesk, About auto assist: https://support.zendesk.com/hc/en-us/articles/9945148867866-About-auto-assist
13. Zendesk, Using auto assist to solve tickets: https://support.zendesk.com/hc/en-us/articles/7051314237466-Using-auto-assist-to-help-agents-solve-tickets
14. Zendesk, Automatically classifying tickets with intelligent triage: https://support.zendesk.com/hc/en-us/articles/4550640560538-Automatically-classifying-tickets-with-intelligent-triage
15. Zendesk, Using intelligent triage to act on ticket escalations: https://support.zendesk.com/hc/en-us/articles/6353620565530-Using-intelligent-triage-to-identify-and-act-on-ticket-escalations
16. Zendesk, AI Trust at Zendesk: https://support.zendesk.com/hc/en-us/articles/9196781863578-AI-Trust-at-Zendesk
17. Zendesk, Analyzing your Copilot activity: https://support.zendesk.com/hc/en-us/articles/9308443151258-Analyzing-your-Copilot-activity
18. Intercom, AI Agent Disclosure (30 June 2026): https://www.intercom.com/help/en/articles/11712008-ai-agent-disclosure
19. Intercom, Additional Product Terms (effective 18 March 2026): https://www.intercom.com/legal/terms-and-policies/additional-product-terms
20. Intercom, Fin AI Agent FAQs (11 September 2026): https://www.intercom.com/help/en/articles/7837535-fin-ai-agent-faqs
21. Intercom, Using actions for automation (17 July 2026): https://www.intercom.com/help/en/articles/6298285-using-actions-for-automation
22. Intercom, Copilot: https://www.intercom.com/helpdesk/copilot
23. Salesforce, Agentforce Privacy FAQ (June 2025): https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Privacy/agentforce-privacy-FAQ.pdf
24. Salesforce, LLM data masking in the Einstein Trust Layer (10 June 2025): https://www.salesforce.com/blog/llm-data-masking/
25. Salesforce, Einstein Service Agent announcement, now Agentforce Service Agent (17 July 2024): https://www.salesforce.com/news/stories/einstein-service-agent-announcement/
26. HubSpot, Customer agent handoff (7 October 2026): https://knowledge.hubspot.com/customer-agent/set-up-and-customize-the-customer-agents-handoff-process
27. HubSpot, Set up the customer agent (16 September 2026): https://knowledge.hubspot.com/customer-agent/set-up-the-customer-agent
28. Freshworks, Overview of Freddy AI for ticketing (17 June 2026): https://support.freshdesk.com/support/solutions/articles/50000010359-overview-of-freddy-ai-for-ticketing

Back to the [AI agent rails hub](https://privycdp.org/ai/rails). To test where your service desk's rail should end and what a private deployment would involve, [request an architecture review](https://privycdp.org/demo).

This article is general information, not legal advice.

## Further reading

- [AI Agent Rails Readiness Assessment: Where to Start, Function by Function](https://privycdp.org/tools/agent-rails-readiness-assessment)
- [Case Classifier: An AI Agent That Proposes Support Queues](https://privycdp.org/ai/rails/agents/case-classifier)
- [Context Briefer: An AI Agent That Summarises Customers for Support](https://privycdp.org/ai/rails/agents/context-briefer)
- [Escalation Spotter: An AI Agent That Flags Objections and Complaints](https://privycdp.org/ai/rails/agents/escalation-spotter)
- [AI Agent Rails: An Operating Model for Running Agents on Customer Data](https://privycdp.org/ai/rails)