GDPR and AI: what data can you send to an LLM

Every time a company gets serious about using AI, the same question shows up — usually too late: can I send this data to the AI? The doubt is fair. A language model handles tasks a person used to do — reading, classifying, summarising — but to do them it has to see the data, and that data often includes names, emails, phone numbers or customer information protected by GDPR.

The honest answer is not “AI is off-limits” nor “send everything and we’ll see”. It is an engineering decision made field by field, before anything is connected. In this guide we explain how we decide what information goes out to an LLM, what stays in-house, and the mistakes we have seen turn costly.

What combining GDPR and AI really means

GDPR does not ban AI. It requires a legal basis for the processing, data minimisation, transparency, and control over who you hand the data to. When you send text to a provider like OpenAI or Anthropic, that provider acts as a data processor: you need a data processing agreement (DPA), you need to know where the data is processed, and whether it is used to train their models.

Being GDPR-compliant with AI is not a checkbox at the end. It is designing the flow so the minimum necessary data leaves, with safeguards, and the rest never leaves at all. Most of the problems we run into are not the model’s fault: they come from a flow built without first deciding what information would travel and with what protection.

Real scenarios we come across

Summarising and classifying support tickets

Tickets carry names, addresses and, depending on the sector, health or payment data. Summarising a hundred emails with AI saves real hours, but sending the whole email to the model is rarely necessary. You can pseudonymise the sender and strip the identifiers before sending: the summary is still useful and the personal data stays in your system.

Enriching or scoring leads in the CRM

When AI reads an incoming message and prioritises it inside the CRM — something we cover in our Zoho CRM integration guide — it is processing data about an identifiable person. Here we decide which fields the model actually needs to score (sector, size, buying intent) and which it does not (ID number, direct phone), and we only send the first set. Scoring does not get better by seeing the contact’s phone number.

Extracting data from documents with personal information

Invoices, contracts, forms. Extracting the fields with a model is powerful, but these are documents full of personal and sometimes tax data. The decision is not “AI or no AI”: it is whether the document can be processed by a model with EU data residency and no retention, or whether the case is sensitive enough to call for a model deployed on your own infrastructure.

The employee who pastes data into ChatGPT

The most common risk is not the well-planned AI project: it is “shadow AI”. Someone pastes a customer list into a public tool to draft an email, and that data leaves with no control, no contract and no one aware of it. Part of the job is providing a safe alternative and a clear policy, because banning it by decree does not work: people find the shortcut anyway.

How we approach it

After building several of these projects, the order we follow avoids nearly every nasty surprise.

We classify the data before choosing the model

Before deciding which LLM to use, we classify the data involved: public, internal, personal, special categories. That classification drives everything else. Picking the model before knowing what it will see is starting from the roof down.

Minimise, pseudonymise and tokenise at source

The best personal data is the data that never leaves. Before calling the model, we remove or replace identifiers when the task does not need them. Many tasks — classifying, summarising, extracting structure — work just as well without real names, and the risk drops sharply.

When the flow does need to re-link the model’s answer to the real record, we don’t delete the data: we tokenise it. We swap the identifier (name, email, ID number) for a meaningless token and keep the mapping in a vault under your control; the model works with the token and we restore the association afterwards, without the sensitive data ever leaving. One nuance many people miss: pseudonymising or tokenising lowers the risk, but as long as you keep the mapping table the data is still personal data under GDPR. Only genuine, irreversible anonymisation falls outside the regulation.

Choose where the model lives

Not all models offer the same guarantees. A model accessed via API with a data processing agreement, EU data residency and no training use covers most cases. When the data is especially sensitive, we weigh a model deployed in your own cloud. That choice is part of the design, not a detail sorted out at the end.

A human on the cases that matter

The model proposes and a person validates where there is impact, especially in the edge cases. Designing what data goes out and designing the oversight go together: it makes no sense to protect the data flow and then blindly automate a decision with consequences.

Mistakes to avoid

• Sending the whole document “because it’s easier”. Over-sending is the most common mistake and the most expensive to fix later.
• Confusing “it’s in the cloud” with “it’s GDPR-compliant”. The cloud is not the problem; the processing agreement, data residency and retention policy are.
• Thinking tokenisation already takes you out of GDPR. If you keep the mapping table it is still personal data; mistaking pseudonymisation for anonymisation is an expensive error.
• Not signing the DPA with the model provider. Without that processor agreement there is no solid basis for the processing.
• Banning AI instead of offering a safe path. Shadow AI shows up anyway, just without any control.
• Leaving the data decision until the end. Once the flow is built, reworking it costs ten times more than thinking it through up front.

How to choose who builds it

GDPR and the EU AI Act are not an obstacle to using AI: they are part of designing a good system. When choosing who builds it, look for people who ask what data is involved before talking about models, who bring up minimisation and EU residency from day one, and who know when a case calls for a model on your own infrastructure. A good team does not sell you “compliant AI”: it helps you decide what goes out, with what guarantees, and why.

At LMNHUB we apply AI to your processes by deciding from the design stage what data travels and with what protection, rather than improvising the legal side at the end. We are a European team and we treat GDPR as what it is: a design advantage, not an excuse to do nothing.

If you have a process where AI would help but the data question is holding you back, tell us about your case and we will get back to you with a concrete plan and a senior team, no hot air and no generic quote.