Compliance · July 18, 2026 · 9 min read

NYC Local Law 144: What the Bias-Audit Rule Requires

NYC Local Law 144 requires an independent bias audit before an automated hiring tool screens candidates. What the rule covers, who owns it, and what it measures.

← Part of Compliance-First Hiring AI: LL144 and the EU AI Act

If your team uses software to screen, rank, or score candidates for a role in New York City, a law already governs how you do it, and most hiring teams underestimate how broadly it reaches. NYC Local Law 144 does not care whether you think of your tool as "AI" or as a routine ATS feature; it cares whether the software substantially assists a hiring or promotion decision. This guide is for the talent leaders, recruiters, and HR or legal owners who actually run those tools, and the stakes are concrete: penalties accrue per violation and can compound daily, so a quietly unaudited tool becomes a growing liability rather than a one-off risk.

This is a deep dive from our guide to compliance-first hiring AI. You will get a plain-language account of what the law covers, the three obligations it puts on employers, what a bias audit actually measures, how those numbers are read, and how a well-designed evaluation workflow keeps the records an audit depends on. The through-line: compliance under LL144 is a property of how you use a tool, which means the work cannot be outsourced to a vendor's marketing claim.

What does NYC Local Law 144 cover?

Local Law 144 applies to automated employment decision tools, abbreviated AEDTs, that substantially assist or replace discretionary decisions in screening candidates for hiring or promotion of people in New York City. An AEDT is, broadly, a computational process derived from machine learning or comparable techniques that produces a simplified output, such as a score, a classification, or a ranking, used to help decide who advances. The reach is wider than most teams assume, because the trigger is the function the software performs, not the branding on the box.

The jurisdictional hook is where the candidate is, not only where the company sits. A remote-first employer headquartered elsewhere that screens New York City applicants with an AEDT should assume the law reaches those decisions. That is a familiar pattern across modern hiring regulation, and it is why multi-jurisdiction employers increasingly design one compliance baseline rather than a patchwork of per-city exceptions.

It is worth being precise about the two conditions that put a tool in scope, because teams talk themselves out of coverage on both. First, the tool must substantially assist or replace a discretionary decision — not merely produce a number a human glances at, but meaningfully shape who advances. Second, that decision must concern hiring or promotion for a role tied to New York City. A résumé ranker that surfaces the top applicants, an assessment platform that scores and sorts, an interview tool that rates responses: each can qualify. The safest posture is to assume coverage and document why a given tool falls outside, rather than assume the reverse and discover the gap during an audit request.

The three obligations, and who owns them

Three obligations attach before an employer may use a covered tool, and all three sit with the employer, not the vendor:

• Bias audit — conducted within the previous year by an independent auditor who had no hand in building, selling, or using the tool, and no compromising financial tie to the employer. The audit is calculated on the employer's own usage.
• Public disclosure — the date of the most recent bias audit, a summary of the results, and the tool's distribution date, posted clearly and conspicuously, typically on the careers or jobs section of the employer's website.
• Candidate notice — provided in advance of using the AEDT, stating that an automated tool will be used and describing the job qualifications and characteristics it assesses, so candidates know what is being evaluated and how.

Notice that every item is an employer duty. That framing is the single most important thing to internalise about this law, because it changes how you should read every vendor pitch you receive.

What does the bias audit measure?

The bias audit is not a vague fairness review; it is a specific statistical calculation. The independent auditor computes the selection rate for each sex category and for each race or ethnicity category, and where relevant the intersectional combinations. Selection rate is simply the share of candidates in a group who were selected, or in scoring tools, the group's average score treated comparably.

From those rates, the auditor derives the impact ratio: each group's selection rate divided by the rate of the highest-scoring group. This is the four-fifths rule applied to an automated tool. An impact ratio below 0.8 is the long-standing flag for potential adverse impact, the same benchmark used in decades of US employment-selection practice. The critical point is that these ratios are computed on your candidates and your usage, not on a vendor's benchmark population, which is why the same tool can pass for one employer and flag for another.

A published audit summary therefore has to disclose the categories analysed, the selection rates, and the impact ratios. That transparency is deliberate: candidates and regulators can see, in numbers, how a group fared relative to the reference group. If your tool cannot produce clean group-level selection data, you cannot produce a defensible audit, which is where record-keeping quietly becomes the whole game.

