AI governance & ethics

AI bias: causes, types, examples and how to reduce it

A model rejects a qualified applicant. A credit algorithm hands two near-identical customers very different limits. A triage tool quietly routes one group of patients to less care than another. None of these systems set out to discriminate. They learned to, from the data we fed them and the choices we made while building them. That is AI bias, and it is one of the most expensive mistakes a data team can ship into production.

We build data and AI systems at Shipshape Data, and we see the same pattern with clients more often than we would like. A model performs beautifully on the headline accuracy number, everyone signs off, and then months later someone notices it behaves very differently for one slice of the population than another. By that point the bias is already in thousands of live decisions. This guide covers what causes AI bias, the forms it takes, a few well-documented cases, and the practical work that actually reduces it.

Why bias is a business risk, not just an ethics question

Bias tends to get filed under AI ethics, which is fair, but it undersells the problem for anyone running a business. When a biased model is in production, it does not make one bad call. It makes the same bad call over and over, at machine speed, usually against the people least able to challenge it. A loan model that gets one demographic wrong gets them wrong every hour of every day. Scale is the thing that turns a flawed model into a liability.

The legal and financial exposure

Regulators have stopped treating algorithmic discrimination as a lesser cousin of the human kind. The rules that apply to a biased hiring manager increasingly apply to a biased hiring model, and the fact that the decision came from software is not much of a defence. In 2019 the credit card launched by Apple and Goldman Sachs drew a regulatory investigation after customers, including a well-known software developer and his wife, reported very different credit limits despite shared finances. The New York State Department of Financial Services opened an inquiry. The eventual review did not find unlawful discrimination, but the episode still cost real money in legal time and public trust, and it put every large lender on notice.

The harder problem is that you have to be able to explain the decision. When an applicant challenges a rejection and your answer is that the model said no, your legal team is defending a black box. Class actions over biased outcomes in hiring, lending and housing have produced settlements running into millions. Automating a decision does not reduce your exposure. It can raise it, because you have now created a clean, documented, repeatable record of the same outcome landing on the same group.

Operational failures that compound

Set the ethics aside for a moment and bias still fails on its own terms. You bought the model to make better decisions than the manual process it replaced. A biased one does not. A recruitment screen that systematically drops strong candidates from a whole demographic is not being efficient, it is shrinking your talent pool and burning the budget you spent to widen it. A support bot that stumbles on regional accents or non-native phrasing pushes those users to phone lines and inflates the cost you were trying to cut.

These failures also feed themselves. A model that learns from its own outputs hardens its worst habits with every retraining cycle. Meanwhile the humans who work alongside it lose faith in its recommendations and quietly go back to doing things by hand, which erases the efficiency you were promised. You end up paying for a system that produces a negative return and generates a queue of problems for someone else to clean up.

Trust is slow to rebuild

People pay attention to this now. When a system produces an outcome that feels unfair, the person on the receiving end has a phone, an audience, and a screenshot. The story travels faster than any correction you issue. Prospective customers start to wonder whether they will be treated fairly, and existing ones reconsider the relationship. Winning that ground back takes an admission, a clear account of what went wrong, visible corrective work, and then a stretch of sustained good behaviour before anyone believes you again. Some brands never quite shake a high-profile bias story.

Where AI bias actually comes from

The comforting idea that algorithms are neutral is the first thing to drop. A model is a compressed record of the data it saw and the decisions its builders made. Every one of those decisions carries a point of view, whether or not anyone intended it to. Bias does not sneak in from outside. It is usually sitting in the inputs and the design from the start, waiting for production to make it visible.

Training data carries history forward

Your training data is the foundation, and a biased foundation gives you a biased model no matter how good the modelling is. Feed an algorithm decades of records that reflect who got hired, promoted or approved in the past, and it learns those patterns as the definition of a good decision. If historical hiring favoured a particular profile, the model treats that profile as the target. It is not learning to judge merit. It is learning to reproduce yesterday.

Train on biased history and the model does not learn to decide better. It learns to repeat old mistakes with perfect consistency.

