Outside GDPR: Is your AI data really anonymous
8 November 2026
Emma Di iorio | CEO & Co-founder, Spriggun
Recently, Spriggun responded to the European Data Protection Board's consultation on its Guidelines on Anonymisation. The guidelines bring welcome structure: a three-part test with defined criteria, AI models addressed directly for the first time, and a practical flowchart. It has not changed that anonymous data sits outside the GDPR, and personal data sits within it. However, the guidelines have solidified guidance, and have removed the ambiguity that allowed for some organisations to avoid hard realities, especially given the increased complexity and volume that widespread AI usage has brought.
There are two common situations, with some organisations suffering both:
-
Many still wishfully consider data that isn't truly anonymised to be so, using it as such, and generally seeing this is not the case when there's a cyber or data breach; a rude awakening.
-
The scope for actually anonymised data to be reidentified has become much larger: due to much larger data sets and data points, or because one org has more context than another.
The context has changed significantly since the previous guidance was written in 2014. Many now combine data across partners, platforms and clean rooms. AI has made it cheaper and faster to reidentify individuals from data that was previously treated as safe. At the same time, the guidelines make clear that whether data is anonymous depends on who holds it. This makes sense, but has always caused confusion.
Is the data really anonymous? In over a decade of data protection work, I have heard every version of this claim:
- names have been removed;
- it is only IP addresses;
- the data sits in a clean room;
- it is masked;
- no one will look at it;
- it is anonymous under Californian law.
None of these, on their own, makes data anonymous under EU or UK law, and several describe data that is clearly still personal.
Take a practical example. A spreadsheet contains first names and job functions for one organisation's employees. From that organisation's position, “Sarah, Marketing Manager” in a team of 20 is almost certainly identifiable; this is personal data. A third party receiving that same column as part of an aggregated dataset across hundreds of organisations generally cannot identify which Sarah this is; from its position, the data may well be anonymous. The same data, different answers for each organisation, and why each organisation must assess anonymity itself.
The guidelines set out three criteria for testing anonymity:
- No Record Isolation. No unique combination of values in the data singles out a specific person.
- No Linkage. Records cannot be matched to records in another dataset to identify someone.
- No Inference. No specific and meaningful conclusion about an identifiable person can be drawn from the data.
Data is anonymous only if all three are met. Failing one does not automatically make it personal, but it triggers further contextual analysis; and whether an organisation takes a strict or contextual approach, it remains squarely on the hook to prove and defend its assessment.
Key watchouts
Record isolation is the most common failure in practice
The more attributes a record contains, the more likely it is unique to one person, even without a name attached. For example, security and system logs are often treated as technical infrastructure data rather than personal data. A log entry with a timestamp, IP address, device type and application accessed, without a username attached, can still identify exactly one person in a team of 30; if it can, it is personal data, and data protection obligations apply.
Linkage catches organisations that combine datasets
This applies directly to data partnerships, martech platforms, and clean rooms. If a record can be matched to another dataset to identify someone, it is not anonymous. In our earlier example, if the third party combines first names and job functions with location, salary band, or tenure, the assessment changes. Make this a priority discussion with your agencies, data brokers, and ad-tech vendors.
Inference is where AI raises the stakes
The guidelines explicitly bring AI models and synthetic data into this test, leaving no room for workarounds. Prompt a model trained on HR data with a department and job title at a mid-sized company, and it may return details specific to one person. While general population insights are fine, specific and meaningful conclusions about an individual are not. Inferences from browsing, purchases, or location data can also reveal health, religion, politics, or sexual orientation, which counts as special category data under EU case law.
Priorities for boards and their advisers
-
Do your own assessment - A supplier's, data partner's, or service provider's conclusion that data is anonymous does not settle the question for the organisation receiving or using it. A media agency running a campaign, a martech platform combining customer segments, a model provider training on data from multiple contributors: each must conduct its own assessment from its own position. The board needs to know who owns this assessment internally, what evidence supports it, and when it was last reviewed.
-
Reassess when circumstances change - Anonymous data can become personal data again if re-identification techniques improve, new datasets become available for combination, or the data is put to a new use such as model training. The EDPB notes that agentic AI will reduce the time and cost of re-identification. Encryption is not anonymisation; it is reversible by design. “No one will look at it” is not a defence; the guidelines note that motivation is difficult to demonstrate and can change; the standard of intention required is not fully resolved.
-
Properly test for inference - Most organisations are not yet doing this. AI models can absorb and reproduce specific details from the data they were trained on; if a model can be prompted to return information that identifies a real person, the data it is built on is not truly anonymous. Testing for this is a practical starting point: run targeted prompts against the model, document what comes back, and address anything identifiable. Where a model is trained on data classified as anonymous, the No Inference assessment should account for what the model can produce at deployment, not only what the training data contained.
Anonymous under the GDPR is not the end of the analysis
Broadly: fundamental rights and equality law still apply to what model outputs do to individuals; consumer protection applies to what customers are told; competition law applies to data pooled or shared with other businesses; intellectual property, confidentiality and licence terms are not cleared by anonymising. The board needs one view across these, not a separate answer from each function.
What remains less clear
The guidelines do not carry forward the technique-specific assessment from the 2014 Working Party opinion; organisations should document their choice of technique against the current state of the art rather than wait for an update. Periodic reassessment is framed as good practice rather than a mandatory component of accountability; treating it as discretionary is a risk most boards should not take. Now the consultation has ended, it remains to be seen whether the EDPB will give further certainty on memorisation testing as part of the No Inference assessment and specify triggers for reassessment; in the meantime both are worth building into existing processes.
Going slow to go fast starts with a list: review every place the business relies on a claim of anonymity, with AI training uses first. The flowchart in Annex 1 of the guidelines is a workable starting framework.
If you rely on anonymised data in AI projects, start the conversation.
Emma Di Iorio is Co-Founder and CEO of Spriggun, a UK-based RegTech and AI governance advisory firm. A qualified solicitor with senior in-house and advisory experience, she writes and speaks internationally on AI, data, privacy, and web compliance.