“Bias audit” is often used as if it described one standardized compliance event. It does not. Depending on the speaker, the phrase may mean the calculation New York City requires for a defined hiring or promotion tool, a broader impact assessment, a validation study under employment-discrimination principles, an internal fairness review, or a vendor's product test. Those exercises differ in scope, method, legal status, and timing.

The timing question is equally easy to blur. A law may require testing before use, require that an audit remain recent while a tool is used, require an assessment on a schedule, require records that make later evaluation possible, or simply prohibit discriminatory results without prescribing any audit cadence. “Continuous monitoring” can be sensible governance shorthand, but it should not be presented as a universal statutory command.

This explainer separates operative law verified through September 25, 2026 from proposed rules, official guidance, and optional governance. It provides general regulatory information, not legal advice for a particular tool or deployment.

New York City starts with a rolling one-year rule

New York City Local Law 144 is the natural starting point because it expressly uses the term “bias audit.” Within the ordinance's defined scope, an employer or employment agency may not use an automated employment decision tool to screen a candidate for employment or an employee for promotion unless the tool has been the subject of a bias audit conducted no more than one year before use. A summary of the most recent audit results and the distribution date of the tool must also be made publicly available before use.

That structure is more precise than saying “an annual audit is required.” If a covered tool remains in use, an audit older than one year will no longer satisfy the condition for use. In practical terms, continued use creates a recurring need for a sufficiently recent audit. But the statute does not require real-time calculations, daily outcome review, or an uninterrupted monitoring feed between audit dates.

The implementing rule defines the required calculations, public-summary content, historical-data conditions, and independent-auditor standard. It also permits certain test-data approaches when sufficient historical data is unavailable. Coverage still depends on the law's definitions and the way the tool is used. Not every algorithm in an HR stack is an AEDT, and an audit of one covered use does not automatically answer questions about every customer, job, or configuration.

Most current regimes do not prescribe that audit cadence

The broader legal landscape is not a collection of New York City copies. Illinois' effective Human Rights Act amendment prohibits covered AI use that has the effect of subjecting employees to discrimination, bars use of ZIP codes as proxies for protected classes in the covered activities, and requires notice. The enacted text directs the Illinois Department of Human Rights to adopt implementation rules, but it does not itself establish an annual independent bias audit or continuous monitoring schedule.

California's effective employment regulations clarify that use of an automated-decision system or selection criteria can violate the Fair Employment and Housing Act when it discriminates. They also bring automated-decision-system data within covered employment-record retention, generally for at least four years, and address automated assessments that may elicit disability-related information. Those are consequential obligations, but they are not a standalone recurring bias-audit program.

Maryland's employment facial-recognition statute is narrower still. It requires a signed consent waiver before an employer uses a facial-recognition service to create a facial template during an applicant's interview. It does not prescribe bias testing, reassessment, or ongoing outcome monitoring. Massachusetts and New Jersey agency materials explain that existing anti-discrimination and consumer-protection principles apply to algorithmic systems; they do not convert that guidance into a fixed annual audit requirement.

AuthorityOperative timing ruleWhat it does not establish
NYC Local Law 144Covered AEDT must have a bias audit no more than one year before useContinuous or real-time monitoring between audits
Illinois Human Rights Act amendmentEffective prohibition and notice duty; implementation details delegated to rulemakingAnnual independent bias audit in the enacted text
California employment ADS regulationsOngoing application of FEHA plus four-year record retentionStandalone audit cadence for every ADS
Maryland facial-recognition interview lawConsent before the defined interview useBias audit, reassessment, or monitoring program
Massachusetts and New Jersey guidanceExisting-law liability applies to algorithmic conductNew binding annual audit schedule created by guidance

Colorado's 2026 reset is about documentation and use—not a general impact assessment

Colorado illustrates why old summaries can be misleading. Senate Bill 26-189 repealed and replaced the state's 2024 high-risk-AI framework. The replacement act applies to covered consequential decisions made on or after January 1, 2027. It requires developer documentation, deployer notices, specified information after adverse outcomes, access and correction processes, meaningful human review in covered circumstances, and at least three years of records reasonably necessary to demonstrate compliance.

The 2026 law does not carry forward the repealed framework's general impact-assessment and risk-management-program mandates. It does require developers to provide instructions for appropriate use, monitoring, and meaningful human review where applicable. That is a documentation duty tied to safe operation; it is not the same as ordering every deployer to conduct a recurring independent bias audit.

The Colorado Attorney General filed proposed implementing rules on August 11, 2026. As of this article's verification date, the official rulemaking page continued to label them proposed, accepted comments through October 26, and explained that the filing implements the 2026 statute. Proposed operational detail should be monitored, but it should not be reported as final law. Nor should requirements from the repealed 2024 framework be carried into the replacement act.

Federal law regulates outcomes and selection procedures, not an AI audit calendar

Federal employment-discrimination law remains relevant even when no AI-specific audit statute applies. The Uniform Guidelines on Employee Selection Procedures, codified at 29 C.F.R. part 1607, address selection procedures with adverse impact and the evidence used to establish validity. The EEOC's interpretive questions and answers emphasize that a commercial test publisher's materials may help, but the user remains responsible for determining whether the validity evidence is adequate and for understanding how the procedure is used and what impact it has. The interpretive Q&A does not create an AI-specific audit schedule.

That creates a strong reason to retain and examine outcome data where the law permits, especially as jobs, applicant pools, thresholds, and workflows change. It does not create a universal annual “AI bias audit” deadline. A disparate-impact claim also does not disappear because a vendor issued a favorable report. The relevant questions include the employer's actual selection procedure, its effects, job relatedness, business necessity, and available alternatives under the governing law.

