Algorithmic Bias Profile Template (IEEE 7003-2024)

Bias profile per IEEE 7003-2024: bias requirements and boundaries, stakeholders, data representation, risk, fairness metrics, mitigation, monitoring, AI Act Art. 10

IA y datosCompletaIEEE Std 7003-2024; ISO/IEC TS 12791:2024; EU AI Act Art. 10bias profile 7003Actualizada 22 oct 2026

Abrir en el editorDescargar .md

Cómo usar: Use it when an AI system makes or supports decisions about people and you need a maintained record of bias decisions and accepted risk. Fill the wanted/unwanted bias table and the testable bias requirements with acceptability boundaries first, then stakeholders and data representation. The main pitfall is measuring one fairness metric once at launch and calling the system unbiased.

Vista previa

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.

Document control

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

Purpose, scope and context
Roles and responsibilities
Bias consideration process
Bias requirements and acceptability boundaries
Bias profile summary
Stakeholder identification
Data representation
Risk and impact assessment
Evaluation and fairness metrics
Mitigation plan
Ongoing monitoring and re-evaluation
Regulatory and standards cross-reference
Traceability matrix
Glossary and references

1. Purpose, scope and context

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Plantillas relacionadas

IA y datos