How the data was collected matters just as much as what it contains. Groups that show up rarely in the dataset get modelled badly, because the system barely saw them. Image recognition struggled for years with darker skin tones because the reference sets skewed heavily towards lighter ones. Medical models trained mostly on male patients have missed conditions that present differently in women. The gap in the data becomes a gap in the model, and the people in that gap pay for it.

Design choices bake in assumptions

Bias also enters through the modelling itself. Feature selection decides what the algorithm is allowed to consider, and dropping a protected attribute rarely removes its influence. Take ethnicity out but keep postcode, and the model uses location as a stand-in, because in many places postcode correlates tightly with the very thing you tried to exclude. Proxy variables are how discrimination survives a well-meaning cleanup.

The objective you optimise for is another quiet source of trouble. Optimise for overall accuracy and the model will happily nail the majority group and give up on the minority, because that is the fastest route to a high aggregate score. You get a system that is right ninety per cent of the time and reliably wrong for the same ten per cent, and the dashboard shows a number everyone is pleased with. The metric hides the harm.

The main types of AI bias

Bias is not one thing. It shows up at different points in a system's life, and naming the type helps you aim the fix at the right place instead of applying a generic patch that misses the actual cause. It is worth mapping where bias enters across the pipeline so you know which stage you are treating.

Bias in the data

Historical bias is the model absorbing past inequality as if it were a rule. Where records reflect years of skewed human decisions, the algorithm reads them as ground truth and carries them forward regardless of current policy. A lending model trained on data where certain groups were routinely turned down will keep turning them down, even after the policy that produced those rejections has been dropped.

Representation bias is the shortfall of examples for some groups. The model performs poorly on populations it barely encountered in training, because it never learned their patterns. Medical imaging tuned on one demographic misreads others. Voice recognition falls over on accents that were absent from the corpus. The model is not malicious, it is undertrained, and the effect on the underserved group is the same either way.

Bias in the model

Measurement bias comes from choosing a convenient proxy for something you cannot measure directly. Teacher-evaluation models that use test scores as a stand-in for teaching quality miss most of what teaching is, and they punish educators working with the hardest intakes. The proxy is easy to compute and quietly wrong.

Aggregation bias is one model stretched across groups that behave differently. You assume a single set of parameters fits everyone, but the settings that suit the majority produce worse results for the minority. Healthcare models built on pooled demographic data can recommend treatment that works for one group and does little for another, because the average buried the difference that mattered.

Bias in deployment

Evaluation bias is about how you test. If your test set does not reflect the real population, or you report a single accuracy figure that averages across everyone, a model can pass with flying colours while failing a specific group completely. Aggregate metrics are very good at hiding disparate outcomes, which is exactly why a model can clear review and still cause harm the moment it meets real users.

A quick way to place the bias: if the problem was baked in before a single line of model code ran, look at the data (historical and representation bias). If it came from what you chose to measure or how you tuned the model, look at the model (measurement and aggregation bias). If it slipped through because testing flattered you, look at deployment (evaluation bias). Most real incidents are a mix, so treat this as a starting map rather than a single box to tick.

What this looks like in the wild

The theory lands harder with real cases. These are not thought experiments. They are systems that shipped, ran at scale, and affected large numbers of people before anyone intervened. The value in studying them is spotting the same shape in your own projects before they reach that point.

Hiring tools that screen out good candidates

Amazon built an internal recruiting model and scrapped it in 2018 after finding it marked down women for technical roles. The training data was ten years of CVs, mostly from men, because that is who had applied and been hired. The model read male-associated signals as markers of a strong candidate and penalised CVs that mentioned women's activities or all-women universities. Nobody set out to build a discriminatory tool. They fed it the past, and the past discriminated.

Risk scoring in criminal justice

