What are the key NYC Local Law 144 best practices?

What the best practice stack looks like for NYC Local Law 144

The practical answer is that local law 144 works best as a control process, not a one-time compliance task. Treat the tool as a regulated decision support system: verify scope before deployment, define who owns review and sign-off, and make sure the hiring team understands what the tool can and cannot do. If the tool changes employment outcomes, the process needs ongoing oversight, not just procurement approval.

Start by mapping the tool’s role in the workflow. If it screens, ranks, scores, or recommends candidates, document that role clearly and keep that documentation aligned with the actual configuration in production. That alignment matters because the strongest control failures usually come from drift between what the vendor says the system does and what the employer actually uses.

For teams operating across jurisdictions, the regulatory mapping should be explicit. A useful starting point is NHIMG’s Global AI Regulation Map, because it helps teams place NYC Local Law 144 alongside other AI governance obligations instead of treating it as a standalone checklist item.

How to make testing, notices, and human review operational

The core operating model is straightforward: run the required impact testing before use, issue the required notices, and preserve human review where the tool affects hiring or promotion decisions. The hard part is making those steps repeatable. Best practice is to assign ownership for testing evidence, notice content, and exception handling so that legal, HR, procurement, and security are not making separate assumptions about the same system.

Testing should not be treated as a single approval event. If the model, data source, hiring criteria, or vendor configuration changes, the original assessment may no longer describe the live system. That is why ongoing re-testing and periodic review of data inputs are part of good practice, not optional extras. Keep a record of what was tested, when it was tested, and what changed after the test.

Where the tool depends on identity data, access to candidate records, or exported assessment results, the surrounding control environment matters as much as the algorithm. For teams also managing credentials and vendor access, NHIMG’s API Key Management Guide is a useful operational reference for scoping, rotation, and revocation discipline around the integrations that often feed hiring tools.

What to watch for when a vendor looks compliant on paper

Many Local Law 144 failures are process failures, not model failures. The tool may have a valid assessment on file, but the employer still fails if notices are incomplete, if candidate-facing disclosures are vague, or if the system is used outside the job family or location the review covered. Another common issue is overreliance on vendor assurances instead of independent review of outputs and data quality.

Vendor documentation is useful, but it is not a substitute for employer accountability. If the vendor cannot explain the data features, training inputs, or intended decision boundaries in a way that supports your notice and review obligations, treat that as a governance gap. The same is true if you cannot show how human reviewers can override the system and why that override is meaningful rather than ceremonial.

For broader AI governance context, teams can use the NIST AI Risk Management Framework to structure accountability, measurement, and monitoring around an employment tool that has real decision influence.

Risk and Threat Considerations

Local Law 144 risk is not limited to a paperwork miss. The real exposure is discriminatory impact, misleading notice, and hidden automation bias, especially when a tool is treated as advisory but still shapes who advances. If testing is stale or incomplete, an employer may continue using a tool that is systematically disadvantaging candidates without noticing it in time.

Failure mechanism: The employer trusts a vendor assessment or an outdated test result, while production use, data inputs, or decision thresholds have already changed. That creates a gap between compliance artefacts and actual hiring behavior.

Impact: Candidates may be screened, ranked, or promoted based on a tool that is not being monitored with the rigor required to detect disparate impact or output drift, which can create legal, reputational, and workforce fairness consequences.

Practitioner Guidance

What to verify: Confirm that the assessment, notice, and human review process all describe the same live workflow. If a recruiter can bypass review, export scores into another system, or rely on the tool informally, the control design is weaker than it appears.

Decision rule: If the tool influences a consequential employment decision, treat every material configuration change, data refresh, or vendor update as a reason to revalidate the assessment and the notice language. Do not wait for a complaint or audit to discover that the deployed tool has drifted from the reviewed version.

Practitioner takeaway: The best Local Law 144 programs are built around evidence, change control, and meaningful human oversight, because compliance depends on the living hiring process, not just the vendor packet.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• What is the difference between the EU AI Act and NYC Local Law 144 for HR teams?
• What are the key local administrator rights best practices?
• How does NYC Local Law 144 work?