# Algorithmic Bias Profile: [AI system name]

> Algorithmic bias profile for an AI system or algorithmic decision
> process, structured on IEEE Std 7003-2024, *IEEE Standard for
> Algorithmic Bias Considerations* (approved December 2024, published
> January 2025). It records the bias requirements and acceptability
> boundaries, the stakeholders, the data representation, the risk and
> impact assessment, the evaluation with defined fairness metrics, the
> mitigations and the ongoing monitoring, and cross-references
> ISO/IEC TS 12791:2024 and Article 10 of the EU AI Act. Replace every
> `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not legal advice, and it is not a conformity
> statement against IEEE Std 7003-2024.

<!--
Guidance: How to use this template
- The bias profile is a living record, not a one-off report. Every step
  (requirements, stakeholders, data, risk, evaluation) reads the current
  profile and writes an updated version. Keep the version history.
- Sections 4 to 9 follow the clause order of IEEE Std 7003-2024 (clause
  4 requirements, 5 profile, 6 stakeholders, 7 data representation,
  8 risk and impact, 9 evaluation). Keep the numbering so an assessor
  can map your evidence to the standard.
- The standard does not prescribe fairness metrics, thresholds or
  mitigation techniques. You choose them for your context and justify
  the choice here. Section 9 and section 10 give a starting set.
- Obtain the standard itself (IEEE offers some AI ethics standards free
  through its GET Program; check current access) and read it alongside
  this file. No text of the standard is reproduced here.
- Common pitfall: measuring one fairness metric on one test set at
  launch and calling the system "unbiased". Record which harms each
  metric can and cannot detect, and keep measuring after release.
-->

## Document control

<!-- Guidance: Identify the system, its version and the people who own the profile and accept residual bias risk. The risk owner must have authority to stop or change the system. -->

| Field | Value |
|---|---|
| Document ID | [BIAS-PROF-001] |
| AI system | [Name, version, model ID] |
| System owner | [@system-owner] |
| Bias profile owner | [@bias-lead] |
| Residual risk acceptor | [@risk-owner, role with authority to stop deployment] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Approvers / reviewers | [@legal], [@dpo], [@domain-expert], [@affected-community-liaison] |
| Lifecycle stage | [Concept / Design / Development / Validation / Deployed / Retired] |
| Linked documents | [AI risk assessment ID], [DPIA ID], [Model card ID], [FRIA ID if applicable] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| System owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Bias profile owner | [@name] | [Confirm completeness] | YYYY-MM-DD |
| Residual risk acceptor | [@name] | [Accept / Do not accept residual risk] | YYYY-MM-DD |
| Data protection officer | [@name] | [Opinion] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial requirements and stakeholder map |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Data representation added after training data audit |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for pilot with two conditions (BIAS-MIT-002, BIAS-MON-001) |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Drift alert on approval-rate gap; profile re-evaluated |

## Contents

1. [Purpose, scope and context](#1-purpose-scope-and-context)
2. [Roles and responsibilities](#2-roles-and-responsibilities)
3. [Bias consideration process](#3-bias-consideration-process)
4. [Bias requirements and acceptability boundaries](#4-bias-requirements-and-acceptability-boundaries)
5. [Bias profile summary](#5-bias-profile-summary)
6. [Stakeholder identification](#6-stakeholder-identification)
7. [Data representation](#7-data-representation)
8. [Risk and impact assessment](#8-risk-and-impact-assessment)
9. [Evaluation and fairness metrics](#9-evaluation-and-fairness-metrics)
10. [Mitigation plan](#10-mitigation-plan)
11. [Ongoing monitoring and re-evaluation](#11-ongoing-monitoring-and-re-evaluation)
12. [Regulatory and standards cross-reference](#12-regulatory-and-standards-cross-reference)
13. [Traceability matrix](#13-traceability-matrix)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose, scope and context

<!-- Guidance: State what the system decides or recommends, for whom, and where it must not be used. Application boundaries are central to IEEE Std 7003-2024: bias often appears when a system is used outside the context it was designed and validated for. -->

| Item | Description |
|---|---|
| Intended purpose | [What decision or output the system produces and why] |
| Decision type | [Fully automated / Recommendation to a human / Ranking / Content generation] |
| Affected population | [Who receives or is affected by the output] |
| Deployment context | [Jurisdictions, channels, languages, volume per month] |
| Validated operating boundaries | [Population, geography, time period, input types the system was validated on] |
| Out-of-scope uses | [Uses the system must not be applied to, and why] |
| Correlation versus causation statement | [How users are told what the output does and does not imply] |

*Example:* A credit pre-screening model scores applications from adult
residents of [Country] who apply online in [Language A] and
[Language B]. It was validated on applications from 2023 to 2025. It
must not be used for small-business loans, for applicants under 18, or
to infer creditworthiness from postcode alone. Its score indicates
statistical association with repayment in historical data; it does not
explain why any applicant would or would not repay.

Explain in plain language why bias matters for this system. Name the
kinds of harm that could follow from unwanted bias: denial of an
opportunity or service, a lower quality of service for some groups,
stereotyping or demeaning outputs, erasure of a group from results, or
an unfair allocation of scrutiny such as more fraud checks. Describe the
setting in which the output is consumed, because the same model can be
low risk as an internal triage aid and high risk as an automatic
rejection.

## 2. Roles and responsibilities

<!-- Guidance: Name people, not teams. The standard expects a formal acceptance of residual bias risk by an accountable owner; record who that is and how disagreement is escalated. -->

| Role | Responsibility in this profile | Person |
|---|---|---|
| System owner | Funds and approves the system, owns business outcome | [@name] |
| Bias profile owner | Maintains this document, coordinates each step | [@name] |
| Data steward | Provides lineage and metadata for every dataset | [@name] |
| ML lead | Runs evaluations, implements technical mitigations | [@name] |
| Domain expert | Interprets results in the domain context | [@name] |
| Stakeholder liaison | Organises consultation with affected groups | [@name] |
| Residual risk acceptor | Formally accepts or rejects residual risk | [@name] |
| Independent reviewer | Challenges assumptions before approval | [@name] |

Escalation route: when the bias profile owner and the system owner
disagree on whether a boundary is met, the matter goes to [governance
committee] within [10] working days, and deployment does not proceed
until it decides.

## 3. Bias consideration process

<!-- Guidance: Show how the steps connect and when each is repeated. The diagram reflects the structure of the standard: the profile is updated by every step rather than being a step itself. -->

```mermaid
flowchart LR
  R[4. Requirements and boundaries] --> P[(5. Bias profile)]
  P --> S[6. Stakeholder identification]
  S --> P
  P --> D[7. Data representation]
  D --> P
  P --> K[8. Risk and impact assessment]
  K --> P
  P --> E[9. Evaluation]
  E --> P
  P --> M[10. Mitigation]
  M --> E
  P --> O[11. Ongoing monitoring]
  O -->|trigger| K
