Every machine learning team that ships into a regulated environment eventually has the same conversation with their compliance counterpart. The compliance team explains that an algorithmic bias audit is needed. The ML team explains that the audit, as scoped by the compliance team, would consume the ML team's roadmap for two quarters. The compliance team explains that the audit, as scoped by the ML team, would not pass an enforcement review. Neither side is wrong. Both are missing the version of the audit that actually fits.
The right scope for a bias audit, in 2026, is narrower than the worst-case interpretation of the law and broader than the lightest-touch interpretation. Hitting that scope is the difference between a defensible compliance posture and a project that runs over the team's capacity.
This is the working version of how to scope a bias audit so that it is real, defensible, and fits the engineering team's actual operating budget.
Start from the regulatory text, not the consultant deck
The first move is to read the regulatory text that applies to the system, not the summary deck the consultant or vendor presented at the kickoff. The regulations on algorithmic bias differ meaningfully from each other. NYC Local Law 144, the EU AI Act, Colorado SB21-169, Illinois AIVID, the federal EEOC guidance, and the various state-level developments each define the obligation slightly differently.
The audit scope is determined by the obligations the system actually has, which is determined by the jurisdictions the system operates in and the categories of decisions it makes. A system used only in California to make decisions that do not involve employment, credit, or housing has a much narrower audit obligation than the same system used in New York to make employment decisions.
Consultants and vendors tend to scope to the worst case, partly because the worst case is also the largest engagement. The team's scope should be derived from the actual obligations, not from the worst case. Reading the statute is unglamorous and takes a few hours. Most engineering and compliance teams have not read the statute that governs the system they are auditing. That is correctable.
Define the population and the decision
A bias audit requires answering, with precision, two questions. What is the population the system makes decisions about, and what is the decision the system actually makes.
The population is rarely the same as the data the system was trained on, and rarely the same as the data the system was tested on at deployment. It is the actual current users or candidates or applicants the system is producing decisions about right now. The audit must use a representative sample of the actual population, or it will produce numbers that do not predict the disparate impact a regulator would measure.
The decision is rarely as clean as it sounds. A scoring model whose output is then used by a downstream rule to produce an accept or reject is, for audit purposes, two systems. The model that produces the score and the rule that converts the score to a decision. Auditing only the model misses the rule. Auditing only the rule misses the model. Both are required for the audit to be defensible.
The team that gets the population and the decision right at the scoping stage saves weeks later. The team that gets them wrong typically discovers the gap mid-audit, at which point the audit has to be rebuilt from the data layer up.
Pick the metrics that match the obligation
The metrics required by a bias audit depend on the regulation. The most common are selection rate by protected category and impact ratio between categories, with cuts by sex and by race-ethnicity at minimum. Some regulations require additional cuts, including age, disability status, or intersectional combinations.
The team should pick the metrics that match the obligations, run them, and document the result. Adding metrics beyond the obligation is fine when the data is available. Adding so many metrics that the audit becomes a research project is where audits go to die.
A common mistake is to demand statistical significance tests on every metric. For most populations, the sample sizes are large enough that the disparities, when present, are readily measurable. For populations with small sample sizes, the audit should report the metric and be explicit about the confidence interval, rather than expanding into a separate research workstream to refine it. The auditor's job is to measure and report. The model team's job is to fix what the measurement reveals.
The data work is the long pole
In almost every audit, the longest workstream is not the analysis. It is getting the data into a state where the analysis is possible.
The data needed for a bias audit is the categorical data that identifies the protected categories of the affected population. Most production systems do not collect this data, because the engineering teams have correctly avoided collecting it absent a clear business need. The audit creates the business need, but the data did not exist before.
The team has two options. Use historical data where the categories can be inferred or self-reported, accepting the limitations of that data. Or institute a forward-looking data collection process and run the audit on the resulting population in a few quarters.
Both are legitimate. The choice depends on the regulatory deadline and the quality of the inferable data. Many systems can produce a defensible audit on historical data with category inference, with a clear methodology note about how categories were derived. Others cannot, and the audit has to wait on the new data collection to mature.
The teams that get this right plan for the data work as the long pole and shape the engineering schedule around it. The teams that treat the data work as a small step inside the larger audit are the teams whose audits run over by months.
What the audit team actually delivers
A defensible audit deliverable is a document that contains, at minimum, a clear description of the system being audited, a clear description of the population, the methodology used to identify protected categories, the metrics computed and how they were computed, the results presented in a form that matches the regulatory format where applicable, an interpretation that distinguishes substantive findings from sampling noise, and a list of recommendations the audit team would make if asked, with their estimated cost.
It does not contain a marketing pitch for the audit firm. It does not avoid uncomfortable findings. It does not soften the recommendations to make them politically easier. The audit's value comes entirely from its credibility, and the credibility depends on the audit team being willing to write findings that the customer might not want to read.
When choosing an audit firm, the question to ask is not what they have audited before. It is what they have written that the customer pushed back on, and how they handled the pushback. A firm whose past work shows nothing controversial has either chosen safe customers or has softened past findings until they were uninteresting.
The right cadence
A real bias audit takes between two and twelve weeks of audit-team effort, depending on system complexity and data readiness. The customer engineering team's involvement is between forty and a hundred and twenty hours total, concentrated in the first and last phases of the audit.
That budget is roughly half what a poorly scoped audit consumes and double what a too-light audit produces. Teams that hit the right budget tend to have done two things. They have read the statute. They have done the data work in advance.
The teams that miss it on either dimension tend to have audits that either consume an unreasonable share of the engineering quarter or produce a report that does not meet the obligation. Both outcomes are avoidable with planning. The planning is mostly free. The cost of skipping it is significant.