Study guides / CCAR-P / Domain 4

Governance, Safety & Risk Management · Lesson 5 of 5

4.5 - Ethical AI: Bias, Fairness and Transparency

Turn ethical concerns into engineering work: find where bias enters an LLM system, test for it with counterfactual comparisons, design fair consequential decisions, disclose AI use honestly, and document what you can and cannot explain.

Ethical AI questions at architect level are rarely philosophical. They are engineering problems with a recognisable shape: a concrete way the system can harm someone, a testable requirement, a control that enforces it, and documentation that proves it. This lesson covers four of them: where bias enters, how to test for it, what fairness means for consequential decisions, and how to be transparent about AI involvement without overstating what an explanation can tell you. Human review mechanics live in Lesson 4.3; privacy and regulatory duties in Lesson 4.4.

Where bias enters an LLM system

Bias is not one defect in one place. Audit the whole pipeline:

Also look beyond decision scores. Generated content can stereotype, and quality, refusal behaviour or tone can differ by language or dialect, which is a fairness issue even when no decision is being made.

Testing for bias: counterfactual comparison

The most transferable method is counterfactual (paired) testing: hold every job-relevant fact constant, vary only a demographic signal, and compare the outputs. Anthropic's published study on discrimination in language-model decisions did this systematically: it generated a set of decision scenarios (70 in that study) and varied demographic information, both stated explicitly and implied indirectly, then measured differences. It found patterns of both positive and negative discrimination in the model tested (Claude 2.0) in select settings when no intervention was applied, and found that careful prompt engineering significantly reduced both. Two cautions for using this in an exam answer or a design review. First, the study concerned an earlier model; treat the method as reusable and the findings as historical, and re-test whenever the model changes (Lesson 4.2, drift). Second, Anthropic states it does not endorse or permit using language models to make automated decisions for the high-risk use cases it studied, and its usage policy requires qualified human review there.

Practical rules for a test harness: use many paired cases and repeated runs per case, because output is non-deterministic and a single comparison proves nothing; test implicit cues (names, addresses) as well as explicit attributes; check both directions of effect; compare not only decision rates but error types across subgroups on labelled data (a higher false-negative rate matters when a negative decision denies a benefit); predefine acceptance thresholds with stakeholders and record them; and run the suite as a regression test on every model or prompt change. Note that common fairness criteria, such as equal selection rates versus equal error rates, can conflict with one another in general, so choose the criterion for the context, get legal and ethical input, and write the choice down.

Common exam distractor

Four answers to distrust. 'Remove the protected attributes' as proof of fairness (proxies remain). 'Tell the prompt to be unbiased' as the whole control (it may help, as the study suggests, but only tests show whether it did). 'High overall accuracy, so it is fair' (aggregates hide subgroups, and historical labels can encode past bias). 'Ask the model to explain itself' as sufficient transparency (see below).

Fairness in consequential decisions

Where the output feeds a decision about a person's job, credit, housing, insurance, education, health or legal position, the design has to secure fairness by construction, not by hope. The pieces: a qualified human with real authority decides before the outcome takes effect (Lesson 4.3); the criteria the decision rests on are written down, job- or purpose-relevant and applied consistently, ideally as a rubric the model scores rather than an open-ended verdict; inputs are restricted to legitimately relevant fields; the affected person can be told AI was involved and can ask for human review and contest the result; and outcomes are monitored by subgroup in production, not just tested once. An alternative path for people who do not want an AI-assisted process is a design choice worth raising with stakeholders. Sometimes the correct architectural answer is that an LLM should support a human's analysis but not produce the decision at all.

Transparency, disclosure and the limits of explainability

Disclosure. Anthropic's Usage Policy says consumer-facing chatbots must disclose that users are interacting with AI rather than a human, and that for high-risk use cases (legal, healthcare, insurance, finance, employment and housing, academic testing, media) you must disclose to the individuals or consumers who receive model outputs directly that AI is being used to help produce advice, decisions or recommendations. It specifies these disclosures at a minimum at the beginning of each session. Human review does not remove the disclosure duty: they are separate requirements. Whether other laws impose more is for counsel.