```

Run the steps in order for a new system, then repeat the affected steps
when a trigger fires: new data source, new population or market, model
retraining, a change to the decision threshold, a complaint pattern, or
a monitoring alert. Record each iteration as a new profile version.
Start the risk and impact assessment at the business case stage, before
data is collected, because many bias decisions (which population to
serve, which proxy to predict) are made before any model exists.

## 4. Bias requirements and acceptability boundaries

<!-- Guidance: Distinguish wanted bias (a deliberate, justified difference in treatment, such as a lower dose for children) from unwanted bias. Write each requirement so that it can be tested, and set a boundary beyond which the system must not be released. -->

### 4.1 Values statement

[State, in two to four sentences, the organisation's position on fair
treatment for this system: which differences in outcome are justified
by the purpose, which are not, and which legal or ethical commitments
apply.]

### 4.2 Wanted and unwanted bias

| ID | Type | Description | Justification or harm |
|---|---|---|---|
| BIAS-W-001 *(Example)* | Wanted | Applicants with verified income above the loan amount score higher | Directly relevant to the purpose; documented business rule |
| BIAS-U-001 *(Example)* | Unwanted | Lower approval rate for applicants writing in [Language B] with equal repayment history | Denial of service unrelated to creditworthiness |
| BIAS-U-002 *(Example)* | Unwanted | Higher false-positive fraud flags for applicants aged 65 and over | Unequal scrutiny and delay |

### 4.3 Bias requirements

| ID | Requirement | Metric (section 9) | Acceptability boundary | Rationale |
|---|---|---|---|---|
| BIAS-REQ-001 *(Example)* | Approval rates must not differ unjustifiably by language of application | Selection rate ratio | Ratio at or above [0.80] on the holdout set | Internal policy choice; documented in [policy ID] |
| BIAS-REQ-002 *(Example)* | Error burden of false rejections must be comparable across age bands | False negative rate difference | Absolute difference at or below [0.03] | Harm of false rejection judged high by stakeholders |
| BIAS-REQ-003 *(Example)* | Score calibration must hold within each protected group | Calibration error by group | Expected calibration error at or below [0.02] per group | Scores are shown to human underwriters |
| BIAS-REQ-004 | [Requirement] | [Metric] | [Boundary] | [Why this value] |

The boundaries above are organisational choices, not values taken from
the standard or from law. State who chose each value, what evidence
informed it, and what happens when it is breached: block release,
release with conditions, or escalate.

## 5. Bias profile summary

<!-- Guidance: Keep a short, current summary on top of the detailed sections. A reader who stops here should know the state of the system and the open risks. -->

| Item | Current state |
|---|---|
| Profile version | [1.0] |
| Steps completed this iteration | [Requirements, Stakeholders, Data, Risk, Evaluation] |
| Requirements met | [3 of 4] |
| Requirements breached | [BIAS-REQ-00N, with mitigation reference] |
| Open high risks | [BIAS-RISK-00N] |
| Residual risk decision | [Accepted by @name on YYYY-MM-DD / Not accepted] |
| Conditions on release | [List] |
| Next trigger-based review | [Event or date] |

Retain the initial, intermediate and latest versions of each step's
outputs (stakeholder maps, data audits, evaluation reports) and link
them here. Auditors usually ask to see how a decision changed between
iterations and why.

## 6. Stakeholder identification

<!-- Guidance: Include people affected by the output who never use the system. Ask: who is scored, who acts on the score, who is excluded from the data, who bears the cost of an error, and who can speak for groups that are hard to reach? -->

| ID | Stakeholder group | Relationship to system | Potential bias exposure | Engagement method | Date |
|---|---|---|---|---|---|
| STK-001 *(Example)* | Applicants writing in [Language B] | Scored by system | Lower representation in training data | Two focus groups via community organisation | YYYY-MM-DD |
| STK-002 *(Example)* | Applicants aged 65 and over | Scored by system | Fraud model trained mostly on younger customers | Survey and complaints review | YYYY-MM-DD |
| STK-003 *(Example)* | Underwriters | Act on recommendation | Automation bias toward the score | Workshop and shadowing | YYYY-MM-DD |
| STK-004 *(Example)* | Applicants without credit history | Excluded from historical data | Default rejection due to missing features | Consumer advocacy group interview | YYYY-MM-DD |
| STK-005 | [Group] | [Relationship] | [Exposure] | [Method] | YYYY-MM-DD |

Record the procedure you followed to identify these groups and why it
was adequate: sources searched, legal protected characteristics in the
jurisdiction, intersectional groups considered (for example older women
applying in [Language B]), and groups you chose not to consult with a
reason. Summarise what stakeholders told you and which requirement or
risk each input changed. Note cultural factors that may change what
counts as fair treatment in each market served.

## 7. Data representation

<!-- Guidance: Describe every dataset that shapes the system's behaviour: training, fine-tuning, validation, test, reference and retrieval data, and the labels. Map each to the population in section 1 and record gaps. Validation datasets deserve the most scrutiny, because they decide whether a bias is detected at all. -->

### 7.1 Data inventory

| ID | Dataset | Use | Source and period | Size | Labels and who produced them | Sensitive attributes available |
|---|---|---|---|---|---|---|
| DATA-001 *(Example)* | Applications 2023-2025 | Training | Core banking export, 2023-01 to 2025-06 | [n] rows | Repaid within 12 months, system generated | Age, language; gender not collected |
| DATA-002 *(Example)* | Holdout 2025-H2 | Validation | Same pipeline, 2025-07 to 2025-12 | [n] rows | As above | Age, language |
| DATA-003 *(Example)* | Fairness test panel | Bias test | Stratified sample with self-reported attributes, consented | [n] rows | Manual review | Age, language, gender, disability (voluntary) |

### 7.2 Representation analysis

| Group | Share of affected population | Share of training data | Share of validation data | Gap assessment |
|---|---|---|---|---|
| [Language B] *(Example)* | 18 % | 9 % | 11 % | Under-represented; see BIAS-MIT-001 |
| Age 65 and over *(Example)* | 14 % | 12 % | 13 % | Acceptable |
| No credit history *(Example)* | 7 % | 0 % | 0 % | Excluded by construction; see BIAS-RISK-003 |
| [Group] | [%] | [%] | [%] | [Assessment] |

### 7.3 Data mapping and quality notes

Describe how each input feature relates to the concept it stands for,
and where a feature can act as a proxy for a protected characteristic
(postcode for ethnicity, first name for gender, device type for income).
Record label quality: historical labels can encode past discriminatory
decisions, so a model that predicts them faithfully reproduces that
bias. State how missing sensitive attributes were handled: not
measured, inferred with a documented method and its error rate, or
collected on a consented test panel. Record the legal basis for
processing any special category data for bias testing (see section 12).

Validation dataset selection criteria applied: [coverage of each group
in section 6, minimum group sample size for stable estimates, time
period matching deployment, independence from training data, label
quality checked by [method]].

## 8. Risk and impact assessment

<!-- Guidance: Treat this as an inventory of how bias could harm each stakeholder group, rated before and after mitigation. The residual risk must be formally accepted by the owner named in Document control. -->

| ID | Source of bias | Affected group | Harm | Likelihood | Severity | Inherent rating | Mitigation | Residual rating | Owner |
|---|---|---|---|---|---|---|---|---|---|
| BIAS-RISK-001 *(Example)* | Under-represented language in training data | STK-001 | Higher false rejection | Likely | Major | High | BIAS-MIT-001 | Medium | [@ml-lead] |
| BIAS-RISK-002 *(Example)* | Automation bias among underwriters | STK-003, all applicants | Errors not caught by reviewer | Possible | Major | Medium | BIAS-MIT-003 | Low | [@ops-lead] |
| BIAS-RISK-003 *(Example)* | Thin-file applicants absent from data | STK-004 | Systematic rejection | Almost certain | Major | High | BIAS-MIT-002 | Medium | [@product] |
| BIAS-RISK-004 *(Example)* | Use outside validated boundaries (small business) | Business applicants | Unvalidated decisions | Possible | Moderate | Medium | Technical block on product code | Low | [@system-owner] |
| BIAS-RISK-005 *(Example)* | Credit and fraud models trained mostly on younger customers | STK-002 | More false rejections and fraud flags for applicants aged 65 and over | Possible | Major | Medium | Larger DATA-003 panel for age bands; BIAS-MON-002 | Medium | [@ml-lead] |
| BIAS-RISK-006 | [Source] | [Group] | [Harm] | [L] | [S] | [Rating] | [Ref] | [Rating] | [@name] |

Rating scale: use the organisation's AI risk matrix from AI Risk
Assessment (`ai-data/ai-risk-assessment`) so bias risks can be compared
with other AI risks. Consider harms at three levels: to individuals, to
groups (cumulative disadvantage across many decisions) and to society
(reinforcing exclusion from a market). Record which risks you accepted
without mitigation and why.

**Residual risk acceptance.** I accept the residual bias risks listed
above for the scope in section 1, subject to the conditions in
section 5. Name: [@risk-owner]. Date: YYYY-MM-DD.

## 9. Evaluation and fairness metrics

<!-- Guidance: Pick metrics that match the harm. Allocation harms (who gets a loan) call for rate and error metrics; quality-of-service harms call for per-group performance; representational harms in generative systems call for content audits. Report confidence intervals: small groups give unstable estimates. -->

### 9.1 Metric definitions

Notation: Y is the true outcome, Ŷ the system's decision, S the score,
A the group attribute, and a, b two groups being compared.

| Metric | Definition (plain words) | Detects | Limitation |
|---|---|---|---|
| Selection rate | Share of a group receiving the positive decision, P(Ŷ=1 given A=a) | Unequal access | Ignores true outcome differences |
| Demographic parity difference | Selection rate of group a minus that of group b | Unequal access | May conflict with accuracy when base rates differ |
| Selection rate ratio | Lower selection rate divided by higher selection rate | Unequal access, scale free | Unstable when both rates are small |
| True positive rate difference (equal opportunity) | Difference between groups in P(Ŷ=1 given Y=1) | Qualified people missed more in one group | Needs reliable labels |
| False negative rate difference | Difference in P(Ŷ=0 given Y=1) | Unequal burden of wrongful rejection | Same as above |
| False positive rate difference | Difference in P(Ŷ=1 given Y=0) | Unequal burden of wrongful flags | Same as above |
| Equalized odds | TPR and FPR both equal across groups; report the larger of the two gaps | Unequal error profile | Often incompatible with calibration |
| Predictive parity | Equal precision, P(Y=1 given Ŷ=1), across groups | Unequal meaning of a positive decision | Can hold while error rates differ |
| Calibration within groups | For each score band, observed outcome rate matches the score in every group | Scores mean different things per group | Requires enough data per band |
| Per-group performance | Accuracy, AUC or task metric computed per group; report worst group | Quality-of-service gaps | Average can hide subgroups |
| Counterfactual consistency | Share of cases whose decision changes when only the group attribute or its proxy is altered | Direct dependence on attribute | Altering one feature may create unrealistic inputs |

When base rates differ between groups, several of these criteria cannot
all be satisfied at once. Choose the criterion that reflects the harm
stakeholders ranked highest, record the trade-off, and report the other
metrics for transparency.

### 9.2 Evaluation of design and outputs

| ID | Requirement | Metric | Groups | Dataset | Result (95 % CI) | Boundary | Pass |
|---|---|---|---|---|---|---|---|
| BIAS-EVAL-001 *(Example)* | BIAS-REQ-001 | Selection rate ratio | [Language B] vs [Language A] | DATA-002 | 0.76 (0.71 to 0.81) | at or above 0.80 | No |
| BIAS-EVAL-002 *(Example)* | BIAS-REQ-002 | FNR difference | 65+ vs 25-64 | DATA-003 | 0.021 (0.008 to 0.034) | at or below 0.03 | Inconclusive: point estimate passes, CI crosses boundary |
| BIAS-EVAL-003 *(Example)* | BIAS-REQ-003 | ECE per group | All language and age groups | DATA-002 | max 0.015 | at or below 0.02 | Yes |
| BIAS-EVAL-004 | [REQ] | [Metric] | [Groups] | [Data] | [Result] | [Boundary] | [ ] |

Record the evaluation conditions: model version, decision threshold,
date, code commit and the person who ran it. When a result passes but
its confidence interval crosses the boundary, treat it as inconclusive
and plan more data rather than declaring a pass. For generative or
agentic systems, add a structured content audit: prompts varied by
group descriptors, rated by trained reviewers against a rubric for
stereotyping, refusal disparity and quality disparity.

## 10. Mitigation plan

<!-- Guidance: IEEE Std 7003-2024 leaves the choice of mitigation to you. Link each mitigation to the risk it treats and plan a re-evaluation to prove it worked. ISO/IEC TS 12791:2024 catalogues treatment techniques for classification and regression tasks by lifecycle stage. -->

| ID | Treats | Stage | Technique | Expected effect | Side effects checked | Owner | Due | Status |
|---|---|---|---|---|---|---|---|---|
| BIAS-MIT-001 *(Example)* | BIAS-RISK-001 | Pre-processing | Collect more [Language B] applications; reweight training samples | Selection ratio above 0.80 | Overall AUC, calibration | [@ml-lead] | YYYY-MM-DD | In progress |
| BIAS-MIT-002 *(Example)* | BIAS-RISK-003 | Design | Route thin-file applicants to manual review with alternative data | No automatic rejection of thin-file applicants | Reviewer workload | [@product] | YYYY-MM-DD | Done |
| BIAS-MIT-003 *(Example)* | BIAS-RISK-002 | Deployment | Show score uncertainty and require written reason for agreement on rejections | Override rate rises to a plausible level | Decision time | [@ops-lead] | YYYY-MM-DD | Planned |
| BIAS-MIT-004 | [Risk] | [Stage] | [Technique] | [Effect] | [Checks] | [@name] | YYYY-MM-DD | [Status] |

Technique families to consider: pre-processing (re-sampling,
re-weighting, better labels, removing or transforming proxy features),
in-processing (fairness constraints or regularisation during training),
post-processing (group-aware thresholds where lawful, calibration per
group), and non-technical controls (human review routes, appeal
channels, changing the decision the system supports). Check local law
before using group-specific thresholds: in some jurisdictions explicit
use of a protected attribute in the decision is itself prohibited. Human
oversight measures for automation bias are covered in Human Oversight
Design (`ai-data/human-oversight-design`).

## 11. Ongoing monitoring and re-evaluation

<!-- Guidance: Bias drifts as the population, the product and the world change. Define what you will measure in production, how often, with which data, and what each alert triggers. -->

| ID | Metric | Population slice | Frequency | Data source | Alert threshold | Action on alert | Owner |
|---|---|---|---|---|---|---|---|
| BIAS-MON-001 *(Example)* | Selection rate ratio | Language | Weekly | Decision log | Below 0.82 for two consecutive weeks | Re-run section 9; consider rollback | [@ml-ops] |
| BIAS-MON-002 *(Example)* | Population shift (PSI) on age | Age band | Monthly | Application stream | PSI above 0.2 | Re-run section 7 and 8 | [@data-steward] |
| BIAS-MON-003 *(Example)* | Complaints mentioning unfair treatment | All | Monthly | Complaints system | Any cluster of 5 or more on one group | Root-cause review | [@customer-ops] |
| BIAS-MON-004 *(Example)* | Underwriter override rate | Reviewer team | Monthly | Case system | Below 2 % | Automation bias review (BIAS-RISK-002) | [@ops-lead] |
| BIAS-MON-005 | [Metric] | [Slice] | [Freq] | [Source] | [Threshold] | [Action] | [@name] |

Production outcome labels often arrive late (a loan defaults months
later) or never (a rejected applicant has no repayment record). Use
leading indicators such as selection rates and overrides, and schedule
a periodic labelled audit. Feed incidents into AI Incident Report
(`ai-data/ai-incident-report`) and production drift into Model
Monitoring Plan (`ai-data/model-monitoring-plan`).

Re-evaluation triggers: retraining or model swap; change in threshold
or features; expansion to a new market, language or population;
material complaint or regulator inquiry; monitoring alert; and at least
every [12] months.

## 12. Regulatory and standards cross-reference

<!-- Guidance: Map the profile to the obligations and standards that apply to you. Check the official, current text of each item; the AI Act has been amended and some provisions moved. -->

| Source | Provision | What it asks for (paraphrase) | Where addressed here |
|---|---|---|---|
| IEEE Std 7003-2024 | Clauses 4 to 9 | Bias requirements, profile, stakeholders, data representation, risk and impact, evaluation | Sections 4 to 9, 11 |
| ISO/IEC TS 12791:2024 | Whole document | Techniques to treat unwanted bias in classification and regression across the lifecycle | Section 10 |
| ISO/IEC TR 24027:2021 | Whole document | Concepts and sources of bias in AI systems and AI-aided decisions, and assessment measures | Sections 7, 9 |
| EU AI Act Art. 10(2)(f) and (g) | Data governance for high-risk systems | Examine data for possible biases likely to affect health, safety or fundamental rights or lead to prohibited discrimination; take measures to detect, prevent and mitigate them | Sections 7, 9, 10 |
| EU AI Act Art. 10(2)(h) and 10(3) | Data gaps and data quality | Identify data gaps that prevent compliance; data sets relevant, sufficiently representative and as error-free and complete as possible for the intended purpose | Sections 7.2, 7.3 |
| EU AI Act Art. 10(4) | Context | Data sets reflect the specific geographical, contextual, behavioural or functional setting of intended use | Sections 1, 7.2 |
| EU AI Act, special category data for bias detection | Art. 10(5) in the original text; restructured by the Digital Omnibus (Regulation (EU) 2026/1744) | Exceptional processing of special category data, strictly for bias detection and correction, under safeguards and with deletion afterwards | Section 7.3 legal basis |
| EU AI Act Art. 15(4) | Learning after deployment | Reduce risk of biased outputs feeding back into future inputs | Section 11 |
| GDPR Art. 9, 22 and 35 | Special categories, automated decisions, DPIA | Lawful basis, safeguards for solely automated decisions, impact assessment | Linked DPIA |

For high-risk systems under Annex III, the amended Article 113 makes
the Chapter III Section 2 requirements, including Article 10, apply
from 2 December 2027 (2 August 2028 for Annex I products); check the
consolidated text on EUR-Lex. For a wider applicability check, use AI
Regulatory Applicability Register
(`compliance/ai-regulatory-applicability-register`). For a broader
impact view on individuals and society, use AI System Impact
Assessment (`ai-data/ai-impact-assessment-42005`); for generative
systems, cross-check GenAI Risk Profile (`ai-data/genai-risk-profile`).

## 13. Traceability matrix

<!-- Guidance: Every requirement should trace to a stakeholder concern, a risk, an evaluation and, where breached, a mitigation and a monitor. Gaps in this table are gaps in the argument. -->

| Requirement | Stakeholders | Risks | Evaluation | Mitigation | Monitor | Status |
|---|---|---|---|---|---|---|
| BIAS-REQ-001 *(Example)* | STK-001 | BIAS-RISK-001 | BIAS-EVAL-001 | BIAS-MIT-001 | BIAS-MON-001 | Breached, mitigation in progress |
| BIAS-REQ-002 *(Example)* | STK-002 | BIAS-RISK-005 | BIAS-EVAL-002 | Larger DATA-003 age panel to narrow the CI | BIAS-MON-002 | Inconclusive, more data planned |
| BIAS-REQ-003 *(Example)* | STK-003 | BIAS-RISK-002 | BIAS-EVAL-003 | None needed | Periodic labelled audit (section 11) | Met |
| BIAS-REQ-004 | [STK] | [RISK] | [EVAL] | [MIT] | [MON] | [Status] |

## 14. Glossary and references

<!-- Guidance: Define terms in your own words for non-specialist readers and list the exact editions you used. -->

| Term | Meaning in this document |
|---|---|
| Bias profile | The maintained record of bias requirements, decisions, evidence and accepted risk for one system |
| Wanted bias | A deliberate and justified difference in treatment that serves the system's purpose |
| Unwanted bias | A difference in treatment or outcome that is not justified by the purpose and can cause harm |
| Acceptability boundary | The limit on a bias metric beyond which the system is not released or must be changed |
| Proxy feature | An input that correlates strongly with a protected characteristic |
| Base rate | The share of actual positive outcomes (Y=1) in a group |
| Automation bias | The tendency of people to over-rely on automated recommendations |

References:

- IEEE Std 7003-2024, IEEE Standard for Algorithmic Bias Considerations, IEEE Standards Association, https://standards.ieee.org/ieee/7003/11357/
- ISO/IEC TS 12791:2024, Information technology, Artificial intelligence, Treatment of unwanted bias in classification and regression machine learning tasks, edition 1, October 2024
- ISO/IEC TR 24027:2021, Information technology, Artificial intelligence, Bias in AI systems and AI aided decision making
- Regulation (EU) 2024/1689 (Artificial Intelligence Act) as amended by Regulation (EU) 2026/1744, Articles 10, 15 and 113 (consolidated text on EUR-Lex)
- Regulation (EU) 2016/679 (GDPR), Articles 9, 22 and 35
- Related templates: AI Risk Assessment (`ai-data/ai-risk-assessment`), Model Card (`ai-data/model-card`), Datasheet for Datasets (`ai-data/datasheet-for-datasets`), Human Oversight Design (`ai-data/human-oversight-design`)

## Standard and licence note

Structure aligned with IEEE Std 7003-2024, *IEEE Standard for
Algorithmic Bias Considerations* (IEEE Standards Association, approved
11 December 2024, published 24 January 2025), with cross-references to
ISO/IEC TS 12791:2024 and Article 10 of Regulation (EU) 2024/1689. The
IEEE and ISO/IEC documents are copyrighted: this template uses only
their structure and clause numbers, and all text, metric definitions,
tables and examples are original. Fairness metric choices and numeric
boundaries are illustrative, not requirements of any standard. Check
the current official versions and the consolidated text of the AI Act
before relying on this document. This is a documentation format, not
legal advice. Template licence: MIT.