Where AI bias comes from, how it is measured, and how it is treated — the bias vocabulary behind ISO/IEC 42001's fairness work
ISO/IEC 42001 requires you to address fairness and unwanted bias, but it does not tell you what bias actually is or where it hides. ISO/IEC TR 24027:2021 is the reference that does. It catalogs the sources of unwanted bias across an AI system, the metrics used to measure fairness, and the strategies for treating bias throughout the lifecycle. Read alongside ISO/IEC 42001, it turns a fairness requirement into a concrete map of what to look for.
Note that ISO/IEC TR 24027 is a Technical Report, not a certifiable standard. It is descriptive — a shared account of current practice that an organization preparing for ISO/IEC 42001 certification draws on when it implements fairness-related controls.
Scope note
This overview is based on the published text of ISO/IEC TR 24027:2021, read alongside ISO/IEC 42001:2023. Where a term could be ambiguous, the standard's wording is used. For formal citation or document submission, refer to the official standard text.
What is ISO/IEC TR 24027?
ISO/IEC TR 24027:2021 is the international Technical Report on bias in AI systems and in AI-aided decision making, published by ISO/IEC JTC 1/SC 42. It applies to any organization that develops, provides, or uses AI, or that uses AI to help make decisions. Its purpose is to articulate current practice for detecting and treating bias, whatever its source.
The report is organized around four questions — what bias and fairness are, where unwanted bias comes from, how it is measured, and how it is treated:
- Overview of bias and fairness (Clause 5) — what "bias" means in an AI context, and how it relates to "fairness."
- Sources of unwanted bias (Clause 6) — a catalog of where bias enters, grouped into human cognitive bias, data bias, and bias introduced by engineering decisions.
- Assessment (Clause 7) — the fairness metrics used to measure bias, built on the confusion matrix.
- Treatment (Clause 8) — strategies for addressing unwanted bias at each stage of the AI system lifecycle.
Three informative annexes support the body: worked examples of bias, a list of related open-source tools, and a mapping example against ISO 26000 (social responsibility).
Key point 1 — Not all bias is unwanted
The word "bias" carries a negative charge in everyday use, but ISO/IEC TR 24027 works from a more precise distinction. Some bias is intended: a system is deliberately tuned toward the outcomes its objectives call for, and that is desired bias. Bias that is not intended in the objectives — that the system reflects, amplifies, or newly creates without anyone choosing it — is unwanted bias, and that is what the report addresses.
This matters because it reframes the goal. The aim is not to remove all bias, which is neither possible nor desirable, but to identify and treat the bias no one intended. An AI system that learns patterns from data can reflect existing societal bias against groups, and it can perpetuate that bias, amplify it, or generate new bias of its own. Naming which bias is unwanted is the first governance decision, not a technical afterthought.
Key point 2 — Bias enters from people, data, and engineering — not just "bad data"
A common assumption is that AI bias is a data-quality problem. ISO/IEC TR 24027 shows it is broader than that, cataloging sources in three families:
- Human cognitive bias — bias that stakeholders bring to the system. It includes automation bias (over-trusting the machine's output), group attribution and in-group bias, implicit and confirmation bias, out-group homogeneity bias, and societal bias, as well as bias baked into rule-based system design or into how requirements were framed.
- Data bias — bias inherent in the datasets. It includes statistical bias, problems in labels and the labeling process, non-representative sampling, missing features and labels, artifacts of data processing and aggregation, Simpson's paradox, and bias arising from distributed training.
- Engineering-decision bias — bias introduced by choices made while building the model: feature engineering, algorithm selection, hyperparameter tuning, and the way models are combined or interact.
The practical consequence is that a fairness effort limited to cleaning the training data will miss two-thirds of the picture. Bias introduced by a human framing of the problem, or by an engineering trade-off made for accuracy, is just as real and often harder to see.
Key point 3 — Fairness is measured, and the metrics can conflict
To move from "seems fair" to something testable, ISO/IEC TR 24027 sets out metrics for assessing bias and fairness, most of them derived from the confusion matrix — the table of correct and incorrect predictions broken down by outcome. From it come measures such as demographic parity, equalized odds, equality of opportunity, and predictive equality, each comparing how the system behaves across the groups of interest.
The subtle point is that these are different definitions of fairness, and they can pull in different directions. Satisfying one criterion can make another impossible to satisfy at the same time, so an organization generally cannot maximize every fairness metric at once. Which definition of fairness applies to a given use is therefore a decision the organization has to make and justify — it depends on the context, the affected groups, and the relative cost of different kinds of error. There is no single "fairness score" that settles it.
Key point 4 — Treating bias is a lifecycle activity, not a one-time check
ISO/IEC TR 24027 places treatment across the whole AI system lifecycle (Clause 8) rather than at a single checkpoint:
- Inception — set external and internal requirements, bring in trans-disciplinary expertise, identify stakeholders, select and document data sources, and define acceptance criteria for bias and fairness before building starts.
- Design and development — attend to data representation and labeling, training and tuning, adversarial methods for mitigating bias, and unwanted bias in rule-based components.
- Verification and validation — static analysis of training data, sample checks of labels, internal and external validity testing, user testing, and exploratory testing.
- Deployment — continuous monitoring and validation, supported by transparency tools, because a system's bias profile can shift once it is in use.
The through-line is that bias treatment is a repeated activity. As data, models, and the operating environment change, bias that was absent at launch can appear later — which is why the report ties treatment to monitoring rather than to a pre-launch sign-off.
How it connects to ISO/IEC 42001
ISO/IEC TR 24027 supplies the substance behind the fairness elements of ISO/IEC 42001:
- ISO/IEC 42001's Annex A includes controls directed at fairness and at the impact of AI on individuals and society. Implementing them concretely requires an account of what bias is and where it comes from — which is exactly what ISO/IEC TR 24027 provides.
- Its bias sources and fairness metrics feed the AI risk work under ISO/IEC 42001 Clause 6.1, operationalized by ISO/IEC 23894 — where "fairness" is one of the AI-related risk objectives to examine.
- Its individual-and-society framing connects to the ISO/IEC 42005 impact assessment, which develops that axis into a formal procedure.
- For classification and regression machine learning specifically, the treatment strategies here are made concrete by ISO/IEC TS 12791, which is built directly on this report.
From an audit perspective — points to watch
Bias and fairness are among the harder areas of AI governance to evidence, because "fair" has to be defined before it can be shown. The gaps that can surface include the following. (These are situations that can arise in practice, not assertions of frequency.)
- Treating fairness as a data problem only — the cognitive and engineering sources of bias are not considered, so the analysis is incomplete by construction.
- No chosen fairness metric — the system is described as "fair" with no defined measure and no rationale for why that measure fits the use, so the claim is not testable.
- A single pre-launch check — bias was assessed once before deployment, with no monitoring for the drift that can reintroduce it.
- The affected group is not analyzed — the group that benefits and the group that bears the negative outcome may not be the same, and that distinction is easy to overlook.
In an audit, you would typically be asked to show not just that bias was considered, but which fairness criterion was chosen, why it fits the context, and what records demonstrate that treatment and monitoring have actually run.
Putting it into practice — where to start
Starting points by situation:
- An organization mapping bias for the first time — use the three source families (human, data, engineering) as a checklist against your own systems, and record where bias could plausibly enter each one.
- An organization preparing for ISO/IEC 42001 certification — choose and justify a fairness metric appropriate to each use, connect the treatment steps to the relevant Annex A controls and to your risk register, and, for classification and regression models, apply the concrete techniques in ISO/IEC TS 12791.
To see where this sits in the wider portfolio, the ISO/IEC AI Standards Map lays out the SC 42 standards by category on a single page.
Key terms at a glance
| Term | Meaning |
|---|---|
| desired bias | Bias intended by the system's objectives — a deliberate tilt toward the outcomes the system is meant to produce. |
| unwanted bias | Bias not intended in the objectives, which the system reflects, amplifies, or newly creates. The target of the report. |
| fairness | The property assessed by comparing how a system behaves across the groups of interest; measurable in several non-equivalent ways. |
| demographic parity | A fairness measure asking whether a favorable outcome is assigned at similar rates across groups. |
| equalized odds | A fairness measure asking whether error rates (such as true-positive and false-positive rates) are similar across groups. |
| protected attribute | A characteristic (such as those tied to a group) with respect to which unwanted bias is a concern. |
The bottom line
ISO/IEC TR 24027:2021 is the shared vocabulary of AI bias. It certifies nothing, but it turns "make it fair" into a concrete map: where bias comes from — people, data, and engineering — how fairness is measured, and how bias is treated across the lifecycle. Two points carry the most weight. First, the goal is to treat unwanted bias, not all bias, which means naming what is unwanted comes first. Second, fairness has no single definition; choosing the right one for a given use is a governance decision the organization must make and defend. It is the reference ISO/IEC 23894 points to for fairness, and the foundation on which ISO/IEC TS 12791 builds its treatment techniques.
Next in this series: ISO/IEC TS 12791:2024 — Treatment of Unwanted Bias in Classification and Regression Machine Learning Tasks, the technique layer that puts this report into practice for those ML tasks.
📚 SC 42 AI Standards Series
← Previous: ISO/IEC 23894:2023 — Guidance on AI Risk Management
📍 Current: ISO/IEC TR 24027:2021 — Bias in AI Systems and AI-aided Decision Making
→ Next: ISO/IEC TS 12791:2024 — Treatment of Unwanted Bias in Classification and Regression ML Tasks