Fairness

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 optimised 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. Conduct a data representativeness assessment under Art. 10: confirm that 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 programmes are thin. Organisations 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.