AI Bias and Fairness: Detection and Mitigation Strategies

This article is part of my series on AI safety and governance. If you haven't read the pillar article, it'll give you the broader context for how this fits in.

Why I Think This Gets Treated as a Checkbox When It Shouldn't

I mentioned in the pillar article that I think bias and fairness work often gets reduced to something like a compliance checklist, run a fairness audit, check a box, move on. The more I've looked into this, the more I think that framing misses what makes this work genuinely hard. Bias isn't a single thing that shows up in one place and gets fixed once. I've come to think of it as something that can enter a system at almost any stage, and that can look completely different depending on where you're standing.

Where I See Bias Actually Coming From

I think it's tempting to assume bias is mostly a training data problem, get better data, get a less biased model. I don't think that's wrong exactly, but I think it's incomplete in ways that matter.

Training data is the most commonly discussed source, and for good reason. If the data used to train a system reflects historical patterns of discrimination, underrepresentation, or stereotyping, I think it's reasonable to expect the system to reflect those patterns too, often in ways that are subtle and hard to spot just by looking at outputs in isolation.

Problem framing is something I think gets much less attention, but I've come to see it as just as important. The way a problem gets defined, what's being predicted, what counts as a good outcome, what gets measured, shapes everything downstream. I think of an example like a hiring tool: if "success" is defined based on outcomes for employees hired under a system that itself had biased hiring patterns, then even a technically well-built model trained on that data will tend to reproduce those patterns, because the definition of success was never neutral to begin with.

Deployment context is the third source I think matters enormously, and it connects to themes I raised in my risk assessment article. A system that performs reasonably well on average can still perform very differently across different groups of people, and those differences might only become visible once the system is actually deployed at scale, in a context where its outputs interact with other systems, incentives, and human decisions in ways that weren't anticipated.

I think the reason I find this framing useful is that it makes clear why "just fix the data" isn't a complete solution. Even with perfectly representative data, a poorly framed problem or an unanticipated deployment context can still produce unfair outcomes.

The Part I Find Genuinely Difficult: Defining Fairness

I think if there's one thing I'd want people to take away from this article, it's that "fairness" isn't a single, agreed-upon concept, and I don't think that's a flaw in how people are thinking about it. I think it reflects something real about the underlying ethical questions.

Here's the kind of tension I mean. One reasonable definition of fairness might be that a system should treat individuals the same regardless of group membership, sometimes called individual fairness. Another reasonable definition might be that a system's outcomes, in aggregate, should be similar across different groups, sometimes called group fairness or demographic parity. These two definitions can directly conflict with each other. A system that achieves equal outcomes across groups might have to treat individuals differently based on group membership to get there. A system that treats every individual identically might still produce very different aggregate outcomes across groups if the groups start from different positions.

I don't think there's a way to satisfy every reasonable definition of fairness simultaneously in every context. I think this means that choosing a fairness definition is itself a value judgment, not something a technical process can resolve on its own. And I think being upfront about this is more honest than presenting fairness as a single metric that, once optimized, means a system is "fair."

Detection: How I Think About Finding Bias

Given that bias can enter at multiple stages and fairness can be defined multiple ways, I think detection has to be similarly multi-pronged.

I think disaggregated evaluation, looking at how a system performs across different subgroups rather than just in aggregate, is close to a baseline requirement. A system that looks good on average can be hiding very different performance for different groups, and I don't think aggregate metrics alone can reveal that.

I also think it's important to test not just outcomes but the inputs that lead to them. If a system is making decisions based on factors that correlate strongly with protected characteristics, even if those characteristics aren't used directly, I think that's worth surfacing, because it can produce biased outcomes through what amounts to a proxy.

I think ongoing monitoring matters here just as much as it does in the broader risk assessment context I discussed earlier in this series. A system that looked fair at launch, based on the data and context available at the time, can drift toward unfair outcomes as the population it's used on changes, or as it's applied to new contexts it wasn't originally evaluated for.

Mitigation: What I Think Actually Helps

I think mitigation strategies roughly map onto the stages where bias can enter, though I'd be cautious about treating any of these as a complete fix on their own.

At the data stage, I think efforts to make training data more representative, and to be more deliberate about what's included and excluded, can help, though I don't think this alone solves problems that originate from how a problem is framed rather than from the data itself.

At the modeling stage, I think there are technical approaches that explicitly account for fairness considerations during training, sometimes by constraining a model to satisfy certain fairness criteria, or by adjusting how different examples are weighted. I think these approaches can be genuinely useful, but I'd also flag that they typically require choosing a specific fairness definition, which brings us back to the value judgment I described earlier. A technical fix doesn't make that judgment go away; it just embeds a particular answer to it into the system.

At the deployment stage, I think human oversight plays an important role, particularly for high-stakes decisions. If a system's output is one input into a decision that a person ultimately makes, rather than the decision itself, I think that creates an opportunity to catch and correct biased outputs before they translate into real-world harm, though I'd also note that human decision-makers bring their own biases, and oversight isn't automatically a fix either.

Why I Think This Connects Back to Transparency

I think bias and fairness work depends heavily on the kind of visibility I discussed in my article on explainability and transparency. You can't do disaggregated evaluation without access to information about how a system performs across groups. You can't investigate whether a problem was framed in a way that embeds bias without transparency into how that framing happened. And you can't hold an organization accountable for fairness commitments without some way of verifying what those commitments actually translate to in practice.

I think this is part of why I see bias and fairness as connected to the broader governance themes in this series, rather than as a narrow technical subfield. The technical work matters, but I think it only delivers on its promise if it's paired with the kind of documentation, review, and external accountability I discussed in my article on responsible AI development.

Where I Land on This

I think the honest summary is that bias and fairness in AI systems is ongoing work, not a problem that gets solved and then stays solved. Definitions of fairness involve real value judgments that different people will reasonably disagree about. Bias can enter at multiple stages, and addressing one source doesn't guarantee the others are addressed too. And the deployment context, which is often the hardest to anticipate in advance, can shift the picture entirely.

I don't think any of this means the work isn't worth doing, quite the opposite. I think it means the work needs to be ongoing, multi-pronged, and honest about its own limitations, rather than treated as something that produces a clean, final answer. I think that's a higher bar than a one-time audit, but I also think it's a more accurate description of what this kind of work actually requires.