Protected Attributes: Which Slides Get Tested

Opening Scene

A lab can’t test every conceivable contaminant on every sample that comes through the door — there isn’t time, budget, or a reason to run a hundred stains on a routine blood draw. Instead, the lab decides, based on what’s actually plausible and consequential, which specific tests to run on which specific slides. A bias audit works the same way: it can’t check a model’s behavior against every conceivable human characteristic, so it has to deliberately decide which attributes actually warrant testing.

In Plain English

A protected attribute is a characteristic — race, gender, age, disability status, religion, national origin, and others depending on jurisdiction and context — that legal frameworks and ethical practice single out as one a model’s decisions should not be unfairly influenced by. Testing a model for bias means running its outputs through group-by-group comparisons specifically along these attributes, checking whether outcomes differ in ways that aren’t justified by legitimate, relevant factors. Which attributes actually get tested is itself a judgment call: some are legally mandated depending on the domain, some are ethically obvious given the use case, and some require deliberate thought about which groups a specific model could plausibly harm.

The Old Way

Before protected attribute testing was a standard, deliberate step in model evaluation:

Models were frequently evaluated without ever explicitly checking performance broken out by race, gender, age, or other legally or ethically relevant groupings.
When protected attributes weren’t included as direct model inputs, teams sometimes assumed the model couldn’t possibly be biased along those lines, ignoring the reality that correlated proxy variables can reproduce the same bias indirectly.
The specific set of attributes worth testing was rarely decided deliberately; it was often whatever data happened to be available, rather than what the use case actually demanded.

Deciding, deliberately and in advance, which slides need testing is what separates a genuine audit from an incomplete one.

What’s Changing (and Why AI Is the Reason)

Teams increasingly build an explicit list of protected attributes to test against before evaluation begins, rather than discovering gaps in coverage after the fact.
This connects to the broader compliance discipline covered in this content library’s dedicated data privacy and compliance series, since protected attribute categories often overlap directly with legally regulated personal data.
As AI models draw on ever-larger, more varied datasets, the number of variables that can act as a proxy for a protected attribute — a zip code standing in for race, a shopping pattern standing in for gender — has grown, making deliberate proxy-awareness a genuine necessity rather than a theoretical concern.

The Metaphor, Fully Extended

The Lab’s Test Selection	Protected Attribute Concept
Deciding which specific stains to run on which slide	Deciding which specific attributes to test a model against
Testing based on what’s actually plausible and consequential	Testing based on legal requirements and realistic potential harm
A test that could miss a contaminant nobody thought to check for	An audit that could miss bias along an attribute nobody thought to test
A hidden compound mimicking a known contaminant’s signature	A proxy variable indirectly reproducing a protected attribute’s effect

For Beginners: What to Actually Do

Learn the commonly recognized protected attributes — race, gender, age, disability, religion, national origin — as a starting checklist, not an exhaustive one.
Practice identifying variables in a dataset that might act as a proxy for a protected attribute even if the attribute itself isn’t directly included.
Ask, for any model you evaluate, “which groups could this plausibly harm” before assuming the standard checklist covers everything relevant.

For Practitioners and Leaders: The Deeper Layer

Build a documented, use-case-specific list of protected attributes to test against before evaluation begins, informed by both legal requirements and realistic harm scenarios.
Actively audit for proxy variables that could reproduce a protected attribute’s effect even when that attribute isn’t a direct model input.
Revisit the protected attribute list periodically, since new use cases and new data sources can introduce new plausible harms the original list didn’t anticipate.

Quick Recap

Protected attributes are the specific characteristics a bias audit deliberately tests a model’s outputs against.
Which attributes to test is a judgment call shaped by law, ethics, and the specific use case, not an automatic or exhaustive list.
Excluding a protected attribute as a direct input doesn’t prevent bias if a correlated proxy variable remains.
A documented, deliberate attribute list is what separates a genuine audit from an incomplete one.

Where This Fits in the Series

Article 4 compared two specific fairness tests. This article stepped back to the prior question of which attributes those tests actually get run against. Article 6 looks at what it actually looks like when one of those tested groups comes back with a noticeably worse reading — disparate impact.