Module 7: Building a Responsible AI Framework

Checklist content: bias + fairness

Next →

Description

We fill in the first section of the checklist with specific items derived from M2 (Bias and Fairness). This section typically has 5-6 items, organized into sub-categories: detection, measurement, mitigation, and ongoing monitoring.

By the end you'll be able to:

  • Specify 5-6 bias/fairness items in the full format
  • Derive items directly from the M2 deliverables
  • Calibrate the evidence requirements

The complete section: Bias and Fairness

# Section 1: Bias and Fairness

## Item 1.1: Protected attributes identified

**Question**: Have the protected demographic attributes relevant to this
system been explicitly identified and documented?

**Why this matters**: You can't test bias for groups you haven't defined.
Common protected attributes vary by jurisdiction (US: race, gender,
age 40+; EU: also includes religion, sexual orientation).

**Evidence required**:
- A document listing the protected attributes for this system
- A justification for the selection
- Legal review if applicable

**Status**: [ ] Yes [ ] No [ ] N/A
**Date verified**:
**Verified by**:
**Critical**: Yes

---

## Item 1.2: Demographic parity measured

**Question**: Has demographic parity been calculated for all protected
attributes within the last 90 days, with results documented?

**Why this matters**: Demographic parity disparities indicate potential
discriminatory impact. Untested = unknown risk.

**Evidence required**:
- A bias audit report (from the M2 deliverable) dated < 90 days ago
- Calculation methodology documented (parity ratio per group)
- Results per group with ratios

**Status**: [ ] Yes [ ] No [ ] N/A
**Date verified**:
**Verified by**:
**Critical**: Yes

---

## Item 1.3: Equalized odds tested

**Question**: Has equalized odds (true positive rate parity, false positive
rate parity) been tested for the protected groups?

**Why this matters**: Demographic parity alone is insufficient. Some
applications (criminal justice, lending) require equalized odds. Knowing
both gives you the full picture.

**Evidence required**:
- TPR per protected group calculated
- FPR per protected group calculated
- Gaps documented; thresholds defined

**Status**: [ ] Yes [ ] No [ ] N/A
**Date verified**:
**Verified by**:
**Critical**: Yes for high-impact decisions, No otherwise

---

## Item 1.4: Disparities mitigated or documented

**Question**: For any disparity exceeding the threshold (e.g., DPR < 0.85 or
an EOR gap > 0.1), is a mitigation implemented OR a justified acceptance
documented with stakeholder review?

**Why this matters**: Discovering bias is half the work. Acting on it is
the other half. Untreated bias = liability.

**Evidence required**:
- Mitigation actions taken (with before/after metrics)
- OR a justified acceptance with reasoning
- Stakeholder sign-off if the disparity is accepted

**Status**: [ ] Yes [ ] No [ ] N/A
**Date verified**:
**Verified by**:
**Critical**: Yes

---

## Item 1.5: Bias mitigation effectiveness verified

**Question**: For each mitigation applied, is its effectiveness verified
with pre/post measurement showing improvement?

**Why this matters**: A mitigation that doesn't work is theater. You must
demonstrate an actual reduction in the disparity.

**Evidence required**:
- Pre-mitigation metrics
- Post-mitigation metrics
- Quantified improvement

**Status**: [ ] Yes [ ] No [ ] N/A
**Date verified**:
**Verified by**:
**Critical**: Yes if mitigations were applied

---

## Item 1.6: Ongoing bias monitoring in production

**Question**: Are bias metrics monitored continuously in production with
alerts when the thresholds are exceeded?

**Why this matters**: Models drift. Inputs change. Bias can emerge
post-deployment. You need ongoing detection, not a one-time test.

**Evidence required**:
- A production dashboard showing bias metrics
- Alert configuration (thresholds, recipients)
- The last 90 days of metric history

**Status**: [ ] Yes [ ] No [ ] N/A
**Date verified**:
**Verified by**:
**Critical**: Yes for systems in production

Adaptations by system type

If your system doesn't make decisions (e.g., generative chat with no recommendations)

  • Item 1.1 still applies (the groups exist regardless)
  • Item 1.2 demographic parity: less directly applicable. Adapt it to "response quality parity"
  • Item 1.3 equalized odds: typically N/A
  • Item 1.4 disparities: applies if quality varies
  • Item 1.5: applies if mitigations were implemented
  • Item 1.6 monitoring: monitor response quality per group

If your system is binary classification (e.g., fraud detection)

  • All the items apply as standard
  • Item 1.3 is critical (TPR/FPR for fairness in a security context)

If your system generates ranked outputs (e.g., search, recommendations)

  • Item 1.2 adapted: the representation of groups in the top-K results
  • Item 1.3 adapted: differential exposure rates
  • Item 1.6: monitor representation over time

The principle: the items must be interpreted in the context of your system, not applied rigidly.

Common traps

Trap 1 — Assuming "no protected attributes" eliminates bias risk. "My system doesn't use race or gender." But it may use proxies (zipcode, name, etc.) that correlate. Identifying the explicit attributes is the start, not the end.

Trap 2 — Bias testing once at deployment. Testing in dev, never in production. Production data is different, and models drift. Re-test periodically.

Trap 3 — Accepting disparities with no justification. "DPR 0.7, acceptable for business reasons" → unjustified. Either improve it or document an explicit rationale with stakeholder buy-in.

Trap 4 — Forgetting mitigation effectiveness. "Mitigated by adding fairness constraints." Did it work? You need before/after measurement.

Trap 5 — Bias-blind monitoring. Production monitoring of accuracy but not bias. Performance can be great on average + terrible per group. Monitor it segmented.

Exercise

For your system:

  1. Identify the relevant protected attributes (the 3-5 most important)
  2. For each item above, give the current status (Yes/No/N/A)
  3. For each "No" or "N/A," explain why
  4. An action plan for the "No"s
See the solution (Knowledge Assistant example)

Relevant protected attributes:

  • Gender (binary + non-binary categorization)
  • Age bucket (18-30, 31-50, 51+)
  • Language preference (Spanish, English, others)
  • Hierarchical role (executive, mid-level, individual contributor — it may correlate with privilege)

Item status:

  • 1.1: ✅ Identified above
  • 1.2: ⚠️ Partially — language parity tested, the others pending
  • 1.3: N/A — the system doesn't do binary classification
  • 1.4: N/A pending completion of 1.2
  • 1.5: N/A
  • 1.6: ❌ Production monitoring of quality is NOT yet segmented by group

Action plan:

  • Q3: Complete 1.2 for all the attributes (a 4-week effort)
  • Q3: Implement the 1.6 segmented dashboard (a 2-week effort)
  • Q4: Re-evaluate based on the Q3 findings

Summary

You learned:

  • ✅ 6 specific items for the bias/fairness section
  • ✅ Each item: question, why, evidence, status, critical flag
  • ✅ Adaptations by system type
  • ✅ The traps: proxies, one-time testing, unjustified acceptance

Checkpoint: if your system has a custom-tailored bias section with 5-6 items, you're ready for the next section.

Next capsule

04 — Privacy + GDPR + EU AI Act sections. We keep filling in sections derived from M3-M5.

Resources

  1. Bias Audit Toolkit (the M2 deliverable).
  2. Fairness Indicators (Google).
  3. Aequitas reports.
  4. What-If Tool — interactive bias exploration.
← PreviousDesigning the checklist: structureNext →The Privacy, GDPR, and EU AI Act sections of the checklist