Are Pseudonymised Prompts Still Personal Data Under GDPR?

An agent pastes a ticket into an assistant: "Ada Lovelace (ada@example.com) says her refund of CHF 2,400 never arrived." A masking layer sends "mf_mask_8c1e... (mf_mask_170b...) says her refund of CHF 2,400 never arrived." Has the personal data left the picture? Not for you. For the provider, the honest answer is "it depends", and the rest of this page is about what it depends on.

What do Article 4(5) and Recital 26 say?

Article 4(5) defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific person without additional information, provided that information is kept separately and protected by technical and organisational measures. Recital 26 says personal data that have undergone pseudonymisation, which could be attributed to a person by the use of additional information, should be considered information on an identifiable natural person. It also says that to decide whether someone is identifiable you take account of all the means reasonably likely to be used, and that the data protection principles don't apply to anonymous information.

So the starting point is plain. If you hold the token store, or can otherwise reverse the tokens, the masked prompt is pseudonymised personal data in your hands. For the general difference between the two concepts, see pseudonymization vs anonymization.

What did the Court of Justice decide in EDPS v SRB?

In EDPS v SRB (C-413/23 P), judgment of 4 September 2025, the Single Resolution Board had passed pseudonymised comments from shareholders and creditors to a consultancy, which didn't hold the key. The Court of Justice set aside the General Court's judgment and sent the case back on a separate point. Published analyses of the judgment draw out these points:

• Pseudonymised data must not be regarded as personal data in all cases and for every person. Whether it is depends on the circumstances and on the position of the party that has it.
• For the original controller, which holds the key, the pseudonymised data stayed personal data.
• A recipient without realistic means to re-identify people may be handling data that isn't personal data for it. The assessment looks at the means that recipient could actually use.
• The duty to tell people who receives their data is judged from the controller's perspective when the data are collected. It doesn't depend on a later view of whether the recipient could identify anyone.

Two cautions. The case arose under Regulation (EU) 2018/1725, which governs EU institutions, not under the GDPR itself, and commentators differ on how far it carries over. And the Court didn't say pseudonymised data is anonymous or outside data protection law. It said the answer depends on who holds the data and what they can do with it.

What have the EDPB and its AI opinion said?

The EDPB adopted Guidelines 01/2025 on pseudonymisation in January 2025 for public consultation, with feedback open until 14 March 2025. As of November 2026 we have not been able to confirm that a final version has been adopted, so check the EDPB website for the current status.

Opinion 28/2024, adopted on 17 December 2024, concerns AI models. It says an AI model trained on personal data can't in all cases be considered anonymous, and that supervisory authorities should assess claims of anonymity case by case, looking at all the means reasonably likely to be used. It does not decide whether a pseudonymised or masked prompt is personal data for the provider that receives it, so it shouldn't be cited for that.

What decides the answer for an AI provider?

What pushes the provider's answer toward "personal data": names or rare details left in free text, a consumer account where the provider already knows who the user is, the same token repeating across many prompts so that a profile of one person builds up, and any route by which the mapping or the original text could reach the provider. What pushes it away: consistent masking of identifiers, no link between the account and the people in the text, and contractual and technical barriers against re-identification.

What should you do in practice?

• Treat every prompt as personal data on your side. You need a legal basis, a processor agreement and, where the risk is high, a DPIA.
• Use masking to reduce what the provider receives, and don't build a legal case on the provider holding no personal data at all.
• Keep the token store separate from the data you send, as Article 4(5) requires of additional information.
• Write down your reasoning on the provider's position, including free-text risk, for each use case.

Maskflare's Detection Engine replaces detected values with reversible tokens before the prompt leaves, can restore them in the response on API traffic, and keeps the originals behind the tokens encrypted for 30 days. Prompts and responses aren't logged or stored (see the no-log policy). That is a strong minimization measure. It doesn't decide the legal status of the masked text, and it isn't a claim that the data is anonymous. The GDPR page covers the wider obligations.