NYC Local Law 144 AI Controls Mapping: Each Obligation Against the Control That Satisfies It
Local Law 144 imposes four obligations on an employer using an automated employment decision tool: an annual bias audit by an independent auditor, publication of the results summary, candidate notice at least ten business days before use, and the record-keeping underneath all three. This maps each obligation to the control that satisfies it, names the owner, and states plainly which of the four an identity-aware gateway on the request path touches and which it contributes nothing to.

Local Law 144 of 2021 runs to four operative obligations, and the New York City Department of Consumer and Worker Protection adopted its final rules on 6 April 2023 to say what each one means in practice. Enforcement started on 5 July 2023. The rules define selection rate, impact ratio, independent auditor, and the contents of the published summary, which is the level of detail a controls mapping needs.
Most mappings I read for this law stop at "run a bias audit annually." That covers one obligation of four and skips the one every other obligation reads from.
I want to walk the four obligations against the control that satisfies each, name who owns that control, and say where a component sitting on HTTP AI traffic contributes and where it does not. The two companion pieces cover the artifacts an investigator would ask for in the Local Law 144 audit evidence walkthrough and the sequenced version in the Local Law 144 compliance checklist.
Obligation 1: the annual bias audit
The audit is a calculation, not a document. Under the DCWP rules an independent auditor computes the selection rate for each sex category, each race and ethnicity category, and each intersectional category, then divides each rate by the rate of the most-selected category to produce the impact ratio. Where the tool produces a score rather than a pass or fail, the auditor computes scoring rates against the median.
Two controls sit underneath it. The first is auditor independence, which the rules define by exclusion: an auditor cannot have been involved in using, developing, or distributing the tool, cannot hold an employment relationship with the employer or the vendor, and cannot hold a direct financial interest in either. That control is settled in procurement, in an engagement letter, and nowhere else.
The second is the input dataset. The rules allow historical data from the employer's own use of the tool, and permit test data only where historical data is insufficient, with the summary required to say which was used and why. An auditor working from historical data is auditing what the tool actually did, which requires records of what the tool actually did.
Obligation 2: the published summary
The rules specify contents. The summary must state the date of the most recent bias audit, the source and explanation of the data used, the selection rates and impact ratios for every category, the number of individuals assessed who fell into an unknown category, and the distribution date of the tool.
The control here is web publishing plus a retention discipline. Clearly and conspicuously has been read to exclude a link buried in a careers footer, and the summary must remain posted for at least six months after the most recent use of the tool. A dated screenshot per posting period is the artifact that survives a later dispute about what was up and when.
Obligation 3: candidate notice
Notice must reach candidates and employees who reside in New York City at least ten business days before the tool is used, identifying the job qualifications and characteristics the tool assesses, and telling them they may request an alternative selection process or accommodation. The employer must also publish the data-retention policy for the information the tool collects, or provide it on request within 30 days.
The ten-business-day clock is what makes this a records control rather than a template control. Evidencing it requires two timestamps in the right order: when notice went out, and when the tool first ran for that same person. Most recruiting stacks produce the first cleanly and estimate the second from whatever the applicant tracking system happened to write.
Obligation 4: the records underneath the other three
Nothing in the statute is headed "record-keeping," and three of the four obligations resolve to a records question. A bias audit needs tool outputs joined to demographics. Its published summary reports the population count those outputs came from, and evidencing notice requires an invocation timestamp per candidate.
Where the tool is reached over HTTP, whether that is a vendor scoring API or a hosted model prompted to rank resumes, every invocation is a request leaving your boundary carrying a candidate reference. A record written on that path names the candidate reference, the destination and model version, the timestamp, the policy in force, and the outcome. It is also the only version of that record the tool vendor did not author.
The mapping
Four of the ten rows read Full or Partial. Six read None, and I would rather write that plainly than publish a mapping showing coverage everywhere, because a team that believes an architecture purchase closed its notice obligation will discover otherwise during an investigation.
Where the tool inventory row gets interesting
The AEDT definition reaches any computational process derived from machine learning, statistical modelling, data analytics, or artificial intelligence that issues simplified output used to substantially assist or replace discretionary employment decisions. Function decides, and product category is beside the point.
That definition catches a recruiter pasting twenty resumes into a general-purpose model and asking it to rank them, which no procurement process registered as an AEDT and no vendor contract covers. An inventory built from a survey returns the tools people remember. An inventory built from observed egress to model endpoints returns the tools in use. The gap between those two lists is the same shadow AI discovery problem arriving under an employment-law heading, and it is why the row above reads Partial rather than None.
My candid view: the December 2025 New York State Comptroller audit, which re-read 32 posted bias audits that DCWP had cleared and identified at least 17 potential issues, will be read as a warning about audit quality. The more useful reading is that scrutiny was the variable, and the artifacts most employers hold were built for a reviewer who was not looking hard. Penalties reach $500 for a first violation and up to $1,500 for each subsequent one, with every day of use without a valid audit counting separately, so the arithmetic on a lapsed audit compounds quickly.
DeepInspect
This is the control that fills the four rows marked Full and Partial. DeepInspect sits inline between your systems and the model APIs they call, as a stateless proxy the calling application has no custody over. It evaluates identity, request classification, and destination on every call, enforces per-role and per-route policy with a fail-closed default, and writes a signed, tamper-evident per-decision record.
For an AEDT reached over HTTP, that record establishes which candidate reference went to which tool version at which moment, produced outside both the vendor's systems and your applicant tracking system. The bias audit stays with an independent auditor and the notice stays with recruiting. The dataset underneath both stops being a reconstruction assembled after the fact. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- What are the four obligations under NYC Local Law 144?
An annual bias audit conducted by an independent auditor, publication of a summary of the audit results on the employer's website, notice to candidates and employees resident in New York City at least ten business days before the tool is used, and the underlying records that make the first three demonstrable. The DCWP final rules adopted on 6 April 2023 define the calculations and the summary contents.
- Who counts as an independent auditor?
The DCWP rules define independence by exclusion. The auditor cannot have been involved in using, developing, or distributing the tool, cannot have an employment relationship with the employer or the vendor during the audit period, and cannot hold a direct financial interest in either. Independence is settled at procurement through an engagement letter rather than through anything in the technical stack.
- Can we use test data instead of historical data for the bias audit?
The rules permit test data only where historical data is insufficient, and the published summary must state which data was used and explain why. That constraint pushes the question back to whether your deployment can produce historical tool outputs at all, which most cannot without reconstructing them from an applicant tracking system.
- Does Local Law 144 apply to a general-purpose LLM used for screening?
The definition turns on function rather than product category. A computational process that issues simplified output used to substantially assist or replace a discretionary employment decision for a New York City resident falls to be assessed as an AEDT. A model prompted to rank resumes is doing that job, whatever it was procured as.
- What is the retention period for the published summary?
The summary must remain posted for at least six months after the most recent use of the tool. Retaining a dated screenshot for each posting period is what allows an employer to demonstrate the summary was up during a specific window, rather than only that it is up now.
- Which parts of Local Law 144 can architecture actually solve?
The invocation record, the notice sequencing evidence, the auditor's input dataset, and retention of all three. The disparate-impact arithmetic belongs to an independent auditor, auditor independence belongs to procurement, the published summary is a web-publishing task, and the notice text and alternative process belong to HR and legal.