EU AI Act Article 4a: When You May Use Special-Category Data to Detect Bias (Formerly Article 10(5))

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

What changed, and why it matters

Regulation (EU) 2026/1744 (the "Digital Omnibus on AI"), published in the Official Journal on 24 July 2026, amends the AI Act's Article 10 by replacing paragraph 1, deleting paragraph 5, and replacing paragraph 6, while inserting a new Article 4a that carries the bias-detection processing permission [7]. The AI Act Service Desk's consolidated text, current as at 27 July 2026, marks Article 10(5) "DELETED" and shows paragraphs 1 and 6 now cross-referencing Article 4a(1) instead [2]. One commentary on the change notes that Article 10(5) had never become applicable in practice before it was deleted and replaced [8].

The relocation is not a narrow renumbering. Article 4a(1) reproduces the former Article 10(5) conditions for providers of high-risk AI systems, tied to the bias duties in Article 10(2)(f) and (g) [1][2]. Article 4a(2) then widens who may rely on the same conditions: providers and deployers of AI systems and models that are not high-risk, and deployers (not only providers) of high-risk AI systems, may also process special-category data where strictly necessary for bias detection and correction tied to health and safety, fundamental rights or prohibited discrimination [1]. Article 4a(2) expressly states that it creates no obligation to conduct such bias detection and correction [1]. The full requirements for training, validation and testing data otherwise sit in the parent article; see our guide to Article 10 data governance for licensed training, validation and test data.

Three scoping points matter before anyone requests attributes:

• Who: under Article 4a(1), providers of high-risk AI systems. Under Article 4a(2), the same conditions also extend to deployers of high-risk AI systems and to providers and deployers of AI systems and models that are not high-risk [1]. General-purpose model providers are covered only to the extent they fall into one of those categories.
• What: the special categories defined in GDPR Article 9(1), such as racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic and biometric data used for identification, health, and sex life or sexual orientation [3]. Age and sex are not Article 9 categories, so they follow ordinary GDPR rules.
• When: the deletion of Article 10(5) and insertion of Article 4a took effect with Regulation (EU) 2026/1744, in force from the Official Journal publication date of 24 July 2026 [7]. Programs built around the old Article 10(5) citation should update their internal references and documentation to cite Article 4a going forward [2].

The six conditions in Article 4a(1)(a) to (f)

All six conditions apply cumulatively, in addition to the GDPR, the EUDPR and the Law Enforcement Directive [1]. The conditions are unchanged in substance from the former Article 10(5); only the article number and, for non-high-risk uses under Article 4a(2), the pool of addressees have changed.

Condition (d) creates the sharpest operational constraint for buyers. An external fairness-audit vendor, a labeling contractor or a cloud analytics tool that can read the attributes may count as "other parties" unless counsel concludes the arrangement is a controlled processor relationship that still satisfies the condition. Settle that question before a vendor is engaged, not after.

How Article 4a interacts with GDPR Article 9

Article 4a does not displace the GDPR; you still need an Article 6 lawful basis and an Article 9(2) condition for processing special-category data [3]. Whether Article 4a itself supplies the Article 9 condition, for example through the substantial public interest route in 9(2)(g), is debated, and counsel should take a documented position. Our glossary entry on lawful basis covers the Article 6 side.

Two GDPR points shape dataset strategy. First, Recital 26 places truly anonymous information outside data protection law, which is why condition (a) asks whether anonymized data would do the job [3]. Second, the EDPB's Opinion 28/2024 treats anonymity of models and data as a case-by-case question and stresses that unlawful processing during development can affect later use [4].

Do not plan around GDPR reform. Changes to the GDPR itself proposed in a separate "Digital Omnibus" package are a different proposal from Regulation (EU) 2026/1744, and should not be assumed in force without checking the current adoption status. For where sensitive attributes hide in operational records, see special category data in operational training datasets.

Why acquired training data rarely carries the attributes you need

Licensed operational data is usually de-identified before delivery, so the attributes needed for a group-fairness test are typically absent by design. A support-ticket corpus with names, emails and account numbers removed will not tell you a customer's ethnicity, and a well-run supplier should not have inferred it either. That is the correct outcome for privacy, but it leaves a gap for Article 10(2)(f) testing.

Teams usually close the gap in one of four ways:

1. Proxy analysis without special categories. Test for disparities by geography, language, product tier or channel, and check for stand-ins. Our guide to proxy variables in structured business data explains how to find them.
2. A dedicated evaluation set with consented attributes. A smaller, separately governed test set where attributes were collected with consent or another valid Article 9 condition, held in the controlled environment that Article 4a(1)(b) to (d) require.
3. Inference under Article 4a. Estimating attributes (for example, from names or locations) is itself processing of special-category data and needs the full necessity analysis. Inferred labels also carry error rates that can distort fairness metrics.
4. Aggregate statistics. Benchmarking dataset composition against published population statistics can test representativeness without any individual-level attribute.

