Showing Posts From

European data

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
Sending European Data to US AI Models: The Risks That Outlast the Contract

Sending European Data to US AI Models: The Risks That Outlast the Contract

The legal team signed off. The data processing agreement is in place. Standard contractual clauses are attached to the vendor agreement. The European company is operating under the EU-US Data Privacy Framework. From a compliance documentation standpoint, the boxes are ticked. Three specific risks persist that none of those documents fix. This isn't an argument against using external AI models. European companies are running AI programmes on US-hosted infrastructure because those models are currently the most capable available, and the business case for using them is real. The argument here is narrower: the compliance documentation that most European companies have in place for cross-border AI data transfers is necessary but not sufficient. Understanding what it doesn't cover — and why — is the starting point for an honest risk assessment. What signing the contract actually achieves Standard contractual clauses (SCCs) create binding obligations on the data importer — the US-based AI vendor receiving European data. The vendor commits to handling the data in accordance with GDPR requirements, to notifying the European company of any requests from authorities, and to applying appropriate technical and organisational security measures. This is genuine legal protection. It creates enforceable obligations. It is also the minimum requirement for a cross-border transfer to be lawful under GDPR, not the complete solution. What SCCs do not do: they do not change the jurisdiction of the vendor's infrastructure. They do not change the legal obligations a US-incorporated company is subject to under US law. A US-incorporated AI vendor that receives a lawful demand from US law enforcement is subject to that demand whether or not it has signed an SCC with every European customer it serves. The SCC creates a contractual conflict — the vendor may be obliged to notify the European customer and resist disclosure where legally possible. It does not create a legal mechanism that overrides US law. The data processing agreement operates in the same space. It defines how the vendor handles the data, what it can do with it, what happens in a breach. It is a contract between two private parties. It cannot bind US law enforcement. The political fragility underneath current EU-US transfers The EU-US Data Privacy Framework (DPF) is the current mechanism that provides an adequacy basis for transfers of personal data from the EU to US companies that have self-certified under the framework. Most major US AI vendors have self-certified. This is what allows European companies to transfer data to those vendors without relying solely on SCCs. The DPF was adopted in July 2023. It is the third iteration of a transatlantic data transfer agreement. The first two — Safe Harbor and Privacy Shield — were both invalidated by the European Court of Justice, in 2015 and 2020 respectively. The conditions that produced those rulings — US surveillance laws, specifically FISA Section 702 and Executive Order 12333, which permit broad data collection on non-US persons — have not materially changed. The DPF was adopted alongside a US executive order (EO 14086) that introduced new redress mechanisms for EU data subjects, but whether those mechanisms are sufficient to satisfy the ECJ's adequacy requirements remains contested. A challenge to the DPF is already working through the European legal system. Privacy rights organisations have filed complaints in several EU member states. The pattern from Safe Harbor and Privacy Shield — challenge filed, referred to ECJ, adequacy decision struck down — is a known sequence. European companies whose entire cross-border transfer strategy depends on the DPF holding are carrying a risk they may not have quantified. The practical position: SCCs should be in place independently of the DPF, as a fallback mechanism. But SCCs alone don't resolve the structural issues the ECJ has identified in prior rulings — which brings us to the third problem. The US CLOUD Act: a structural gap no SCC closes The Clarifying Lawful Overseas Use of Data Act (CLOUD Act), enacted in 2018, allows US law enforcement to compel US-incorporated companies to produce data stored on their servers — regardless of where that data is physically stored. A US-based AI vendor with a data centre in Frankfurt is still subject to a CLOUD Act order for data held in that Frankfurt facility, because the obligation runs to the company, not to the data's location. This is not a theoretical risk or an unlikely scenario. It is the structural architecture of US data law. European companies that have negotiated data residency commitments from their US AI vendors — contractual guarantees that data stays in EU data centres — have obtained a meaningful operational control and a genuine security benefit. They have not obtained protection from CLOUD Act orders. SCCs require vendors to notify the European customer of government access requests and to resist such requests where legally possible. In practice, where US law enforcement has obtained a valid CLOUD Act order, the vendor's ability to resist is limited and the notification may be subject to a gag order that prevents it. The SCC provision exists; the real-world protection it provides against a valid CLOUD Act order is narrow. The only structural approach that avoids CLOUD Act exposure entirely is infrastructure that is not subject to US jurisdiction — EU-incorporated companies, with EU-domiciled infrastructure, and no US parent company with control over the entity. Several European AI infrastructure providers market this explicitly as a selling point for regulated industries. It is a legitimate differentiator for use cases where the CLOUD Act risk is assessed as unacceptable. What actually reduces exposure — and what just creates paperwork For European companies that need the capability of major US-hosted foundation models and have concluded the business case outweighs the residual risk, the realistic risk reduction available is a layered approach, not a single mechanism. The most practical technical control is pseudonymisation before data leaves the organisation. If the data reaching the AI model doesn't contain directly identifying information — names, identification numbers, email addresses, and other direct identifiers have been replaced with tokens, and the re-identification key stays on-premise — then what the vendor receives, and what any CLOUD Act order would compel them to produce, is pseudonymised data. Pseudonymised data is still personal data under GDPR, so this doesn't eliminate GDPR obligations. But it significantly reduces the impact of a disclosure event. Combined with this: SCCs in place as a fallback, a documented assessment of the DPF's continued validity as a transfer mechanism, a clear record of what data categories are permitted to enter the AI model and which are not, and a written acceptance of the residual CLOUD Act risk at the appropriate seniority level in the organisation. That last point matters. The risk assessment is not complete until someone with authority has reviewed and signed off on the residual risk — not because sign-off eliminates the risk, but because undocumented accepted risks are a different regulatory problem from documented ones. What doesn't reduce exposure: signing the SCC addendum in the vendor's standard contract pack without reading it; obtaining a data residency commitment without understanding it doesn't address CLOUD Act; and treating DPF certification as equivalent to a permanent adequacy finding. These create documentation. They don't close the exposure. What to take from thisHave SCCs in place as a baseline, but treat them as necessary rather than sufficient. Understand what they actually obligate the vendor to do and where US law creates limits on what those obligations can achieve. Assess the EU-US Data Privacy Framework as a risk position, not a permanent mechanism. Build SCCs as a fallback and document the contingency position for the scenario where the DPF is challenged successfully — which is not an unlikely scenario given the historical pattern. Understand that data residency commitments from US vendors do not provide CLOUD Act protection. A contractual guarantee that data stays in EU infrastructure is a meaningful operational control; it is not a jurisdictional change. Implement pseudonymisation before data exits the organisation for AI processing. This is the most practical technical control available for reducing the impact of any disclosure event — whether that's a CLOUD Act order, a vendor breach, or a DPF invalidation. Document the accepted residual risk at the appropriate executive level. A risk that has been assessed, quantified, and signed off by someone with authority is a different compliance position from a risk that has been ignored. Regulators distinguish between the two. For use cases where CLOUD Act exposure is genuinely unacceptable — particularly in regulated industries, defence-adjacent work, or cases involving highly sensitive personal data — evaluate EU-incorporated AI infrastructure providers as the structural answer, not a contractual workaround.Cross-border data transfers in AI are a live compliance question with no clean answers at present. The honest position is that European companies using US-hosted AI models are operating in a legal environment that is less stable than the documentation in their procurement files suggests. That's not a reason to stop — it's a reason to understand the actual risk clearly, document what has been accepted and why, and hold a position that survives scrutiny when examined. The organisations that have done that work are in a defensible position. The ones that assumed the vendor's standard agreement covered everything are not.

Read full article