You've got a policy. It says "all personal data is pseudonymised before use." The checkbox is ticked. Your legal team signed off on it.
Now ask yourself three questions: Who tested whether the pseudonymisation is reversible? What's the re-identification risk given the other data you're combining with it? And if a regulator asks for your methodology, can you show them something more detailed than a policy document?
For most organisations, the honest answer to all three is "we haven't." That's not a policy failure. It's an infrastructure failure — and it's the gap that data clean rooms were built to fill.
What Traditional Anonymisation Actually Does
Traditional anonymisation — tokenisation, hashing, pseudonymisation — works by removing or obscuring direct identifiers. You replace a name with a token, a national ID with a hash, an email with a one-way digest. This is good hygiene, and it reduces the immediate exposure if the data is leaked.
But anonymisation doesn't solve the problem it promises to solve. Under GDPR, "anonymised" data is defined as data that cannot be attributed to a specific individual even using "all the means that might reasonably be used." The standard is whether re-identification is possible, not whether it's intended.
The problem is that pseudonymisation is reversible by design. A token is only as strong as the key mapping it back to the individual. Add a second dataset — one you acquired from a third party, or one your model generates during inference — and the link might become recoverable.
The Article 29 Working Party (now the European Data Protection Board) has held that pseudonymised data is still personal data under GDPR, because the controller can re-identify individuals using the means at its disposal. True anonymisation must eliminate that possibility — not just make it inconvenient.
This matters because DUAA 2025 (Article 19) requires anonymisation that meets this standard for AI training data sharing. A policy that says "we pseudonymise" doesn't give you the evidence you need to demonstrate Article 19 compliance when a buyer asks — or when a regulator audits you.
What a Data Clean Room Actually Does
A data clean room is infrastructure, not a policy. It provides an environment where two or more parties can combine and analyse data without either party seeing the other's raw records. The access controls are technical, not documentary — the protection is enforced by the environment, not by a contract clause that says "you won't look."
The key properties that distinguish a clean room from a tokenisation policy:
- No raw data leaves the environment. Both parties' data stays within the clean room boundary. Neither sees the other's underlying records.
- Computation is controlled, not just documented. The operations that can be performed on the data are defined in the infrastructure — not just in a legal agreement between parties.
- Aggregation is enforced, not promised. Outputs are produced by the environment enforcing minimum cohort sizes, suppressing small cells, and preventing query-level record extraction.
- Audit trails are structural, not optional. Every query, every join, every output is logged and attributable — not as a best-practice aspiration but as a system constraint.
None of these properties are achievable by writing a policy and hoping people follow it.
The Compliance Comparison
Here's where the gap becomes concrete:
| Capability | Traditional Anonymisation | Data Clean Room |
|---|---|---|
| Reversibility of identifiers | Reversible — token/key mapping exists | Irreversible — no key mapping outside environment |
| Re-identification risk testing | Optional — rarely done systematically | Structural — enforced by access controls |
| Output control (no record-level extraction) | Contractual — depends on agreement terms | Technical — enforced by environment |
| Cross-dataset linkage prevention | Not enforced — pseudonymised data can be linked | Enforced — environment controls data ingress |
| Audit trail for regulatory review | Manual — policies, not logs | Automatic — structural system logging |
| DUAA 2025 Article 19 compliance path | Needs additional evidence — policy alone insufficient | Direct path — technical controls satisfy the standard |
The critical row is the last one. Under DUAA 2025, sharing AI training data that contains personal data requires anonymisation that meets the irreversible standard. A tokenisation policy does not give you evidence of this. A data clean room — with the right technical controls, audit logging, and output suppression — can.
Where the Gap Bites Hardest
The problem isn't that pseudonymisation is wrong. It's that it's often treated as the compliance destination rather than the starting point. Most organisations that say "we anonymise" are doing the minimum — masking names and calling it done. They haven't asked:
- What combinations of our other datasets could re-identify this data?
- How does our inference output interact with the anonymised training data?
- What does a DUAA 2025 Article 19 audit trail look like for our current process?
A data clean room forces you to answer these questions structurally, not by writing a policy. The environment doesn't let you take shortcuts — because the output controls are part of the system, not a contractual clause your legal team wrote three years ago.
If you're sharing data for AI training in the EU or UK, pseudonymisation alone is not enough for DUAA 2025 or GDPR compliance. The regulation requires irreversible anonymisation — which means your compliance path needs to be infrastructure, not policy. A data clean room is the practical implementation of that requirement.
What This Means for Your Data Pipeline
If you're building a data pipeline for AI training, and you're currently handling anonymisation as a policy checkbox, here's what you should be doing instead:
1. Treat re-identification risk as a technical problem, not a legal one
Run a re-identification risk assessment on your pseudonymised dataset — including the other datasets in your environment. If the risk is non-trivial, pseudonymisation alone doesn't meet the standard.
2. Choose infrastructure over documentation
If you're sharing data with another party — or allowing cross-functional teams to combine datasets for AI training — use an environment where access controls, output suppression, and audit logging are structural, not contractual.
3. Build the audit trail before you need it
A DUAA 2025 Article 19 audit trail isn't just a record of what you did — it's evidence of what controls were in place. If you only document your anonymisation after a regulatory question, you've already missed the point.
4. Treat clean rooms and anonymisation as complementary
Data clean rooms don't replace anonymisation — they operationalise it. The clean room provides the environment; anonymisation is still applied to the data before it enters. But the combination is what satisfies the regulatory standard, not the pseudonymisation on its own.