Reversible anonymization: masking with a private key (tokenization done right)

Reversible anonymization replaces each piece of personal data with a consistent placeholder token, while a private key kept only by you stores the mapping needed to restore the original. The party you share the masked text with — an AI model, a contractor, a support tool — sees only tokens like [PERSON] or [PESEL]. You, holding the key, can turn the model’s response back into real names and numbers. Legally this is pseudonymization, and getting the key handling right is what separates a safe two-way workflow from a data leak.

TL;DR

• Reversible anonymization = masking + a private restore key. The recipient sees placeholders; only the key-holder can reverse them.
• Strictly, it is pseudonymization under GDPR Art. 4(5) — the mapping is “additional information” that must be kept separate and secure.
• It is not encryption (which garbles the whole text) and not hashing (which is one-way and can’t restore) — it’s a structured token↔value map.
• Use it when you need the answer to come back linked to the real entities: AI drafting, translation, analysis, redlining.
• Keep the key local and access-controlled. If the key leaks, the pseudonymization is undone.

What is reversible anonymization?

Ordinary (“irreversible”) anonymization throws away the link between the placeholder and the person — Jan Kowalski → [PERSON], mapping destroyed. That is great for compliance but useless when you need the original back.

Reversible anonymization keeps a private mapping:

Mask:    Jan Kowalski → [PERSON_1]     85010212345 → [PESEL_1]
Key:     [PERSON_1] = Jan Kowalski     [PESEL_1] = 85010212345   (stored only on your device)
Restore: [PERSON_1] → Jan Kowalski     [PESEL_1] → 85010212345

The masked text is safe to send anywhere. When a response comes back referring to [PERSON_1], the key rewrites it to Jan Kowalski. Consistent tokens matter here: the same person must map to the same token every time, or the restore step — and any reasoning the model does across the document — breaks.

Why the AI provider’s view is anonymous but yours is pseudonymous

This is the subtle part that decides your GDPR obligations:

• The recipient sees only irreversible placeholders. With no key, they cannot re-identify anyone. Their view is effectively anonymized.
• You keep the key. On your side the data is still linkable to individuals, so the mapping remains personal data and the workflow is pseudonymization (Art. 4(5)) — not anonymization.

The practical rule that follows: protect the key like the personal data it represents. Keep it local, encrypted at rest, and access-controlled. See anonymization vs pseudonymization for the full legal line.

Reversible anonymization vs encryption vs hashing

	Reversible anonymization	Encryption	Hashing
Output	Readable placeholder tokens	Ciphertext (unreadable)	Fixed-length digest
Reversible?	Yes — with the key map	Yes — with the key	No — one-way
Text stays usable?	Yes (structure/format preserved)	No	No
Good for AI prompts?	Yes	No	No
GDPR status	Pseudonymization	Pseudonymization	Pseudonymization*

*Hashing a small, guessable value (like a national ID) is brute-forceable, so it’s pseudonymization at best — not anonymization.

The key difference for real work: only reversible anonymization leaves the surrounding text usable. You can still read the sentence, the model can still reason about it, and the placeholders slot back out cleanly afterwards.

When to use reversible vs irreversible masking

Use reversible (keep the key) when the output must map back to real entities:

• Drafting an email or contract with an AI, then sending it to the real client.
• Translating a document that must be delivered with real names restored.
• Analysing a support ticket where the resolution has to reference the actual account.

Use irreversible (destroy the mapping) when you never need the original again:

• Publishing or sharing a dataset.
• Retaining analytics data past its purpose (see does GDPR apply to anonymized data).
• Satisfying a right-to-erasure request.

If in doubt, prefer irreversible — a key you keep is a risk you keep. Only hold the mapping when the workflow genuinely needs the round trip.

FAQ

Is reversible anonymization the same as pseudonymization? Yes. Because a key can restore the original, GDPR Art. 4(5) classifies it as pseudonymization, and the data (plus the key) remain personal data on your side.

Does reversible anonymization take my data out of GDPR scope? Not on your side — you hold the key, so it’s still personal data. But the recipient who only sees placeholders cannot re-identify anyone, so their processing is far lower-risk.

Where should the restore key live? Locally, under your control, encrypted at rest and access-controlled. Storing it next to the masked data, or on the same third-party service you’re protecting against, defeats the purpose.

Isn’t this just find-and-replace? No. It needs consistent, collision-free tokens per entity, detection of what to mask in the first place, and a safe stored mapping to reverse — including handling repeated and inflected forms of the same name.

Can I mask reversibly for AI and then destroy the key later? Yes. Keep the key only for the round trip, then delete it. Once the mapping is gone, the remaining data is irreversibly anonymized.

---

Amaze masks names, PESEL, NIP, REGON, KRS, emails, phones, IBANs and more with consistent tokens, and keeps the restore key as a private mapping on your own machine — so you can un-mask an AI’s reply locally, and nothing sensitive ever leaves your device. See how it works.

Part of our complete guide to data anonymization.