GDPR Blocked Bias Testing. The June 2026 Fix, Explained

Here's a contradiction that sat unresolved in EU law for years, long enough that I assumed someone smarter than me had already found the loophole. To prove your model isn't discriminating against a protected group, you need data that identifies who's in that group, race, health status, sexual orientation, the "special category" data GDPR Article 9 locks down hardest. But GDPR also tells you not to collect that data unless you have a very specific, narrow reason to.

So the honest state of bias testing for a lot of teams was: you suspect your model treats one group differently, and you are legally barred from the exact dataset that would let you check.

Why this wasn't just a theoretical problem

You cannot fix what you cannot measure, and demographic bias is the textbook case of something you can only measure by having the demographic labels in the first place. A model can absolutely encode bias against a group without a single explicit "race" or "ethnicity" column anywhere near it, proxies leak through zip codes, names, purchase history, whatever correlates. Confirming that requires deliberately holding out a labeled sample and checking outcomes against it. Under a strict reading of GDPR, building that labeled sample was itself the violation you were trying to avoid causing downstream.

Teams dealt with this in one of two ways before June 2026: quietly not testing for it and hoping, or testing anyway and hoping nobody asked how the demographic labels got there. Neither is a good answer, and both were common.

What actually changed

On May 7, 2026, the EU Council and Parliament reached a provisional agreement on the "Digital Omnibus," the first package amending the AI Act. The relevant piece cleared a Parliament vote on June 16: Article 10 now spells out an explicit legal basis for processing special-category data, race, health, biometrics, sexual orientation, specifically for the purpose of detecting and correcting bias in an AI system.

That's the debiasing exception. It doesn't touch GDPR's general rule, GDPR Article 9 still locks that data down for every other purpose. It carves out one specific hole, shaped exactly like "I need this data to check if my model is unfair," and nothing wider than that.

The conditions attached, because of course there are conditions

The exception ships with real constraints, not a blank check:

• State-of-the-art security and privacy-preserving measures on the special-category data itself, not your normal production-tier security, the actual current best practice.
• Access restricted to authorized people, meaning this isn't a dataset that sits in a shared analytics warehouse everyone on the data team can query.
• Deletion once the bias is corrected, or sooner if possible. This is explicitly not a dataset you keep around "in case," it has a shelf life tied to the specific correction it was collected for.
• Ordinary GDPR data minimization and security obligations still apply on top of all this. The exception unlocks the ability to collect the data for this one purpose, it doesn't relax anything else about how carefully you have to handle it once you have it.

The European Parliament specifically added these safeguards on top of what was originally negotiated, which tells you the concern about this exception becoming a backdoor for collecting sensitive data under a debiasing pretext was taken seriously, not waved through.

What this actually means if you're building the thing

If you've been avoiding a fairness audit because you genuinely didn't have a legal path to the labeled data, that path now exists, narrowly, and with a paper trail requirement attached. In practice that looks like:

1. Document the purpose before you collect anything. "We are collecting X special-category field specifically to test for bias in Y system" needs to be written down before the data exists, not reconstructed afterward if someone asks.
2. Scope access hard. The people who can query this dataset should be a short, named list, not "the ML team" as a blanket group.
3. Actually delete it. Set a real deletion trigger tied to "bias corrected" or a hard date, whichever comes first, don't let it become permanent infrastructure because deleting things is annoying.
4. Keep everything else exactly as strict as before. This exception is a scalpel, not a general loosening of how your org handles sensitive data everywhere else.

The genuinely useful part of this amendment isn't that it makes bias testing easy. It's that it makes bias testing legal in a way that was previously a real gray area, which meant the teams most worried about liability were often the ones doing the least testing. That's backwards, and this closes the gap, at least for the EU.

FAQ

Does this mean I can now freely collect race, health, or biometric data if I say it's for bias testing?

No. The exception is narrow and conditioned: state-of-the-art security, restricted access, mandatory deletion once the bias is corrected, and every normal GDPR data minimization rule still applies on top. It's a specific legal basis for a specific purpose, not a general exemption from Article 9.

Was there really no legal way to test for AI bias before this amendment?

It was a genuine gray area rather than a flat prohibition, but a real one. GDPR Article 9's default posture toward special-category data made collecting the demographic labels needed for a rigorous bias audit legally risky, which pushed a lot of teams toward either not testing rigorously or testing without a clean legal basis for the data involved.

When did this actually take effect?

The provisional agreement landed May 7, 2026, and the relevant Article 10 changes cleared a European Parliament vote on June 16, 2026, as part of the Digital Omnibus package amending the AI Act.

Does this apply outside the EU?

The legal mechanism is specifically GDPR and the EU AI Act, so it's EU law. But the underlying design pattern, a purpose-scoped, access-restricted, deletion-bound exception for collecting sensitive data specifically to test for bias, is a reasonable template regardless of which jurisdiction's privacy law you're actually operating under.