The Decision Happens in Your System Architecture, Not Your Legal Docs. After the CJEU’s Single Resolution Board judgment, whether your AI training pipeline violates GDPR is no longer a question lawyers answer after the fact. It’s a question engineers answer when they design the system.
If your organization builds or deploys artificial intelligence — particularly in HR, workforce analytics, health-adjacent services, or behavioral platforms — the legal ground under your feet shifted recently, and most businesses haven’t noticed yet.
The Court of Justice of the European Union’s Single Resolution Board judgment didn’t introduce new rules exactly. What it did was clarify how existing GDPR rules apply to the way AI systems actually function. The practical result is significant: whether data processed during AI model training qualifies as personal data under the GDPR is no longer determined by what you labeled the dataset. It’s determined by what your system can do — and who can access what.
Identifiability, the court made clear, is an architectural property. Not a legal one.
The Assumption Most Teams Get Wrong
Teams building AI on top of data that includes special category information — health data, biometric data, data revealing political opinions or religious beliefs — tend to land in one of two places. Either they conclude the processing is too legally risky to proceed without extraordinary justification, or they conclude that hashing identifiers or stripping names solves the problem.
Both positions are wrong, and in practice, both expose organizations to unnecessary risk.
Pseudonymization — tokenizing records, hashing identifiers, removing names — is not a lawful basis for processing. It does not authorize anything. It is a risk-reduction technique. A useful one, but a technical measure, not a legal answer. Applying it aggressively is good practice and doesn’t trigger a new legal regime, but it doesn’t answer the fundamental question: can anyone in this system, using means realistically available to them, connect this data back to a real person?
That question determines everything. And the answer depends almost entirely on how the system is built.
Two Pathways. The One You End Up On Is an Engineering Decision.
The SRB ruling effectively describes two legitimate approaches to AI training on sensitive data. Which one applies to your organization isn’t something a lawyer decides after reviewing your documentation. It’s something your engineering team decides — often without realizing it — when they design data pipelines, configure access controls, and choose where to store encryption keys.
Pathway One: Make Identification Technically Impossible
The first approach is the cleaner of the two, but it demands genuine architectural discipline. The goal is a training environment that is structurally incapable of connecting model inputs back to real individuals — not just one where people are trusted not to do so.
In practice this means all identity resolution happens upstream, before data enters the training pipeline. One-way transformations — typically salted hashing — are applied in a preprocessing layer that the training system has no access to. The salt itself is stored outside the training environment entirely, either deleted after use or held in a separate trust domain the training system cannot reach. Once transformation is complete, raw identifiers are gone. They don’t exist in the training world.
Indirect identifiers require equal attention. Precise timestamps, rare feature combinations, high-cardinality attributes, and free-text fields can all reintroduce identifiability even after direct identifiers are removed. If a model can learn from a pattern, it doesn’t need that level of precision. Coarsening, aggregation, and selective suppression of outlier data points aren’t optional refinements — they’re what makes a claim of non-identifiability credible when a regulator examines it.
Access architecture matters just as much as data transformation. If the same engineers can reach both raw ingestion systems and training environments — organizationally or technically — the argument that identification is not realistically possible becomes difficult to sustain. Separation of duties isn’t a governance formality in this context. It’s a core component of the identifiability analysis itself.
When this pathway is implemented correctly, the training activity steps outside the practical scope of GDPR’s special category protections. The model is learning statistical relationships. It is not processing personal histories. The legal risk doesn’t disappear entirely — purpose limitation, compatibility assessments, and transfer controls still apply — but the core exposure is neutralized by design rather than managed by policy.
Most teams aim for this pathway. Far fewer actually achieve it. The failure modes are consistent: the salt lives in the same environment as the training code. The token vault is accessible from the training pipeline. Auxiliary datasets are kept available “for debugging” that would allow re-identification joins. Each of these choices reintroduces identifiability in ways that regulators — and the post-SRB framework — will treat as reasonably likely means of identification.
When that happens, the system is operating under the second pathway, whether the team intended it or not.
Pathway Two: Keep the Data Personal, Justify the Processing
The second approach isn’t a failure mode. It’s the honest acknowledgment that in many real-world AI systems, especially complex ones, eliminating identifiability entirely would destroy the utility that makes the system worth building. In those cases the data remains personal data even after pseudonymization, and the question shifts: can AI training on this data be justified under legitimate interest, even when the underlying data originated from special category processing?
After the SRB judgment, the answer can be yes — but only if the system is built in a way that actually supports that legal position.
Legitimate interest analysis rests on three things, and engineering determines the outcome on all three.
Necessity requires a concrete explanation of why the training data, in the form it takes, is required to achieve a specific, legitimate goal — improving accuracy, reducing bias, increasing robustness. Vague claims about making the model better won’t survive scrutiny. The design needs to be able to answer: why these features, why this level of granularity, and why synthetic data or a more anonymized alternative doesn’t produce equivalent results.
Safeguards are where most of the work lives. Pseudonymization remains essential even if it’s no longer decisive on its own. Encryption keys must be separated. Access must be tightly scoped. Training pipelines must be isolated from production systems. Critically, models must be designed and regularly tested to prevent memorization and resist membership inference attacks — scenarios where a model can effectively reproduce training records or confirm whether a specific individual’s data was used. If those vulnerabilities exist, the legitimate interest argument collapses.
Impact is the hardest concept to operationalize but the most consequential. Legitimate interest doesn’t ask whether the underlying data is sensitive in the abstract. It asks whether individuals are likely to be affected by how the model operates in practice. Models that produce aggregate or probabilistic outputs, and that cannot be used to make decisions about specific individuals, present materially lower risk than models generating individual-level insights tied to identifiable users. Engineers shape this directly through output design, model architecture, and use-case constraints.
Privacy-enhancing techniques — differential privacy, noise injection, federated learning, secure enclaves — are genuinely useful tools here, but only if they actually reduce the system’s capacity to identify or harm individuals. Deployed effectively, they strengthen the legitimate interest case. Deployed as a checklist item without meaningful impact on risk, they’re window dressing that won’t hold up under examination.
The Broader Point Most Organizations Are Missing
The SRB ruling tells us something that should change how legal and technical teams interact. Compliance is no longer something that gets applied to a finished system. It is either built into the system or it isn’t there.
When a legal team reviews an AI project after deployment and asks whether GDPR is satisfied, the honest answer depends on decisions that were already made months earlier — what access controls were configured, where keys are stored, whether the training environment can reach production data, how outputs are structured. The legal analysis doesn’t determine the outcome. It describes it.
For businesses operating AI systems at scale, the implication is direct. The engineering team needs to understand what identifiability means under current EU law and design against it deliberately. The legal team needs to be involved before system architecture is finalized, not after. And both teams need to agree on which pathway applies — because operating under pathway two while believing you’re in pathway one is the exact scenario most likely to produce a regulatory finding that surprises everyone.
The law has caught up with how systems actually work. The organizations that recognize that earliest will have a significant compliance advantage over those still treating data protection as a documentation exercise.
Your AI Systems May Already Have Exposure You Haven’t Mapped
The SRB ruling is EU-focused, but the principle — that compliance is determined by architecture, not policy documents — applies across CCPA, CPRA, HIPAA, and every major privacy framework your business operates under. If your organization uses AI tools, analytics platforms, behavioral tracking, or third-party data vendors, the likelihood is high that your current data flows don’t fully reflect your legal obligations.
We help businesses identify exactly where their exposure is and what it takes to close it — before a regulator does it for them. The consultation is free from our compliance superhero team just book a demo below to get started.
