Your AI vendor will sell you a deflection rate. Your Data Protection Officer will ask where the personal data goes, who can read it, and how you delete it on request. This checklist is built for the second conversation.
GDPR compliance for AI customer support is the set of data-protection requirements an AI agent must meet when it processes EU and UK personal data on support tickets: a documented lawful basis, data minimization, PII handling, EU/UK data residency, a signed Data Processing Agreement, sub-processor transparency, support for data-subject rights, contractual no-training terms, and audit logging. In 2026, regulators treat an AI agent as a processor acting on your instructions, which means the obligations land on you and your vendor jointly.
GDPR fines can reach 20 million euros or 4% of global annual turnover, whichever is higher, per the official GDPR text (Article 83).
An AI support agent is almost always a data processor under Article 28, so a Data Processing Agreement and documented sub-processors are mandatory, not optional.
Training a model on customer support data without a lawful basis is one of the fastest-growing enforcement areas, which is why contractual no-training terms now sit at the top of procurement checklists.
Data-subject rights (access and erasure) must be answerable within one month, so your AI vendor needs a mechanical way to find and delete a person's data, not a manual ticket.
EU and UK data residency is now a hard requirement for many regulated buyers, not a preference, because international transfers carry their own Chapter V obligations.
Last updated: June 2026
This is a requirements checklist, not a vendor roundup. Each item below states the obligation, what good looks like in a vendor's answer, and how Lorikeet maps to it. The goal is to give your data-protection lead a document they can take into a vendor call and use to separate platforms that support your GDPR obligations from platforms that hand you a transcript and a privacy policy. Nothing here is legal advice; treat it as a procurement aid and confirm your specific obligations with your own counsel and DPO.
What GDPR Means for an AI Customer Support Agent
When an AI agent reads a ticket, looks up an account, and drafts a reply, it is processing personal data on your behalf. Under GDPR you are the controller (you decide why and how the data is processed) and the AI vendor is almost always the processor (they act on your documented instructions). That split matters because it determines who is accountable for each item in this checklist. The controller owns lawful basis, minimization, and the response to data-subject requests. The processor owns the technical and organizational measures that make those obligations achievable: residency, access controls, deletion mechanics, sub-processor management, and audit logs.
Controller: the organization that determines the purposes and means of processing personal data. For AI support, that is you, the company deploying the agent.
Processor: a party that processes personal data on the controller's behalf under a contract. For AI support, that is the platform vendor, and frequently the model providers behind it.
Lorikeet is an AI customer support platform built for complex and regulated companies, including fintechs, financial institutions, healthtechs, insurers, and regulated gaming operators. Roughly 80% of its customers are US financial institutions and fintechs, many of which also serve EU and UK customers and run the GDPR gauntlet in procurement. Lorikeet builds AI concierges that resolve issues end-to-end across chat, email, voice, SMS, and WhatsApp, and is built so a privacy and compliance team can review the data flows before launch rather than after an incident.
The GDPR Requirements Checklist for AI Customer Support
Work through these nine requirements with any AI support vendor. For each, ask the vendor to show, not tell. A privacy policy is a claim; a configuration screen, a DPA clause, or an audit log is evidence.
1. Documented lawful basis for processing
What good looks like: You can name the lawful basis for every category of personal data the AI touches, usually contract performance for resolving a customer's own request and legitimate interest for service improvement, with the analysis written down. The vendor's tooling does not force you into processing you cannot justify, and it lets you scope what the agent can and cannot access per workflow.
How Lorikeet maps: Lorikeet processes data strictly on your instructions as a processor. Workflows are configured in plain English, and each workflow only calls the tools and data sources you connect, so you can keep the agent inside the lawful basis you have documented. Lorikeet does not require you to feed it data beyond what a given workflow needs.
2. Data minimization
What good looks like: The agent retrieves only the personal data needed to resolve the specific ticket, rather than ingesting a full customer record by default. Tool access is scoped, and you can prove the agent did not pull fields it did not need.
How Lorikeet maps: Lorikeet uses least-privilege, scoped tools and webhooks: each integration endpoint is configured to expose only the specific actions and fields a workflow requires. The agent calls a tool to fetch an account status or a transaction rather than syncing whole customer tables, which keeps the data footprint tight and auditable.
3. PII detection and redaction
What good looks like: The platform can detect and redact personal data such as card numbers, government IDs, and health details before it is logged or passed to a model, and it does not store sensitive fields in plain text where they are not needed. Redaction is configurable to your data categories.
How Lorikeet maps: Lorikeet supports PII redaction so sensitive data can be stripped or masked in the processing and logging path. Combined with scoped tools, this limits the personal data that ever reaches model context or stored logs, which supports both minimization and security-of-processing obligations under Article 32.
4. EU and UK data residency
What good looks like: You can choose where personal data is stored and processed, and the vendor can keep EU or UK data in-region. Where data does cross borders, the vendor documents the transfer mechanism (such as Standard Contractual Clauses) so you can meet your Chapter V obligations.
How Lorikeet maps: Lorikeet offers data residency in the US, AU, and UK. UK residency directly supports UK GDPR data-localization expectations, and the residency options let regulated buyers keep data in an approved region rather than defaulting to a single jurisdiction. Confirm the specific region and current transfer documentation for your contract with the Lorikeet team, since residency scope is set per deployment.
5. Data Processing Agreement
What good looks like: The vendor signs an Article 28 Data Processing Agreement that names the subject matter, duration, nature, and purpose of processing, the categories of data and data subjects, and the processor's obligations, including assistance with data-subject requests and breach notification. The DPA is available before you sign the main contract, not after.
How Lorikeet maps: Lorikeet is set up to sign a Data Processing Agreement as part of onboarding regulated customers, and is GDPR-aligned in its data handling. Ask for the current DPA and any region-specific addenda during procurement so your DPO can review the processing terms and the assistance commitments alongside the technical measures.
6. Sub-processor transparency
What good looks like: The vendor maintains a current list of sub-processors (including the model providers and any cloud or telephony partners), gives you advance notice of changes, and lets you understand what each sub-processor does with personal data. Hidden sub-processors are a red flag.
How Lorikeet maps: Lorikeet dynamically routes work across model providers (Anthropic, OpenAI, and Google) by task, and uses voice partners such as ElevenLabs and Cartesia for voice synthesis. Because these are material sub-processors, ask Lorikeet for the up-to-date sub-processor list and change-notification process so you can keep your own records of processing current under Article 30.
7. Right to erasure and right of access
What good looks like: When a data subject asks for their data or asks to be deleted, the vendor gives you a reliable way to find every place that person's data lives and act on it within the one-month statutory window. Deletion is real deletion, including from logs and backups on a defined schedule, not just a flag in a UI.
How Lorikeet maps: As a processor acting on your instructions, Lorikeet is built to assist with data-subject requests, and PII redaction plus scoped data retention reduce how widely a person's data is spread in the first place, which makes access and erasure requests easier to fulfill. Confirm the specific deletion timelines and the handling of data held by sub-processors as part of your DPA review.
8. No model training on your customer data
What good looks like: The vendor contractually commits that your customer data will not be used to train its models or the underlying foundation models, and that commitment flows down to the model providers. This is in writing, not just in a sales conversation.
How Lorikeet maps: Lorikeet holds contractual no-training agreements with its model providers (OpenAI, Anthropic, and Gemini), so customer support data passed to those models is not used to train them. This is one of the clearest GDPR procurement wins, because it removes a common and hard-to-justify processing purpose from the equation. Ask for the relevant clause so your DPO can confirm the no-training commitment flows down the chain.
9. Audit logging
What good looks like: Every action the agent takes is logged in a way you can review and replay, so you can demonstrate accountability under Article 5(2), investigate an incident, and answer a regulator. Logs capture what data was accessed, what tool was called, and what decision was made.
How Lorikeet maps: Lorikeet produces audit trails of agent actions, and its Coach agent provides 100% automated QA, scoring and verifying resolutions rather than sampling a few. Combined with role-based access control on who can view ticket data, this gives a privacy team the accountability record GDPR expects, plus a way to detect when a workflow behaved outside its scope.
Defence in Depth: How the Requirements Fit Together
The checklist above is not nine separate boxes, it is a chain. A scoped tool (minimization) means less PII reaches a model, which makes redaction simpler, which shrinks what an erasure request has to reach, which makes the audit log cleaner. Lorikeet's broader approach reflects this: pre-launch adversarial simulations and red-teaming, inbound message checks, outbound guardrails, and 100% post-facto QA through Coach. For a regulated buyer the practical value is that the controls are testable before go-live. You can simulate the workflows your DPO is worried about and read the results, rather than approving behavior on trust and discovering a problem in production.
Lorikeet's wider security posture supports the same obligations: SOC 2, BAA-ready for HIPAA where health data is in scope, RBAC, and the residency and no-training commitments above. It has passed security reviews with major US banks, which tend to set a high bar on exactly the data-handling questions GDPR asks. The honest limitation: Lorikeet is GDPR-aligned and built to support your obligations, but no vendor can make you compliant on its own. Lawful basis, your record of processing, and your responses to data subjects remain your responsibility as controller. A vendor can only give you the mechanisms; the documentation and decisions are yours.
Vendor Coverage at a Glance
This is a brief, fair read of how a few leading AI support vendors tend to present against the checklist. Always verify the current DPA, sub-processor list, residency options, and SOC 2 scope directly with each vendor under NDA, because these details drift and matter most in the specifics.
Lorikeet · Built for regulated industries. EU-relevant strengths: US/AU/UK data residency, contractual no-training with model providers, PII redaction, RBAC, scoped least-privilege tools, audit trails, 100% QA via Coach, and pre-launch simulation. GDPR-aligned and DPA-ready. Best fit when your DPO and compliance team are the toughest stakeholders in procurement.
Sierra · Enterprise AI agent platform with outcome-based pricing and standard enterprise security posture (SOC 2, DPA). Verify EU/UK residency options and the sub-processor and no-training terms directly, as these are negotiated per enterprise contract rather than published in detail.
Fin by Intercom · Drop-in AI on top of Intercom's helpdesk, with Intercom's established compliance program (SOC 2, GDPR documentation, published sub-processor list and DPA). Data handling is shaped by the underlying Intercom platform, so confirm how AI-specific processing and any model-training terms are covered.
Decagon · Enterprise AI agent platform with white-glove deployment and standard enterprise security commitments. As with other enterprise vendors, residency, sub-processor disclosure, and no-training clauses are typically handled in the contract; request the specifics for an EU or UK deployment.
If you are evaluating an AI support agent against GDPR, talk to Lorikeet and bring your data-protection checklist. We will walk your team through residency, no-training terms, redaction, and audit logging before you sign.
How to Run This Checklist in a Vendor Call
A demo is designed to look good. The prompts below are designed to test the data-handling claims, not the resolution rate.
Show me the Data Processing Agreement you would sign with us, and the sub-processor list it references.
Where will our EU and UK customers' personal data be stored and processed, and what transfer mechanism covers anything that leaves the region?
Walk me through what happens when a data subject asks to be deleted: how do you find the data, how long does it take, and does deletion reach your sub-processors and backups?
Show me the clause that says our customer data will not be used to train your models or the foundation models behind them.
Show me an audit log for a real ticket, including what personal data was accessed and which tools were called.
Can my DPO review the data flows and run the workflows we are worried about in a sandbox before go-live?
Lorikeet's Take on GDPR and AI Support
Most AI vendors treat GDPR as a privacy policy page and a SOC 2 badge. For a regulated buyer that is the start of the conversation, not the end. The questions that actually decide an approval are mechanical: where the data sits, who can read it, whether it trains a model, and how you delete it on request. The platforms that pass a serious data-protection review are the ones that can show the configuration and the log, not just point at the policy.
Lorikeet is built for that review. Scoped tools and PII redaction keep the data footprint small, US/AU/UK residency and contractual no-training terms remove the two processing purposes that most often fail a GDPR analysis, and audit trails plus 100% QA give your privacy team the accountability record GDPR expects. If your DPO is the stakeholder you most need to convince, see how Lorikeet resolves tickets end-to-end while keeping the data handling reviewable.
Key Takeaways
An AI support agent is a data processor under GDPR, so a signed Article 28 DPA and a current sub-processor list are mandatory, not nice-to-haves.
The nine requirements form a chain: minimization and redaction shrink the data footprint, which makes erasure, access, and audit logging easier to satisfy.
Contractual no-training terms and EU/UK data residency are the two items that most often decide a GDPR procurement, because they remove hard-to-justify processing and transfer risk.
Lorikeet supports these obligations with US/AU/UK residency, no-training agreements with model providers, PII redaction, RBAC, scoped tools, audit trails, and 100% QA, while you retain controller responsibilities.
Ask every vendor to show evidence (a DPA clause, a residency setting, an audit log), not tell you a claim.
Conclusion
GDPR does not block AI customer support, but it does decide which vendors survive a data-protection review. The agent reads personal data, so the obligations are real: lawful basis, minimization, PII handling, residency, a DPA, sub-processor transparency, data-subject rights, no model training on your data, and audit logging. Use the nine requirements above as the checklist, and make every vendor show evidence rather than recite a policy.
Lorikeet is built so a privacy and compliance team can sign off before launch: scoped tools, PII redaction, US/AU/UK residency, contractual no-training terms, RBAC, audit trails, and pre-launch simulation. It supports your GDPR obligations, while lawful basis and your responses to data subjects stay with you as controller. If GDPR is the gate your AI support project has to clear, book a Lorikeet demo and bring your DPO.
