# AI bias detection & mitigation under the EU AI Act > AI bias detection under the EU AI Act refers to the structured process of identifying, examining, and correcting systematic disparities in an AI system's training data and outputs that could lead to discrimination. For high-risk AI systems, this process is legally mandatory under Articles 10(2)(f) and 10(2)(g) of Regulation (EU) 2024/1689. **Author:** Maarten Stolk **Last reviewed:** 1 July 2026 **Source:** https://deeploy.ai/eu-ai-act-hub/articles/ai-bias-detection-mitigation-eu-ai-act/ Organisations that have deployed AI systems in consequential settings already suspect bias is a risk. The EU AI Act makes it a legal obligation to do something about it; systematically, documentably, and on an ongoing basis. Under the Act, providers of high-risk AI systems are required to examine their training data for bias, implement measures to detect and mitigate those biases, and maintain records of everything they find and do. This is not a one-off compliance exercise. The risk management framework under Article 9 explicitly requires bias monitoring to continue throughout the system's operational life, which means organisations must build ongoing processes, not just conduct a pre-launch audit. This guide explains what the regulation requires, what it does not require, which technical methods satisfy the obligation, and what compliance documentation should contain. It also addresses the harder problem that most guidance papers skip: what happens when a system that was unbiased at launch begins to behave in biased ways months later, because the world it is operating in has changed. The enforcement date for high-risk AI systems is 2 December 2027 for stand-alone systems listed in Annex III, under the Digital Omnibus provisional agreement reached in May 2026,  deferred from the original 2 August 2026 date. That window is narrower than it looks, and building a defensible bias programme from scratch takes time. ## The legal framework: Articles 10, 9, and 12 The EU AI Act's bias requirements are distributed across three articles that work together as a system. **Article 10: Data and data governance** Article 10 is the primary source of bias obligations for high-risk AI systems that use training data. Paragraph 2(f) requires providers to identify and examine biases that are likely to affect the fundamental rights of individuals or lead to discriminatory outcomes prohibited under EU law. Paragraph 2(g) then requires that "appropriate measures to detect, prevent and mitigate" those biases are implemented. These are two distinct obligations: examination and action. Identifying a potential bias and taking no remedial step does not satisfy Article 10. Article 10(5) contains an important and often overlooked provision: providers may, in exceptional circumstances, process special categories of personal data (including race, ethnicity, and health data) where this is strictly necessary for bias detection and correction. This is a narrow exception, not a general permission, and it comes with requirements for appropriate safeguards. **Article 9: Risk management system** Article 9 requires providers to establish a continuous risk management system that spans the full AI lifecycle; from design through deployment and beyond. Bias is a risk within the meaning of Article 9. Findings from Article 10 bias examinations should feed directly into the risk management process: logged, evaluated, mitigated, and reviewed again after mitigation. The risk management system must be updated as new information emerges from post-market monitoring. Bias that develops in production must be addressed within this framework. **Article 12: Record-keeping** Article 12 requires high-risk AI systems to automatically log events relevant to the system's operation. For bias compliance purposes, Article 12 intersects with the obligation to maintain an audit trail of bias testing, findings, mitigation steps, and re-testing outcomes. That trail is also required under Article 11 (technical documentation) and must be retained for ten years following market placement. **The GDPR intersection** Processing sensitive demographic data for bias testing sits at the boundary between the AI Act and GDPR. Article 9 GDPR sets conditions for processing special category data. Where those conditions are satisfied and bias detection is the genuine purpose, Article 10(5) of the AI Act provides a specific legal basis. Regulators have signalled that this exception will receive scrutiny: using sensitive data under the pretext of bias correction without genuine mitigation intent is likely to attract enforcement attention from both AI Act and data protection authorities. ## What the regulation actually requires: step by step The regulation sets out a structured sequence. Providers cannot skip straight to mitigation without completing the examination stage, and cannot treat examination as complete without documentation. **Step 1: Identify which demographic groups are relevant to your use case** Relevance is determined by the intended purpose and context of deployment. A hiring algorithm operating in a jurisdiction with a history of gender pay gaps must examine gender. A credit scoring model operating across diverse national markets must examine ethnicity and age. There is no universal list: the examination must be designed for the specific deployment context. **Step 2: Examine training, validation, and test data for bias** Article 10(2)(f) requires examination of data for biases that may affect the system's outputs in ways that breach fundamental rights. Practically, this means: - Measuring representation of protected demographic groups across the dataset - Identifying proxy variables; features that are not themselves protected characteristics but that correlate strongly with them (postcode as a proxy for ethnicity, for example) - Measuring outcome disparities across demographic groups in the existing dataset before any mitigation - Checking for label bias in historical data where the labels themselves reflect past discriminatory decisions **Step 3: Implement measures to detect, prevent and mitigate identified biases** Where the examination in Step 2 identifies biases, Article 10(2)(g) requires appropriate mitigation. The regulation does not specify which technical methods must be used; it requires that measures are appropriate to the findings. Common approaches are described in the technical methods section below. **Step 4: Re-test after mitigation** Mitigation without verification is not sufficient. After applying any bias correction technique, the system should be re-tested on the relevant fairness metrics to confirm that the targeted disparity has been reduced and that no new disparity has been introduced in the process. **Step 5: Document everything** Every step in this process must be documented in the technical documentation required under Article 11 and Annex IV. The documentation must be available to market surveillance authorities on request. It should cover: the demographic groups examined, the methodology used, the specific findings, the mitigation measures applied, the post-mitigation test results, and any residual bias that was accepted and why. ## Types of bias the EU AI Act is concerned with The regulation's core concern is with bias that leads to discrimination prohibited under EU law; most directly under the Charter of Fundamental Rights and the EU anti-discrimination directives. The protected characteristics most relevant to high-risk AI deployment include gender, racial or ethnic origin, age, disability, religion or belief, and sexual orientation. The Act does not enumerate a taxonomy of bias types, but compliance programmes typically distinguish between: **Data bias**: The training data does not accurately represent the population the system will affect. Historical datasets often reflect past human decisions that were themselves discriminatory. A model trained on ten years of hiring decisions made by managers who favoured men will embed that preference even if gender is not an explicit input feature. **Representation bias**: Certain demographic groups are substantially under-represented in training data, causing the model to perform less accurately for those groups in deployment. **Label bias**: The labels used to train a supervised model encode human judgements that were applied inconsistently across demographic groups. **Proxy bias**: A model learns to use features that are not protected characteristics themselves but that correlate with them. Postcode, name etymology, and device type can all function as proxies for ethnicity or socioeconomic status. **Measurement bias**: The instruments or processes used to collect data perform differently for different demographic groups, introducing systematic error before the model is trained. **Feedback loop bias**: A deployed model generates outputs that influence future training data. If the model already underperforms for a particular group, those individuals are affected in ways that then appear in the data the model is updated on, amplifying the original disparity. ## Technical detection methods The EU AI Act does not prescribe specific technical methods. The obligation is to use methods appropriate to the system's purpose, risk level, and deployment context. The following are the approaches that feature most commonly in compliance programmes. **Disaggregated performance evaluation** Model performance (accuracy, precision, recall, false positive rate, false negative rate) is measured separately for each relevant demographic group. The goal is to identify whether the model performs substantially worse for any group than for others. For high-stakes applications such as credit, employment, and medical risk assessment, even small accuracy disparities can have significant real-world consequences for affected individuals. **Fairness metrics** Formal fairness metrics operationalise different concepts of what it means for a model to behave equally across groups. Common metrics include: - _Demographic parity_: The proportion of positive outcomes should be similar across groups - _Equalised odds_: Both true positive rate and false positive rate should be similar across groups - _Equal opportunity_: True positive rate should be similar across groups (appropriate where the cost of false negatives is the primary concern) - _Calibration_: The model's confidence scores should be equally accurate for all groups It is technically impossible to satisfy all fairness metrics simultaneously in most real-world settings. Compliance programmes must make a reasoned choice about which metrics are most appropriate given the system's purpose and document that reasoning. **Counterfactual analysis** A specific individual's profile is tested with a protected characteristic altered while other features are held constant. If the model's output changes, the protected characteristic is influencing the outcome either directly or through proxy features. **Proxy feature identification** A separate analysis of the training data examines correlations between model features and protected characteristics. Features that correlate strongly with protected characteristics require scrutiny even if the correlation is not intuitively obvious. **Intersectional analysis** Bias may not appear in single-attribute analysis but emerge clearly when demographic groups are defined by intersecting characteristics (e.g. skin color, older disabled workers, young people from particular geographic areas etc). Article 10 does not explicitly require intersectional analysis, but risk-based reasoning suggests it is appropriate where the deployment context makes intersectional harm plausible. ## Bias mitigation strategies Detection without mitigation does not satisfy the regulation. Once bias has been identified, the provider must implement appropriate measures. The choice of mitigation strategy should be documented and justified. Common approaches fall into three categories by the stage of the pipeline they address. **Pre-processing: Addressing bias in training data** - Resampling: over-sampling under-represented groups or under-sampling over-represented groups to improve balance - Reweighting: assigning higher weights to training examples from under-represented groups - Data augmentation: generating additional training examples for under-represented groups through techniques such as SMOTE (Synthetic Minority Over-sampling Technique) - Removing proxy features: dropping features that carry strong correlation with protected characteristics where those features add little predictive value independent of the proxy relationship **In-processing: Adjusting the model during training** - Fairness constraints: adding regularisation terms to the training objective that penalise disparate treatment across demographic groups - Adversarial debiasing: training a secondary model to predict protected characteristics from the primary model's representations, and penalising the primary model when prediction succeeds - Reductions: reformulating the fairness-constrained learning problem as a sequence of cost-sensitive classification problems **Post-processing: Adjusting model outputs** - Threshold adjustment: applying different decision thresholds for different demographic groups to equalise a chosen fairness metric - Calibration: adjusting predicted probabilities to be equally reliable across groups Each of these approaches involves trade-offs between overall model performance and fairness performance. Those trade-offs must be documented and, where residual bias is accepted, the reasoning for that acceptance must be recorded. ## The post-deployment challenge: drift-induced bias This is the part that catches organisations out after they have completed a thorough pre-launch bias audit. Article 9(7) explicitly requires post-market monitoring throughout the AI system's lifecycle. The reason is not formality;  it is because bias is not a static property of a model. A system that performed fairly at launch can become systematically biased months later without any change to the model itself. The mechanism is data drift. The statistical distribution of real-world inputs shifts over time. Economic conditions change. Demographic patterns in the applicant population shift. External events alter how people interact with the system. If the training data was representative of conditions in 2022, the model's behaviour may diverge meaningfully from its tested performance by 2025. Drift-induced bias is particularly dangerous in high-risk domains because it is invisible without continuous monitoring. An organisation that audited thoroughly at launch and then moved on has no mechanism to detect this shift. By the time it appears in outcomes data, a substantial number of individuals may already have been affected. The compliance obligation is clear. Article 9 requires the risk management system to incorporate feedback from post-market data. Article 72 requires providers to actively and systematically collect and analyse data about system performance in deployment. For bias, this means tracking performance metrics disaggregated by demographic groups across the operational life of the system, not just at launch. In practice, this requires organisations to: - Maintain monitoring infrastructure that can apply bias metrics to production data on an ongoing basis - Define thresholds that trigger re-examination and potential re-training - Establish a documented process for acting on detected drift - Keep records of monitoring findings and any corrective actions taken The European Commission is expected to publish a template for post-market monitoring in 2026 that will specify required elements in more detail. In the meantime, the lifecycle monitoring obligation under Article 9 and Article 72 is already in force. ## What good documentation looks like Regulators examining Article 10 compliance will look for evidence that the bias programme was real (structured, executed, and recorded) rather than a document written after the fact to satisfy an audit. The technical documentation required under Article 11 and Annex IV should contain, at minimum: **Dataset documentation** - Description of training, validation, and test datasets - Data provenance and collection methodology - Demographic distribution across relevant protected characteristics - Identified gaps or imbalances and how they were addressed **Bias examination records** - Which demographic groups were examined and why - Which analysis methods were used - Quantitative findings: specific metrics, by group, with confidence intervals where applicable - Proxy features identified and how they were handled **Mitigation decisions** - Which mitigation techniques were applied and why those techniques were selected - Post-mitigation test results showing the effect of each intervention - Any residual bias accepted, with written justification **Ongoing monitoring records** - The monitoring methodology in use post-deployment - Metrics tracked, thresholds defined, and monitoring frequency - Any drift or performance degradation detected, and actions taken in response This documentation must be retained for ten years and must be available for inspection on request from national market surveillance authorities. ## Deeploy: Continuous bias monitoring in practice Getting the pre-launch audit right is one thing. The harder challenge is maintaining bias monitoring as a continuous operational function rather than a point-in-time exercise. Deeploy's platform integrates directly with deployed AI systems to monitor model behaviour in production, including disaggregated performance tracking across demographic groups. It surfaces distributional drift before it translates into degraded fairness outcomes, generates the audit trail required under Articles 11 and 12, and connects monitoring findings back to the risk management process required under Article 9. For organisations building towards the December 2027 deadline, Deeploy provides both the monitoring infrastructure and the documentation layer needed to demonstrate ongoing compliance; not just at the moment of conformity assessment, but throughout the system's operational life. ## Frequently asked questions ### How do I know if my AI system is high-risk within the EU AI Act? There are two routes to high-risk classification. Under Article 6(1), an AI system that is a safety component of a product covered by EU harmonised legislation (such as medical devices or machinery) is high-risk. Under Article 6(2), standalone AI systems listed in Annex III are high-risk. Annex III covers eight sectors: biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration and asylum, and administration of justice. ### Is our recruitment screening tool high-risk within the EU AI Act? Almost certainly yes. Annex III Point 4 covers AI systems used for recruitment, candidate selection, CV screening, task allocation, performance monitoring, and promotion or termination decisions. If your tool performs any of these functions, it falls within scope and is subject to the full high-risk requirements. ### What must our technical documentation include? Annex IV of the Act specifies eleven mandatory documentation elements, including: a general description of the system and its intended purpose; a description of the development process; details of training, validation, and testing data; the risk management measures applied; the human oversight measures built in; performance metrics and known limitations; and post-market monitoring arrangements. ### What is a Fundamental Rights Impact Assessment and when is it required? A Fundamental Rights Impact Assessment (FRIA) is a structured assessment of the impact of a high-risk AI system on fundamental rights, required under Article 27. It applies to deployers who are bodies governed by public law, or private entities providing public services such as banking, insurance, or education. It must be completed before the system is first put into use and updated if deployment conditions change materially. It is distinct from a DPIA but should be conducted in parallel where both apply. ### How does the EU AI Act interact with our existing GDPR compliance programme? The two frameworks are complementary and share significant infrastructure. Records of Processing Activities, DPIAs, data subject rights workflows, and consent management are all relevant to AI systems that process personal data. Organisations with mature GDPR programmes have a head start, but should not assume GDPR compliance equals EU AI Act compliance. The EU AI Act adds obligations that go beyond data protection, including risk management systems, human oversight requirements, and post-market monitoring that have no direct GDPR equivalent. ### What does post-market monitoring require in practice? Post-market monitoring is the ongoing obligation to track how a high-risk AI system performs once it is deployed. Under Article 72, providers must establish a post-market monitoring plan before deployment covering the metrics to be tracked, the data to be collected, the review frequency, and the conditions that would trigger corrective action or re-assessment. Deployers must monitor the system's operation and report relevant findings back to the provider.