The Interpretability article closed by naming a real, well-documented problem interpretability and explainability techniques exist partly to catch. This article covers that problem directly: AI bias.
The simple definition
AI bias refers to a model producing systematically unfair or discriminatory outcomes for certain groups, typically because it learned those patterns from biased or unrepresentative training data. Recall from the Data article’s “garbage in, garbage out” principle, established at the very start of this glossary. AI bias is that principle’s most consequential, real-world form — a model doesn’t invent unfairness on its own; it learns and often amplifies whatever patterns, including unfair ones, were genuinely present in the data it trained on.
Why this happens mechanically, not maliciously
Recall from the Training article’s core process: a model adjusts its weights to minimize loss across its training examples, as covered throughout the Training Mechanics phase. If a training dataset happens to reflect historical human bias — say, a company’s decade of hiring decisions that favored one group over another — a model trained to predict “who gets hired” from that data will learn to reproduce that same pattern, not because it has any intent or belief about fairness, but because reproducing the pattern genuinely minimizes its training loss on the data it was given.
flowchart LR
A[Historical data reflecting real-world bias] --> B[Model trains to minimize loss on this data]
B --> C[Model learns to reproduce the bias, faithfully and efficiently]
The real story: when Amazon’s own hiring tool taught itself to penalize women
This deserves to be told in full, because it’s one of the most widely cited, genuinely instructive real cases of this exact failure mode.
Starting in 2014, Amazon built an experimental AI recruiting tool designed to score job applicants’ resumes on a 1-to-5 scale, aiming, in one team member’s words, to create “an engine where I’m going to give you 100 resumes, it will spit out the top five, and we’ll hire those.” The system was trained on roughly a decade of the company’s own past resumes — and because the tech industry, and Amazon’s own past hires, had been predominantly male during that period, the model learned a genuine, measurable preference for male candidates.
It specifically penalized resumes containing the word “women’s” — as in “women’s chess club captain” — and downgraded graduates of two all-women’s colleges. Amazon’s engineers edited the system to stop penalizing those specific terms, but, according to people familiar with the project, could not be confident the model hadn’t learned other, less obvious proxies for the same underlying bias.
The company scrapped the tool entirely in 2017, and Reuters’ 2018 reporting on the story became one of the most widely cited real-world illustrations of AI bias in the years since.
ANALOGY vs. TECHNICAL REALITY
Analogy: Think of a new manager who’s told to learn hiring judgment purely by studying which of a company’s past 1,000 hires turned out to be considered “successful” — if that historical record happens to reflect real, past discrimination, the new manager, studying only the pattern in the data with no other context, would learn to replicate that same discrimination, faithfully, without ever being told to.
Where this breaks down: A human manager could, in principle, recognize the historical pattern as unfair and consciously choose not to repeat it.
A model has no such capacity for that kind of reflective, moral reconsideration — recall from the Reasoning article’s honest framing of AI capability — it simply, mechanically minimizes its training loss, with genuinely no built-in mechanism for recognizing that a pattern it learned efficiently might also be one nobody should want reproduced.
A concrete example, layered
For a simple beginner example: a loan-approval model trained on a bank’s historical lending data, if that historical data reflected real, past discriminatory lending practices in certain neighborhoods, could learn to systematically disadvantage applicants from those same neighborhoods today, even with no explicit instruction to consider location or race at all.
For a production example: the Amazon hiring tool case above remains the standard, most frequently cited real-world reference point across the industry precisely because it involved a major, sophisticated tech company, genuinely well-resourced machine learning specialists, and a bias that emerged despite that expertise — a real, humbling demonstration that AI bias isn’t a hypothetical risk reserved for careless or under-resourced teams.
Why fixing surface-level bias doesn’t guarantee the deeper problem is solved
It’s worth being honest about a genuine, documented difficulty here, directly echoed in the Amazon case. Amazon’s engineers could edit the model to stop penalizing the literal word “women’s,” but couldn’t be confident the underlying pattern hadn’t simply shifted to some other, less obvious signal correlated with gender — a real, well-documented challenge in bias mitigation generally, since a model can learn to encode the same unfair pattern through many different, harder-to-detect proxy signals in the data.
A second real case, and an honest example of one that was never resolved
It’s worth telling this one too, precisely because it didn’t end as cleanly as Amazon’s. In May 2016, investigative journalists at ProPublica published an analysis of COMPAS, a proprietary risk-assessment tool from Northpointe used across the U.S. criminal justice system to score defendants’ likelihood of reoffending, directly influencing real bail and sentencing decisions.
ProPublica found that among defendants who were not rearrested within two years, Black defendants had been incorrectly flagged as “high risk” nearly twice as often as white defendants. Northpointe disputed the finding directly, arguing that COMPAS was equally accurate for both races when measured by a different, also legitimate statistical standard — whether a given risk score meant the same real-world probability of reoffending regardless of race, a property called calibration, which COMPAS did satisfy.
Both sides were using genuine, defensible definitions of fairness that turned out to be mathematically incompatible with each other — a real, published finding in the algorithmic fairness research that followed. Unlike Amazon, there was no clean resolution: COMPAS remains in active use in parts of the U.S. justice system today, and the underlying dispute over which definition of “fair” should govern such tools remains, honestly, unresolved.
Where bias can enter the pipeline
Bias does not enter only through training examples. It can appear at several points:
flowchart LR
A[Real world] --> B[What gets measured]
B --> C[Who appears in the dataset]
C --> D[How people label examples]
D --> E[What the model learns]
E --> F[How the product uses the result]
F -->|feedback loop| A
- Selection bias: some groups appear too little or only in unusual situations.
- Measurement bias: the chosen feature is a poor substitute for what the team actually cares about.
- Label bias: human decisions used as labels already contain unfair patterns.
- Deployment bias: a prediction is used for a purpose the model was not tested for.
- Feedback-loop bias: earlier model decisions shape the future data used to retrain it.
A small numerical fairness check
Suppose a face detector is tested on 100 images from Group A and 100 from Group B. It correctly detects 95 faces in Group A but only 75 in Group B.
Overall accuracy = (95 + 75) / 200 = 85%
Group A accuracy = 95 / 100 = 95%
Group B accuracy = 75 / 100 = 75%
The overall result, 85%, hides a 20 percentage-point gap. Production teams therefore examine metrics for relevant groups, error types, and situations rather than trusting one average.
How this connects to GPT and Gemini
Generative models can show bias in names used for occupations, assumptions about cultures, image generation, translations, or the tone used for different people. Teams evaluate many carefully matched prompts, change only the demographic detail being tested, compare the outputs, and have qualified reviewers examine the results. The model is only one part of the system. Retrieval sources, safety filters, ranking rules, and the product interface can reduce or introduce bias too. A responsible test therefore checks the complete application and the real population that will use it.
Common misconception
A measured example from OpenAI models
OpenAI evaluated GPT-4o, o1-preview, and o1 on a bias benchmark called BBQ. Some questions contain enough information for one correct answer. Others are deliberately ambiguous, so the safe answer is that there is not enough information.
On unambiguous questions, the reported accuracy was 72% for GPT-4o, 94% for o1-preview, and 93% for o1. On ambiguous questions, GPT-4o scored 97% and o1 scored 96%. These figures come from OpenAI’s published o1 System Card; they describe that named evaluation and those model versions, not every kind of bias.
These results do not mean that one model is “93% fair.” They measure performance on one particular benchmark. Real applications must also test relevant languages, cultures, disabilities, age groups, and error consequences.
Benchmark result -> evidence about one test
Benchmark result -X-> proof of fairness everywhere
OpenAI also studied whether names associated with different genders or ethnic groups changed ChatGPT responses. The published fairness study reported stereotype rates below 1 in 1,000 when averaged across its tested domains and tasks, while clearly noting that it primarily covered English-language interactions, binary gender associations, four race or ethnicity groups, and a limited set of tasks.
A frequent beginner assumption: that AI bias only happens when a development team is careless or under-resourced, and that a sufficiently careful, well-funded team would naturally avoid it. As the Amazon case directly demonstrates, this isn’t reliable — a major, well-resourced company with genuine machine learning expertise still produced a measurably biased system, precisely because the bias was baked into the historical training data itself, not into any obvious carelessness in the model’s design.
Where this fits in what comes next
You now understand how bias enters a model through its training data, and a real, well-documented case of exactly this happening at scale. The next article, Prompt Injection, shifts to a different category of concern entirely — not a model’s learned patterns being unfair, but a model’s behavior being deliberately manipulated by a malicious input.
In one sentence
AI bias occurs when a model learns and reproduces unfair patterns present in its training data, and Amazon’s own real, documented 2014-2017 hiring tool — which taught itself to penalize the word “women’s” after training on a decade of male-dominated historical hiring data — remains the field’s most widely cited reminder that even sophisticated, well-resourced teams can build genuinely biased systems without intending to.
Verified sources
- NIST Face Recognition Vendor Test: Demographic Effects
- NIST AI Risk Management Framework Core
- OpenAI o1 System Card: fairness and bias evaluations
- OpenAI: Evaluating fairness in ChatGPT
Related Terms
- Author
- TechByteByByte Editorial Team
- Reviewed by
- TechByteByByte Admin
- Published
- Last reviewed