Anonymisation, pseudonymisation, de-identification: definitions and what ndaact.ai does

Anonymisation is irreversible, pseudonymisation keeps a key, and de-identification describes the effect for the recipient; ndaact.ai does the second and aims at the third.

This page gives the three definitions, the texts behind them and the exact position of ndaact.ai, including its limits. It is written for the DPO, solo lawyer, independent physician or accountant who needs to know which word to use in a record of processing activities.

The three terms in one table

Term	Definition	Reference text
Anonymisation	The data no longer allows the person to be identified by any means reasonably likely to be used. The GDPR then no longer applies to that information. The operation cannot be undone.	GDPR, recital 26
Pseudonymisation	The data can no longer be attributed to a specific person without additional information, kept separately and protected by technical and organisational measures. The key exists, so the operation can be undone by whoever holds it.	GDPR, article 4(5)
De-identification	A term the GDPR does not use. We use it to describe the effect on a given recipient: if the recipient has no reasonable means to re-identify the people, the data may no longer be personal for that recipient.	CJEU, C-413/23 P, 4 September 2025, paragraphs 76, 77, 85 and 86

What ndaact.ai does on your machine

ndaact.ai detects entities (names, addresses, identifiers) in the text and replaces each one with a marker such as {{PERSON_a1b2}}. The correspondence table stays on your machine: it is what restores the original values in the model’s answer.

Because that table exists, the operation is client-side pseudonymisation under article 4(5). On your side, the data remains personal data. Calling it anonymisation for your own workstation would be inaccurate.

What the model provider receives

The text then goes to the model provider with markers in place of the detected entities. The provider does not receive the correspondence table. The intended effect, for the provider, is de-identification.

The CJEU clarified this relative approach in EDPS v SRB (C-413/23 P, 4 September 2025). It holds that pseudonymised data is not automatically personal data in every case and for every person (paragraph 86). For the controller that holds the additional information, the data stays personal (paragraph 76). For the recipient, the outcome depends on two conditions set out in paragraph 77: the recipient must not be able to lift the pseudonymisation measures, and those measures must prevent it from attributing the data to the person by other means, such as cross-referencing.

Two points in the judgment limit this reasoning:

• If the recipient can reasonably attribute the data to the person by cross-referencing, the person remains identifiable for that recipient and for any further processing (paragraph 85).
• For the duty to inform data subjects, identifiability is assessed at the time of collection, from the controller’s point of view (paragraph 111).

The Court also sets aside the judgment of the General Court and refers the case back to it. The case concerns Regulation (EU) 2018/1725, whose definitions the Court notes are substantially identical to those of the GDPR (paragraph 52).

What the EDPB says

Opinion 28/2024 of the European Data Protection Board, adopted on 17 December 2024, deals with AI models. It holds that a model trained on personal data cannot be considered anonymous in all cases, and that anonymity is assessed case by case, taking into account “all the means reasonably likely to be used” by the controller or another person. The opinion covers models, not prompts. We cite it for the reasonable-means test, which is the same.

The limits of ndaact.ai

• Detection can miss entities. An undetected entity stays in clear text in what is sent.
• An indirect identifier buried in free text (“my client, the only organic baker in the village”) can still identify a person by cross-referencing.
• ndaact.ai therefore does not make the whole prompt anonymous. It replaces the detected entities and helps you limit what the provider receives, without guaranteeing that every entity is found.
• Read the text before sending it, and check with your DPO or counsel what your professional rules and your record of processing allow.

Which word to use in your record

For your own workstation: client-side pseudonymisation. Towards the model provider: a measure aimed at de-identification, whose effect depends on the entities actually detected and on what the provider can cross-reference. This is the vocabulary of our privacy policy.

Source: GDPR art. 4(5) and recital 26, EUR-Lex, accessed 11 October 2026; CJEU, EDPS v SRB, C-413/23 P, 4 September 2025, EUR-Lex, accessed 11 October 2026; EDPB, opinion 28/2024, 17 December 2024, accessed 11 October 2026.

This page is a translation. The French version prevails.