EU AI Act Processing Sensitive Data for Bias Detection: Conditions After the Digital Omnibus on AI

What Article 10(5) allows and how it sits with GDPR

Article 10(5) of Regulation (EU) 2024/1689 lets providers of high-risk AI systems exceptionally process special categories of personal data, such as health, ethnicity or religion. The processing must be strictly necessary to ensure bias detection and correction under Article 10(2), points (f) and (g), and subject to appropriate safeguards for fundamental rights and freedoms.

The allowance does not replace data protection law. The conditions apply in addition to Regulation (EU) 2016/679, Regulation (EU) 2018/1725 and Directive (EU) 2016/680, as applicable, so GDPR Article 9 analysis remains part of the assessment. The text is also cumulative: all listed conditions must be met for the processing to occur. Recital 70 frames the purpose as protecting others from discrimination resulting from bias in AI systems, and treats the processing as a matter of substantial public interest once all applicable conditions are applied.

The conditions visible in the text are these. First, bias detection and correction cannot be effectively fulfilled by processing other data, including synthetic or anonymised data. Second, the data are subject to technical limitations on re-use and to state-of-the-art security and privacy-preserving measures, including pseudonymisation. Third, the data are protected with strict controls and documentation of access, so that only authorised persons have access, under appropriate confidentiality obligations. Fourth, the data are not transmitted, transferred or otherwise accessed by other parties.

What the Digital Omnibus on AI changed

Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, amends Regulation (EU) 2024/1689 as regards simplification of implementation of harmonised AI rules. It also amends Regulations (EU) 2018/1139 and (EU) 2023/1230. This is adopted law, not a pending proposal.

The relevant change is one of scope. Recital 9 states that bias detection and correction is a substantial public interest. It notes that the AI Act gives providers of high-risk AI systems a legal basis for exceptional processing under strict safeguards, and says the same interest justifies allowing processing, exceptionally and where strictly necessary, by providers and deployers of other AI systems and models and by deployers of high-risk AI systems. Deployers, who previously had no express footing in Article 10(5), are therefore within the stated intent.

Two practical points follow. The strictness test is unchanged in the recital: exceptional and strictly necessary. And the first step for any organisation is to determine whether it acts as a provider, a deployer of a high-risk system, or an operator of another AI system or model, then read its position against the amended article text.

A separate Commission Digital Omnibus proposal addresses a different problem: residual special-category data that appears during AI development and operation. Its text would require effective measures to avoid such data across the lifecycle, removal once identified, and protection against inference, disclosure or third-party availability where removal is disproportionate. That is avoidance and clean-up, not deliberate processing for bias correction, and it should not be treated as a substitute for the Article 10(5) conditions.

Mapping each safeguard to a control and an evidence artifact

The sources set conditions, not implementation methods. The mapping below is our interpretation of how each condition can be made enforceable and provable. Deletion and retention are included as good operational practice for sensitive datasets, and should be agreed with your data protection officer rather than read as separate text of Article 10(5).

• Necessity (condition a): Control: a gate that blocks use of special-category attributes until a documented decision exists. Evidence: a dated record of why synthetic or anonymised data was insufficient, with an approver.
• Pseudonymisation and re-use limits (condition b): Control: pseudonymised identifiers and purpose-bound use of the data. Evidence: pseudonymisation design record and a defined list of permitted uses.
• Access restriction (condition c): Control: identity-bound access limited to named roles. Evidence: the list of authorised persons and access records for each use.
• Confidentiality (condition c): Control: confidentiality obligations attached to every authorised person. Evidence: signed undertakings tied to the access list.
• No transfer or access by other parties (condition d): Control: blocking sensitive attributes from leaving the boundary, including to external models or tool endpoints. Evidence: decision records showing attributes blocked or redacted.
• Deletion and documentation: Control: scheduled removal of working copies and retention of processing records. Evidence: deletion confirmations and a version history of the rules applied.

Enforcing the conditions at runtime, not only in policy

A policy document states that sensitive attributes will be handled carefully. A regulator is more likely to ask what actually happened on a given date. That question is hardest to answer where AI interactions are involved, because sensitive attributes can appear in prompts, in model responses and in the arguments passed to tools.

Condition (d) shows the exposure clearly. If a prompt containing an ethnicity or health attribute is sent to an external model provider, or a tool call carries it to a third-party endpoint, access by another party may have occurred regardless of what the policy says. Controls therefore need to sit where the data moves, and need to be tied to identity so that condition (c) can be demonstrated.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. For individual interactions and tool calls it can allow, redact or block, and it can escalate for human approval. Applied to this topic, a rule can allow a named authorised role to use a sensitive attribute in an approved bias analysis, redact the attribute from everything else, and block it from reaching external tool calls. Each decision is enforced at runtime, not reviewed after the fact, and generates audit-ready evidence that can be mapped to EU AI Act documentation obligations. Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which matters when the evidence itself contains sensitive context.

What runtime enforcement does not cover

Runtime enforcement addresses the access, transfer and documentation conditions. It does not perform bias testing, and it does not establish dataset provenance or model lineage. Those remain with your data science, data governance and model risk functions. Nor does it make the necessity judgment for you: someone must decide, and record, that synthetic or anonymised data could not achieve the bias objective.

Deletion and retention schedules for the underlying datasets also sit in your data management processes, and the lawful-basis analysis under GDPR remains a legal task. The tradeoff to plan for is that tighter enforcement can interrupt analysts who need sensitive attributes. Define approved bias-analysis workflows and authorised roles in advance so that legitimate work is allowed and everything else is blocked or escalated.

For evaluation, ask of any approach whether it binds decisions to named identities, whether it can stop sensitive attributes leaving the boundary rather than only record that they did, whether the records are durable and retained under your own schedule, and whether it can show which rule version applied to a given event. Separate those answers from the work that must be done by other processes.