Use LLMs on personal data without sending personal data

Many teams want to use a language model on documents with personal data: applications, dossiers, customer emails. The risk is real. The Dutch Data Protection Authority received data breach notifications after employees put patient and customer data into AI chatbots. There is a better pattern. The model does the language work, but it never sees who the person is.

Why a contract with the provider is not enough

A business contract with an AI provider helps, but the personal data still leaves your environment. You still need a legal basis. You must also limit the data to what is necessary for the purpose. The GDPR calls this data minimisation, in Article 5(1)(c).

The Dutch Data Protection Authority also warns that most companies behind chatbots store all data that users enter. The people in your documents do not know where their data goes. Thus the safest personal data is personal data that you do not send.

What pseudonymisation means in the GDPR

Article 4(5) of the GDPR defines pseudonymisation. You process personal data so that you cannot connect it to a specific person without additional information. You keep that additional information separately, and you protect it with technical and organisational measures.

Recital 26 adds an important point. Pseudonymised data is still personal data, but anonymous data is not. The European Data Protection Board published guidelines on pseudonymisation in 2025, with examples.

So pseudonymisation does not remove the GDPR from your project. It decreases the risk, and it controls which party sees which data.

The pattern: a vault between your data and the model

1. Find the personal data. Look for names, dates of birth, addresses, email addresses, phone numbers, company registration numbers and bank account numbers. Use rules for fixed formats, such as IBAN and postcodes. Add a named entity recognition model that operates in your own environment.
2. Replace each item with a stable token, for example ‹PERSON_1› or ‹ADDRESS_1›. The same name gets the same token in the full dossier. Thus the model can still follow who is who.
3. Keep the link between token and real value in a vault in your own environment. Only the vault can change a token back into the real value.
4. Send only the pseudonymised text to the language model. Ask for structured output: facts, amounts, dates and a short summary.
5. Put the real values back only where a person needs them, for example in the screen of the reviewer. Record each re-identification in a log.
6. Do a leak check before each external call. Search the outgoing text for the original values. If one of them is in the text, stop the request.

What the model needs, and what it does not need

Most extraction tasks do not need the identity of a person. The model needs roles (“the applicant”), relations (“the director of the company”) and facts (amounts, dates, products).

Use general values where the detail matters. Give an age range instead of a date of birth. Give a city instead of a street address. Write “company founded in 2019” instead of the company name. Make this decision per field, together with the people who own the process.

Where this pattern fails

• Free text can identify a person without a name. “The only female pilot at our airfield” is an example. Detection does not find everything. Test it on real samples and measure what it misses.
• Some checks need the real identity, for example a check against a sanctions list. Do those checks in your own environment, with rules or a local model.
• Scans and photos need OCR first. Pseudonymise the text after OCR and before any external call.
• Pseudonymised data is still personal data. You still need a legal basis, an agreement with the provider and a record of the processing activity.

What to do now

1. Make a list of the AI tools that your team uses, and of the data that goes into them.
2. Make clear agreements about which data employees can enter. The Dutch Data Protection Authority gives the same advice.
3. Select one pilot process with a high volume and standard documents.
4. Put the detection, the vault and the leak check in place before you connect a model.
5. Measure two things: the personal data that detection misses, and the quality of the extraction with tokens.
6. Ask your privacy officer to examine the design and the data flows.

How we approach this

We used this pattern for a car-lease company. The system makes a first assessment of lease applications. The language model extracts the facts from pseudonymised dossiers. A fixed set of rules makes the decision, and the model never sees data that can identify a customer.