Compliance decisions
GDPR: can this AI input identify someone?
Replacing a name with a token does not establish anonymity. Assess the additional information and means reasonably likely to identify a person in the actual context. Pseudonymisation can reduce risk while personal-data obligations remain relevant; a label such as anonymised is not the legal decision.
For DPOs, data owners and security teams preparing AI inputs
The sample token remains linked to an invented identity through a separate key.
All people, roles and events are invented. No legal anonymity determination or re-identification of a real person has occurred.01
Start with the identifiability question
GDPR Recital 26 addresses identified and identifiable people and the means reasonably likely to be used for identification. It calls for objective factors such as cost, time and available technology. A transformation’s name does not answer that contextual question.
Article 4 describes pseudonymisation in terms of additional information kept separately with appropriate measures. Consider who holds that information, who can obtain or combine it, and what other context remains. Do not assume that every recipient has identical capabilities or that removing one field settles the analysis.
Source context: EU GDPR: identifiability and pseudonymisation
02
Distinguish a token from removal of the link
The synthetic files replace two invented names with P-01 and P-02. A separate linkage table still connects each token with an identity. For an organisation holding that key, the names have been moved out of the working file rather than made irretrievable.
Keeping the key separately can be a meaningful safeguard. It does not automatically make the working dataset anonymous. Assess access controls, the purpose and the realistic means of linking the records, including what information a recipient could obtain from other sources.
Source context: EU GDPR: identifiability and pseudonymisation
03
Look for identification without the key
A unique role, precise event date or uncommon combination of attributes may identify someone even where the token key is unavailable. The example includes a distinctive workshop role and event. Those clues are invented, but they demonstrate why a name-only or token-only review can miss the practical link.
Do not confuse this with a rule that every imaginable attack is reasonably likely. The assessment needs a reasoned view of the actual recipient, available information and means. Record the assumptions and evidence instead of claiming anonymity from a generic tool score.
Source context: EU GDPR: identifiability and pseudonymisation
04
Choose a less identifying input when it meets the task
If the AI task needs only a general description, an invented scenario or sufficiently broad summary may be enough. Avoid including stable tokens when record-level linking is unnecessary. If a real-data analysis requires individual records, retain the safeguards and legal review appropriate to that identifiable information.
The reduced-detail example deliberately drops the unique role and exact event. It is not a certified anonymisation result. A real dataset needs its own assessment, including the risk from combination, small groups and the information available to its recipients.
Source context: EU GDPR: identifiability and pseudonymisation
05
Keep the legal result and safeguards separate
An anonymity decision concerns whether the relevant data relates to an identified or identifiable person in the assessed context. Pseudonymisation is one protective measure and does not itself supply a lawful basis, contractual permission or the answer to an Article 9 question.
Document the data version, recipient, retained links, evidence and conclusion. Revisit changes to the dataset or recipient context. The downloadable pair is wholly synthetic and intentionally includes its key for teaching; it is not advice to distribute a real linkage key with a real dataset.
Source context: EU GDPR: identifiability and pseudonymisation
Put it into practice
Linked-identifier review exercise
Read the synthetic tokenised data, separate key and recipient context together. Then explain which links remain and what the task actually needs.
All people, roles and events are invented. No legal anonymity determination or re-identification of a real person has occurred.
Original
Mara Example + feedback
Working file
P-01 + distinctive event context
Separate key
P-01 → Mara Example
All information is synthetic.
Alternative
General themes without record-level links
| Representation | Synthetic content | Reasoning |
|---|---|---|
| Original | Mara Example and Elliot Example have invented feedback records. | Direct identity is present in the teaching data. |
| Tokenised working file | P-01 and P-02 replace the names. | The transformation removes visible names but retains stable links. |
| Separate linkage key | P-01 maps to Mara Example; P-02 to Elliot Example. | The holder of this key can attribute the records. |
| Context without the key | P-01 is described as the only facilitator at a specific invented event. | Distinctive contextual information may provide another identification route. |
| Reduced-detail alternative | General feedback themes with no token or unique event detail. | May meet the wording task; no real anonymity conclusion is established by this example. |
| Recipient assessment | Available information and realistic linking means must be assessed. | Do not assume every recipient can identify equally, or that none can identify without the key. |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
gdpr-linked-identifier-exercise.mdInspect
# Linked-identifier review exercise
All people, roles and events are invented. No legal anonymity determination or re-identification of a real person has occurred.
Read the synthetic tokenised data, separate key and recipient context together. Then explain which links remain and what the task actually needs.
| Representation | Synthetic content | Reasoning |
| --- | --- | --- |
| Original | Mara Example and Elliot Example have invented feedback records. | Direct identity is present in the teaching data. |
| Tokenised working file | P-01 and P-02 replace the names. | The transformation removes visible names but retains stable links. |
| Separate linkage key | P-01 maps to Mara Example; P-02 to Elliot Example. | The holder of this key can attribute the records. |
| Context without the key | P-01 is described as the only facilitator at a specific invented event. | Distinctive contextual information may provide another identification route. |
| Reduced-detail alternative | General feedback themes with no token or unique event detail. | May meet the wording task; no real anonymity conclusion is established by this example. |
| Recipient assessment | Available information and realistic linking means must be assessed. | Do not assume every recipient can identify equally, or that none can identify without the key. |
## Review steps
- Inventory the remaining links: Include keys, stable identifiers, distinctive attributes and other accessible information.
- Assess the actual context: Consider realistic means, time, cost and available technology for the relevant parties.
- Record the data-specific conclusion: Keep the version, assumptions, recipients and legal reasoning separate from a tool’s transformation label.
## Invented example
Original: Mara Example, only facilitator at the fictional Elm Workshop on 3 March 2026, gave feedback about room layout.
Tokenised: P-01, only facilitator at that same invented workshop/date, gave the same feedback.
Reduced description: “Participants suggested clearer room signage.”
The tokenised version retains a key and contextual clues. The reduced description illustrates minimisation, not a legal finding about a real dataset. The supplied linkage key is for teaching only.
## Source and scope
Guide: https://aona.ai/resources/guides/gdpr-anonymisation-pseudonymisation-ai/
Source check: 21 September 2026. General information, not professional approval or a completed control test.
- EU GDPR: identifiability and pseudonymisation: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
gdpr-linked-identifier-exercise.csvInspect
Representation,Synthetic content,Reasoning
Original,Mara Example and Elliot Example have invented feedback records.,Direct identity is present in the teaching data.
Tokenised working file,P-01 and P-02 replace the names.,The transformation removes visible names but retains stable links.
Separate linkage key,P-01 maps to Mara Example; P-02 to Elliot Example.,The holder of this key can attribute the records.
Context without the key,P-01 is described as the only facilitator at a specific invented event.,Distinctive contextual information may provide another identification route.
Reduced-detail alternative,General feedback themes with no token or unique event detail.,May meet the wording task; no real anonymity conclusion is established by this example.
Recipient assessment,Available information and realistic linking means must be assessed.,"Do not assume every recipient can identify equally, or that none can identify without the key."
synthetic-tokenised-feedback.csvInspect
record_token,context,feedback
P-01,Only facilitator at fictional Elm Workshop on 2026-03-03,Clearer room signage
P-02,Participant in fictional Elm Workshop,Shorter session instructions
synthetic-linkage-key.csvInspect
record_token,invented_identity
P-01,Mara Example
P-02,Elliot Example
synthetic-recipient-context.txtInspect
TEACHING CONTEXT ONLY
The originating organisation holds the synthetic linkage key. A hypothetical recipient might know the unique facilitator role from the invented event programme. Assess those different means explicitly. No real event, person or successful identification is represented.
Before you proceed
Keep these distinctions clear
- Pseudonymised is not a legal anonymity label
- Assess the retained information and realistic linking means.
- A hidden name is not the only identifier
- Distinctive roles, events and combinations can preserve a link.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate sensitive-input detection and redaction for supported employee AI paths.
It does not guarantee legal anonymisation or decide GDPR applicability for every recipient and dataset.
Use the invented original and transformed files to inspect remaining content, separately from the legal identifiability assessment.
Review your use caseFAQ
Questions for this decision
Does hashing or replacing a name always anonymise it?
Does keeping a key separately have value?
Must every recipient be assessed identically?
Is the reduced example legally anonymous?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- EU GDPR: identifiability and pseudonymisation
Recitals 26–29 and Article 4 distinguish personal data, additional identifying information and pseudonymisation, considering means reasonably likely to be used.
law · checked 2026-09-21