Who must comply with NYC Local Law 144?

Any employer or employment agency using an automated employment decision tool (AEDT) to screen candidates for a job located in New York City, regardless of where the employer is headquartered. They must run an independent bias audit within the prior year, publish the summary, and notify candidates at least 10 business days in advance.

When do EU AI Act obligations apply to hiring systems?

AI systems used for recruitment and employee selection are high-risk under Annex III 4(a). High-risk obligations for hiring systems apply from August 2, 2026, covering risk management, data governance, human oversight, transparency, logging, and post-market monitoring.

An Automated Employment Decision Tool is any computational process derived from machine learning, statistics, or AI that produces a score, classification, or recommendation used to substantially assist or replace discretionary hiring or promotion decisions.

What are the penalties for NYC Local Law 144 non-compliance?

Fines start at $500 for a first violation and reach $1,500 for each subsequent violation. Each day of non-compliant use and each missed candidate notice counts as a separate violation.

Can our AI vendor perform our bias audit?

No. NYC Local Law 144 requires an independent auditor with no role in building, selling, or using the tool and no financial interest in it. Vendors can supply data but cannot serve as the independent auditor.

Vendor vs. Deployer: Who Is Responsible for AI Hiring Compliance?

Summary: When you buy an AI hiring tool, responsibility for compliance does not transfer to the vendor. Under NYC Local Law 144, the employer using the tool carries the obligations to audit, disclose, and notify. Under the EU AI Act, obligations are split between the provider that builds the tool and the deployer that uses it, with the heavier build-side duties on the provider and use-side duties on the employer. The costly misconception is assuming your vendor has handled compliance for you. In almost every case, meaningful responsibility stays with you.

Key takeaways

Buying a tool does not outsource your compliance obligations to the vendor.
Under Local Law 144, the employer using the tool owns the audit, disclosure, and notice duties.
Under the EU AI Act, providers carry build-side obligations and deployers carry use-side obligations.
Customizing or rebranding a tool can turn you into a provider with the heavier set of duties.
The vendor is a partner in compliance, not a substitute for it. Contracts should make the split explicit.

The misconception that creates the most risk

The most expensive assumption in AI hiring compliance is a natural one: we bought the software, so the software company handles the legal side. It feels reasonable. It is also, in almost every case, wrong. The laws attach obligations to the party using the tool to make hiring decisions, and that party is you. A vendor can help. A vendor cannot absorb your responsibility.

Companies that discover this late often find they have been out of compliance for months while assuming they were covered, which is precisely the scenario the per-day penalty structure punishes most.

Responsibility under Local Law 144

Local Law 144 is straightforward on this point. The obligations, an independent bias audit within the prior year, publication of the audit summary, and candidate notice, fall on the employer or employment agency using the automated tool. The law regulates the use of the tool in your hiring, not the sale of the tool by the vendor.

This has a sharp practical consequence for the audit. The auditor must be independent, and the vendor cannot be independent because it built and sold the tool. So not only does the vendor not own the audit obligation, the vendor is actually disqualified from being the independent auditor. The vendor can supply the underlying data, but you must engage a separate, independent party to run and sign the analysis, and you must publish the result and notify candidates.

Responsibility under the EU AI Act

The EU AI Act is more nuanced because it explicitly names two roles.

The provider develops the AI system, or has it developed, and places it on the market under its own name. Providers carry the build-side obligations: risk management, data governance under Article 10, technical documentation, the quality management system, conformity assessment, and more. These are the heavier duties, and they sit with the party that makes the system.

The deployer uses the system. Deployers, which is what most employers are, carry use-side obligations: using the tool according to the provider's instructions, ensuring genuine human oversight, monitoring operation, keeping logs, and informing affected workers and their representatives that a high-risk system is in use.

So the EU regime does distribute responsibility across the vendor and the employer, but it does not let the employer off the hook. It gives the employer a distinct, non-transferable set of duties around how the tool is used.

When a buyer becomes a provider

Here is the trap that catches sophisticated companies. Under the EU AI Act, certain actions can turn a deployer into a provider, inheriting the heavier obligations. Putting your own name or trademark on a high-risk system, making a substantial modification to it, or changing its intended purpose can all shift you into provider status.

This matters because the more you customize an AI hiring tool, fine-tuning it on your data, adapting it to a bespoke process, rebranding it as your own, the more likely you are to have crossed the line. The very acts that make a tool feel like yours can legally make it yours, with all the build-side duties that follow. Understanding which role you occupy for each tool is not a formality. It determines the size of your obligation.

What this means for vendor contracts

Because responsibility is shared but not transferable, your contracts should make the split explicit. A good vendor relationship documents who supplies what: the vendor provides the data and documentation you need, cooperates with your independent auditor, and gives you the technical information the EU regime requires. You retain the obligations the law assigns to you and hold the vendor to concrete commitments that let you meet them.

Silence in the contract is where disputes live. When an audit is due and the vendor will not release the data, or a regulator asks for documentation the vendor never provided, the absence of an explicit agreement becomes your problem. Negotiating these commitments before you sign is far easier than extracting them under deadline pressure.

A simple way to assign responsibility

For each tool, answer three questions. First, are we using this tool to evaluate candidates for a covered role? If yes, the use-side obligations are yours. Second, have we built, substantially modified, or rebranded it? If yes, some or all of the build-side obligations may be yours too. Third, what has the vendor contractually committed to provide? That answer tells you what you can rely on and what you must arrange yourself. Working through these three questions for every tool produces a clear responsibility map and eliminates the dangerous assumption that someone else has it covered.

Frequently asked questions

If we buy an AI hiring tool, does the vendor handle compliance? No. The obligations attach to the employer using the tool. The vendor can assist but cannot absorb your responsibility.

Can the vendor perform our bias audit? No. The auditor must be independent, and the vendor is disqualified because it built and sold the tool. The vendor can provide data only.

What is the difference between a provider and a deployer? The provider builds and places the system on the market and carries build-side duties. The deployer uses it and carries use-side duties. Most employers are deployers.

Could we accidentally become a provider? Yes. Rebranding, substantially modifying, or repurposing a high-risk tool can make you a provider with the heavier obligations.

What should our vendor contract say? It should specify that the vendor supplies the data and documentation you need, cooperates with your independent auditor, and meets the technical requirements the law places on providers.

The safest assumption is that meaningful compliance responsibility stays with you, no matter how much the vendor promises. If you want a clear responsibility map across your stack, showing exactly which duties are yours and what to demand from each vendor, that mapping is a core part of a compliance check.