A Vendor Model Update Can Outdate Your Hiring Bias Audit

Consider the record that should sit beside every automated hiring decision: a deployment entry naming the model artifact, scoring configuration, input schema and activation time. An employer reviewing applicants for a warehouse supervisor role may have a current audit PDF from its screening vendor, yet find that the deployment entry points to a model released after the auditor completed the test.

That mismatch is the issue. The annual date answers one compliance question. It does not establish that the auditor measured the system producing today’s scores.

New York City’s automated employment decision tool law provides the clearest operational example. It generally bars an employer or employment agency from using a covered tool unless “such tool has been the subject of a bias audit conducted no more than one year prior to the use of the tool.” The city defines a bias audit as an impartial evaluation by an independent auditor that includes testing for disparate impact, meaning materially different outcomes across protected groups.

The law and implementing rules require calculations and public disclosures around the tool’s results. They do not expressly say that every vendor release starts a new annual clock, nor do they require the published audit summary to carry a cryptographic model identifier. That gap does not make version changes irrelevant. It makes version control an employer’s evidence problem.

This analysis is not legal advice. Coverage and obligations depend on how a system is used, the jurisdiction and the facts of a particular employment process.

An audit measures a particular system behavior

A hiring tool may parse resumes, convert selected fields into features, produce a score and rank candidates for a recruiter. The score can change without a visibly new product. A vendor might retrain model weights, add recent employment as an input, alter how missing credentials are handled or move the score threshold that determines which applications reach human review.

Each change affects a different part of the deployment entry.

A weights update changes the mapping from inputs to scores. An input change alters what information the mapping receives. A threshold change can leave every raw score untouched while changing who advances. Even a preprocessing revision, such as treating an unrecognized school name as missing rather than grouping it under “other,” can shift outcomes for applicants whose resumes follow different patterns.

Bias audit results are therefore attached to more than a product name. They reflect a model artifact, its surrounding code and configuration, a defined population, a measurement period and the selection rule used during testing. If one of those components changes, the employer needs to determine whether the earlier evidence still describes the operating tool.

New York City’s rules direct auditors to calculate selection or scoring rates and impact ratios across specified sex, race and ethnicity categories, including intersectional categories where the data permits. An impact ratio compares one group’s rate with the rate of the group receiving the highest rate. Those calculations describe observed or tested outputs. They are not a permanent certification that later versions of the product are unbiased, valid for every job or compliant with every employment law.

The deployment entry should make that distinction visible. “Vendor screening platform, current version” is not enough.

Build the version chain before assessing the change

The employer first needs the identifier for the system the auditor evaluated. A useful evidence package links the audit report to the model artifact or service release, feature schema, preprocessing code, scoring threshold and job configuration. Where software is packaged in a container, a container digest can identify the exact image; where the vendor operates a closed cloud service, the employer may need a vendor-issued release identifier and a signed change record instead.

A model card or marketing release note is weaker evidence. It may describe intended use and broad limitations without identifying the code path that scored a particular applicant. Semantic version labels such as “major” or “minor” also reflect the vendor’s release policy, not the likely effect on selection rates.

Next, compare the audited deployment with the new one. The change record should state which components moved, when traffic switched, whether old scores were retained or recomputed, which job families received the update and whether the employer changed its own cutoff or recruiter workflow at the same time. A vendor statement that accuracy improved does not answer those points, and an aggregate performance result can hide movement concentrated in one applicant group.

The employer also needs lineage for the audit data, meaning a record of where the tested examples came from and how they were transformed. New York City’s rules favor historical data from the tool’s actual use; test data may be used when historical data is unavailable or insufficient, with an explanation. If the updated system accepts a new input that does not exist in the historical records, replaying those records may silently fill the field with a default value. The resulting audit would test fallback behavior, not normal production use.

That is why the deployment entry, the audit dataset and the vendor change log must connect. Without that chain, a recent report can be impossible to map to a current score.

Decide whether the old evidence can travel