Nonbinding EEOC and DOJ technical-assistance materials on disability discrimination similarly warn that algorithmic tools can screen out qualified people with disabilities, generate prohibited inquiries, or fail to support reasonable accommodation. The underlying ADA obligations remain binding, but the technical-assistance documents do not independently create a recurring bias-audit mandate. The Department of Labor's AI & Inclusive Hiring Framework offers voluntary practices for assessment, acquisition, and deployment. These materials support attentive lifecycle governance, but guidance and voluntary frameworks should not be relabeled as recurring statutory audits.

Material changes: the legal trigger is often less explicit than the governance need

Current employment-AI laws do not supply one universal rule saying that every retraining event, model update, threshold change, or new integration triggers a fresh bias audit. New York City's public summary must identify the distribution date of the tool to which the audit applies, which makes version alignment important, but the ordinance does not provide a comprehensive national definition of “material modification.” Other regimes may require documentation, records, notices, or accurate representations without specifying a retest after each change.

Governance teams may nevertheless decide that a material change should trigger review. A model update can change outputs; a new job family can change the relevant criteria; a threshold adjustment can change selection rates; a new applicant population can make earlier results less informative; and a customer-specific workflow can depart from the vendor's tested use. That is a risk-based control unless a particular law, contract, consent order, or policy makes it mandatory.

  • Point-in-time audit: a defined test of a defined system, dataset, population, and period.
  • Periodic reassessment: a review repeated on a calendar or before an earlier result becomes too old for the applicable rule.
  • Change-triggered testing: a review prompted by a new version, use case, threshold, data source, or population.
  • Outcome monitoring: repeated analysis of actual decisions or selection rates after deployment.
  • Operational monitoring: watching reliability, drift, data quality, overrides, incidents, or use outside documented limits.

A vendor may call all five activities “continuous monitoring.” Procurement and legal teams should ask which one is actually being offered, how often it occurs, what data it uses, who receives alerts, and what happens after a threshold is crossed.

A vendor's passing result is not the end of the inquiry

A statement that a product “passed a bias audit” is incomplete without scope. New York City's rule calls for calculations and disclosure; it does not create a general pass-fail safe harbor or declare a particular impact ratio lawful. A report can be technically accurate for the tested dataset while remaining a poor fit for a different version, employer, role, geography, selection stage, or decision threshold.

Responsibility also does not automatically move to the vendor. Employers make deployment choices, combine tools with other screens, select cutoff scores, define jobs, and act on outputs. Under federal selection-procedure principles, the user's context and actual outcomes matter. Under state and local regimes, statutory duties may attach directly to the employer or deployer even when the developer supplies documentation or performs testing.

What employers and buyers should ask for

The following is procurement and governance preparation, not a claim that every item is legally required in every jurisdiction:

  1. Audit identity and date. Obtain the report date, the period covered, the auditor's identity, and evidence of independence where the applicable rule requires it.
  2. Tested version and distribution date. Match the report to the model, release, configuration, and product distribution actually being used.
  3. Population and decision stage. Identify the jobs, locations, applicant or employee population, sample size, and point in the workflow represented in the data.
  4. Methodology and limits. Ask which groups, metrics, intersectional categories, exclusions, assumptions, and test-data substitutions were used—and what the analysis cannot establish.
  5. Customer-specific differences. Document thresholds, integrations, human overrides, upstream screens, and uses that differ from the tested configuration.
  6. Remediation history. Ask what findings led to changes, what remains unresolved, and whether the vendor retested after remediation.
  7. Change controls. Define what counts as a material version or use change, who sends notice, how much advance notice is provided, and when review or retesting occurs.
  8. Monitoring and drift process. Specify the data reviewed, cadence, alert thresholds, responsible party, escalation path, and treatment of small samples.
  9. Records and access. Preserve the documentation and decision data needed for applicable retention, explanation, investigation, or validation duties, subject to privacy and other law.

What current law does not necessarily require

  • Continuous real-time bias monitoring of every employment AI system.
  • An annual independent audit for every employer, tool, or jurisdiction.
  • The same methodology, protected-group analysis, or publication format nationwide.
  • A new audit after every software update, regardless of whether the change affects the covered function.
  • Treating an impact assessment, validation study, bias audit, and general risk review as the same instrument.
  • Accepting a vendor's product-level audit as conclusive for the employer's actual deployment.

None of those cautions means organizations should ignore systems between formal reviews. Anti-discrimination duties apply to actual employment practices, and a stale or mismatched analysis may be poor evidence even where no statute specifies a monitoring cadence. The distinction is between an explicit legal schedule and a governance process designed to identify changing risk.

Where the rules appear to be heading

The direction is toward more lifecycle documentation, notice, records, data access, and human review—but the instruments remain uneven. Colorado's replacement framework requires monitoring instructions from developers without reinstating the former general impact-assessment mandate. California preserves data that can support later review. Illinois leaves notice details to rulemaking. Federal agencies continue to apply existing civil-rights law and publish technical assistance rather than a single AI-audit code.

Pending rules and bills may go further. Until they are adopted or enacted, they are watch items, not compliance mandates. The sound editorial rule is simple: identify the authority, status, covered system, regulated party, timing trigger, and required output before using the words “must continuously monitor.”

Bottom line

For covered New York City tools, the audit is neither a one-and-done certificate nor continuous surveillance: the tool must have a qualifying bias audit no more than one year before each use. Elsewhere, current law may prohibit discriminatory effects, require notice or consent, preserve records, demand documentation, or provide human-review rights without specifying an annual independent audit.

Prudent governance can be more continuous than the legal minimum. Organizations may monitor outcomes, set change triggers, review drift, and require vendor notices because systems and deployments evolve. Those controls should be described accurately—as risk management, contractual protection, or internal policy unless a cited authority makes them law.