The mapping table: where to keep it so pseudonymization holds

Pseudonymisation turns "Jean Martin" into "Person_1". What makes it pseudonymisation rather than anonymisation is a second file: the table that says Person_1 is Jean Martin. Where that table lives decides whether your pseudonymisation actually protects anything.

1. The GDPR requires it to be kept apart

Article 4(5) of the GDPR only calls it pseudonymisation when data can no longer be attributed to a person "without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures". The mapping table is that "additional information". If it travels with the document, there is no pseudonymisation in the regulation's sense any more: there is a document and its instructions.

2. The EDPB: think in domains

The EDPB Guidelines 01/2025 on pseudonymisation (the version put to public consultation in January 2025) offer a useful notion: the "pseudonymisation domain", meaning the set of people and systems you want to prevent from re-identifying anyone. The protection holds as long as the additional information stays outside that domain. For a firm using AI, the domain is plain: the AI provider, and anyone with access to what it keeps. The table must never enter it.

The same guidelines are firm on one point: pseudonymised data remain personal data, even when the pseudonymised data and the additional information are held by different people. The firm that keeps the table keeps GDPR obligations on the file.

3. The Court of Justice: the recipient's point of view

In its judgment of 4 September 2025 (C-413/23 P, EDPS v SRB), the Court of Justice held that pseudonymised data "must not be regarded as constituting, in all cases and for every person, personal data" (our translation): depending on the circumstances, pseudonymisation can effectively prevent people other than the controller from identifying the data subject. The judgment interprets Regulation 2018/1725, which applies to EU institutions and whose definitions parallel the GDPR's, and the case was sent back to the General Court.

The practical lesson is the same as the EDPB's, seen from the other side: what the recipient can do depends on what it can reach. An AI provider that never had access to the table is in a very different position from one that received it in the same prompt.

4. Six rules for the mapping table

1. It stays in the firm. On the firm's own machines or storage, never with the AI provider and ideally never with the pseudonymisation vendor either.
2. It is never pasted into the AI. Not to "help it understand", not in a project's instructions, not in a file of the folder the AI can read. Re-identification happens after the answer comes back, on your side.
3. Access is limited. Only the people working on the file need it. The same rule as for the original documents.
4. It is protected like the file. It is, in effect, a list of your client's identifiers. Store it with the protections you apply to the client file itself: encrypted disk, backups, no personal cloud.
5. Its lifetime follows the file. Keep it as long as you may need to re-identify AI output for that matter, then delete it with the rest of the file under your retention policy.
6. One table per matter. Consistent pseudonyms inside a file let the AI follow who did what. Reusing the same pseudonyms across unrelated clients creates links that should not exist.

5. How Hexagone AI handles it

In the Hexagone AI desktop app, the mapping between markers and real values is created and stored on your computer, and never sent anywhere. The same person keeps the same pseudonym across every document of a folder, so the AI can follow the file, and the AI's answer is re-identified on your machine. Every detection and substitution is also logged locally in an audit trail you can export as CSV, for your DPO or a regulator.

For the difference between pseudonymisation and anonymisation, and when you need one rather than the other, see our GDPR explainer.