The practical decision is not limited to “audit again” or “do nothing.” Employers can first run a controlled comparison that sends the same records through the old and new configurations, while preserving each version’s raw score and advance decision. This is a regression test, a comparison designed to find behavior that changed after a software revision.

The comparison should examine whether candidate rankings moved, whether pass rates changed at the operating threshold and whether missing or unusual inputs now receive different treatment. Group-level audit metrics should then be recalculated for the new outputs using the same population, where lawful and methodologically appropriate. Stable aggregate accuracy does not settle the matter because two models can make the same number of correct predictions while changing which applicants receive favorable outcomes.

Population fit matters too. Evidence from hourly retail hiring may not transfer to an executive search workflow that uses different resume fields and a different cutoff. The EEOC’s Uniform Guidelines on Employee Selection Procedures treat validity as connected to a particular selection procedure and employment context; they also warn that an impact ratio above the commonly cited four-fifths measure does not automatically establish the absence of adverse impact.

A narrow change may support continued reliance on some earlier evidence. A logging patch that does not alter inputs, scores, thresholds or routing is unlike a retrained model. The employer should still retain proof that behavior remained unchanged, rather than accepting the vendor’s release category as the conclusion.

Changes to weights, input definitions, protected-group handling, score normalization, ranking logic or advancement thresholds deserve a stronger presumption that the prior audit needs supplementation or replacement. The same applies when the employer maps the tool to a new job family, because the audited applicant population and selection context may no longer match.

A fresh independent audit costs auditor time, data preparation work and possibly a delayed release. Reusing weak evidence is cheaper until an employer must reconstruct which system made a disputed decision. A controlled rollout can reduce that tradeoff: hold the new version from employment decisions, replay representative records, obtain updated audit evidence, then activate it with a recorded approval and a rollback path.

The vendor contract has to support the audit trail

Cloud vendors can update models without shipping software to the employer. Procurement terms therefore need to make change notification an engineering control, rather than a courtesy email sent after deployment.

The contract or service schedule should identify changes that require advance notice, preserve access to prior release information and require a stable identifier in decision logs. It should also allocate responsibility for supplying data to an independent auditor, explain whether the vendor can reproduce earlier scores and set a retention period long enough to investigate a hiring decision after the system has moved on.

These controls go beyond the fields expressly required in New York City’s public audit summary. They are not presented here as statutory commands. They are the records an employer needs to show that an audit applied to the tool it used.

Federal employment law adds a separate constraint. EEOC guidance has warned that an employer may remain responsible when a vendor’s automated procedure causes unlawful discrimination. A contract can require cooperation or indemnification, but it cannot make the employer’s actual selection process disappear.

Return to the deployment entry. Before the new release handles applicants, it should point to the approved artifact, the relevant audit evidence, the comparison results and the person who authorized activation. If the vendor cannot provide a stable version identifier or describe changed scoring inputs, the employer cannot complete that record. The fallback is the prior verified release or a human process that does not use the unverified score.

Questions people ask

Does every vendor update require a new bias audit?

New York City’s rule does not expressly impose a new audit for every software release. The employer still needs evidence that the audited and deployed systems match in relevant behavior. Changes to model weights, inputs, ranking logic or advancement thresholds are stronger reasons to commission new or supplemental testing than a patch confined to logging.

Is an audit valid until its one-year anniversary?

The date establishes whether the audit falls within New York City’s annual window, but it does not prove that the report covers a later model or configuration. An audit can remain timely on the calendar while becoming weak evidence for the system currently scoring candidates.

What identifier should an employer request from the vendor?

Request an immutable model or release identifier tied to the scoring service used for each decision. The supporting record should also name the feature schema, preprocessing version, threshold and job configuration, because identical model weights can produce different hiring outcomes when those surrounding components change.

What if the vendor will not disclose its model changes?

Ask for a version-specific change statement, reproducible comparison results and independent audit access without demanding proprietary source code. If the vendor cannot identify the deployed release or confirm whether scoring behavior changed, the safer operational fallback is to keep the verified version or stop using the score until evidence is available.