Why bias detection creates a data protection problem
Testing an AI system for discriminatory bias requires knowing who the system is discriminating against. To find out whether a recruitment model rejects applicants of a particular ethnic origin, you need data about ethnic origin. That is precisely the data Article 9(1) of the GDPR prohibits processing, subject to narrow derogations.
This is a genuine bind, and until recently it had no clean answer: one body of law told companies to eliminate bias, another that they could not collect the data needed to measure it. The Digital Omnibus on AI has now addressed it directly by inserting a new Article 4a into the AI Act. Any Swedish company building or deploying AI that touches people should understand what it permits, because the permission is real but narrow.
What Article 4a is and where it came from
Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026. Among its changes it deleted Article 10(5) of the AI Act and inserted a new Article 4a, headed “Processing of special categories of personal data for bias detection and correction”. Article 10 now runs 1, 2, 3, 4, 6.
The relocation is significant. Article 10 sits in Chapter III and applies only to high-risk AI systems, while Article 4a sits in Chapter I among the general provisions. Moving the legal basis out of the high-risk chapter is what allowed the legislature to extend it beyond high-risk providers. The Omnibus also rewrote Article 2(7), the provision stating that the AI Act does not affect the GDPR, so that it now reads “without prejudice to Articles 4a and 59 of this Regulation”.
Omnibus recital 9 explains the reasoning. It states that “bias detection and correction constitute a substantial public interest because they protect natural persons from the adverse effects of biases, including discrimination”, and notes that biases “could also result from the actions of the deployers of high-risk AI systems” and “could also arise in the case of other AI systems or models”.
Who can rely on it
Article 4a has two paragraphs covering different populations. Paragraph 1 applies to providers of high-risk AI systems, allowing them to process special categories of personal data to the extent strictly necessary for bias detection and correction in accordance with Article 10(2), points (f) and (g). Paragraph 2 extends the same possibility to “providers and deployers of other AI systems and models and deployers of high-risk AI systems”.
Read together, they cover very nearly everyone. A provider of a high-risk system relies on paragraph 1. A bank deploying someone else’s high-risk credit model relies on paragraph 2, as does a company building an ordinary non-high-risk AI tool, or merely using one. That breadth is new, and it is the practical headline for most businesses.
Paragraph 2 is narrower in one respect. It requires the processing to be strictly necessary in view of possible biases “that are likely to affect the health and safety of persons, have a negative impact on fundamental rights or lead to discrimination prohibited pursuant to Union law”. The bias being looked for has to be of that seriousness.
The six conditions, and they apply to everyone
Article 4a(1) sets out six cumulative conditions, and Article 4a(2)(b) imports all of them by reference. Whichever paragraph a company relies on, all six must be satisfied.
Necessity and data minimisation
The first condition is that the bias detection and correction “cannot be effectively fulfilled by processing other data, including synthetic or anonymised data”. This is a genuine test, not a formality. If synthetic or anonymised data would do the job, the derogation is unavailable, and a company that has not seriously considered those alternatives has not met the condition.
Technical limitation and privacy-preserving measures
The second condition requires that the data be “subject to technical limitations on the re-use of personal data, and state-of-the-art security and privacy-preserving measures, including pseudonymisation”. Note that pseudonymisation is named as an example of what is required, not offered as an option.
Access control, no transmission, and deletion
The third condition requires measures ensuring the data are secured and protected, “including strict controls and documentation of the access, to avoid misuse and to ensure that only authorised persons have access to those personal data with appropriate confidentiality obligations”, so access logging is part of the condition rather than a nice-to-have. The fourth is absolute: the data “are not transmitted, transferred or otherwise accessed by other parties”. That rules out sending the dataset to an external bias-testing vendor, and needs checking against any cloud or processor arrangement before the work starts. The fifth requires deletion “once the bias has been corrected or the personal data has reached the end of its retention period, whichever comes first”.
Recording the reasons
The sixth condition is the one companies most often miss. The records of processing activities kept under the GDPR must include “the reasons why the processing of special categories of personal data was strictly necessary to detect and correct biases, and why that objective could not be achieved by processing other data”. The justification for the first condition has to be written into the Article 30 record. If it is not there, the condition is not met, however good the underlying reasoning was.
How it fits with the GDPR
Article 4a does not displace data protection law. Its first paragraph states that the conditions apply “in addition to the provisions set out in Regulations (EU) 2016/679 and (EU) 2018/1725 and Directive (EU) 2016/680, as applicable”. Everything the GDPR otherwise requires continues to apply in full, including a lawful basis under Article 6, transparency, data subject rights and a data protection impact assessment where the processing is likely to result in high risk.
The article itself does not name the GDPR gateway it operates through. Omnibus recital 9 does, stating that the basis is subject to the same limitations, conditions and safeguards as the former Article 10(5), “thereby ensuring compliance with Article 9(2), point (g) of Regulation (EU) 2016/679”. That is the substantial public interest route, which requires a basis in Union or Member State law. Article 4a supplies that basis, though the characterisation rests on the recital rather than on the article’s own wording.
Recital 9 adds a point that is easy to overlook: the basis established by Article 4a “should apply from the date of entry into application of that Regulation”, so providers can lawfully do bias detection work in preparation for compliance rather than waiting until their obligations bite.
A permission, not a duty
Article 4a(2) closes with a sentence that decides a great deal: “This paragraph does not create any obligation to conduct such bias detection and correction.” Both paragraphs are drafted permissively — providers and deployers “may exceptionally process” — and paragraph 2 creates no duty at all.
That is not the same as saying there is no duty anywhere. Providers of high-risk AI systems remain bound by Article 10(2)(f), which requires examination in view of possible biases, and by Article 10(2)(g), which requires “appropriate measures to detect, prevent and mitigate possible biases identified according to point (f)”. Neither point was amended. So a high-risk provider has an obligation to examine for bias and a permission to use special category data in doing so. Everyone else has the permission without the obligation.
The European Data Protection Board and the European Data Protection Supervisor flagged this in their Joint Opinion 1/2026 on the proposal, warning that the use of “may” in Article 4a(2) “is likely to give rise to legal uncertainty”. The final text went the other way and added the express no-obligation sentence, though several of their other recommendations were accepted: the proposal had used a weaker “necessary” standard, and the enacted text requires strict necessity throughout.
Practical example
A Swedish HR technology company sells a candidate-ranking tool to Nordic employers. Recruitment and worker management sit among the use cases listed in Annex III, so it expects to be a provider of a high-risk system when those rules apply from 2 December 2027. It wants to test whether its model ranks candidates differently by ethnic origin, but holds no ethnicity data and its data protection officer has always said it must not collect any.
Under Article 4a(1) it may do so, if it satisfies every condition. It first has to establish that synthetic or anonymised data would not answer the question, which is often true for bias testing but has to be documented rather than assumed. It then has to pseudonymise, restrict access to a named test team under confidentiality obligations, log that access, keep the data inside its own environment rather than sending it to the external fairness consultancy it had in mind, and delete it once the bias is corrected. Finally it has to record why the processing was strictly necessary. Its Nordic customers, as deployers, can run equivalent testing under Article 4a(2), on the same conditions.
Common mistakes companies make
The first is treating Article 4a as a general licence to collect sensitive data about customers or employees “for fairness purposes”. It is a narrow, purpose-bound derogation, and the necessity test comes first.
The second is forgetting that the GDPR still applies in full. Article 4a adds conditions; it removes none. Companies treating it as a self-contained regime miss the Article 6 basis, the transparency obligations and usually the impact assessment.
The third is involving a third party: one condition prohibits transmission, transfer or other access by other parties, directly at odds with the instinct to outsource bias auditing. The fourth is skipping the record-keeping condition, which an authority can check first and fastest.
The fifth is reading the permission as an obligation, or the reverse. Non-high-risk providers and deployers have no duty to test for bias under Article 4a. High-risk providers do have one, but it comes from Article 10(2).
Recommended actions
Before any bias testing that touches special categories of personal data, run the necessity analysis and write it down. Establish in writing why synthetic or anonymised data will not answer the question, because that document is both the first condition and half of the sixth. Then update the record of processing activities to carry the reasoning, and check that the data protection impact assessment covers the testing itself and not only the AI system.
Review the technical arrangements against the operational conditions before the data is collected rather than after. Confirm that no external adviser, consultancy or processor will have access to the special category data, and that a deletion trigger is built into the process rather than left to a calendar reminder. Providers of high-risk systems should document their Article 10(2)(f) and (g) work and their Article 4a justification together, since an authority looking at one will ask about the other.
Frequently asked questions
Does Article 4a mean we must test our AI systems for bias?
Not by itself. Article 4a is permissive, and its second paragraph states expressly that it does not create any obligation to conduct bias detection and correction. Providers of high-risk AI systems do have a duty to examine for and mitigate bias, but that duty comes from Article 10(2), points (f) and (g), which the Omnibus did not amend.
Can we send the data to an external bias auditor?
No. One of the conditions requires that the special categories of personal data are not transmitted, transferred or otherwise accessed by other parties, so an external audit involving the auditor accessing the data falls outside the derogation. Testing has to stay inside the organisation’s own controlled environment.
Do we still need a legal basis under the GDPR?
Yes. Article 4a applies in addition to the GDPR, the EU institutions’ data protection regulation and the Law Enforcement Directive. It supplies the Union-law element that the substantial public interest derogation in Article 9(2)(g) of the GDPR requires, but does not remove the need for an Article 6 basis or for compliance with the rest of the Regulation.
Conclusion
Article 4a resolves a real contradiction in EU law, and more generously than most companies realise: the permission now reaches deployers and non-high-risk systems, not only high-risk providers. But it is conditional, and the conditions are strict, cumulative and partly documentary. The organisations able to rely on it will be the ones that did the necessity analysis first, kept the data inside their own walls, and wrote the reasoning into their record of processing activities before anyone asked.
Lawgent helps businesses structure lawful bias testing of AI systems under Article 4a of the AI Act and the GDPR.
