Showing Posts From

Data anonymisation

Data Anonymisation for AI: Why the GDPR Standard Is Harder Than European Companies Think

Data Anonymisation for AI: Why the GDPR Standard Is Harder Than European Companies Think

A European data team prepares a dataset for processing by an external AI model. Before it goes, they run the standard anonymisation process: names removed, email addresses stripped, identification numbers deleted. The team confirms the data is anonymous. The dataset is sent. It isn't anonymous. What most organisations call anonymisation is pseudonymisation. The distinction matters — not as a legal technicality, but because GDPR treats them entirely differently, the actual standard for true anonymisation is far higher than most teams have achieved, and AI models introduce a specific re-identification risk that didn't exist in conventional data processing. European companies making data flow decisions based on an anonymisation claim they haven't actually met are carrying GDPR exposure they believe they've eliminated. The gap between the two terms is where most enterprise AI programmes are currently sitting. The difference between pseudonymisation and anonymisation — and why it changes everything Pseudonymisation replaces identifying fields with artificial identifiers. A name becomes a token. An ID number becomes a different ID number. The original identity can be restored using a key held by the originating organisation. The data looks de-identified. Under GDPR, it is explicitly classified as personal data. GDPR Recital 26 makes this clear: pseudonymised data — data that could be attributed to a natural person by the use of additional information — remains within the scope of the regulation. Cross-border transfers of pseudonymised data still require a valid transfer mechanism. Data subject rights still apply to it. Breach notification obligations apply if it is compromised along with the re-identification key. Pseudonymisation is valuable risk reduction — GDPR Article 32 explicitly recommends it as a technical security measure — but it does not remove data from GDPR scope. True anonymisation is the irreversible kind. Data is genuinely anonymous when re-identification is not reasonably possible, taking into account all the means likely to be used by any party. That is the GDPR standard. It is an extremely high bar. Truly anonymous data falls entirely outside GDPR scope — it can be transferred to AI models outside the EU without triggering the transfer restrictions in Chapter V, it carries no breach notification obligations, and it is not subject to data subject access rights. The problem is that meeting this standard for real-world enterprise datasets is genuinely difficult. And most organisations claiming anonymisation have not met it. Why the re-identification standard is harder than it appears Remove a name, remove an email address, remove a national identification number. The dataset looks clean. Now consider what remains: age, job title, department, location, salary band, tenure, performance rating, and a timestamp on when the record was created. For a company with three hundred employees in a single city, how many people does that description fit? Often fewer than five. Sometimes one. This is the re-identification problem. It doesn't require the re-identifier to have the original data. It requires them to have other data — which may be publicly available, commercially available, or deducible from the context — that allows them to match records back to individuals. The more detailed and rich the dataset, the smaller the group that any given record could describe, and the easier the re-identification. Study after study has demonstrated this in practice. Researchers have re-identified individuals in supposedly anonymous medical datasets by cross-referencing with public records. Anonymous mobility data has been linked back to named individuals by correlating location patterns with public social media. Netflix user records, released as part of an anonymisation research dataset, were re-identified by cross-referencing with public film ratings platforms. The European Data Protection Board is working on updated guidelines on anonymisation — this was announced in its 2024-2025 work programme. The updated guidance hasn't resolved the standard; it has reinforced the position that organisations asserting anonymisation should be able to demonstrate it, not assert it as a processing decision taken internally without external validation. For European enterprises, the practical implication is this: if the dataset is complex, if the records are detailed, if the organisation holds a re-identification key anywhere in its systems, or if the data could be cross-referenced with external sources to recover identities — the data is pseudonymous at best, not anonymous. And pseudonymous data requires all the GDPR protections that come with personal data. How AI models add a re-identification risk that didn't exist before Conventional data processing treats data as data. An analytics platform runs queries. A reporting system aggregates records. The data doesn't learn from its own processing. AI models are different. A model trained on pseudonymised data can, under certain conditions, learn patterns correlated with the identity of specific individuals — patterns derived not from the identifiers (which were removed) but from the combination of other attributes in the records. This creates what is known as a membership inference risk: an attacker — or the model itself, under specific prompting conditions — can determine whether a specific individual was present in the training set and, in some cases, infer characteristics of that individual's record. The model hasn't stored the record. It has encoded patterns from it during training. Those patterns are queryable. This is not a theoretical attack vector — membership inference has been demonstrated on real models trained on real datasets, and it is an active area of regulatory concern at both the EDPB and national supervisory authority level. For European companies, this creates a specific additional problem. An organisation might correctly conclude that sending pseudonymised data to an external processor for conventional analytics is acceptable. Sending the same pseudonymised data to an AI model for training or fine-tuning is a materially different decision — because the model learns from the data in ways a conventional processor doesn't, and those learned patterns can be queried in ways that don't look like data access requests. The re-identification key doesn't need to be compromised. The model output can, under the right conditions, function as a partial re-identification mechanism — without any key ever leaving the organisation. What the November 2025 ECJ ruling actually says — and what it doesn't The European Court of Justice issued a ruling in November 2025 that clarified a specific scenario: pseudonymised data held by a recipient who does not have access to the re-identification key, and who cannot reasonably obtain it, may fall outside GDPR scope from that recipient's perspective. This ruling has been widely reported as a significant relaxation of the pseudonymisation standard. It is useful clarification. It is not the broad clearance it has sometimes been described as. The ruling applies to the recipient's position, not the sender's. The organisation sending pseudonymised data still holds the re-identification key. From the sending organisation's perspective, it is still processing personal data, and the transfer still requires a valid mechanism under GDPR Chapter V. The question of whether the recipient — the AI vendor — is processing personal data is a separate analysis that requires examining whether the vendor can reasonably obtain or derive the means to re-identify individuals. For major AI vendors with access to large external datasets, broad internet data, and models capable of cross-referencing patterns at scale, answering that question is not straightforward. A vendor that cannot access the specific organisation's re-identification key may nonetheless be capable of re-identifying individuals by cross-referencing the pseudonymised data with other sources in their possession. The ECJ ruling doesn't provide clearance in that scenario — it requires case-by-case analysis. The safe position for European companies is not to cite the November 2025 ruling as a blanket clearance for pseudonymised AI transfers. It is to conduct the case-by-case analysis the ruling prescribes — which requires understanding what external data the AI vendor has access to, what their re-identification capabilities are, and whether the specific pseudonymised dataset could reasonably be linked back to identifiable individuals by someone in the vendor's position. What this means in practice for European AI programmes The path forward is not to avoid AI models or to conclude that no data can be transferred. It is to be accurate about what has and hasn't been achieved. Pseudonymisation before data leaves the organisation is the correct technical control for reducing exposure when processing data on external AI models. It should be implemented properly — direct identifiers removed, re-identification key held on-premise and not transmitted, pseudonymisation applied consistently and auditably. It significantly reduces the impact of any disclosure event. It reduces but does not eliminate re-identification risk. What it does not do is remove the organisation's GDPR obligations. The transfer still requires a valid mechanism. The data still counts as personal data for GDPR purposes. The organisation still needs a lawful basis for the processing. These obligations persist alongside the pseudonymisation. For fine-tuning or training AI models on internal data, the additional membership inference risk needs to be part of the architecture decision — not assessed after the model is in production. The question of what personal data is in the training dataset, what patterns an attacker could derive from it, and what technical controls reduce the inference risk is an architecture question, not a post-deployment compliance question. What to take from thisAudit what your organisation actually does when it calls data "anonymous" before sending it to an AI model. In most cases, direct identifiers have been removed but the data remains pseudonymous. Update the data flow documentation accordingly — GDPR obligations follow from the accurate classification, not the assumed one. Treat pseudonymisation as risk reduction, not GDPR elimination. It is valuable and recommended under Article 32. It does not take data out of GDPR scope. Cross-border transfer mechanisms still apply. Do not cite the November 2025 ECJ ruling as a blanket clearance. It applies to recipients who genuinely cannot re-identify individuals. Establish whether your AI vendor meets that condition before relying on it — because a vendor with access to large external datasets may not. Include membership inference risk in AI architecture reviews. For any model trained or fine-tuned on internal data containing personal information, assess whether the model could be queried in ways that allow re-identification of individuals in the training set. Do this before the model is built, not after it's running. Keep the re-identification key on-premise. This sounds obvious. In practice, I have seen organisations pseudonymise data and then include a lookup table in the data package sent to the vendor — which converts pseudonymisation into a form of weak encryption rather than a genuine privacy control. Document the anonymisation or pseudonymisation process with enough detail to support a regulatory assessment. If a supervisory authority asks how the data was anonymised, the answer needs to be a documented process, not a verbal account of what the data team did six months ago.The word "anonymisation" has been in data governance policies for years as shorthand for "we processed the data carefully before sharing it." That shorthand has never fully survived GDPR scrutiny. It survives even less well when the sharing is with an AI model that learns from what it receives. The question isn't whether the organisation intended to comply with the regulation. The question is whether the data classification was accurate — and for most European enterprises running AI programmes, the honest answer is that it hasn't been tested against the standard that actually applies.

Read full article