Ask suppliers early whether source systems hold sensitive fields at all, and whether those fields were stripped, retained or never collected. A supplier's de-identification record tells you which route is realistic; our de-identification evidence package checklist lists what to request.

A necessity record you can file

The necessity record under Article 4a(1)(f) is the document most likely to be read by a market surveillance authority or notified body, so write it as a standalone decision. It should reference the specific dataset, the bias hypothesis, the alternatives tried and the safeguards applied. Keep it with the Annex IV dataset description [5].

Illustrative example: invented to show structure; it does not describe an available dataset.

art4a_necessity_record:
  record_id: BIAS-2027-004
  ai_system: "Credit-limit recommendation model v3 (Annex III, point 5(b))"
  dataset_ref: "DS-0412 licensed loan-servicing histories, de-identified"
  bias_hypothesis: "Approval-rate disparity by ethnic origin in training labels"
  art10_2_link: ["10(2)(f) examination", "10(2)(g) mitigation"]
  legal_basis_article: "Article 4a(1)"
  special_categories: ["racial or ethnic origin"]
  gdpr_basis: { art6: "to be confirmed by counsel", art9_2: "to be confirmed by counsel" }
  alternatives_assessed:
    - method: "geographic and language proxies"
      result: "disparity signal inconclusive; proxies explain under half of variance"
    - method: "synthetic attribute assignment"
      result: "cannot validate against real label distribution"
  why_strictly_necessary: "Group-level error rates cannot be measured without the attribute on held-out test records"
  safeguards:
    pseudonymization: "HMAC-SHA256 record keys; key held by privacy engineering"
    environment: "isolated evaluation workspace; no export; no third-party access"
    access_list: ["fairness-lead", "privacy-engineer-1"]
    access_logging: true
  deletion_trigger: "bias corrected and verified, or 2027-12-31, whichever first"
  deletion_evidence: "pending"
  approved_by: ["DPO", "responsible-AI lead"]

Mirror the same entry in your training data use register so the dataset's permitted uses and the sensitive-attribute workstream stay linked.

Documentation and retention traps

The biggest documentation risk is a conflict between the Article 4a(1)(e) deletion duty and the Article 18 duty to keep technical documentation for 10 years [6]. Resolve it by retaining the record of the processing, fairness metrics and deletion evidence, while deleting the special-category values themselves. Annex IV point 2(d) asks for a description of datasets and preparation steps, not the raw sensitive values [5].

Other common failure modes:

• Attributes leak into the training pipeline. If evaluation attributes join the training feature store, the reuse limits in (b) are breached and the model may learn the attribute directly.
• Fairness vendor access. Sharing attribute-level files with an outside auditor can conflict with (d).
• Stale retention. "Retain until no longer needed" fails (e); set a date or event trigger.
• License mismatch. A data license that limits use to model training may not cover evaluation joins with other sources; check the permitted-use clause and the supplier's DPA terms.
• Stale legal citations. Internal policies, DPIAs and vendor contracts that still cite "Article 10(5)" should be updated to cite Article 4a so reviewers are not checking a deleted provision [2].

For how long the rest of your records should live, see AI training data retention requirements, and for describing the evaluation set itself, see Annex IV technical documentation for datasets.

What to ask a data supplier before relying on Article 4a

The supplier questions that matter are about what sensitive fields existed, what happened to them and what the license lets you do in evaluation. Ask in the first diligence round:

• Did source systems hold any Article 9 categories, and were they removed, generalized or never collected?
• Which de-identification method was used, and was a sample checked?
• Does the license permit fairness evaluation, joining with your own consented evaluation data and retaining derived metrics after deletion?
• Can the supplier provide aggregate composition statistics (for example, regional distribution) without individual attributes?

SourceX sources operational datasets from US companies on request and rights-reviews each dataset for ownership and consents before it is delivered under a license that defines records, uses, term and delivery. Personal details such as names, emails, phones and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. If your bias program needs a clearer picture of source fields, you can describe your evaluation data requirements to SourceX. The broader framework is in our compliance hub for data buyers and the SourceX legal framework.

Sourcing data for fairness evaluation under Article 4a

SourceX sources operational datasets from US companies on request and manages licensing; every dataset is rights-reviewed and delivered under a license defining records, uses, term and delivery. Nothing is contracted until a supplier agrees, and a request does not guarantee a match. Describe the data you need for fairness testing.