Your customer support team turned on sentiment analysis last quarter. The customer is not told. The customer's verbatim transcript may become training data for the vendor depending on the contract. The customer's escalation path is determined by an AI the customer cannot challenge. GDPR Articles 13, 22, and 9 each have something to say about that, and almost no support team currently has answers that satisfy basic GDPR compliance requirements.
This piece is the operational map for the DPO and the Head of Customer Operations sitting on a rollout of Intercom Fin, Forethought, Cresta, Ada, or a call-transcription product. Four data types, the GDPR exposure per type, and the six things the support team has to do before the rollout is defensible.
The Four Data Types In Customer Support AI
The data flowing through a typical customer support AI deployment splits into four categories, each with a different regulatory profile.
Verbatim transcripts. The actual words the customer said or typed. Voice transcribed by speech-to-text, chat captured natively. The transcript is personal data of the customer (and any third party named in it) by definition.
Inferred sentiment. The AI's classification of the customer's emotional state - frustrated, angry, confused, satisfied. The classification is itself personal data, generated by the firm about the customer, and the inference may surface special category data even when the verbatim transcript does not.
Customer profile and journey data. Account history, prior tickets, product usage, and the AI-driven enrichment that builds a profile picture used for routing, prioritisation, and next-best-action. Personal data, often combined from multiple processing activities the firm conducts under different lawful bases.
Agent feedback signals. The data the AI captures about how human agents handled cases, adherence to scripts, response times, resolution outcomes, AI suggestions accepted or overridden. This is employee personal data, with its own GDPR exposure on the employment-relations side and works-council implications in some member states.
GDPR Exposure Per Type
Verbatim transcripts attract Article 13 information obligations at the point of collection, typically the start of a chat or call, and Article 28 processor obligations on the support AI vendor. Where transcripts are used to train the vendor's models, the lawful basis is contested unless the customer has been specifically informed and a clear basis (consent, or legitimate interests with appropriate safeguards) is established. The default contract terms of some support AI vendors place transcripts in a training pool unless the firm holds an Enterprise tier with explicit no-training commitments, a gap the firm's data processing register will not reflect if the DPO was never informed of the change.
Where the Transcript Problem Actually Starts |
The transcript handling problem rarely surfaces through a DPO review. It surfaces through a vendor terms update. The support AI vendor sends out a notice, data processing terms updated, effective within thirty days. The legal team brings it to procurement, who brings it to IT, who updates the contract record accordingly. The DPO does not hear about it because the renewal workflow was never designed to include them. By the time the DPO finds out, typically because something else triggers a review of the support stack, the new terms have been live for two quarters. In any discovery run Montro conducts, the first question is not whether the tool is sanctioned; it is when the contract was last reviewed by the DPO and whether the current terms match what the DPO signed off on. The answer is almost never YES. |
Inferred sentiment is where Article 9 special category data risk lives. Sentiment analysis on the verbatim transcript can surface inferred information about health ("frustrated because of medication issue"), religion ("calling because of Ramadan-related billing question"), sexual orientation, and political opinions. The Article 9(1) prohibition applies regardless of whether the inference was the firm's intention; the Article 9(2) lawful basis exceptions are narrow and rarely cover incidental inference in a customer support context. The DPC and CNIL have both signalled in supervisory communications that inferred special category data attracts the same protections as directly-collected special category data.
Customer profile and journey data attracts Article 14 obligations when the data is enriched from sources other than the customer themselves. The notice obligation under Article 14 is more demanding than Article 13 because the customer may not know the firm holds the data. Each enrichment source that feeds the AI's profile-building is a processing activity that warrants its own RoPA GDPR entry.
AI-driven escalation, refund eligibility, and account-closure recommendations potentially engage Article 22. The threshold is decisions producing legal effects or similarly significant effects. Routing decisions typically do not reach the threshold. Refund-eligibility scoring, escalation gating that determines whether a customer gets human attention, and account-closure recommendations typically do, particularly when the AI's recommendation is followed without meaningful human review.
Article 13 and 14 - The Notice Obligation
The information obligations are where most support AI deployments fall short. Article 13 requires the customer to be told, at the point of collection, the identity of the controller, the purposes of the processing, the lawful basis, recipients including processors, retention periods, and rights including the right to object and to withdraw consent.
"Calls may be recorded for training purposes" was sufficient in 2010. It is not sufficient in 2026. The current standard, signalled across European supervisory authorities, requires the notice to be specific enough that the customer can understand what processing actually happens, that the call will be transcribed, that the transcript will be analysed by AI for sentiment and routing, that AI may make or substantially influence decisions about their case, that the transcript may be retained by the support AI vendor and may be used for model improvement, and what the customer can do about each.
Practical implication. Most firms need to revisit the call-opening notice, the chat opening message, and the privacy notice on the contact-us page in tandem with any support AI rollout. Getting this right is the first privacy governance test of a defensible customer support AI deployment, and the notice must be present before the customer's data starts being processed, not retroactively.
Six Things the Support Team Must Do
Before the deployment is defensible:
- Audit the transcript handling against the vendor contract. Where transcripts go, who retains them, whether they enter training pools, whether the firm has the Enterprise-tier contract that prevents this. The default contract is usually not the one the firm thinks it has.
- Identify the Article 9 risk in sentiment analysis. The risk is real even when the firm has no intention of inferring special category data. Configure the sentiment model's exposure to inputs likely to surface health, religious, or sexual orientation content; document the safeguard.
- Map the Article 22 trigger points. Which AI-driven decisions reach the legal-or-similarly-significant threshold. Build human review into the workflow at those points, with the human review meaningful enough to satisfy the supervisor.
- Update the Article 13 and 14 notices. The call opening, the chat first message, and the contact-us privacy page. Specific to the AI processing, in language the customer can act on.
- Update the Article 30 RoPA, the firm's data processing register. The new processing activities, sentiment analysis, AI-driven routing, customer profile enrichment, agent feedback, each warrant their own RoPA entries with their own purposes, lawful bases, and retention determinations.
- Run the DPIA where applicable. Sentiment analysis at scale, AI-driven decision support for refund and account-closure determinations, and any system processing special category data attract Article 35 DPIA obligations. The DPIA is the documented basis for the rollout decision.
None of this prevents the rollout. All of it makes the rollout defensible from an AI compliance standpoint if the supervisor asks, and the question of "what AI is your support team running on customer conversations" is increasingly part of EDPB-coordinated inspection focus across member states.
Frequently Asked Questions
Is inferred sentiment data considered personal data under GDPR?
Yes. Sentiment classifications generated by AI - frustrated, angry, satisfied, are personal data because they relate to an identifiable individual. Where the inference surfaces information about health, religion, or sexual orientation, it becomes special category data under Article 9, and the firm's GDPR compliance position on that inference needs to be documented before the rollout, not after.
Do works council consultation requirements apply to customer support AI?
Not directly for customer-facing processing, but agent feedback signals captured by support AI are employee personal data. In Germany, the Netherlands, and Austria, deploying systems that monitor employee performance or behaviour typically requires works council consultation before implementation. The agent-facing layer of a support AI deployment can trigger co-determination obligations that the customer-facing layer does not.
What lawful basis applies to using customer transcripts for vendor model training?
Consent is the most defensible basis where transcripts enter a vendor's training pool, but consent must be freely given, specific, and informed, which most call-opening notices do not currently satisfy. Legitimate interests is theoretically available but requires a balancing test that is difficult to pass where the customer's reasonable expectation is that their support conversation will not be used to train a commercial AI model. The safest position is a contractual carve-out that prevents training use entirely.
What does EDPB-coordinated inspection focus on customer support AI mean in practice?
The European Data Protection Board coordinates thematic inspection campaigns across national supervisory authorities. Where customer support AI is identified as a coordinated focus area, it means multiple national DPAs are likely to inspect organisations in their jurisdiction on the same set of questions simultaneously, transcript handling, sentiment inference, Article 13 notices, and Article 22 trigger points. A finding in one member state on these issues increases the likelihood of inspection in others, which is why privacy governance across the full customer support AI stack cannot be treated as a single-jurisdiction problem.
