LLMs and GDPR: stop messing about with your customer data!

Three years ago, choosing a Customer Success tool took weeks: security questionnaire, DPA, list of sub-processors, server locations… and a DPO who wouldn't let anything slide. Today, that same DPO finds out that a CSM has plugged HubSpot, their note-taker and the back office into an LLM to prepare QBRs. Nobody asked where the meeting transcripts were going. Here's what really happens to your data, and how to stay compliant without missing the AI boat!

The paradox is quite striking. With traditional software, we insist on European hosting, comb through the standard contractual clauses and ask for certifications. And rightly so: your customers trust you with their data, and your terms and conditions often make them a specific promise about how it will be handled.

But as soon as an LLM is involved, those reflexes vanish. We connect, we test, we're amazed. And sometimes we get it badly wrong! The power of the tool pushes the hosting question into the background, even though the data being sent is often more sensitive than what we used to put in the CRM. Names, email addresses, verbatim quotes from unhappy customers, contract values, usage data and so on.

And it's not just a feeling. Harmonic Security analysed more than three million prompts and files sent to generative AI tools in Q3 2025, across US and UK companies: more than a quarter of uploaded files contained sensitive data (26.4%, up from 22% the previous quarter). And these were companies that actually monitor this kind of usage.

Let's take Claude as an example, because it's one of the most widely used LLMs in B2B and its documentation is transparent. The same reasoning applies to the others.

What really happens when you connect your tools to an LLM

When you connect HubSpot, your note-taker or your back office to Claude, your databases don't move. The data stays with each vendor, in the region where your account is hosted. The LLM doesn't copy your entire CRM.

The catch is this: everything the LLM reads to answer you enters the conversation, and therefore goes through Anthropic's infrastructure. A contact record, a deal history, a call transcript, a ticket export. Every request the AI makes to your tools brings data back, and that data is processed by Anthropic.

Where exactly? You need to separate two things that are often confused: processing and storage.

Processing (inference) is the moment the model reads your data and generates its answer. Since 19 August 2025, Anthropic has processed requests from its business customers (API, Team, Enterprise) in several regions: the United States, Europe, Asia and Australia. These aren't data centres owned by Anthropic, but regions of its cloud providers (AWS, Google Cloud, Microsoft), listed as sub-processors. So your requests may be processed in Europe… or just as easily in the US or Asia. But you can't choose! There's even an option to force processing in the US, but none to force it in Europe.

Storage is where your data stays once the answer has been generated. And that's the US, and only the US. No choice! Conversations, history, uploaded files (customer lists, contacts, contract data...), generated documents, slides and dashboards: everything is kept on US servers.

So there are three zones to keep apart:

• The source platforms (CRM, note-taker, back office): they keep their data, according to their own hosting.
• Processing by the model: in the US, Europe, Asia or Australia, with no way to choose the region from claude.ai.
• What Anthropic keeps: in the US. Conversation history, working files, documents, slides and dashboards produced.

One important point: a back office connected through a remote connector is called from Anthropic's servers. The data it returns passes through them, even if your back office is hosted in Paris.

So the real question isn't "where is my data?", but "which data am I going to let the LLM read, and how long will it stay there, in the US?"

Use case by use case: what goes where?

Let's look at the concrete use cases we see in CS teams every day. For each one: what stays on your platforms, what passes through and what is kept on the LLM side.

Account summaries and 360° dashboards

You ask the LLM to combine HubSpot, your usage KPIs and your subscription data to produce an account summary or a health dashboard for your portfolio.

• Passes through: every record, deal, meeting summary and back-office extract the LLM retrieves, processed in the US or elsewhere, without you choosing.
• Kept by Anthropic (US): the conversation, the working files generated during the analysis and the dashboard itself, figures included. If the dashboard pulls live data, that data passes through every time it's opened.

With or without PII? This use case works perfectly well without personal data: account information (company, segment, plan), aggregated usage KPIs, MRR, renewal dates. Sensitivity stays moderate, because MRR and contract data are confidential business information. PII only comes into play if you add contacts, conversations or usage by named user.

Criticality: 3/5 with aggregated data, 4/5 if you add contacts or conversations.

Calculating a health or risk score

To calculate a health score properly, the LLM retrieves the raw data (usage, tickets, invoices, contacts) and runs the calculation in its workspace, also in Anthropic's cloud, where working files are stored in the US. It's not just the scores that leave, it's all the data used to calculate them. If the score is then written back to the CRM, the final value lives there too.

With or without PII? You can calculate a health score from aggregated account data (usage per account, ticket volume, billing trends, MRR) by stripping contacts out of the export. But for most B2B SaaS businesses, that's a downgraded version: a reliable score also relies on people's engagement (adoption per user, activity of the champion and decision-makers, tone of conversations). Without PII, you lose some of the most telling risk signals. It's a possible compromise, not the ideal.

