Pseudonymisation for AI: A Local Privacy Filter

In its guidance tool on generative AI and the GDPR from July 2026, the Dutch data protection authority (AP) advises organisations to look into whether generative AI can be used "without personal data". For many tasks, it can: the cloud needs the content, not the names.

Pseudonymisation for AI is replacing names, numbers and other identifying data with neutral labels before a text goes to a cloud AI, while the key to restore them stays inside your own network. A local model or local detection rule finds the personal data, turns "Jan de Vries" into [PERSON_1], sends the cleaned text to the cloud model, and puts the names back into the answer. The cloud sees the question, but not who it's about.

Is pseudonymised data still personal data?

For your organisation, yes. Recital 26 of the GDPR says pseudonymised data that could be attributed to a person using additional information should be considered information on an identifiable person. You hold the key table, so for you everything remains personal data, with every obligation that comes with it.

For the recipient, it's more nuanced since 4 September 2025. In EDPS v SRB (C-413/23 P), the EU Court of Justice ruled that pseudonymised data must not be regarded as personal data "in all cases and for every person". Whether it is for a recipient depends on whether that recipient can re-identify the person by means reasonably likely to be used. The case concerned the data protection rules for EU institutions, but the Court says in paragraph 52 that the concept of personal data is interpreted the same way there and in the GDPR.

Two caveats. The EDPB's Guidelines 01/2025 on pseudonymisation predate the judgment, are stricter, and are still a consultation version. And the Court also says the duty to inform is assessed from your position at the time of collection. So you still have to tell people that their data, pseudonymised, goes to an AI service.

The Court's line is being followed. In its draft anonymisation guidelines (Guidelines 02/2026, open for consultation until 30 October 2026), the EDPB assesses anonymity per party: information can be anonymous for one organisation and not for another. In its Digital Omnibus package of November 2025, the European Commission proposed writing that relative approach into the GDPR's definition of personal data itself. That proposal is still being negotiated and isn't in force. So build your filter on today's rules: for you it stays personal data, and for the cloud provider it depends on how good your filter is.

When does pseudonymisation help with transfers to the US?

The EDPB's Recommendations 01/2020 describe two scenarios that map directly onto this design. In use case 6, a cloud provider needs the data in the clear, and for that case the EDPB is "incapable of envisioning an effective technical measure". In use case 2, the exporter pseudonymises the data first and only transfers the pseudonymised version. That counts as an effective supplementary measure when four conditions are met:

1. The data can't be attributed to a person without additional information, nor used to single someone out in a larger group.
2. The additional information is held exclusively by the exporter and kept separately, in the EEA or with a trusted party under equivalent protection.
3. The exporter alone controls the key that makes re-identification possible.
4. A thorough analysis shows re-identification also fails using information the authorities in the recipient country can reasonably be expected to have.

A local privacy filter is an attempt to turn a use case 6 situation into use case 2. The key table stays on your own server, which covers conditions 2 and 3. Conditions 1 and 4 depend on how good the filter is, and that's where the work is.

Which Dutch identifiers does a privacy filter need to catch?

Most off-the-shelf tools are built for English text and US numbers. A filter for Dutch data needs to recognise at least these:

The BSN needs a rule of its own. Under Article 46 of the Dutch GDPR Implementation Act, a statutory identification number may only be used to carry out the law that requires it, and the AP says on its page on conditions for using the BSN that consent doesn't change that. No cloud model needs a BSN for any task. The filter removes it without putting it in the key table.

Combinations are the second issue. The AP writes on its page on pseudonymising data that a date of birth plus the four digits of a postcode is "often unique enough" to trace someone through the Dutch population register. According to the AP, removing only names isn't pseudonymisation if the rest of the text still points to a person.

What do existing tools miss?

Existing tools for detecting personal data miss more Dutch identifiers than their documentation suggests, and it's been measured.

• Presidio, the best-known open-source toolkit for detecting personal data, ships recognisers for national numbers from eighteen countries, but not the Netherlands. There's no BSN recogniser. IBAN is recognised, with checksum.
• The Dutch spaCy models reach an entity-recognition F-score of about 0.76 for the largest model, trained on news text, and have no labels for BSN or IBAN.
• Specialised Dutch models do better, with a blind spot. In the study by Trienes and colleagues on 1,260 Dutch patient records, the best model reached an F1 of 0.893 and found 95.6% of names. It found 26.2% of professions.

That last figure is the problem in one number. "The new controller at our Zwolle branch" contains no name, but in a 200-person company it points to exactly one person. The EDPB's pseudonymisation guidelines list exactly these quasi-identifiers for employees: role, working hours, length of service. The makers of DEDUCE, a Dutch tool for de-identifying medical text, write in its documentation that de-identification is "almost never perfect" and is mainly a way to reduce risk, not a way to obtain anonymous data.

What we combine in a filter

A filter that works in practice uses three layers. Fixed patterns with check digits for BSN, IBAN, KVK and postcodes, because they're reliable. A list of known names from your own systems, such as customers from the CRM and staff from HR, because a lookup list doesn't miss names that are on it. And a local language model for the rest: unknown names, plus job titles and branches, which it generalises to [ROLE] and [BRANCH]. A small language model is enough for that, running on the same server as the key table.

Use consistent labels per document. If [PERSON_1] is the same person throughout the text, the cloud model can still reason about who emailed what to whom. Random labels per sentence make the answer useless.

When doesn't a privacy filter work?

A privacy filter doesn't work when the content itself is the person. A medical history, a complaint about a one-off incident or a disciplinary file stays identifiable without a single name. With small groups, such as a five-person board. And with tasks that need the identity, such as checking a Chamber of Commerce registration or summarising a known client's file.

For the bottom two rows, a filter isn't a solution but a paper shield. There, it's about AI under professional secrecy or a fully local model, and the trade-off between the two is in our guide to local AI for business. Record the choice of filter, the tested detection rates and the residual risks in your DPIA. Why an EU region from a US vendor doesn't solve the transfer problem on its own is covered in EU data residency for AI, and the wider GDPR picture in private AI under the GDPR and the EU AI Act.