7 Best GDPR-Compliant AI Customer Service Platforms in 2026
Zeyad Genena
19 min read

A vendor can say it supports GDPR and still leave a security team with basic questions. Where is customer data stored? Which model providers receive prompts? Is the data used for training? Can it be deleted? What happens when data moves outside the EEA?
Those details matter more than a badge on a sales page. GDPR readiness depends on the vendor's controls and contracts, but it also depends on how your team uses the product.
We reviewed public DPAs, privacy policies, security pages, Trust Centers, subprocessor lists, and AI data-use documentation. After that review, we selected Chatbase, Intercom/Fin, Zendesk AI, Ada, Freshworks/Freddy AI, Fini, and Lorikeet.
Compliance details checked September 2026. Vendor terms, hosting options, subprocessors, and plan availability can change.
Best GDPR-focused AI customer service platforms compared
| Platform | DPA & transfers | AI data handling | Data location |
|---|---|---|---|
| Chatbase | DPA + SCCs | No customer-data training; ZDR on Enterprise | Primary processing in the US |
| Intercom / Fin | DPA + SCCs | Anonymized fine-tuning with opt-out; third-party AI uses ZDR | US, EU, or Australia, with service-specific rules |
| Zendesk AI | DPA + transfer safeguards | Third-party LLMs do not train on Service Data; ZDR on documented endpoints | Several regions; availability varies by product and account |
| Ada | DPA + subprocessor terms | Current trust docs say no customer-data training; ZDR with LLM providers | Europe storage option; some terms are contractual |
| Freshworks / Freddy AI | DPA + SCCs | Training opt-out; third-party generative providers do not store data at rest | Regional hosting; some AI processing can occur elsewhere |
| Fini | DPA + SCCs | No foundational-model training without explicit authorization; universal ZDR not publicly verified | US or EU designated region |
| Lorikeet | DPA available; Enterprise supports custom review | No customer-data training; vendor states ZDR inference | Standard plans use US geography; Enterprise adds geo-specific storage and inference |
What matters most: A GDPR claim by itself is not enough. Compare where customer data is stored and processed, whether conversations can be used to train AI, what model providers retain, how international transfers are handled, and which privacy or governance controls depend on the plan.
How we evaluated each platform
We publish this comparison and include Chatbase in it. We used the same public evidence standard for Chatbase and the other six vendors, and we kept limitations that could affect a buying decision.
For each platform, we checked 12 areas: the DPA, controller and processor roles, transfer safeguards, data location, inference location, model training, LLM retention, subprocessors, retention and deletion, GDPR rights support, access controls, and independent security assurance.
Evidence rule: When we could not verify a feature in public first-party docs, we did not turn that gap into a "No." We say "not publicly verified" or tell the reader what still needs to be confirmed.
What we mean by GDPR-ready: A vendor can provide contracts and controls that support GDPR duties. That does not make every customer setup compliant by default. Your team still needs a lawful basis, clear notices, limited data collection, sensible retention, and proper access controls. The European Commission's GDPR principles are a useful baseline.
1. Chatbase: Best for enterprise AI customer service with documented GDPR controls
![[object Object]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fi6kpkyc7%2Fprod-dataset%2F091cc5c6b2d50f6e579b7010415324c4560020d3-1438x699.png&w=3840&q=75)
At Chatbase, our customer-facing AI agents work alongside a native Helpdesk, actions, human handoff, analytics, and enterprise controls. We make the main privacy and security documents public so procurement teams can review the contracts, data-handling terms, and controls before moving forward.
Data handling: Our Data Processing Addendum sets out controller and processor roles. It covers EU and UK GDPR, subprocessors, data subject requests, and SCCs for covered transfers. It also includes support for DPIA-related requests.
We do not use customer data to train AI models. Our privacy policy explains that we use RAG to answer from a customer's sources without turning that data into model-training data.
Hosting: This is the main limit to know. Our primary processing is in the United States, and our privacy policy lists AWS us-east-1 for the database and app infrastructure. Our current public documentation does not list an EU data-residency option. Teams with an EU-only residency requirement should treat the current US-based processing model as a procurement consideration.
That does not make GDPR use impossible. The DPA includes SCCs for covered transfers outside the EEA. Still, a team with an EU-only hosting rule should treat US processing as a real buying constraint.
Enterprise controls: Our Security page lists GDPR and SOC 2 Type II, plus encryption at rest and in transit. Enterprise adds SSO, custom RBAC, audit logs, and zero data retention. Workspace members can also enable two-factor authentication. If those controls are part of your security review, check the Enterprise plan rather than assuming they come with every plan.
Authenticated support: For agents that need to recognize signed-in customers, our docs cover JWT-based identity verification. Sensitive values carried inside the signed token are protected from the agent context, while the verified identity can be used for account-aware support and actions.
Trust documentation: We maintain a Trust Center for security and compliance documentation, with dedicated pages for security controls and the current subprocessor list. Our DPA sets out the subprocessor notice and objection process, while the Privacy Policy explains how we collect, use, store, and protect personal data.
European customer examples: Slovenia's national tax and customs authority, FURS, uses Chatbase across five specialized agents for tax and customs questions. Its customer story reports more than 800,000 citizen questions answered and says 83% of callers reached a human within the 30-second service target during the 2026 peak tax season, up from under 50% the year before.
German publisher Saarbruecker Zeitung gives us a more direct GDPR example. It says GDPR compliance was non-negotiable when it selected Chatbase; its agent has handled nearly 3,800 subscriber conversations and more than 18,000 messages since launch. These deployments show real-world use, but they do not replace a customer's own GDPR review.
Separate healthcare requirements: HIPAA is a different framework from GDPR. For teams that also handle US healthcare data, our HIPAA compliance guide explains Enterprise BAAs, zero data retention, 2FA, and the shared-responsibility model.
Chatbase is a strong fit for enterprise support teams that need AI customer service, documented GDPR safeguards, and governance controls in the same platform. Teams with an EU-only residency requirement should treat the current US processing model as a constraint.
2. Intercom and Fin: Integrated helpdesk with separate fine-tuning rules
![[object Object]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fi6kpkyc7%2Fprod-dataset%2F4328d70cc6f97994eb629115b5d5cc3421c132d7-1600x846.jpg&w=3840&q=75)
Intercom publishes detailed security and privacy documentation, and Fin sits inside the wider helpdesk. The important distinction is that third-party model rules and Intercom's own fine-tuning rules are not the same.
Fin's data rules: Intercom says third-party AI providers are barred from training on customer data. It also says Fin may use anonymized customer data for fine-tuning. Customers can opt out, and Intercom says the fine-tuning data is deleted within 30 days after an opt-out.
LLM retention: Intercom states that third-party AI providers use zero retention once a response is generated. That provider-retention rule is separate from Fin's own use of anonymized data for fine-tuning.
Regional setup: Intercom supports US, EU, and Australian workspace hosting, but AI processing does not follow the same rule in every region. Intercom says EU customers can use Fin AI Agent, Copilot, and inbox AI with data processed within the EU.
For Australian-hosted workspaces, those AI features remain hosted in the US. A team with strict locality rules should therefore confirm the processing path for Fin, not just the workspace's main hosting region.
Its DPA includes SCCs, processor terms, subprocessor rules, and deletion timelines. Intercom also lists SOC 2 Type II, ISO 27001, ISO 27701, and ISO 42001.
Intercom and Fin are a practical fit when AI resolution and human support need to stay in the same service stack. Organizations with a strict no-training policy should include the fine-tuning opt-out in their rollout requirements.
3. Zendesk AI: Regional hosting with product-specific exceptions
![[object Object]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fi6kpkyc7%2Fprod-dataset%2F897a424e3e1ec38e011648cbf58814116fef468d-1561x715.png&w=3840&q=75)
Zendesk offers several regional hosting options for large service teams. Its AI docs also explain how external model providers handle customer data.
Model-provider rules: Zendesk says third-party LLMs used for generative AI do not train on Service Data. Its own machine-learning systems have separate data-use rules, so a review should keep Zendesk models and external generative models separate.
ZDR: Zendesk uses two main patterns. Some models run through infrastructure where the model company does not receive Service Data. For direct integrations with model providers such as OpenAI or Google Gemini, Zendesk says it uses zero-data-retention endpoints. Request and response bodies are not kept by the model provider after the output is returned.
Regional hosting: Zendesk supports several regions for covered services, including the US, EEA, UK, Japan, and Australia. The details are more complex than a yes-or-no residency field. Product, data type, plan, and account age can change what is covered.
For AI agents, Zendesk says accounts created on or after March 10, 2026 support broader regional hosting. Older accounts have narrower choices.
Zendesk is better suited to larger support operations that need several regional options and mature service controls. The tradeoff is complexity: locality rules vary by product and data type, so the data-hosting policy needs to be checked against the exact Zendesk services in scope.
4. Ada: No-training and ZDR commitments are clearly documented
![[object Object]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fi6kpkyc7%2Fprod-dataset%2Fee806491a9e63c3991009c6c39df77022bcb99bb-1600x900.jpg&w=3840&q=75)
Ada's current trust documentation is direct about two questions that often get mixed together. It says customer data is not used to train models, and its LLM providers use zero data retention.
LLM handling: Ada states that prompts and outputs are discarded by its model providers after the request is processed. Its current trust page says customer data is not used for model training. An older 2024 Ada article described de-identified, customer-specific fine-tuning in some cases, so teams with a strict no-training rule should confirm the current contract scope.
Residency: Ada lists a Europe data-storage option for enrolled customers. Its subprocessor page also shows which providers can use European data centers. For broader enterprise deals, Ada says residency, retention schedules, and deletion rights can be set in the contract.
Access controls: Ada documents RBAC, MFA, and audit logging. Its public trust material also lists SOC 2 Type II and AIUC-1 certification.
Ada is worth shortlisting when LLM retention and AI-governance terms carry more weight than a broad feature comparison. The exact region and retention language still needs to be confirmed in the enterprise agreement; a general "Europe available" statement does not define the contract scope.
5. Freshworks and Freddy AI: Regional hosting can differ from AI processing location
![[object Object]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fi6kpkyc7%2Fprod-dataset%2Fe2a70c79546d6faa5b821346dbbec673c87341c6-1573x690.png&w=3840&q=75)
Freshworks shows why storage and inference need separate questions. An account can keep data in one region while a specific AI task runs somewhere else.
Storage vs inference: Freddy AI says most data is processed and stored in the local region by default. It also lists exceptions. Some features for India, Australia, and the Middle East/Africa can be processed in the United States because the required AI capacity is not available locally.
A regional hosting choice therefore does not, by itself, tell you where every AI request runs or which provider processes it.
Training: Freshworks lets customers request a full opt-out from AI model training. The accurate comparison is therefore "opt-out available," not "Freshworks never trains on customer data."
Retention: Freshworks says generative third-party providers do not store data at rest. It also lists a 30-day deletion rule for certain batch files. Those facts are useful, but they do not prove universal ZDR for every Freddy AI path.
Freshworks is a natural option for organizations already using Freshdesk or the wider Freshworks stack. A strict no-training policy needs an explicit opt-out request during setup rather than an assumption that training is disabled by default.
6. Fini: Contract terms put clear limits on model training
![[object Object]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fi6kpkyc7%2Fprod-dataset%2F0c6dde991a40b3eca146477eb0ea137070e2f708-1508x683.png&w=3840&q=75)
Fini's DPA spells out what it and its AI subprocessors may do with customer data. For procurement teams that want model-training limits in the contract, that is more useful than relying on a marketing claim.
Training terms: Fini says it will not use customer data to train or improve foundational models unless the work is limited to the customer's own instance and the customer gives written approval. It also says AI subprocessors must not use customer data to train, fine-tune, or improve their models or a third party's models.
Region choice: Fini supports a designated region in the US or EU. Its DPA says customer data is stored and processed primarily in that region. It also says AI requests are routed to endpoints in or near the chosen region where those endpoints are available.
The DPA allows limited processing outside that region when needed to provide the service, with the DPA safeguards still in place. It also includes EU SCCs and provides at least 30 days' notice before a new subprocessor starts processing customer data.
Fini is most relevant when contract-level training restrictions and a US-or-EU region choice are hard requirements. We did not find enough public first-party evidence to describe every model path as universal ZDR, so that requirement should be confirmed provider by provider in writing.
7. Lorikeet: Geo-specific storage and inference are Enterprise features
![[object Object]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fi6kpkyc7%2Fprod-dataset%2F158d78aa8ca13ec3d185b4e29fb4b733551a4b84-1497x673.png&w=3840&q=75)
Lorikeet publishes clear claims about model handling and hosting. Its pricing page also makes the plan split easy to see.
Model handling: Lorikeet says it does not train on customer data and has ZDR agreements with its model providers. It also states that PII is redacted before it reaches systems that do not need it.
Plan split: Start and Scale use standard US geography with ZDR inference. Enterprise adds geo-specific storage and inference. Lorikeet also states that storage residency is available in the US, Australia, and the EU.
Security: Lorikeet lists SOC 2 Type II and ISO 27001. The company also states that it uses TLS 1.3 in transit and AES-256 at rest. Some deeper reports sit behind its Trust Center rather than on public marketing pages.
Lorikeet is most relevant when geo-specific storage and inference are part of an Enterprise procurement requirement. Its main limitation is plan scope: the most flexible locality controls are not included with the standard tiers.
GDPR compliance, EU residency, SOC 2, and ZDR are different things
These terms often end up in one "security" column. Grouping them together is convenient, but it can hide what each term proves.
| Term | What it tells you |
|---|---|
| GDPR compliance | Whether processing and the parties' practices meet the GDPR duties that apply |
| DPA | How controller and processor duties are set out for covered processing |
| EU data residency | Where specified data is stored or processed |
| SCCs | A contract tool that can support certain data transfers outside the EEA |
| SOC 2 Type II | Independent assurance on relevant controls over a set period |
| ISO 27001 | Certification of an information-security management system within its scope |
| Zero Data Retention | Whether data is kept after a defined AI request is processed |
SOC 2 does not make a product GDPR compliant. EU residency does not do that either. ZDR can reduce retention risk, but it does not remove duties around lawful use, clear notices, limited data collection, or deletion elsewhere in the product.
Does GDPR require AI customer service data to stay in Europe?
No. GDPR does not generally require all personal data to stay inside the EU or EEA.
Data can move outside the EEA when the transfer rules are met. The European Commission recognizes several tools for this, including adequacy decisions and Standard Contractual Clauses. Its SCC guidance explains how these pre-approved clauses can support certain transfers.
EU residency can still matter in procurement. Your team may require it to reduce transfer work, meet a contract, or follow an internal rule. That is a buying requirement, not the same as saying GDPR always requires EU-only hosting.
This point matters for Chatbase, which uses US primary processing with SCCs for covered transfers. It also matters for Freshworks, Zendesk, Intercom, and Lorikeet, where storage and AI processing can follow different regional rules.
No AI training, ZDR, and data deletion answer different questions
A vendor can say it does not train models on your data and still keep a support transcript. A model provider can use ZDR while the customer service platform keeps conversation history. Those are separate parts of the data path.
No model training: This asks whether prompts, conversations, or outputs are used to train or improve a shared, vendor, or foundation model. Chatbase and Ada state that customer data is not used for model training. Freshworks offers an opt-out. Intercom says Fin may use anonymized data for fine-tuning unless the customer opts out.
Zero data retention: This usually asks what the model provider does with a request after it returns an answer. Ada and Lorikeet state ZDR arrangements with their LLM providers. Zendesk documents ZDR endpoints for direct model-provider integrations. Chatbase lists ZDR as an Enterprise feature.
Platform retention: The support platform may still keep conversations, logs, tickets, knowledge, or analytics. Review that retention rule on its own.
GDPR erasure: This asks whether data tied to a person can be found and deleted when the right applies. A model-provider ZDR statement does not answer that question.
Data storage and AI inference may happen in different places
A regional hosting claim should lead to one more question: Where does inference run?
Freshworks makes the issue easy to see. Some data can stay in the account's home region while AI processing for certain features runs in the US. Zendesk offers regional hosting for covered data, but it also lists product and data-type exceptions. Intercom and Lorikeet also separate hosting from the AI processing path.
Check three locations separately:
1. Primary storage: Where tickets, conversations, files, and user data are kept.
2. AI inference: Where a prompt is processed to produce an answer.
3. Subprocessor processing: Where other providers may handle personal data.
That gives a security team more than a simple "EU hosting: yes" field.
GDPR due-diligence checklist for AI customer service vendors
A security page is only the start. The contract and technical docs should answer the questions that affect your actual setup.
Data location and AI processing
- Where is conversation data stored? Ask for hosting and residency documentation.
- Where does AI inference run? Ask for AI architecture or regional processing documentation.
- Which companies receive prompts or conversations? Check the current subprocessor list.
- Is customer data used to train a model? Review the AI data-use policy and contract terms.
Retention and data rights
- How long do model providers keep requests? Ask for provider-retention or ZDR documentation.
- How long does the platform keep conversations and logs? Review the retention schedule.
- How are access and deletion requests handled? Check the vendor's DSAR and deletion documentation.
Access and security controls
- Can workspace access be limited? Review SSO, RBAC, MFA, and permission documentation.
- Can admin changes be traced? Check the audit-log documentation.
- What independent security assurance is current? Ask for the latest SOC 2 or ISO reports and confirm their scope.
Contracts and subprocessors
- How are transfers outside the EEA handled? Review the DPA and international-transfer terms.
- How will we hear about new subprocessors? Check the DPA and subprocessor-change terms.
Do not stop at a certificate: SOC 2 and ISO can support a security review, but they answer different questions from GDPR, data location, model training, and retention.
When AI customer service needs extra privacy review
Some use cases carry more risk than an agent that answers public product questions.
DPIA: A data protection impact assessment may be required when processing is likely to create a high risk to people's rights and freedoms. Examples can include large-scale processing of sensitive data and some systematic automated evaluations. Do not assume every AI support setup needs a DPIA. Assess the need before launch when the use case is high risk.
Automated decisions: GDPR limits some decisions made only by automated means when they have legal or similarly significant effects. Routine ticket routing is not automatically the same as an automated credit denial. When an AI system can make a major decision about a person, the legal basis and human review need closer attention.
Pseudonymization: Replacing direct identifiers can lower risk. It does not always take the data outside GDPR. If the data can still be linked back to a person, it can still be personal data.
Which platform fits which requirement?
The shortlist changes depending on which requirement is non-negotiable.
- Enterprise AI customer service with documented GDPR safeguards and governance controls: Chatbase. Our DPA includes SCCs for covered transfers, customer data is not used to train AI models, and Enterprise adds SSO, RBAC, audit logs, and ZDR. The main constraint is US-based primary processing.
- Regional hosting plus a tightly linked AI and helpdesk stack: Intercom/Fin. Review the fine-tuning opt-out during setup.
- Broad regional hosting in a mature service platform: Zendesk AI. Expect more product-specific locality rules.
- Documented ZDR and no-training commitments: Ada. Confirm the exact contract terms for residency and retention.
- Freshworks stack with regional controls: Freshworks/Freddy AI. Check the inference path and request the training opt-out when needed.
- Clear contract limits on foundational-model training: Fini. Ask for written ZDR details if that is a hard rule.
- Geo-specific storage and inference on Enterprise: Lorikeet. Confirm the plan and region before comparing it with standard tiers.
Once your research reaches a formal security review, compare your requirements with the controls documented above. Enterprise teams with specific governance or deployment requirements can talk with our team about the setup they need. If the documented controls fit your requirements, you can start with Chatbase and create your first agent.
If compliance is only one part of the buying decision, our best AI customer support agents comparison looks more broadly at automation, human handoff, channels, and day-to-day support capabilities.
Frequently asked questions
Which AI customer service platforms are GDPR compliant?
The seven platforms in this comparison all publish privacy, security, or contract terms that address GDPR-related requirements. That does not mean every deployment is compliant by default.
Before choosing a platform, check its DPA, transfer safeguards, data location, AI training policy, model-provider retention, subprocessors, deletion process, and access controls against your own use case.
Is Chatbase GDPR compliant?
Yes. Chatbase is GDPR compliant, and our DPA documents the processor obligations, data-subject support, subprocessor terms, and transfer safeguards that support customers’ GDPR reviews. Your own GDPR obligations still depend on how you configure and use the platform.
We also state that customer data is not used to train AI models and that Chatbase is SOC 2 Type II compliant.
The main location limit is US primary processing. Teams that require EU-only residency should account for that before they buy.
What should an AI customer service DPA cover?
A DPA should explain the processing relationship and the safeguards that apply when a vendor handles personal data for a customer. Key points include processing instructions, confidentiality, security, subprocessors, support for data-subject rights, deletion or return of data, audit rights, breach terms, and cross-border transfers.
AI adds another layer. The DPA or related documentation should make it possible to identify which model providers receive customer data, where that processing happens, and what those providers are allowed to do with the data.
Share this article:
Zeyad Genena is a Senior Content Writer at Chatbase with 5+ years of experience in SaaS and AI driven customer solutions. He holds a degree in Business Economics. At Chatbase, he covers AI agent design, CX strategy, and customer operations for midsize and enterprise businesses.







