Pillar 01 of seven
Fairness
Fairness means the system does not create unjustified disadvantage, most clearly systematically worse outcomes on the basis of protected characteristics. It is not identical treatment, but outcomes that can be justified and that hold up across the groups the system affects, with harmful bias in the data, the model, and the use of the output managed.
What it means
Fairness in an AI system is the property that the system does not produce systematically worse outcomes for people on the basis of characteristics that should not influence the decision. In the EU context this connects directly to non-discrimination law and to the EU AI Act's treatment of high-risk systems in employment, credit, and access to essential services. Fairness is not a single mathematical quantity. It is a contested concept with several formal definitions that can conflict with one another, and part of the AI Officer's job is to choose, document, and defend a definition appropriate to the use case.
The practical failure modes are well understood. A model trained on historical hiring decisions learns the historical bias in those decisions. A credit model using features correlated with protected characteristics reproduces discrimination even when the protected characteristic itself is excluded. A system optimized purely for accuracy will happily achieve that accuracy by performing well on the majority group and poorly on a minority, because the minority contributes little to the aggregate error. None of these failures announces itself. Each one requires deliberate testing to surface.
Why it matters
The consequences are concrete. A deployer of a high-risk hiring system that produces disparate impact faces both EU AI Act enforcement and a discrimination claim under separate law, and the second is often the more expensive. Beyond the legal exposure, fairness failures are reputationally radioactive in a way that few other governance failures are, because they translate easily into a story about a named individual harmed by an opaque machine.
Governing fairness
Fairness cannot be established once at deployment and assumed thereafter. The population the model serves shifts, the relationship between features and outcomes drifts, and a model that was balanced at launch can become skewed within months. Fairness controls must therefore operate continuously, not as a one-off pre-deployment certification.
| Control layer | Control |
|---|---|
| Preventive | Define and document the fairness criterion for each high-risk use case before development, including which groups are protected and which formal fairness definition applies. Assess the representativeness of the input data under your control (Art. 26(4)), and verify from the provider's Art. 10 data-governance documentation that the training and validation data adequately represents the affected population. Exclude proxy features that correlate with protected characteristics where they are not justified by the use case. |
| Preventive | Require a fairness section in every Fundamental Rights Impact Assessment (Art. 27) for systems in scope, signed off before deployment. |
| Detective | Run scheduled disparate-impact testing on live outcomes, broken down by protected group, at a defined frequency. Monitor for fairness drift by comparing current group-level performance against the deployment baseline. Maintain a complaints channel that lets affected individuals flag a suspected unfair outcome, and route those complaints into the monitoring process. |
| Corrective | Define a remediation path that is triggered when disparate impact exceeds the documented threshold: retraining, re-weighting, feature removal, or suspension of the system. Log every fairness incident, the analysis, and the action taken. Report serious cases through the incident process and, where the failure affected individuals, through the transparency and redress mechanisms. |
The detective layer is where most fairness programs are thin. Organizations conduct a pre-deployment bias test, file the result, and never test again. That satisfies a procurement checklist but not the underlying obligation, because the test result expires the moment the live population diverges from the test population. The control that matters is the scheduled one, not the one-off.
- PrincipleJustifiable, non-discriminatory treatment
- HarmSystematically worse outcomes for a protected group
- RiskLikelihood of bias, combined with its impact on those affected
- ControlBias testing on representative data + thresholds
- EvidenceTest results, data lineage, and a documented audit
* Article references are verified against the consolidated text of Regulation (EU) 2024/1689 and, where cited, Regulation (EU) 2016/679. The pillar itself is a general responsible-AI principle; these articles are where it anchors in EU law.
Fairness becomes real through controls that detect and bound unequal outcomes before they reach people, and evidence that the outcomes can be justified.
Set a policy on which decisions may be automated, define acceptable fairness bounds, and assign ownership for bias outcomes.
Test for bias on representative data before release and monitor outcome distributions across groups in operation.
An agent that screens, prices, or allocates can compound a small bias into many decisions before anyone reviews an outcome. Fairness shifts from checking one model to watching a stream of autonomous actions.
Require a fairness sign-off before an agent may act unattended on a protected group, and set the bounds it must stay inside.
Monitor group outcomes in near real time with automatic escalation when the agent drifts outside bounds, not a review after the fact.