How to actually treat unwanted bias in classification and regression models — the technique layer built on ISO/IEC TR 24027
If ISO/IEC TR 24027 tells you what bias is and where it comes from, ISO/IEC TS 12791:2024 tells you what to do about it. It is a set of good-practice measures and techniques for treating unwanted bias, scoped specifically to classification and regression machine learning (ML) tasks, and organized along the AI system lifecycle. Read together, the two standards join up: 24027 names the problem, 12791 supplies the treatment.
Note that ISO/IEC TS 12791 is a Technical Specification, not a certifiable standard. It deliberately leaves the organizational and management-system processes to ISO/IEC 42001, and builds its technical steps on the bias types of ISO/IEC TR 24027 and the AI lifecycle of ISO/IEC 22989 and ISO/IEC 5338.
Scope note
This overview is based on the published text of ISO/IEC TS 12791:2024, read alongside ISO/IEC TR 24027 and the AI system lifecycle of ISO/IEC 22989:2022 and ISO/IEC 5338: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 TS 12791?
ISO/IEC TS 12791:2024 is the international Technical Specification on treating unwanted bias in classification and regression ML tasks, published by ISO/IEC JTC 1/SC 42. It describes good-practice steps an organization can take to treat unwanted bias during the development or use of these ML systems. Three boundaries define it:
- It is built on ISO/IEC TR 24027. The types of bias it treats are the ones that report catalogs, and its treatment techniques are context-agnostic — the same measures apply regardless of the specific domain.
- It follows a defined lifecycle. The treatment steps are arranged along the AI system lifecycle of ISO/IEC 22989 and ISO/IEC 5338, so each measure attaches to a stage of the work.
- It stops at the management system. The document explicitly does not cover the organizational management and enabling processes of an AI management system — those belong to ISO/IEC 42001. It is the technique layer, not the governance layer.
Its scope is also narrow by design: the measures are for classification and regression ML tasks, and the specification does not claim they apply outside those tasks. Two informative annexes support the body: a map from lifecycle stages to the document's clauses, and an examination of how unwanted bias can affect different types of user.
Key point 1 — The scope is classification and regression, deliberately
ISO/IEC TS 12791 is precise about what it covers. Its measures are validated for two families of ML task: classification (assigning an input to a category) and regression (predicting a continuous value). It does not extend its claims to other kinds of AI, and it says so.
That precision is a feature, not a limitation. Bias mitigation techniques behave differently across task types, and a specification that promised to cover everything would have to be vaguer to do it. For an organization whose AI systems are classifiers or predictors — a large share of AI in production — this is the standard that speaks directly to the work. For systems outside that scope, its lifecycle logic still transfers even where its specific techniques do not.
Key point 2 — Bias treatment mapped to the lifecycle
The core of the specification (Clause 5) places treatment measures at each stage of the AI system lifecycle, so that treating bias is embedded in the process rather than bolted on:
Inception
Identify stakeholders and define their needs and requirements; carry bias requirements into procurement (important where a third-party or pre-trained model is involved); select and document data sources; integrate the work with risk management; and set acceptance criteria for bias and fairness before development begins. Setting the fairness bar up front is what gives every later step a target.
Design and development
Attend to feature representation, metadata sufficiency, and data annotations; adjust data where needed; and apply defined methods for managing the risks that have been identified.
Verification and validation
Combine static testing of the data used in development with dynamic testing of the trained system, so that both the inputs and the behavior are checked against the acceptance criteria.
Re-evaluation, continuous validation, and monitoring
Watch for external change — shifts in data or environment that can reintroduce bias after launch — and re-evaluate on that basis. As in the risk and lifecycle standards around it, the specification treats bias as something that can re-emerge, not something settled at release.
Disposal
Address the end of the system's life as its own stage, closing the lifecycle.
Key point 3 — Three families of treatment technique
Alongside the lifecycle measures, the specification gathers concrete techniques for reducing unwanted bias (Clause 6). In industry practice these are often grouped as pre-processing, in-processing, and post-processing — that is, acting on the data, on the training, or on the outputs. ISO/IEC TS 12791 presents them as:
- Algorithmic and training techniques — measures applied during model training, including specific attention to pre-trained models, which can carry bias inherited from their original training into a new system.
- Data techniques — measures applied to the data, such as adjusting representation and sampling so that the material the model learns from is less likely to encode unwanted bias.
The point is that treatment is not a single lever. Depending on where the bias originates and the constraints of the task, an organization may act on the data, on the training procedure, or on both — and a technique that helps one fairness measure can affect another, which is why the choice is tied back to the acceptance criteria set at inception.
Key point 4 — Bias in a distributed lifecycle
Modern AI is rarely built end-to-end by one team. A system may fine-tune a third-party pre-trained model, use externally sourced data, or combine components from several suppliers. ISO/IEC TS 12791 addresses this directly (Clause 7): when the lifecycle is distributed across parties, responsibility for treating bias is distributed too.
This is where the procurement and pre-trained-model threads from earlier converge. If bias can be inherited from an upstream model or dataset, then bias requirements have to travel up the supply chain — into contracts, into documentation requests, and into the acceptance criteria applied to what a supplier delivers. Treating bias only within your own four walls leaves the inherited bias untouched.
How it connects to ISO/IEC 42001
ISO/IEC TS 12791 is the concrete technique layer beneath the fairness elements of ISO/IEC 42001, for classification and regression ML:
- Where ISO/IEC 42001's Annex A controls call for fairness and for managing AI's impact, ISO/IEC TS 12791 provides the actual measures and techniques that satisfy them for these ML tasks.
- It inherits its bias taxonomy from ISO/IEC TR 24027 and its lifecycle structure from ISO/IEC 5338 and ISO/IEC 22989, so it slots into the same lifecycle an ISO/IEC 42001 program already uses.
- Its integration-with-risk-management step connects to ISO/IEC 23894, so bias treatment feeds the same risk process as everything else.
- Because it explicitly excludes the management-system processes and points to ISO/IEC 42001 for them, the division of labor is clean: ISO/IEC 42001 governs, ISO/IEC TS 12791 treats.
From an audit perspective — points to watch
For classification and regression systems, ISO/IEC TS 12791 gives an auditor and an implementer a shared, concrete reference — which also makes the gaps more visible. Points that can surface include the following. (These are situations that can arise in practice, not assertions of frequency.)
- Applying the techniques outside their scope — using the specification's measures on a task that is neither classification nor regression, without validating that they transfer.
- Inherited bias assumed away — a third-party or pre-trained model is used with no assessment of the bias it may carry, and no bias requirement placed on the supplier.
- No acceptance criteria at inception — treatment steps exist, but with no defined fairness target for them to meet, so there is no way to say whether they worked.
- Treatment without monitoring — bias was treated during development, but there is no re-evaluation trigger for the external change that can reintroduce it.
In an audit, you would typically be asked to show the acceptance criteria, the treatment measures mapped to lifecycle stages, and the records that both were applied and re-checked — including for any inherited model or data.
Putting it into practice — where to start
Starting points by situation:
- A team building a classifier or predictor — set fairness acceptance criteria at inception, map a treatment measure to each lifecycle stage using Clause 5, and choose data and training techniques from Clause 6 that fit the task and the chosen fairness measure.
- A team using a pre-trained or third-party model — treat inherited bias explicitly, and carry bias requirements into procurement and into the acceptance criteria for whatever a supplier delivers.
- An organization preparing for ISO/IEC 42001 certification — record the results against the relevant Annex A controls and the risk register, so the bias work is visible as part of the management system rather than a separate technical exercise. The AI risk management template is a useful starting document for that link.
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 |
|---|---|
| classification | An ML task that assigns an input to one of a set of categories. |
| regression | An ML task that predicts a continuous numeric value. |
| pre-trained model | A model trained on an earlier dataset and reused as a starting point; it can carry inherited bias into the new system. |
| pre-/in-/post-processing | The industry grouping of mitigation techniques by where they act — on the data, on the training, or on the outputs. |
| acceptance criteria | The bias and fairness targets set at inception, against which treatment is later judged. |
| distributed lifecycle | A lifecycle spread across multiple parties, so that responsibility for treating bias is shared along the supply chain. |
The bottom line
ISO/IEC TS 12791:2024 is the how-to companion to ISO/IEC TR 24027: a lifecycle-organized, technique-level specification for treating unwanted bias in classification and regression ML. It certifies nothing, and it does not cover the management system — that is ISO/IEC 42001's job. What it gives engineering and governance teams is the concrete set of measures that makes a fairness commitment real for these ML tasks: acceptance criteria set up front, treatment mapped to each lifecycle stage, explicit handling of inherited and pre-trained-model bias, and monitoring for the change that can bring bias back. Built on ISO/IEC TR 24027 and the ISO/IEC 22989 / 5338 lifecycle, and pointing to ISO/IEC 42001 for governance, it is the layer where an AI fairness policy turns into engineering practice.
📚 SC 42 AI Standards Series
← Previous: ISO/IEC TR 24027:2021 — Bias in AI Systems and AI-aided Decision Making
📍 Current: ISO/IEC TS 12791:2024 — Treatment of Unwanted Bias in Classification and Regression ML Tasks