Bias isn't something you check once and forget. It can hide in the labels, in how a model treats each group, and in how the world changes after launch. This lesson covers the practical checks the exam names (label quality analysis, subgroup analysis and human audits), how to keep watching a model after release, and which AWS tools support each check today.
Check the labels first
A supervised model treats its labels as the truth, so biased or inconsistent labels become biased predictions. Label problems usually come from people: unclear instructions, labelers who interpret a category differently, or labelers whose own assumptions creep in.
Common checks include:
- sending each item to several labelers and comparing their answers;
- measuring how often they agree;
- reviewing the items where they disagree;
- auditing a random sample against expert judgment.
Combining several labelers' answers into one, called consensus, reduces the effect of any single person's mistakes or bias. If agreement is low, fix the instructions and relabel before training.
Subgroup analysis
Subgroup analysis means calculating a model's results separately for each group of people, such as age band, region, language or gender, and comparing them. Useful comparisons include accuracy, error rates, and how often each group gets the favourable outcome (an approval or a job interview). A large gap between groups is a warning sign, even when the overall numbers look good. This is the core technique for detecting unfair treatment, because averages hide exactly the groups that are being failed.
Human audits
Automated metrics can't catch everything. A human audit is a structured review in which people examine a sample of a model's inputs and outputs, looking for unfair, harmful or untrue results. Reviewers should include people with the right expertise and a range of backgrounds. Audits work best when they're repeated on a schedule, use clear written criteria, and feed findings back into data and model fixes.
For generative AI, Amazon Bedrock model evaluation supports human-based jobs, where your own work team of employees or subject-matter experts rates model responses against metrics you describe.
Monitoring after launch
A model that was fair at launch can drift. New kinds of users arrive, behaviour changes, and the data stops matching what the model was trained on. Ongoing monitoring means re-running subgroup analysis on recent predictions, tracking complaints and user feedback, and repeating evaluations whenever the model, prompt or data changes.
Trustworthiness and truthfulness need watching too. For generative AI, Bedrock evaluation jobs that use a large language model as a judge offer built-in responsible AI metrics, including Stereotyping, Harmfulness and Refusal, alongside quality metrics such as Correctness and Faithfulness. Automatic evaluation jobs can also score Toxicity against built-in prompt sets.
AWS tools and their status
| Need | Current option | Note |
|---|---|---|
| Automated bias and harm scoring for generative AI | Bedrock model evaluation (judge metrics such as Stereotyping) | Repeatable before each release |
| Human audits of generative AI output | Bedrock human-based evaluation with your own work team | You define the rating criteria |
| Bias metrics for traditional ML models | Amazon SageMaker Clarify | Closed to new customers; existing customers can still use it |
Amazon Augmented AI (A2I), which routes low-confidence predictions to human reviewers, and SageMaker Model Monitor, which watches deployed models for drift, are also closed to new customers. Know what they do, but don't expect them to be the recommended choice for a new project.
On the exam
When a scenario asks how to find out whether a model treats groups fairly, look for subgroup analysis: comparing results group by group. When the labels are suspect, look for checking labeler agreement before retraining. When a team needs repeatable checks on generative AI output without reviewers every time, look for an automated evaluation with responsible AI metrics.