Local Law 144

How Local Law 144 Works in Practice

Local Law 144 is not a general AI ethics statement, it is a compliance rule with a narrow trigger. The law turns on whether an automated employment decision tool is used in an employment decision, where it is used, and whether the use falls within the covered NYC context.

That structure matters because the legal obligation is tied to a specific decision path, not to all automation in hiring or talent workflows. A tool can be relevant only if it is actually supporting an employment decision in the regulated context, which is why organisations need a clear view of where the tool sits in the hiring or promotion process.

The practical effect is that covered use cases must be treated as regulated decision support, with independent bias auditing as a condition of lawful use. For compliance teams, the first question is usually not “Is this AI?” but “Is this the type of tool and use case the law captures?”

For teams building inventory and governance around automated decisioning, the underlying control problem is visibility into where such tools are deployed and who owns the review path. That is why general identity and access discipline still helps, including knowing which systems and operators can change the tool or its outputs, and why a broader governance lens such as NIST Cybersecurity Framework 2.0 is useful for assigning ownership, control, and review responsibilities.

Bias Audits and Compliance Evidence

The central control concept in Local Law 144 is the bias audit. The audit is meant to provide independent evidence that the covered tool has been examined for discriminatory impact before or during use, rather than relying on vendor assurances or informal testing.

This makes documentation part of the security and governance story. A compliant programme typically needs a defensible record of what tool was audited, what employment use case it supported, what population or decision type was assessed, and how the audit outcome maps to the organisation’s deployment.

Independent review is important because the law is trying to reduce blind trust in automated screening or ranking systems. The audit is therefore not just a technical test, but a governance checkpoint that connects model behaviour, decision context, and legal accountability.

Where automated employment tools rely on data processing patterns that may create disparate outcomes, the audit also becomes a privacy and data-governance exercise. The same deployment that creates fairness exposure can also create retention, disclosure, and documentation obligations, which is why NIST Privacy Framework is a useful companion reference for data governance and risk treatment.

What Organisations Must Define Before Using a Covered Tool

Local Law 144 forces organisations to define boundaries that are often vague in practice. They need to know which tool is in scope, which role or decision it supports, and whether the use is occurring in a covered NYC employment context.

That scoping work matters because many hiring workflows mix human judgment, automation, and vendor tooling. If organisations cannot clearly separate recommendation, ranking, screening, and final decision support, they can misjudge whether the law applies and whether the required audit is complete enough.

The most common operational failure is not necessarily a flawed audit method, but a poor inventory of the decision pipeline. When the governance team cannot trace the tool from vendor package to actual use case, compliance gaps become very hard to prove away.

For that reason, many teams pair this kind of legal control with broader control frameworks for AI governance and assurance, especially where procurement, legal review, and security review all touch the same system. The most relevant external reference for the audit-and-control mindset is SOC 2 Trust Services Criteria (AICPA), which practitioners often use to structure evidence, process ownership, and control accountability.

Operational Implications for Hiring and HR Systems

Local Law 144 affects how HR, legal, procurement, and technical teams divide responsibility. It is not enough for one team to assume another has handled the audit, because the law links legal exposure to operational deployment, not to internal organisational boundaries.

That means the organisation needs repeatable ownership for vendor review, tool classification, audit retention, and release approval. It also needs a way to detect when a covered tool changes in a way that could invalidate an earlier audit, such as a new model version, a different scoring rule, or a new employment use case.

In practice, the safest operating model is to treat the audit as a recurring governance artifact rather than a one-time procurement checkbox. A fresh deployment or a changed decision workflow can create a new compliance question even if the vendor name has not changed.

Where organisations want a broader technical control baseline around automated systems, security, and governance, NIST AI Risk Management Framework helps align risk identification, governance, and mapping of harms to controls without confusing the legal requirement itself.

Risk and Threat Considerations

Local Law 144 creates real exposure when organisations misclassify a tool, rely on stale audit evidence, or fail to notice that a workflow has changed. The risk is not only regulatory, it is also reputational and operational, because a flawed decision-support pipeline can produce unfair outcomes that are difficult to unwind after the fact.

Failure mechanism: A tool can fall out of compliance when the organisation cannot prove independent audit coverage for the exact employment use case, or when the actual deployment drifts away from the audited configuration.

Impact: The result can be unlawful use of the tool, weakened hiring governance, and increased exposure to complaints, remediation work, and loss of trust in the hiring process.

Practitioner Guidance

What practitioners should watch for: The main governance challenge is scope control, not just model quality. Teams should pay close attention to whether a tool is genuinely covered, whether the audit still matches the deployed workflow, and whether ownership for review, evidence retention, and approval is clearly assigned.

Practitioner takeaway: Treat the law as a decision-path compliance problem, not merely an AI testing problem, because that is where most avoidable failures occur.

Related resources from NHI Mgmt Group

• What is the difference between New York City Local Law 144 and the newer state-level AEDT bias audit approaches?
• What is the difference between New York City Local Law 144 and the New York State AEDT bills?
• What is the difference between an automated employment decision tool and a bias audit under Local Law 144?
• What is the difference between the EU AI Act and NYC Local Law 144 for HR teams?