LLM Pseudonymization Gateways: Does the Prompt Leave GDPR Scope?

A pseudonymization gateway does not take you out of GDPR scope. At best it takes the model provider out of scope, and that is a narrower claim you have to be able to prove. The category sells one implicit promise: route the prompt through a pseudonymizer, and sending it to a hosted model stops being a data protection problem. Since 4 September 2025 that promise has a precise legal shape, and the shape is more useful than the marketing, because it tells you exactly which evidence a buyer has to collect.

On that date the Court of Justice held, in Case C-413/23 P, EDPS v SRB, that "pseudonymised data must not be regarded as constituting, in all cases and for every person, personal data". Read the second half of that sentence carefully. The data can remain personal for you while ceasing to be personal for the recipient. Your obligations do not move. The recipient's status might, if the facts support it.

This page owns the buy-side question: what a bought pseudonymization platform changes about your legal position, and what evidence you need before you rely on it. Our PII redaction pipeline guide owns how to build the detection and placeholder layer with Presidio, Privacy Filter or managed DLP. Our EU data residency guide owns where the model itself runs, and our GDPR and AI Act stacking guide owns the artifact list a DACH product team has to ship. Sources reviewed on 18 August 2026.

What is a pseudonymization gateway for LLMs?

It is a control point that sits between your users and one or more hosted models, replaces identifying values with placeholders on the way out, and restores them on the way back. The mechanism is three steps, and every product in the category implements the same three.

1. Detect and replace. Names, addresses, customer numbers, account identifiers and free-text mentions are found and swapped for typed placeholders.
2. Call the model. The placeholder-bearing prompt goes to the provider. The provider never sees the original values, only the tokens.
3. Restore. The response comes back, placeholders are mapped to the original values, and the user sees a complete answer.

Products differ in packaging, not in mechanism. Some sell it as an API you put in front of your own application. Some sell a finished chat product with the gateway inside. Pryvet, a German platform in this category, is a useful worked example because it publishes enough detail to inspect. Its published pricing page starts at 29 euros per user per month with contingents from ten employees, and it groups the selectable models by server location into German, European and US-American, with GPT-5.2, Gemini 2.5 Pro, Claude Opus 4.7 and Alibaba Qwen in the third group. Its trust center lists the subprocessors behind that, including T-Systems, Microsoft Azure, AWS, MongoDB Atlas and Auth0 on the infrastructure side and Anthropic, OpenAI, Google, Mistral, DeepSeek and Alibaba Qwen on the model side.

That model grouping is the most honest thing on any vendor page in this category, and it is the reason the legal analysis below matters. The gateway is the control. The destination is still a choice you make per request, and a US-hosted destination is still a Chapter V transfer of whatever actually leaves your building.

Independence and trademarks: Wavect publishes this page and is itself a provider, so we have a commercial interest in it. We are not affiliated with, endorsed by or partnered with the other companies named here, and all third-party company names, brands and trademarks are the property of their respective owners. Statements about other providers are taken from publicly available sources, primarily their own published pages, as of the review date shown on this page, and may have changed since. Please verify them directly before you decide. This page was written to the best of our knowledge and with the intent to remain objective. If you believe anything here is inaccurate or unfair, write to us and we will correct it: [email protected]

Does pseudonymization take a prompt out of GDPR scope?

Not for you, and that is settled. Article 4(5) GDPR defines pseudonymisation as processing after which the data can no longer be attributed to a data subject without additional information, provided that additional information is kept separately. The definition assumes the additional information still exists. If it did not, you could not restore the answer, and the product would not work.

The EDPB Guidelines 01/2025 on Pseudonymisation put it directly at paragraph 22: pseudonymised data that could be attributed to a natural person by the use of additional information is personal, and that "holds true if pseudonymised data and additional information are not in the hands of the same person". Erasing the mapping later does not retroactively help either. The guidelines say the data becomes anonymous "only if the conditions for anonymity are met", which is a separate and much higher bar.