Two practical wrinkles trip teams up here. The audit runs on data — either your historical usage or, where you lack enough, appropriate test data — and thin or messy demographic records make a clean audit hard to produce. And an impact ratio below 0.8 is a flag, not an automatic verdict of unlawful discrimination; it signals that a group is being selected at a materially lower rate and that the disparity needs explaining and, where warranted, addressing. The four-fifths threshold is a screening heuristic drawn from established selection practice, which is precisely why it travels so well from human hiring into automated tools: regulators did not invent a new yardstick, they applied a familiar one to software.

Why the penalties compound

The enforcement design is what turns a paperwork lapse into a material exposure. Civil penalties under Local Law 144 reach up to 1,500 dollars per violation, and each day a non-compliant tool is used can be treated as a separate violation. Failing to provide the required candidate notice is treated as its own violation as well.

Because exposure accrues daily and can attach across a high-volume funnel, the arithmetic is unforgiving for a tool that has quietly gone unaudited. It is not a single fine you can reserve against; it is a running meter. Enforcement of the law began in July 2023, so this has been a live obligation, not a future one, for the entire time many teams have been deploying automated screening at scale.

How LL144 compares to other AI hiring laws

Local Law 144 is deliberately narrow and audit-centric, which makes it a useful anchor point against broader regimes. If you hire across jurisdictions, it helps to see where the mechanisms differ even when the underlying goals converge:

• NYC Local Law 144: narrow and audit-centric. Covers AEDTs used for New York City candidates; requires an annual independent bias audit, published results, and candidate notice. Enforced since July 2023.
• EU AI Act: classifies employment AI as high-risk, with provider and deployer obligations spanning risk management, human oversight, and logging. Broader and more systemic than a single audit.
• Colorado's AI framework: after a 2026 rewrite, emphasises transparency, data-access and correction rights, and meaningful human review across many consequential decisions, not only hiring.
• Illinois AI hiring laws: a civil-rights approach layered onto existing human-rights statutes, addressing discriminatory AI use and notice in employment.

The regulators disagree on mechanism — audits, risk management, disclosure, civil-rights enforcement — but agree on substance: tell candidates when an automated tool is involved, be able to explain and defend the decision, keep a human meaningfully in the loop where it counts, and keep records. Teams that build to that common core once, rather than patching per jurisdiction, spend far less over time. That is the argument behind treating bias reduction as a design constraint on the hiring system itself.

Where record-keeping meets compliance

The recurring failure mode is not bad intent; it is missing data. When an auditor asks for selection rates by group, or a regulator asks why a candidate was screened out, an opaque score is not an answer. The tools that survive an audit comfortably are the ones that were logging the right things all along: who was assessed, on what qualifications, what the outcome was, and where a human intervened.

This is also where evaluation design and compliance stop being separate projects. Assessments built around observable work — work-sample tests and job-specific tasks rather than generic scores — give reviewers something concrete to review and give your candidate notice something honest to describe. Job-relatedness by construction is the strongest foundation under any adverse-impact analysis, because it answers the "why this question" objection before it is raised.

The candidate-notice obligation deserves the same care as the audit itself, because it is the part most visible to applicants and the easiest to get wrong quietly. A notice has to be genuine and specific: it should tell candidates that an automated tool will assess them and describe the qualifications and characteristics it evaluates, in language they can actually understand, delivered before the tool runs rather than buried after the fact. When the assessment maps cleanly to the job, that notice writes itself, because you are describing real, role-relevant work rather than reverse-engineering a justification for an opaque score.

What H-Evaluate provides

H-Evaluate was built compliance-first for exactly this pattern. It is an AI-native skills assessment platform, which means the record-keeping an audit depends on is part of the workflow rather than a bolt-on. Concretely, it provides:

• Bias scanning at question generation, with the scan result recorded against each assessment.
• Adverse-impact reporting — selection rates and impact ratios by group — the figures an LL144 audit summary must disclose.
• An audit trail of decisions, reasons, and human overrides, so the human-in-the-loop step is evidenced, not assumed.
• Consent and notice records, so candidate-notice obligations are documented rather than claimed.
• AI-generated assessments produced per job, so the questions map to the qualifications your notice describes.

None of this makes H-Evaluate compliant on your behalf — nothing can, because LL144 compliance is a property of your deployment. What it does is remove the record-keeping excuse, so the audit and disclosure your own team runs rest on clean, complete data. If you are rethinking your stack, start with our overview of AI-native hiring: the argument, in short, is that tools designed under compliance constraints beat tools retrofitted to them after an audit request lands.

Regulation will keep changing faster than your hiring stack. The only durable strategy is making decisions you would be comfortable explaining — to a candidate, an auditor, or a court.