Imagine you are the data protection officer (DPO) of a Dutch municipality. The Work and Income department uses a vendor's model to select social assistance files for review. After the Dutch Data Protection Authority (AP) report on the Tax Administration, the department wants to know whether the model selects residents with a migration background more often. The data analyst says: "I can only measure that if I know who has a migration background." Those data are not in the department's files. The country of birth of residents and their parents is in the Dutch Personal Records Database (BRP), but the municipality may in principle not use it for this purpose.
This is the dilemma of every discrimination test: to see whether a system disadvantages a group, you need to know who belongs to that group. Since 27 July 2026 the AI Act provides a legal basis for this. It is narrow, and it asks more than most summaries show.
In short
Data revealing ethnic origin, health or religion are special categories of personal data; processing them is prohibited unless an exception applies (Article 9 GDPR). The Dutch exceptions in the GDPR Implementation Act (UAVG) were not written for bias testing. Article 4a of the AI Act, inserted by Regulation (EU) 2026/1744 and in force since 27 July 2026, allows a municipality as deployer of an AI system to process such data, but only to the extent strictly necessary to detect and correct bias that affects fundamental rights or leads to prohibited discrimination, and only if six conditions are all met. The hardest: other data demonstrably do not suffice, and the data are not transmitted, transferred or otherwise accessed by other parties. Article 4a is a permission, not a duty. That you must be able to show your selection does not discriminate follows from the GDPR and the prohibition of discrimination.
Lesson 1: know which data are special, and which are not
Article 9(1) GDPR prohibits processing personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, and processing genetic data, biometric data for the purpose of uniquely identifying a person, data concerning health and data concerning sex life or sexual orientation.
Nationality and postcode are not on that list. Testing whether a model treats nationalities or neighbourhoods differently therefore needs, in principle, no Article 9 exception, but it does need an ordinary legal basis and a compatible purpose. That changes if you use those features precisely to infer origin: according to the Court of Justice, data from which sensitive information can be deduced through an intellectual operation also fall under Article 9 (OT, C-184/20). And such features can work as proxies. The Dutch student finance case showed this: according to the government statement of 1 March 2024, data on origin were not used, but students in neighbourhoods with many residents with a migration background had a higher chance of being checked, as did students living closer to their parents, while children of parents with a migration background often live closer by. The government called this indirect discrimination.
Migration background (the country of birth of a person or their parents) is not literally in Article 9, but it can reveal ethnic origin. In Article 25(b)(2°) UAVG the Dutch legislator uses the country of birth of the data subject, their parents or grandparents as one of the criteria for establishing whether someone belongs to an ethnic or cultural minority group. That indicates that such data can reveal ethnic origin. In our reading you should therefore treat migration background as special category data.
Lesson 2: Dutch law does not solve it
The UAVG has two exceptions that come close. Article 25 UAVG allows processing data on racial or ethnic origin for identification, to the extent unavoidable, or to give persons from an ethnic or cultural minority group a preferential position in order to remove or reduce actual disadvantages. In our reading a bias test is neither: it gives no one a preferential position.
Article 24 UAVG allows processing if it is necessary for scientific or historical research or statistical purposes with the safeguards of Article 89(1) GDPR, the research serves a general interest, asking for explicit consent is impossible or requires disproportionate effort, and privacy is not disproportionately harmed. That may fit in a single case, but it was written for research, not for continuously testing and adjusting a selection tool. Consent from residents is rarely a usable route for a municipality, because they depend on its decisions.
Lesson 3: Article 4a gives a municipality a narrow basis, through paragraph 2
Regulation (EU) 2026/1744 deleted Article 10(5) of the AI Act and inserted the legal basis as Article 4a, in Chapter I. This widened the circle of parties. Paragraph 1 applies only to providers of high-risk AI systems. Paragraph 2 applies to providers and deployers of other AI systems and models and to deployers of high-risk systems. A municipality that uses a vendor's model is a deployer and therefore falls under paragraph 2. Note: if the municipality itself makes a substantial modification to a high-risk system, for example by retraining the model to correct the bias, it may become the provider (Article 25(1)(b) AI Act), with all provider obligations that entails.
Article 4a works as the Union law basis for the exception in Article 9(2)(g) GDPR (recital 9). The GDPR continues to apply in full alongside it: you also need a legal basis under Article 6(1) GDPR, for a municipality usually point (e). And Article 4a does not regulate where the data come from; obtaining them, for example from the BRP, must also fit within the GDPR and the Dutch BRP Act.
Paragraph 2 has its own threshold. The processing must be strictly necessary to detect and correct bias that is likely to affect the health and safety of persons, have a negative impact on fundamental rights or lead to discrimination prohibited under Union law. Recital 9 of Regulation (EU) 2026/1744 gives the example of bias in admission or risk assessment tools used for applications for public permits or licences, which may restrict rights or in effect deny groups access to public services. In our reading, a selection tool for social assistance reviews fits that picture.
Two limits. Article 4a only concerns AI systems and models. A set of fixed decision rules that is not an AI system (see our article on the definition of an AI system) falls outside it; you are then left with the GDPR and the UAVG. And the basis covers only detecting and correcting bias, not any other use of the same data.
Lesson 4: start with the question whether it can be done without
The six conditions of paragraph 1 apply to the municipality through paragraph 2(b), all at once. The first is the most important: bias detection and correction cannot be effectively fulfilled by processing other data, including synthetic or anonymised data.
So first record what you can measure without special category data. For example: does the model work out differently per neighbourhood or age group, and which input features correlate with origin? The Dutch student finance follow-up shows another route: according to DUO, Statistics Netherlands (CBS) supplied data on the migration background of students, which were linked to DUO's data on the checking steps, after which the foundation Algorithm Audit analysed the linked data. That happened in 2024, before Article 4a existed. That route is not "other data" within the meaning of condition (a): special category data are processed there too, but by other parties and on their own legal basis, outside Article 4a. Ask whether such an analysis through CBS is possible for your tool, and under which conditions. If you rely on Article 4a, an external firm may not analyse the data itself (condition (d)). Only if you can show that none of those routes suffices does Article 4a come into view.
Lesson 5: the data stay inside the municipality
Condition (d) says that the special category data are not transmitted, transferred or otherwise accessed by other parties. That affects how many municipalities work. The model vendor cannot receive the origin data to adjust the model, and on the safe reading an external firm doing the test for you cannot access them either, not even as a processor (see below). What you can share are outcomes that are no longer personal data, such as totals per group that cannot be traced back to individuals.
Whether a processor, for example the party hosting your analysis environment, is also an "other party" has not been settled. The GDPR does not count a processor as a third party (Article 4(10) GDPR), but Article 4a speaks of other parties, not third parties. The safe reading is that no external party receives or can access the data. For hosting this means at least encryption under which the host has no access. If you depart from that, record why in the DPIA.
The other conditions are practical: technical limits on re-use and pseudonymisation (b), strict access controls with documentation and confidentiality (c), deletion once the bias has been corrected or the retention period ends, whichever comes first (e), and in the record of processing activities the reasons why the processing was strictly necessary and why other data did not suffice (f).
Lesson 6: Article 4a requires nothing, the test is still needed
Paragraph 2 ends by saying that it does not create an obligation to detect and correct bias. That does not mean you can sit still. That you must be able to show that a selection does not discriminate follows from the GDPR (lawfulness and fairness in Article 5(1)(a), accountability in Article 5(2) and Article 24) together with the prohibition of discrimination (Article 1 of the Dutch Constitution, Article 21 of the Charter). Testing is how you show it. The AP wrote about the Tax Administration that anyone using selection criteria must substantiate the distinction and test whether the outcome is unintentionally unfair, and that without that substantiation the processing quickly becomes discriminatory and therefore unlawful.
If the model is a high-risk system under Annex III, the AI Act adds to this. A deployer ensures that input data under its control are relevant and sufficiently representative (Article 26(4)), and a body governed by public law carries out a FRIA before first use (Article 27). Those duties apply from 2 December 2027. If the system was placed on the market or put into service before that date, they apply only after a significant change in its design. For systems intended to be used by public authorities, 2 August 2030 is in any case the latest date (Article 111(2)). Our article on AI for fraud signals in social assistance explains why such a selection tool falls under Annex III in our reading.
A DPIA remains necessary. Article 4a provides a legal basis, not a risk assessment, and processing origin data of a large part of your social assistance recipients is high-risk processing (Article 35(1) and (3)(b) GDPR). Also inform the data subjects about this processing (Articles 13 and 14 GDPR).
Also for banks and schools
A bank that uses a vendor's credit model is in the same position as the municipality: deployer, so paragraph 2. If the bank develops the model itself and it is a high-risk system for the creditworthiness of natural persons (Annex III, point 5(b)), the bank is the provider and the route also runs through paragraph 1, with its reference to the data requirements in Article 10(2)(f) and (g). A bank deploying such a system also carries out a FRIA (Article 27(1)). For a school or university using an AI system for admission or assessment, the same applies as for the municipality.
Clean up old references
Records of processing, DPIAs and policy documents that still refer to Article 10(5) of the AI Act have referred to a deleted provision since 27 July 2026. Replace those with Article 4a for current and new processing. Article 2(7) has been replaced too: where it left the GDPR unaffected "without prejudice to Article 10(5) and Article 59", it now says "without prejudice to Article 4a and Article 59".
What to do now
- List, per selection tool, the features you want to test on, and determine per feature whether it is special category data.
- Establish whether the tool is an AI system. If not, Article 4a does not apply.
- Record which test you can do without special category data, and whether an analysis through CBS is possible.
- If Article 4a is still needed: do the DPIA first, set up a closed environment that only authorised staff can access, and give the vendor only totals.
- Make the deletion moment a monitored deadline and include the justification in the record of processing.
- Want to see quickly which duties attach to your tool? Run the case check.
Frequently asked questions about special category data and bias testing
Sources
Newsletter
Every Tuesday, the AI Act week ahead in 5 minutes
A practical briefing on deadlines, new guidance and enforcement, so you know what matters this week. No spam and you can unsubscribe in one click.
Practical and short · No spam · One-click unsubscribe