Audit the hiring model before a regulator does
Accurate and unfair are not the same number

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.
You might also like
Keep reading from the journal.
June 29, 2026AI
Define the metric once, or argue about it forever
One definition, or an argument that never ends
June 29, 2026AI
Build an Event-Driven Gemini API Pipeline with Webhooks Instead of Polling
On June 2026, Google added event-driven Webhooks to the Gemini API, so the Batch API and long-running operations can call your server when they finish instead of making you ask.
June 29, 2026AI
Run LLM-Generated Code Safely with Cloudflare codemode and Dynamic Workers
Cloudflare's Agents SDK v0.16.1, shipped June 16, 2026, includes code mode: a way to let a model write a single program and execute it inside a sandboxed Dynamic Worker instead of making one tool call at a time.