European AI law contains a near-perfect catch-22 for any organisation trying to do bias work honestly. GDPR Article 9 prohibits, as a baseline, the processing of special categories of personal data: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data used for unique identification, health data, and data concerning sex life or sexual orientation. EU AI Act Article 10(1), in the very next breath, requires providers of high-risk AI systems to examine training, validation, and testing datasets for "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 under Union law." You cannot perform that examination across protected groups without processing protected-attribute data, and that data is what GDPR Article 9 generally locks down. Article 10(5) is the carve-out the AI Act gives you to escape the catch-22, but it is a narrow one. This lesson walks the carve-out word by word, names the strict-necessity test, lists the safeguards Article 10(5) requires you to document, runs a worked Annex III §4 employment example, and ends with the six common mistakes that turn the carve-out into a regulator finding.

The Puzzle - GDPR Article 9 Locks the Door That EU AI Act Article 10(1) Tells You to Walk Through

Read in isolation, GDPR Article 9(1) is one of the strictest provisions in EU data-protection law: "Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation shall be prohibited." Article 9(2) lists ten exceptions, explicit consent, employment / social-security law, vital interests, public-interest health, scientific research, substantial public interest under EU or Member State law, and so on, but the default posture is prohibition, and any exception must be lawful, necessary, proportionate, and accompanied by safeguards.

Read in isolation, EU AI Act Article 10(1) is just as strict in the opposite direction. Providers of high-risk AI systems (Article 6 plus Annex I or Annex III) must subject their training, validation, and testing datasets to "data governance and management practices appropriate for the intended purpose of the high-risk AI system," and those practices "shall concern in particular ... examination 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 under Union law, especially where data outputs influence inputs for future operations." The plain reading is unambiguous: you must look for protected-attribute bias, and "looking" means computing fairness metrics, which means processing protected-attribute data.

For an Annex III §4 employment system, an Annex III §5(b) creditworthiness system, an Annex III §5(c) life-or-health insurance pricing system, or an Annex III §6 law-enforcement system, the obligation under Article 10(1) is non-discretionary. There is no path to compliance that omits the bias-examination methodology, and there is no honest bias-examination methodology that omits protected-attribute analysis. The EU legislator knew this when drafting the AI Act. Article 10(5) is the deliberate, narrow bridge between Article 10(1) and GDPR Article 9.

The Carve-Out - Article 10(5) Text and Strict-Necessity Test

The full text of Article 10(5) in the consolidated EU AI Act reads: "To the extent that it is strictly necessary for the purposes of ensuring bias detection and correction in relation to the high-risk AI systems in accordance with paragraph (2), points (f) and (g) of this Article, the providers of such systems may exceptionally process special categories of personal data, subject to appropriate safeguards for the fundamental rights and freedoms of natural persons." The provision then enumerates a non-exhaustive list of required safeguards, which we walk in the next section.

Four operative words carry most of the legal weight: "strictly necessary," "exceptionally," "appropriate safeguards," and "in accordance with paragraph (2), points (f) and (g)." The cross-reference to Article 10(2)(f) and (g) anchors the bias-examination obligation to the carve-out. It is bias detection and correction work that earns the carve-out, not any other AI-development activity that happens to involve protected attributes. Use the protected-attribute data for anything else, and you are back inside GDPR Article 9's general prohibition with no AI Act bridge.

The strict-necessity test, as drafted and as elaborated by early Member State data-protection-authority guidance (CNIL France, BfDI Germany, AEPD Spain, Garante Italy, AP Netherlands have each published preliminary analyses through 2025-2026), has three operational prongs:

• Without the protected-attribute data, bias detection is impossible or substantially limited. The provider or deployer must be able to demonstrate that the fairness analysis required by Article 10(1) cannot be performed using non-protected-attribute data: that no statistical proxy, no sampling design, no synthetic-data approach achieves the bias-examination objective at comparable rigor.
• Less intrusive means have been considered first. The strict-necessity test borrows the proportionality logic from GDPR Article 5(1)(c) data minimisation: the provider must document that synthetic-data approaches, proxy attributes, sampling, differential privacy, or other less-intrusive alternatives were considered and either rejected (with reasoning) or layered in alongside the protected-attribute processing.
• Processing is limited to the minimum necessary. Only the protected attributes relevant to the bias examination, only the subset of the population needed for statistical power, only the retention period required for the analysis, only the bias-monitoring team accessing the data. The "minimum necessary" prong applies both to the categories of data and to the volume, scope, and duration.