What the CJEU added in 2025 is the recipient half of the picture. Identifiability is assessed per actor and per situation, so the same bytes can be personal data for the party holding the key and not personal data for a party that cannot realistically get it. The Court also confirmed the limit of that idea in the same judgment: your duty to inform people about recipients is assessed at the time of collection and from your point of view, before any pseudonymisation happens.

Two caveats belong in any memo that cites this. The Court set aside the General Court's judgment and referred the case back, so the litigation is not finished. And the EDPB pseudonymisation guidelines carry the header "Adopted - version for public consultation", adopted on 16 January 2025 with the consultation closing on 28 February 2025. Both are the best available authority today. Neither is a final word, and a claim built on them needs a review date.

What would you have to prove for the model provider to be outside scope?

The EDPB has already written the test, and most buyers have never read it. Paragraphs 63 to 68 of the guidelines describe when pseudonymisation works as a supplementary measure for a third-country transfer. Three conditions have to hold together.

Paragraph 70 adds the rule that applies even without a transfer question: before transmitting pseudonymised data to a third party, at minimum identify the means available to that recipient for attribution. For a frontier model provider that means being explicit about what the provider already holds, including your other traffic, and about retention on their side. A gateway that reduces the prompt but leaves a stable per-user identifier in the metadata has not passed this test.

Why free text defeats field-level pseudonymization

Replacing names is easy. Preventing a prompt from describing exactly one person is not. This is where the "cannot single out" condition breaks in practice, and the evidence is uncomfortable for the whole category.

Researchers at ETH Zurich showed in Beyond Memorization: Violating Privacy Via Inference with Large Language Models that current models infer personal attributes such as location, income and sex from ordinary text, reaching up to 85 percent top-1 and 95 percent top-3 accuracy, at roughly one hundredth of the cost and one two-hundred-fortieth of the time a human needs. The attack surface is not the name field. It is the writing.

The EDPB anticipates the same problem from the other direction. Paragraph 21 of the guidelines says information beyond your control, "for example, information from publicly accessible sources, such as posts in a social media or an online forum", counts toward attribution and must be considered in your assessment of whether the pseudonymisation is effective.

In real prompts, the residue that survives a good field-level pass usually looks like this.

• Role plus organisation plus event. "Our interim CFO who started in March at the Innsbruck site" identifies one person without a single named entity.
• Rare combinations. A diagnosis, a postcode and an age band. None is a name. Together they are a person.
• Quoted correspondence. Writing style, salutation habits and internal shorthand travel with a pasted email even after the header is stripped.
• Attachments and screenshots. A gateway that parses structured text may pass an image through untouched. Ask explicitly, because screen content cannot be redacted the way a form field can.
• Retrieval context. If the assistant does RAG, the retrieved chunks are prompt content too. Permission-aware retrieval is a separate control, covered in our RAG permissions guide.

None of this makes the gateway pointless. It makes the claim conditional on your corpus. A ticket queue of "printer on floor 3 is jammed" pseudonymizes cleanly. An HR grievance thread does not, and no amount of placeholder engineering will change that. The honest architecture decision is to route the second category somewhere else rather than to buy a stronger detector.

Eight questions to ask a pseudonymization platform vendor

These are ordered by how often the answer changes a decision, not by how they sit in a security questionnaire. Our AI vendor security questionnaire covers the generic layer underneath them.