Criticality: 3/5 for a downgraded version on aggregated data, 5/5 for a complete score. Done properly, it's actually the use case that draws on the widest scope of data: CRM, named usage, support, billing, conversations.

Agents and risk alerts

You set up an agent that checks your accounts every morning and alerts the team on Slack when a customer starts to disengage. Each run is a new session in Anthropic's cloud: the data is read and transferred again on every run. The history of each run is kept by Anthropic, in the US. And the alert itself (customer name, reason for the risk, amount at stake) is stored by Slack or Google, on top of Anthropic.

With or without PII? An agent can monitor aggregated account indicators and send alerts using only the company name, with no PII. It becomes necessary as soon as the alert concerns a person (champion leaving, inactive contact) or the agent reads emails and tickets to detect the risk.

Criticality: 3/5 on aggregated data, 4/5 with named data. And bear in mind that the transfer is repeated on every run.

Meeting notes, QBR preparation and QBR slides

This is one of the most sensitive use cases, and probably one of the most common. To write meeting notes or prepare a Business Review, the LLM reads call transcripts. And a transcript is your customer's own words: their name, their figures, their internal issues, the names of their colleagues, sometimes their criticism of their own management. It passes through in full. Meeting notes and slides produced in Claude are stored by Anthropic, in the US.

With or without PII? QBR slides can be prepared without PII, from the account's KPIs and the Success Plan objectives. But as soon as the LLM reads a transcript or meeting notes, or accesses your emails or calendars, PII is unavoidable: names, voices, what was said.

Criticality: 3/5 for slides built on KPIs, 5/5 as soon as a transcript is involved.

Other common Customer Success use cases

• Summarising customer emails: impossible without PII, as the LLM reads names, addresses, signatures and the content of conversations. Criticality: 5/5.
• Drafting context-aware emails from the relationship history: PII required (recipient, past conversations). A lighter version is to provide only the account context and add the recipient yourself. Criticality: 5/5.
• Using support data (sentiment, recurring issues): tickets contain names, email addresses, sometimes even data about your customers' own customers. Analysis on pseudonymised tickets, or on categories and volumes alone, is still possible. Criticality: 5/5 on raw tickets, 3/5 on categorised data.
• Enriching contact records: PII is the whole point of the task (names, emails, phone numbers, job titles). Criticality: 5/5.
• Analysing a CSV export of your customer base to find churn patterns: feasible without PII if the export only contains account data. The whole file is loaded into Anthropic's workspace and stored in the US. Criticality: 3/5 without contacts, 5/5 with.
• Preparing an onboarding plan from the contract and sales notes: feasible without PII by removing the names of your contacts, but the contract and notes still pass through. Criticality: 3 to 4/5.

The critical use cases to spot first

Not all use cases are equal. The right question isn't "is this sensitive?", but "do I really need personal data for this?" The scale used here: 1/5 for data with no real stakes, 3/5 for confidential business data (MRR, contracts, aggregated usage), 5/5 for your customers' raw personal data.

In short: if your use case involves a transcript, an inbox or a contact file, you're sending PII outside Europe. And there's no way around it.

How long does your data stay with the LLM?

It's the question almost nobody asks. And the answer may come as a surprise: on Claude's Team and Enterprise plans, conversations are kept until someone deletes them. They stay in the history, on servers in the US, with everything they contain, so that the user can find them again.

Here are the rules Anthropic publishes for its business plans (page updated on 1 July 2026):

Three takeaways for a CS team.

First, the Team plan doesn't let you set a retention period: unless someone deletes them manually, your transcripts and customer exports stay there indefinitely. Only Enterprise offers automatic deletion. And even then, an administrator has to switch it on.

Next, a thumbs up or thumbs down isn't harmless. A CSM who rates an answer containing a customer's meeting notes sends that content into five-year retention. Your teams need to know this!

Finally, this table only covers the LLM. Slack alerts, notes written back to HubSpot or documents saved to Google Drive follow each tool's own retention periods. A piece of data read once by the AI can end up copied in three or four places.

Team, Enterprise: no, paying more doesn't keep your data in Europe

Many teams assume that moving to an enterprise plan solves the problem. More guarantees, a DPA, audit logs… so surely European hosting? Well, no!

As things stand, neither claude.ai (Team and Enterprise included) nor Anthropic's API offers data residency in the European Union. Data from Team and Enterprise workspaces is stored in the US, and the API only offers two processing zones, "global" or "us". The Enterprise plan brings real safeguards (no training on your data by default, configurable retention periods, audit logs), but it changes nothing about location.

