Tensor LabsTENSORLABS

Audit the hiring model before a regulator does

Accurate and unfair are not the same number

June 30, 20263 min read4 sectionsBy Ahmed Abdullah
Audit the hiring model before a regulator does

Introduction

Halfway through the demo, the head of legal asked her question. The screening model was impressive: it ranked thousands of applicants in seconds, and its picks closely matched who the company had actually hired and promoted over the past decade. Everyone nodded at the accuracy number. Then legal, who had been quiet, asked the only question that mattered: can you prove it does not discriminate? The room went still, because the honest answer was that nobody had checked. They had measured whether the model was accurate. They had never measured whether it was fair, and the two are not the same question.

Here is the uncomfortable mechanism underneath that silence. The model was trained to predict who the company hired before. If past hiring favored certain groups, for reasons good, bad, or simply unexamined, then a model that reproduces that pattern with high accuracy is not neutral. It is bias, laundered through math and handed the authority of a number.

An accurate model trained on a biased history does not remove the bias. It automates it and gives it a clean interface.

The right way: test selection rates before launch, not after a lawsuit

The method is adverse-impact testing, and it is concrete enough to run before a model ever sees a real candidate. For each protected group you compute the selection rate, the share of applicants the model advances. Then you compare. A longstanding benchmark, the four-fifths rule, says the selection rate for any group should be at least eighty percent of the rate for the highest group. Fall below that and you have measurable adverse impact, the same standard regulators and courts already use. This is not a vibe or a values statement. It is a ratio you compute on a held-out set and watch like any other gate.

If the model fails, you do not ship it and hope. You mitigate: rebalance the training data, adjust the decision threshold, and hunt down the proxies, which is the part teams underestimate.

You cannot fix this by deleting the gender column

The intuitive fix, just do not give the model the protected attributes, does not work, and knowing why is the difference between a real audit and a fig leaf. Remove gender and race and the model rebuilds them from proxies: the zip code that tracks demographics, the college that correlates with background, the six-month gap that often marks caregiving. The information leaks back in through correlated features, and a model blind to the attribute can still discriminate sharply on it. That is exactly why you measure outcomes, the selection rates, rather than trusting inputs. You test what the model does, not what you think you withheld.

Dropping the protected field does not make a model fair. It makes the bias harder to see.

Why this is now table stakes

This stopped being optional. Regulations now require bias audits of automated hiring tools, with laws already on the books mandating annual adverse-impact testing and published results. Beyond the law, the reputational math is brutal: a discriminatory screening tool is the kind of story that outlives any efficiency it bought. Building the audit in from the start is cheaper than every alternative, and far cheaper than discovery.

We built this gate for a team deploying a candidate-screening model, and the model did not ship until its selection rates passed, with the proxies tracked down and the results documented, so the answer to legal's question was a report instead of a silence.

Audit the hiring model before a regulator does and fairness stops being something you assert in a values deck. It becomes a number you measure, a gate you pass, and a document you can hand to anyone who asks.

TensorLabs builds the bias-audit and adverse-impact infrastructure behind that kind of prove-it-is-fair hiring AI.