The three prongs are cumulative. Failing any one of them collapses the Article 10(5) carve-out, and the processing becomes prohibited under GDPR Article 9(1), exposing the controller to the higher tier of GDPR fines (up to €20M or 4% of worldwide turnover under Article 83(5)(a)) in addition to the AI Act Article 99(3) penalty exposure (€15M or 3% per Article 26/27 failure).

Required Safeguards Under Article 10(5)

Article 10(5) enumerates "appropriate safeguards for the fundamental rights and freedoms of natural persons" and the recital text together with early Member State DPA guidance flesh out the operational expectations. The audit-defensible safeguard package contains the following elements, each of which the provider must document and the deployer must be able to evidence to a notified body, an external auditor under ISO/IEC 42001 Stage 2, or a national data-protection authority under Article 70 of the GDPR:

• Technical and organisational measures appropriate to the rights and freedoms. The phrasing tracks GDPR Article 32. In practice: encryption at rest and in transit; key management separated from the dataset; access controls with audit logging; security incident-response plan for the protected-attribute dataset specifically; testing and evaluation of the safeguards' effectiveness.
• Data minimisation. Only the protected attributes the bias examination genuinely requires, not the full Article 9 list "in case." Only the candidate / customer / patient population needed for statistical power, not the entire dataset. Only the time window required, not perpetual retention.
• Access controls limited to the bias-monitoring team. A named team with named individuals, role-based access control, multi-factor authentication, and access logs reviewed at a defined cadence. The bias-monitoring team is not the same team as the model-development team or the deployer's business operations team. The separation is operational and documented.
• Pseudonymisation or encryption where feasible. The protected-attribute dataset should be pseudonymised (per GDPR Article 4(5), separated from the primary identifiers via a key held under separate access controls) or encrypted in a way that limits the practical risk of re-identification beyond the bias-monitoring purpose.
• Retention limits aligned with the bias-monitoring purpose. The protected-attribute data is retained only as long as the bias-monitoring purpose requires, typically the duration of the model's deployment plus a defined audit-tail period. A retention schedule is documented, and deletion is evidenced.
• Documentation of the necessity assessment. The strict-necessity test (above) is documented in writing, dated, signed by the data-protection officer (where the GDPR Article 37 DPO requirement applies) or equivalent senior data-governance role, and refreshed on substantial changes to the model, the dataset, or the legal context.
• Re-use restrictions. The protected-attribute data may not be re-used for any purpose other than bias detection and correction. Marketing, customer segmentation, pricing, operational analytics, all excluded. The re-use restriction is documented, contractually flowed down to any processors, and technically enforced where feasible.

The safeguard package is what an external auditor reads against ISO/IEC 42001 Annex A.7 data-governance controls and what a CNIL or BfDI inspection would test. Skipping the documentation does not mean the safeguards are absent: but it means the controller cannot demonstrate them, and the burden of proof under both GDPR (Article 5(2) accountability) and the AI Act (Article 16 provider obligations, Article 26 deployer obligations) sits squarely on the controller.

Worked Example - Annex III §4 Employment System Monitoring Sex, Race, and Age Disparate Impact

Acme Talent Acquisition AI is an Annex III §4 high-risk system used by an EU-headquartered employer with operations in France, Germany, Spain, and Italy to screen candidates for a high-volume sales role. Following the lesson 017 fairness-metric-selection memo, the deployer commits to the four-fifths rule as compliance threshold (EEOC + NYC LL 144 alignment for U.S. operations; useful proxy under EU non-discrimination directives for EU operations) and equalized odds as operational quality target. To compute either metric across sex, race / ethnicity, and age bands, the deployer must process special-category data. Walk the Article 10(5) carve-out application.

Step 1 - Lawful basis stack under GDPR. The Article 10(5) AI Act carve-out is a permission to process special-category data under the AI Act, but the deployer still needs a GDPR lawful basis at Article 6 plus an Article 9(2) exception. The defensible stack for the worked example, refined by Member State variation:

• Article 6(1)(c), legal obligation, where a Member State law mandates equality monitoring (e.g., the French Code du travail Article L1132-1 anti-discrimination obligations with associated monitoring expectations; the UK Equality Act 2010 §149 public-sector equality duty as influential analogue; certain German collective-bargaining frameworks). Where mandated monitoring applies, Article 6(1)(c) supplies the lawful basis and Article 9(2)(g) substantial public interest under Member State law supplies the special-category exception.
• Article 6(1)(a) + Article 9(2)(a), explicit consent from candidates. Candidate-supplied demographic data with a clear, granular, withdrawable consent specifically for bias-monitoring purposes. CNIL guidance (October 2024 update on AI-system data governance) treats consent as appropriate where the employer-candidate power imbalance can be mitigated (e.g., demographic data collected post-application, decoupled from the hiring decision, with a clear non-impact statement).
• Article 9(2)(j), scientific research / public interest, only where the bias-monitoring work is structured as a research programme with the additional Article 89 safeguards. Less defensible for routine deployer monitoring; more defensible for provider-side dataset evaluation prior to placing on the market.

The deployer's data-protection officer documents the lawful-basis stack in the FRIA Section 4 (specific risks) and Section 5 (oversight) and refreshes on substantial changes.

Step 2 - Storage and access architecture. The candidate-supplied demographic data (sex M/F/NB; race / ethnicity 5 categories; age band) is stored in a dedicated bias-monitoring database, physically and logically separated from the primary HR system. The bias-monitoring database is encrypted at rest with keys managed by the data-protection function (not the HR function). Access is limited to a three-person bias-monitoring team: the lead data scientist, the AI Officer team's fairness specialist, and the external auditor for the annual independent bias audit (NYC LL 144 in the U.S. operations; not legally required in the EU, but adopted as audit-defensible practice). Access logs are reviewed monthly; anomalies trigger a security incident.

Step 3 - Bias-examination workflow. The bias-monitoring team computes the chosen fairness metrics (four-fifths rule + equalized odds) on a quarterly cadence, with triggered recomputation on model updates or candidate-pool shifts. Results are reported to the AI Governance Committee in summary form (selection-rate ratios, equalized-odds disparities), not in row-level detail. Where a metric breach is identified, the bias-monitoring team works with the model-development team on remediation (threshold adjustment, training-data rebalancing, model retraining), and the remediation work uses the protected-attribute data only to the extent the strict-necessity test continues to be satisfied.

Step 4 - Retention. The candidate-supplied demographic data is retained for the duration of the model's deployment plus a 36-month audit-tail period to support post-market monitoring under Article 72 and any litigation discovery. After the audit-tail expires, the data is deleted (not anonymised, deleted) and the deletion is evidenced. The retention schedule is documented in the FRIA Section 5 and the data-processing register.

Step 5 - FRIA integration. Section 4 (specific risks) names the fairness risks the bias monitoring addresses, cites the Article 10(5) carve-out and the strict-necessity assessment, and references the fairness-metric-selection memo. Section 5 (oversight) describes the bias-monitoring team, the access controls, the retention schedule, the refresh cadence, and the safeguard review process. The FRIA is notified to the national supervisory authority under Article 27(3).

Step 6 - Documentation package. The deployer maintains a written Article 10(5) necessity assessment (signed by the DPO), the safeguard documentation (technical and organisational measures), the lawful-basis-stack memo, the data-processing register entry, the access-control documentation, the retention schedule, the bias-monitoring team charter, and the quarterly bias-examination reports. The package is the artifact a CNIL inspection or a Stage 2 ISO/IEC 42001 audit would request first.

Member State Variation - Why "EU Compliance" Is Not Uniform

The Article 10(5) carve-out is harmonised at the AI Act level, but the GDPR Article 9(2) exceptions and the substantial-public-interest definitions (Article 9(2)(g)) are largely Member State law. The result is a federated landscape where the same Annex III §4 employment system, deployed in five EU Member States, may need five slightly different Article 10(5) documentation packages, each anchored in the local data-protection authority's guidance and the local employment-law overlay.