Is this going to change? Nothing has been announced. There are signs, though. In April 2026, job adverts revealed that Anthropic was looking to sign data centre capacity deals in Europe, notably in major hubs such as Frankfurt, Paris, Amsterdam, London and Dublin; the company declined to comment. On the Microsoft side, the European option for Claude on Foundry has been announced "for 2026", with no firm date.

A word of caution, though: data centres in Europe don't automatically mean a European hosting option in claude.ai. That capacity may be used first and foremost to meet demand. Until an option is available and written into a contract, you have to work with what exists today.

And if your terms and conditions promise your customers that their data will be processed in the EU, what exists today isn't enough.

What about the other LLMs?

Claude isn't an isolated case, but it is lagging behind on this point. OpenAI, Google and Microsoft already offer data residency in Europe. The catch: it's reserved for top-tier plans, and it has to be configured.

In practice, EU residency remains conditional. At OpenAI, it only applies to workspaces set up in the European region from the start. At Google, it's reserved for the Enterprise Plus and Frontline Plus editions. At Microsoft, flex routing can send processing to the US during peak demand, and the Claude models built into Copilot are excluded from the EU Data Boundary. And at Mistral, you need to choose the European endpoint, as a paid option, to keep processing in Europe.

In short, switching LLM can solve the location question, provided you take out the right plan and configure it properly. With Claude, that isn't possible today.

How to use AI without your data leaving Europe

The good news is that you don't have to give up on AI. You just need to run it in the right place.

Use a cloud configured in a European region

Claude models are available through the major cloud providers, which let you choose a European region:

• Google Cloud Vertex AI: Claude is offered in Belgium, the Netherlands and an EU multi-region, with processing taking place in the region the request is sent to.
• AWS Bedrock: Frankfurt, Ireland, Paris or Stockholm regions, with EU inference profiles.

In this case, Google or AWS becomes your sub-processor, under its own DPA. These two routes are currently the only confirmed options for EU residency with Claude, provided the regional configuration is properly locked down.

In practice, it's not just a switch you flip. This is API access: you lose the chat interface, its connectors and the skills managed in claude.ai, and you have to build your own workflows (scripts, pipelines, internal tools). Your in-house skills aren't lost, though: they're simply instruction files, reusable with Claude Code or the Agent SDK pointed at the EU region. Anthropic's ready-made skills (Word, PowerPoint, Excel), on the other hand, don't come with you. Regional endpoints also cost slightly more than global ones. And you need to nail down the details: EU inference profile rather than global, prompt logging switched off or stored in Europe, source files also hosted in an EU region.

One nuance to keep in mind: residency isn't sovereignty. AWS and Google are still US companies. If your customers expect zero exposure to US law, you'll need to look at sovereign cloud offerings or models hosted by European providers.

Choose business tools that run LLMs in their own EU infrastructure

The other route, simpler for a CS team, is to use a CRM or a Customer Success Platform that builds AI features directly into its European infrastructure. You get the summaries, the scoring and the risk detection, without exporting your data to an LLM hosted in the US.

That's the choice we made at Skalin: the platform is hosted on Google Cloud in Belgium, and the LLM features run in that same EU zone. It's also one of the reasons why an LLM plugged into your CRM doesn't replace a Customer Success Platform: data governance isn't solved by adding a connector.

Whichever route you take, the same set of questions applies to any AI tool you assess:

• Where is the data processed, and where is it stored?
• How long is it kept, and who can set that period?
• Is it used to train models?
• Which sub-processors are involved, and in which countries?
• Is the data anonymised or pseudonymised before it's sent to the model?

These are exactly the questions you already asked your software vendors. You just need to ask them again.

Conclusion

AI is genuinely changing how Customer Success is done. Summaries in seconds, QBRs prepared in ten minutes, risks spotted before they turn into churn: nobody wants to miss the boat, and that's perfectly understandable.

But the rise of LLMs doesn't change one simple rule. Your customers' data doesn't belong to you: it's entrusted to you, and it can't be sent anywhere, any old how. Especially if your terms and conditions promise them processing in the EU. In that case, feeding a meeting transcript into an LLM hosted in the US means risking a breach of your contractual commitment.

So before your next enthusiastic test, go back to your good old reflexes: map your use cases, spot the ones involving PII, check retention periods, and run AI where your commitments allow it. Your DPO will thank you. So will your customers!

Further reading:

• No, Claude Is Not Going to Replace Your Customer Success Platform
• Artificial Intelligence for Enhancing Customer Success
• Agentic AI: the next revolution in Customer Success?
• What are the differences between CRM and Customer Success Platform?