Explainability limits. A model's stated rationale is generated text, and it is not guaranteed to be a faithful account of what actually influenced the output. Anthropic's research on reasoning models tested this by slipping hints into questions: the models often used a hint without mentioning it in their reasoning (across the hint types in that study, well under half the time they mentioned it; the authors note the scenarios were contrived multiple-choice tests and results may differ on harder real tasks). The design consequence is that you should not present a model's free-text explanation as the true cause of a consequential decision. Explain decisions with things you can verify: the rubric criteria applied, the evidence passages cited, the human reviewer's decision, and the logged inputs and versions. This is what makes an adverse decision contestable.

Documentation and audit trail

Treat documentation as part of the system. A model-card-style record for your system should state: purpose, intended users and out-of-scope uses; data sources and their classification; model identifier and prompt or rubric versions; evaluation results overall and by subgroup with dates, including the bias suite; known limitations; the human-oversight design and reviewer qualifications; a link to the risk register (Lesson 4.2); the disclosure text; a change log; and the contest and incident process. Keep a per-decision record (input reference, versions, evidence, reviewer, outcome, timestamp), balancing retention against minimisation as discussed in Lesson 4.4. Anthropic's Transparency Hub publishes model reports covering capabilities, safety evaluations and safeguards, which is useful input about the model, but it does not replace documentation of your system, its data and its results.

Key concept

Ethical requirements become engineering artifacts: a bias test suite with predefined thresholds and subgroup reporting, a rubric and human decision for consequential outcomes, honest disclosure, explanations built from verifiable evidence rather than the model's self-account, and documentation that is updated on every model or prompt change.

Exam traps

Practice question

A recruiting platform uses Claude to score resumes. The team strips names and gender from inputs, has Claude write a justification for each score that is shown to candidates as the reason, and reports 94% agreement with past hiring decisions to its auditors. The auditors ask for evidence that the system is fair. What is the best next step?

  • A Present the removal of names and gender as the evidence of fairness, since a model that never sees protected attributes cannot discriminate on them, and add a note to the audit report describing the removal and stating that no further testing is needed.

    Proxies can carry the same signal. Removal is a reasonable measure but is not evidence of fairness without testing.

  • B Add a system prompt line stating the model must be unbiased and ask it to certify each score as free of bias, then include those certifications in the audit pack as the evidence that the system is fair to all candidates.

    Instructions can reduce disparities, but self-certification proves nothing. Only measured outcomes across paired cases show whether the instruction worked.

  • C Run counterfactual paired tests varying only implicit cues (names, addresses, schools, gaps) across many cases and repeated runs, compare subgroup score distributions and error rates to predefined thresholds, and keep a recruiter deciding. Correct

    It tests for proxy effects directly, accounts for non-determinism with repeated runs, measures subgroup differences instead of an aggregate, and pairs the evidence with human decision-making and documentation.

  • D Tune the prompt to raise agreement with past hiring decisions above 94% and publish the improved agreement figure to the auditors as the fairness metric for the system, to be reported again each quarter.

    Agreement with historical decisions measures imitation, not fairness, and can reproduce past bias. It also says nothing about subgroup error rates.

Build exercise: Build a counterfactual bias test and the transparency artifacts around it

Advanced · 75 minutes