• France - CNIL. The Commission Nationale de l'Informatique et des Libertés issued a series of AI-system guidance documents in 2023-2025, including an October 2024 specific guidance on bias monitoring in HR-tech AI. CNIL's posture: explicit consent is workable for demographic data collected post-application; the Article 9(2)(g) substantial public interest route requires explicit Member State law authorisation. CNIL treats the Article 10(5) carve-out as available but expects rigorous strict-necessity documentation.
• Germany - BfDI plus Länder DPAs. The Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (federal-level for public-sector and federal-supervised private sectors) plus the sixteen Länder DPAs each have jurisdiction in different domains. The Düsseldorfer Kreis (the conference of German DPAs) has published joint positions on AI-system data governance through 2024-2025. German posture: skeptical of consent in employment contexts (power imbalance concerns), preferring Article 9(2)(b) employment law + collective-bargaining where applicable. Strict-necessity documentation expected to be detailed.
• Spain - AEPD. The Agencia Española de Protección de Datos issued a January 2024 guide on AI-system audits and a follow-up 2025 guidance specific to high-risk AI under the EU AI Act. AEPD posture: emphasises the proportionality assessment and the consideration of less-intrusive alternatives (synthetic data, proxy variables) before defaulting to protected-attribute processing.
• Italy - Garante. The Garante per la protezione dei dati personali has been one of the most enforcement-active DPAs in the AI space (recall the 2023 ChatGPT enforcement and the subsequent OpenAI fine in late 2024). Garante posture on Article 10(5): the strict-necessity assessment is the single most important document; absence or weakness of the assessment is treated as a substantive (not procedural) failure.
• Netherlands - AP. The Autoriteit Persoonsgegevens issued a 2024-2025 framework on AI-system data governance, with specific attention to bias monitoring in public-sector AI (post-SyRI ruling 2020 and post-childcare-benefits scandal). AP posture: emphasises the technical safeguards (pseudonymisation, encryption) and the access-control regime; expects evidenced log review.

Multi-jurisdiction deployers need to consult locally, and to maintain a per-Member-State annex to the Article 10(5) documentation package that captures the local DPA guidance and the local employment / consumer / sectoral overlay.

Cross-Walks - How Article 10(5) Sits in the Broader Compliance Stack

Article 10(5) is a single sub-provision of the AI Act, but it touches a wide regulatory surface. The audit-defensible documentation package cross-references the related obligations explicitly:

• GDPR Articles 5, 6, 9, 13, 14, 22, 32, 35. Article 5 lawfulness and minimisation; Article 6 lawful basis; Article 9 special-category prohibition with exceptions; Articles 13/14 transparency to data subjects; Article 22 automated decision-making rights; Article 32 security; Article 35 data protection impact assessment (DPIA), and the relationship between the DPIA and the AI Act FRIA is itself a documentation exercise.
• EU AI Act Articles 10(1), 10(2), 10(3), 10(4), 10(5), 26, 27, 27(3). Article 10(1)-(4) the data-governance obligations; 10(5) the special-category carve-out; Article 26 deployer obligations including the obligation to use the system in accordance with instructions; Article 27 FRIA; Article 27(3) notification to the supervisory authority.
• ISO/IEC 42001 Annex A.7 data governance. The control area against which a Stage 2 audit tests the data-governance evidence. Article 10(5) safeguard documentation is core to A.7 evidence.
• NIST AI RMF Govern 4 (governance roles) and Measure 2 (fairness evaluation). The cross-walk to the U.S. voluntary framework supports global organisations using NIST AI RMF as the management-system spine.
• The fairness-metric-selection memo (lesson 017). The Article 10(5) safeguard package is the operational substrate for the fairness-metric-selection memo's protected-attribute analysis. Without the safeguards, the memo's data is unlawfully processed; with the safeguards, the memo's data is the load-bearing artifact in the FRIA.

Six Common Article 10(5) Mistakes

Mistake 1 - Skipping the Strict-Necessity Assessment

The most common failure pattern is collecting protected-attribute data because "we need it for bias monitoring" without ever documenting the strict-necessity test in writing. Italian Garante enforcement posture in particular treats the absence of the necessity assessment as substantive. There is no presumption that bias monitoring inherently satisfies strict necessity. The assessment must be specific to the system, the population, the methodology, and the alternatives considered.

Mistake 2 - Collecting More Special-Category Data Than the Examination Requires