1. Where does the mapping live, and who can read it? Name the jurisdiction, the operator and the access path. The EDPB condition is exclusivity, so "our cloud" is not an answer and "a hyperscaler region in Germany" only becomes one once you know who holds the keys.
2. Is pseudonymization on by default, or is it a tier feature? Worth asking of every product. On Pryvet's published matrix, for instance, the Professional tier lists automatic deletion and pseudonymisation of personal data as optional, while the Enterprise tier adds sensitive data and an optional custom ruleset. A control that a user can switch off is a control your policy has to enforce elsewhere.
3. Which model, in which country, for this request? A platform that lets a user pick a US-hosted model has handed the transfer decision to the user. Decide whether that is acceptable, then enforce it with configuration rather than with training.
4. What exactly do you send besides the prompt? Tenant identifiers, user identifiers, session identifiers and system prompts all travel. Stable per-user identifiers defeat the singling-out condition on their own.
5. What is retained, by you and by the model provider? Ask for the retention setting per provider, in writing, and for what happens to the mapping store when a chat is deleted.
6. What is in scope for detection, and what is passed through? Structured fields, free text, tables, PDFs, images, audio. Ask for the false-negative rate on German compound names and on Austrian and Swiss formats, not on an English benchmark.
7. Who is the processor, and what does the DPA actually say? Article 28 contract, current subprocessor list, notification period for changes, and audit rights. A published subprocessor list, as Pryvet maintains, is the minimum bar rather than a differentiator.
8. What evidence do you hand me for my own file? A transfer impact assessment input, an architecture description of the pseudonymisation domain, and the results of the last penetration test. If the vendor cannot produce these, you will write them yourself, and that cost belongs in the comparison.

What stays yours no matter which platform you buy

Every duty in this table survives the purchase. Vendors are not being dishonest about this; buyers simply read a compliance badge as a transfer of responsibility, and it never is one.

Buy the gateway, move the model, or keep the data out?

Four options, and the gateway is only the best answer in one band. Cost modelling for the alternatives is in our self-hosting cost analysis and our internal assistant cost breakdown.

That third row says processing region, not nationality, on purpose. A provider's corporate domicile tells you which company law it lives under, not where a given request is served, and a European vendor can still run inference in a third-country region or on a third-country cloud. Pin the region in the contract, per model and per endpoint, and get it in writing that it does not silently fail over. A European brand with an unspecified processing location leaves you with exactly the Chapter V question you were trying to avoid.

In practice the good answer is usually two of these at once: a hard rule that most work never carries personal data, plus one governed path for the work that does. That is the shape we built for PromptID, where model-agnostic calls run behind a single orchestration layer, so the provider is a configuration decision rather than an architectural commitment. If you are still choosing between a platform and a build, our custom software versus off-the-shelf guide is the neutral version of that decision.

A two-week evidence pilot

Do not evaluate this category on a demo. Evaluate it on your own worst prompts, and end with a file you can hand to a data protection officer.

1. Build a 200-prompt corpus from real traffic, weighted toward the ugly cases: HR, legal, support escalations, anything with an attachment.
2. Run the singling-out test. Take the pseudonymised output and ask a strong model to describe who wrote it and about whom. Count how often the population narrows below ten people.
3. Measure false negatives by category, separately for German, Austrian and Swiss formats, and separately for free text and structured fields.
4. Measure the task-quality delta. Placeholders change answers. Score the same tasks with and without the gateway, because a compliant assistant nobody uses is not a control.
5. Log latency and cost per request through the gateway against the direct call. Two model round trips are common in this category.
6. Write the mapping-store architecture down in one page: location, operator, access, retention, deletion. This is your pseudonymisation domain, and it is the document the EDPB test is graded against.
7. Decide the routing rule that survives the pilot: which prompt classes go to the gateway, which go to an EU-hosted model, and which never leave.

Primary sources

• Court of Justice of the European Union, press release 107/25 of 4 September 2025 on Case C-413/23 P, EDPS v SRB
• EDPB Guidelines 01/2025 on Pseudonymisation, consultation page, adopted 16 January 2025
• Regulation (EU) 2016/679, GDPR, including the Article 4(5) definition of pseudonymisation
• ETH Zurich SRI Lab, Beyond Memorization: Violating Privacy Via Inference with Large Language Models
• Pryvet security page, on pseudonymisation before processing and German or European server processing