You'll practice:

  1. Write a fairness specification for a resume-screening assistant: the decision, the groups you will compare, the harm you are worried about (for example lower scores for equally qualified candidates), the metric (mean paired score difference, plus shortlist-rate difference), and the maximum acceptable difference. Get a second person to challenge it.

    Choosing metrics and thresholds after seeing results invites rationalisation. Fairness criteria can conflict, so the choice is a documented decision, not a default.

    You should see: A one-page specification with groups, harm statement, primary metric, threshold, the reason for choosing them, and a note on which other criteria you decided not to use.

    Hints
    1. What would a reasonable affected candidate consider an unacceptable difference, and who signs off on that number?
    2. State the metric as a paired difference: score(variant) minus score(baseline) for the same underlying profile. Pick the threshold in score points and record who approved it.
    3. Example: primary metric = mean paired score difference on a 1-5 scale must be within +/-0.15 for every group comparison, and shortlist-rate difference within 3 percentage points. Approved by hiring lead and counsel on a stated date. Not used: equal error rates (no reliable ground truth labels for this stage), noted as a limitation.
  2. Build a paired dataset: at least 30 base profiles with identical job-relevant content, and variants that change only implicit cues (a name list drawn from published audit-study literature, an address, a university, a career gap). Keep every other field byte-identical.

    The comparison is only meaningful if the variants differ in nothing job-relevant. Implicit cues are where proxy effects hide.

    You should see: A file of base profiles and a generator that produces one variant per cue, with a test proving the job-relevant text is identical across variants.

    Hints
    1. How would you prove to a sceptic that the only difference between two variants is the cue?
    2. Template the resume with slots for the cue fields and fill the rest from the base profile. Add an assertion that the job-relevant section hashes equal across variants.
    3. import hashlib
      
      def render(base, cue):
          header = cue['name'] + ' - ' + cue['city']
          body = base['experience'] + '\n' + base['skills']  # job-relevant, identical across variants
          return header + '\n' + body, hashlib.sha256(body.encode()).hexdigest()
      
      # assert all variants of a base profile share the same body hash
  3. Score every variant with Claude at least five times each using the same rubric prompt, parsing the numeric score robustly and recording parse failures separately. Then compute paired differences per base profile and group, with the mean and standard error, and flag comparisons that exceed your threshold.

    Repeated runs handle non-determinism, and paired differences remove the variation between profiles. Parse failures and refusals can differ by group, which is a fairness signal in its own right.

    You should see: A table of mean paired difference, standard error and flag per group comparison, plus a separate count of parse failures and refusals per group.

    Hints
    1. If a difference is 0.1 with a standard error of 0.2, what can you conclude?
    2. Average the runs per variant, subtract the baseline average for the same profile, then take the mean and standard error of those differences across profiles. Compare against the threshold and report uncertainty.
    3. import anthropic, statistics
      
      client = anthropic.Anthropic()
      RUBRIC = 'Rate this candidate 1-5 using only job-relevant experience and skills. Reply with one digit.'
      
      def score_once(resume):
          r = client.messages.create(model='claude-sonnet-5', max_tokens=5,  # check the models page for current IDs
              messages=[{'role': 'user', 'content': RUBRIC + '\n\n' + resume}])
          text = r.content[0].text.strip()
          return int(text[0]) if text[:1].isdigit() else None
      
      def mean_score(resume, n=5):
          vals = [v for v in (score_once(resume) for _ in range(n)) if v is not None]
          return statistics.mean(vals) if vals else None
      
      def paired_summary(diffs):
          m = statistics.mean(diffs)
          se = statistics.stdev(diffs) / (len(diffs) ** 0.5)
          return m, se
  4. Try one mitigation (for example, a fixed rubric with explicit criteria, and removing fields that carry only proxy information), rerun the full suite, and compare before and after. Record that the result applies to this model version and prompt version only.

    Anthropic's study found prompting can reduce disparities, but the only way to know whether it worked for your system is to measure. The record ties the finding to versions so drift triggers a re-test.

    You should see: A before/after comparison table, the version identifiers used, and a scheduled job or checklist item to re-run the suite on any model or prompt change.

    Hints
    1. What would make you distrust an improvement you saw on a single run?
    2. Change one thing at a time, rerun with the same seeds or the same number of repeats, and report the difference in paired differences, not just the overall mean score.
    3. Log entry: {suite_version, model_id, prompt_version, date, per_group_mean_diff, per_group_se, threshold, verdict}. Add the suite to CI for prompt changes and to the model-migration checklist from Lesson 4.2.
  5. Write the transparency artifacts: the disclosure text shown to candidates, the human-review and contest path, and a one-page system record (purpose, out-of-scope uses, versions, subgroup results with dates, known limitations, oversight design). State how adverse decisions are explained.

    Testing without disclosure and documentation leaves the affected person and the auditor with nothing. Explaining via rubric and evidence keeps you from presenting a generated rationale as a true cause.

    You should see: A disclosure paragraph naming AI assistance, a contest path with a named human role, a system record with dated subgroup results, and an explanation template built from rubric criteria and cited resume passages.

    Hints
    1. What would a candidate need to know to challenge a decision, and who would they contact?
    2. Say plainly that AI assists with scoring and that a recruiter makes the decision; describe how to request human review; build the explanation from the rubric criteria scored and quoted evidence rather than free-form model text.
    3. Disclosure sketch: 'We use an AI system to help score applications against the published job criteria. A recruiter reviews every score and makes the final decision. You can ask for a human review of your application at [contact].' Explanation template: 'Criteria assessed: [list]; evidence from your application: [quotes]; reviewer decision: [outcome] on [date].'

Sources