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:
- The model. It can reflect patterns in its training data. You do not control that, so you test for it instead of assuming its absence.
- Your instructions and examples. Criteria wording, a persona, or few-shot examples drawn from one population all steer output.
- Inputs and proxies. Deleting a protected attribute does not delete the signal. Names, postcodes, schools, employment gaps and writing style can act as proxies, so 'we removed gender' is a claim to test, not a control.
- Retrieval corpus and knowledge base. Skewed, outdated or one-sided documents produce skewed answers even from a neutral model.
- Evaluation data. A golden set that under-represents a group produces healthy aggregate scores that hide failures for that group, the same aggregate trap as in Lesson 4.3.
- The human and feedback loop. Reviewers have their own biases and are subject to automation bias, and decisions that later become training or evaluation data can entrench earlier errors.
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.