"Let's collect every Article 9 attribute in case we need it later" is the default of operations teams unused to GDPR rigour. The data-minimisation prong of the strict-necessity test prohibits exactly this. The bias-monitoring methodology determines the minimum data; collecting beyond that minimum collapses the Article 10(5) carve-out for the over-collected categories and re-engages the Article 9(1) prohibition.

Mistake 3 - Weak Access Controls on the Bias-Monitoring Dataset

If everyone in the data-science team can query the protected-attribute database, the access-control safeguard is absent regardless of what the policy document says. The bias-monitoring team is a named, scoped, audited set of individuals. Access logs are reviewed. Anomalies are escalated. Without the operating evidence of access discipline, the safeguard is documentation theatre.

Mistake 4 - No Retention Limits

Protected-attribute data retained "as long as the model exists" or "indefinitely for audit purposes" fails the proportionality test. The retention schedule must be tied to a specific purpose-driven duration, typically deployment duration plus a defined audit-tail (24-36 months is common). At the end of the schedule, the data is deleted and the deletion is evidenced. Anonymisation can substitute for deletion only where the anonymisation is genuine (not pseudonymisation).

Mistake 5 - Re-Using the Protected-Attribute Data for Other Purposes

Once the protected-attribute dataset exists, the temptation to use it for adjacent purposes, diversity reporting, ESG metrics, marketing segmentation, customer-experience research, is operationally strong. Every such re-use collapses the Article 10(5) carve-out (which is purpose-limited to bias detection and correction) and re-engages GDPR Article 9(1). The re-use restriction must be documented, contractually flowed down to processors, and technically enforced where feasible.

Mistake 6 - Treating "EU Compliance" as Uniform and Skipping Member State Overlay

The AI Act carve-out is harmonised; the GDPR Article 9(2) exceptions are mostly Member State law. A multi-jurisdiction deployer that maintains a single "EU compliance" package without the per-Member-State annex on CNIL / BfDI / AEPD / Garante / AP guidance will be defensible in some Member States and indefensible in others. The fix is operational: one Article 10(5) base package plus N Member State annexes, refreshed on local DPA guidance updates.

Key Takeaways

• Article 10(5) is the deliberate, narrow bridge between AI Act Article 10(1) bias-examination obligations and GDPR Article 9(1) special-category data prohibition. Without it, the bias examination required for high-risk AI systems would be largely impossible under EU law.
• The strict-necessity test has three cumulative prongs. Without protected-attribute data, bias detection is impossible or substantially limited; less intrusive means have been considered first; processing is limited to the minimum necessary.
• Required safeguards are enumerated and must be evidenced. Technical and organisational measures; data minimisation; access controls limited to the bias-monitoring team; pseudonymisation or encryption where feasible; retention limits; written necessity assessment; re-use restrictions.
• The Article 10(5) AI Act carve-out does not replace the GDPR lawful-basis stack. The deployer still needs Article 6 + Article 9(2) under GDPR, typically Article 6(1)(c) + Article 9(2)(g) where Member State law mandates monitoring, or Article 6(1)(a) + Article 9(2)(a) where consent is appropriate.
• The Annex III §4 employment worked example shows the operational pattern. Separate storage, separate access, named bias-monitoring team, quarterly recomputation, retention schedule, FRIA integration, signed necessity assessment.
• Member State variation is real. CNIL France, BfDI Germany, AEPD Spain, Garante Italy, AP Netherlands each have published guidance; multi-jurisdiction deployers need a per-Member-State annex.
• The cross-walk to GDPR Articles 5, 6, 9, 13, 14, 22, 32, 35 and to ISO/IEC 42001 Annex A.7 + NIST AI RMF Govern 4 / Measure 2 anchors the Article 10(5) package in the broader compliance stack. The fairness-metric-selection memo from lesson 017 sits on top of the Article 10(5) safeguards.
• The six common mistakes are operational, not exotic. Skipping the necessity assessment; over-collection; weak access controls; no retention limits; purpose creep; treating EU compliance as uniform.
• Failure cost is doubled. Collapsing the Article 10(5) carve-out exposes the controller to GDPR Article 83(5)(a) fines (€20M / 4%) plus AI Act Article 99(3) penalties (€15M / 3% per Article 26/27 failure).
• The Article 10(5) documentation package is the artifact a CNIL inspection or a Stage 2 ISO/IEC 42001 audit would request first. Build it once, refresh it on substantial changes, evidence it operationally.