COMPAS, a risk-assessment tool used in parts of the US court system, became the reference case for algorithmic bias after a 2016 ProPublica investigation. The reporting found the tool was roughly twice as likely to wrongly flag Black defendants as high risk, and more likely to wrongly clear white defendants, when compared across similar histories. The vendor disputed the analysis, and researchers have argued at length about which fairness definition should apply, which is part of the lesson: fairness is not a single number, and the choice of definition changes who the model treats well. Courts were leaning on these scores for bail and sentencing while that debate was still open.

Healthcare algorithms that ration care

A 2019 study in Science examined a risk model used across US health systems to flag patients for extra care, and found it systematically underrated the needs of Black patients relative to white patients who were just as unwell. The cause was a proxy. The model used past healthcare spending as a measure of health need, but Black patients had historically incurred lower costs for the same conditions, largely because of unequal access. The model learned the spending gap and mistook it for a health gap, so it recommended less care for people who needed the same or more.

Notice the common thread. In every case the system was doing exactly what it was trained to do. The bias lived in the data and the design, not in some rogue behaviour, which is precisely why it is so easy to miss and so important to test for.

How to reduce AI bias, starting now

Bias will not clear itself up if you leave it alone, and it is far cheaper to catch early than to unpick after launch. There is no single switch that makes a model fair. What works is a set of habits applied across the pipeline, from the data you gather to the monitoring you run long after go-live. None of the steps below need exotic tooling. They need discipline and the willingness to look for problems you would rather not find.

Audit the data before you trust it

Start with where the data came from and who is in it. Run demographic breakdowns of your training set and find the groups that are thin or missing, then go and get more representative data for them, whether through fresh collection or carefully generated examples that balance the set. If the historical record is skewed, you need something to counterweight it, not a model that treats the skew as truth.

Write it all down. Track how each dataset was gathered, which populations it covers, and the limitations you already know about. A short data card for every source, listing demographic coverage, collection context and known gaps, gives everyone downstream the information they need to judge whether that data is safe to use for their case. This is unglamorous work and it is where most bias is either caught or waved through.

Test for fairness throughout, not at the end

Bias testing belongs in the loop, not in a final gate before launch. Define fairness metrics that look at performance across groups, and compute them separately for each population that matters: accuracy, false positive rate and false negative rate, group by group. One blended accuracy figure is the number most likely to lie to you. Break it apart and the disparities you need to see become visible.

Push on the edges too. Build adversarial and edge-case tests that probe how the model treats underrepresented groups and unusual inputs, shift the demographic profile of your test data and check whether fairness holds, and record every disparity you find alongside what you plan to do about it. A gap you have documented and are tracking is a manageable risk. A gap nobody looked for is the one that turns up in an audit.

Build for explanation and accountability

You cannot govern what you cannot see. Favour approaches that let you explain individual decisions and trace which features drove a given prediction, so an auditor can catch a proxy variable quietly encoding a protected characteristic. Log decisions across demographic groups as a matter of course, so you have an audit trail to interrogate when someone asks why the model did what it did. Clear ownership matters as much as the technology: someone has to be accountable for the model's behaviour in production, with the authority to pull it if it starts drifting. This is the heart of practical AI governance, and it is far easier to build in from the start than to retrofit under pressure.

Where to start

Fair AI is not a compliance box you tick once. It is a property you design in from the first data decision and keep checking for the life of the system. The reward is not only staying clear of legal trouble, though that matters. A model that works properly across your whole user base is simply a better model. It makes more accurate decisions, it earns trust instead of eroding it, and it holds up when someone finally looks closely.

Most bias we find with clients traces back to the same root: a data foundation that nobody audited before the modelling began. Get that right and a great deal of the risk drops away, because you are no longer building on inputs you never inspected. Get it wrong and no amount of clever modelling on top will save you. That is the work we do, and it is where we would start.

If you want to know where bias might already be sitting in your pipeline before it reaches a live decision, that is exactly the kind of question a readiness review answers. Talk to us and start with a clear view of your data foundation rather than a nasty surprise in production.

Start at your core.

Tell us where your data is today and what you want AI to do. We will come back with a straight answer on what your foundation needs and where the quickest real win is.

Talk to us