A common pattern for using external AI models with sensitive material is to replace identifying values, such as names, account numbers and addresses, with placeholder tokens before the text leaves the organisation, and to swap the real values back into the answer when it returns. The model sees “CLIENT_17 transferred AMOUNT_3 to ACCOUNT_9” rather than the real details.
It is a sensible technique. It is also routinely described in a way that overstates what it does. The result is not anonymous data, and treating it as if it were can lead to the wrong conclusions about contracts, transfers and risk.
What the GDPR says
The General Data Protection Regulation (Regulation (EU) 2016/679) defines pseudonymisation in Article 4(5) as processing personal data “in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information”, provided that additional information is kept separately and protected.
Recital 26 then draws the line that matters here. Personal data that have undergone pseudonymisation, and could be attributed to a person by using additional information, “should be considered to be information on an identifiable natural person”. The Regulation’s principles do not apply to anonymous information, which the same recital describes as information that does not relate to an identified or identifiable person, or data rendered anonymous so that the person is no longer identifiable.
Tokenisation with a mapping kept on the device fits the first description, not the second. Whoever holds the mapping can re-identify every value by design, because that is how the real details are restored in the answer.
Quotations are from the English text of Regulation (EU) 2016/679 on EUR-Lex, checked on 24 September 2026. Whether particular data are personal data in the hands of a particular recipient can depend on the circumstances, including the means reasonably likely to be used to identify someone. That assessment needs qualified legal advice; this article does not provide it.
What tokenisation genuinely achieves
Being clear about the limits is not an argument against the technique. Recital 28 of the Regulation notes that pseudonymisation “can reduce the risks to the data subjects concerned” and help controllers and processors meet their obligations. In practice, tokenising a prompt before it leaves the device can:
- keep direct identifiers out of a model provider’s logs, caches and support tooling;
- reduce the harm if an outgoing request or response is exposed;
- make it harder to link one request to another about the same person, if tokens are not reused across contexts;
- keep the ability to re-identify under the organisation’s control, on its own device, rather than with a third party.
What it does not achieve
The limits are just as practical.
- Context still identifies. “The newly appointed head of compliance at a small regional lender” needs no name. Tokenising named entities does nothing about identifying descriptions, rare combinations of facts or free-text detail.
- Detection is imperfect. Automated detection of sensitive values misses some and wrongly flags others. No system detects every confidential concept, and a product that claims to should be treated with caution.
- Confidential is broader than personal. Deal terms, trading strategies and draft regulatory findings can be highly sensitive without identifying anyone. Personal-data techniques do not address them on their own.
- The obligations remain. Because pseudonymised data remain personal data, questions about lawful basis, processor terms, transfers and retention still have to be answered for the provider receiving them.
Where the mapping lives matters
The protection that tokenisation offers depends almost entirely on the mapping between tokens and real values. If the mapping is sent to the same provider, or stored centrally next to usage logs, the separation that the definition requires is thin. If it stays on the device, protected by the operating system and deleted according to a defined retention policy, the separation is real.
That is the approach in Synainesi’s design. Protection is applied locally, before the outgoing payload is assembled and rescanned; re-identification mappings stay local and protected; and the product describes the technique as pseudonymisation, not anonymisation. The central governance service is designed not to receive protected values or mappings at all.
How to describe masking honestly
For compliance teams writing policies, answering client questionnaires or briefing supervisors, precise language is the safest language.
- Say “identifiers are replaced with reversible tokens before leaving the device”, not “data is anonymised”.
- Say where the mapping is held, who can access it and when it is deleted.
- State what is not covered: indirect identification, free text and non-personal confidential information.
- Treat the provider as receiving personal data unless qualified advice concludes otherwise for your specific situation.
Tokenisation is a good control. It becomes a liability only when it is described as something it is not.
Related: the principles behind Synainesi, and what an AI control should record.