AI Ethics & Bias

Welcome to Day 6, post 3. We've defined bias and argued why it matters; now we get mechanical. You can't close a door you can't find, so this post maps every stage where bias enters an AI system — and there are more doors than most people expect.

The central lesson is that bias is not a single bug located in one place. It seeps in throughout the pipeline: data collection, labelling, training, deployment, and feedback. Understanding the full map is what lets you intervene effectively instead of fixing one visible symptom while the real cause leaks in elsewhere. By the end you'll also understand why the most popular 'fix' — deleting the sensitive column — doesn't work.

The framing here corrects a common misconception: that bias lives in 'the algorithm' and can be patched there. In reality it enters at every stage of the pipeline. It comes in when you decide whose data to collect, when humans assign labels, when the model amplifies whatever patterns it finds, when you choose who the system gets used on, and when feedback flows back to shape future data.

The practical implication is that fixing one stage while ignoring the others just relocates the problem. Clean your training data but optimise a biased metric, and bias returns at training. Debias the model but deploy it on a population it wasn't built for, and bias returns at deployment. Effective fairness work has to address the whole pipeline, which is why knowing the full map (the next slides) matters so much.

This pipeline diagram is the post's backbone: five stages, each with its own bias risk. Collect data — who's missing from it? Label data — whose judgement defined 'correct'? Train model — which patterns is it amplifying? Deploy — who is it actually used on, versus who it was built for? Feedback — how do its outputs reshape future inputs?

Laying it out as a pipeline does two things. First, it shows bias as a property of the whole flow, not a single component. Second, it gives you a checklist: at each stage you can stop and ask the stage-specific question. Most real-world bias incidents trace back to neglecting one of these five checkpoints. The diagram turns 'check for bias' from a vague aspiration into five concrete, answerable questions you can run on any project.

Stage one: unrepresentative data. If a group is under-represented in your training set, the model simply hasn't seen enough examples to perform well for them, so its accuracy drops for that group. The 'Gender Shades' finding from post 1 is the textbook case: facial-analysis systems trained largely on lighter-skinned faces performed worse on darker-skinned faces.

What makes this insidious is that the model isn't malfunctioning — it's behaving exactly as expected given a gap in its experience. The bias is in the data's composition, not the code. The fix begins with auditing representation before training: who is in this dataset, in what proportions, and who's missing? A gap you don't measure becomes a performance gap you ship. Representation is the first door, and often the easiest to check if you remember to look.

Stage two: biased labels. Even with perfectly representative data, the labels — the 'right answers' the model learns from — come from humans, and humans carry bias. If past loan officers unfairly rejected a group, those rejections are recorded as the 'ground truth', and the model dutifully learns to reproduce them.

The subtle point is that, by its own internal logic, the model isn't wrong at all — it's faithfully copying a biased teacher. The unfairness was injected before the model existed, in the human decisions that generated the labels. This is harder to fix than representation gaps, because the bias is woven into the very definition of 'correct'. It forces an uncomfortable question: do we trust our historical labels as ground truth, or do we need to question the process that produced them? Often the data itself is the problem, not the model.

Stage three: proxy variables, the reason naive fixes fail. Even after you remove sensitive attributes like race or gender, other features quietly encode them. ZIP code correlates strongly with race in many places; first names hint at gender and ethnicity; shopping or browsing history can reveal both. The model reconstructs the protected attribute from these 'innocent' columns and discriminates just as before.

This is the single most important mechanism to understand in AI fairness, because it defeats the intuitive solution. 'We removed gender, so the model can't be sexist' is false — the model finds gender hiding in correlated features and uses it anyway. Worse, by deleting the column you've blinded yourself to the bias while leaving it fully operational. Proxies are why fairness requires measurement and intervention, not just omission, as the code post will demonstrate concretely.

Stage four: feedback loops, where bias compounds after deployment. Once live, a model shapes the data it will later be trained on. Recommend one kind of content and users can only engage with what they're shown, which 'proves' the recommendation was right and feeds that confirmation back into training. The loop quietly entrenches whatever bias it began with.

This connects to the predictive-policing example from post 1, and it's the stage people forget because it happens after launch, outside the tidy training phase. A system that launches only mildly biased can spiral as its own outputs poison its inputs over time. The defence is ongoing monitoring rather than a one-time pre-launch check — you have to watch deployed models for drift and self-reinforcement, because the pipeline doesn't stop at deployment; it loops back to the beginning.

Having mapped the doors, this slide names how teams actually fight back, stage by stage. Audit data for representation gaps before training (addresses stage one). Measure performance per group rather than only overall (catches problems at every stage). Test for proxies by checking whether a model can predict the sensitive attribute from the 'neutral' features (addresses stage three).

And apply fairness constraints during or after training to actively balance outcomes (a direct intervention). Notice these are concrete, doable techniques — not vague aspirations. Each maps to a stage in the pipeline, which is why the map matters: it tells you which tool to reach for. The code post puts several of these into practice, but the meta-point is that bias is fightable with a known toolkit, provided you've located where it's entering.

This comparison surfaces the hard truth that fairness often costs accuracy. The left column, maximising accuracy, optimises overall hits, is easiest to report, and is the default — but it can quietly fail a minority group and ignores who bears the cost of errors. The right column, adding fairness, constrains the model to balance errors across groups, which may lower overall accuracy but yields a system that's defensible and lawful.

The point isn't that fairness is 'better' than accuracy — it's that they genuinely trade off, and pretending otherwise is naive. A model tuned purely for aggregate accuracy will often achieve it by performing well on the majority and poorly on a minority. Choosing to give up some accuracy for balanced treatment is a real, deliberate decision with real costs. Mature practice is to make that trade consciously and document why, not to stumble into whichever the default optimiser produces.

This slide sets a realistic expectation: there is no button that makes a model perfectly fair. Partly that's because the reasonable fairness definitions provably conflict (post 1), so 'perfectly fair by every measure' is mathematically unavailable. The honest goal is therefore management, not magic: measure the bias, choose which fairness criterion matters for this context, and deliberately reduce harm against it.

This matters because the fantasy of a complete fix leads to two failure modes — either giving up ('bias is unsolvable, so why try?') or false confidence ('we ran the debias function, we're done'). The truth is in between: bias is measurable and reducible but not eliminable, and managing it is an ongoing, judgement-laden practice. Accepting that reframes fairness from a checkbox to a continuous responsibility, which is exactly the right mental model for high-stakes AI.

The closing mistake is the most common false fix in the field: 'just remove the sensitive column'. It feels decisive and even principled — if the model can't see race or gender, surely it can't discriminate. But proxies (from stage three) smuggle the information back in, so the discrimination continues, and now you've made it worse in a specific way: you can no longer measure the bias you've hidden.

The counterintuitive correct move is often to keep the sensitive attribute precisely so you can audit fairness across groups — using it to measure and correct outcomes, not to make individual decisions. This 'fairness through awareness' beats 'fairness through blindness'. Understanding why the obvious fix backfires is the clearest sign you've grasped how bias actually works, and it sets up the code post, which proves the proxy problem with a few lines of Python.

So bias enters at every stage — data, labels, proxies, feedback — fairness and accuracy genuinely trade off, you manage bias rather than erase it, and deleting the sensitive column hides bias instead of fixing it. Save this map; it's the diagnostic you run to find where unfairness is actually entering a system.

Tomorrow we prove it in code. Day 6, post 4 measures bias with real Python — approval rates by group, the legal 80% rule, and a demonstration that 'neutral' features still leak gender — then applies a simple mitigation. The mechanics become numbers you can compute.