Compliance · July 18, 2026 · 9 min read

Compliance-First Hiring AI: LL144 and the EU AI Act

Compliance-first hiring AI treats NYC Local Law 144 and the EU AI Act as design inputs, not legal afterthoughts. How to build assessment records auditors trust.

If you run hiring for a regulated employer, or build the tools they use, regulators have already decided what your software is: high-risk. NYC Local Law 144 makes automated employment decision tools subject to bias audits, and the EU AI Act places employment-related AI in Annex III — its high-risk category — with obligations around documentation, human oversight, logging and transparency. Compliance-first hiring AI is the answer to a simple question that talent leaders and product teams now share: do you treat that regulation as a legal department's problem, or as an engineering specification you can build against? An AI-native skills assessment platform that takes the second view produces the evidence an auditor asks for as a by-product of normal operation. This post is written for the hiring manager, talent leader or founder who has to stand behind an automated decision — and wants the records to exist before anyone asks for them.

Why hiring AI is the most regulated corner of applied AI

Most AI applications sit in a grey zone where the rules are still forming. Hiring does not. Employment decisions have been regulated for decades, and lawmakers have moved quickly to extend that scrutiny to the software making or shaping those decisions. The stakes are asymmetric: a recommendation engine that guesses wrong costs a click, but an assessment that quietly disadvantages a protected group costs someone a job and exposes the employer to liability. That is why the newest wave of law treats hiring AI as high-risk by default, and why a compliance-first posture is not caution for its own sake — it is a rational response to where the enforcement is heading.

Three regimes matter most right now, and they overlap more than they conflict. NYC Local Law 144 governs bias auditing of automated employment decision tools. The EU AI Act sets horizontal obligations for high-risk systems, hiring among them. GDPR governs how candidate data is processed and erased. Read together, they describe a single expectation: show your work, keep a human accountable, and let people see and correct what was decided about them. That convergence is the good news for anyone building or buying assessment software, because it means you are not chasing three moving targets — you are building toward one durable standard that each regime approximates from a different angle.

NYC Local Law 144: the bias audit is on your usage

Local Law 144 requires that an automated employment decision tool used to screen candidates in New York City be subject to a bias audit before use, that a summary of results be made public, and that candidates be notified. The important nuance for anyone buying assessment software is this: the audit is conducted by an independent auditor on your own usage, not on the vendor's product in the abstract. A vendor cannot hand you a compliance certificate. What a vendor can do is make the audit tractable by generating the records it depends on — a defensible account of what was assessed and how outcomes distributed.

That distinction changes what you should demand of a platform. You are not looking for a claim of compliance; you are looking for evidence you can hand to an auditor. If you are hiring into New York roles, our dedicated guide to NYC Local Law 144 covers the notice and publication mechanics in more depth, and the broader question of statistical fairness is the subject of the four-fifths rule.

The EU AI Act: Annex III makes hiring high-risk

The EU AI Act classifies AI used in recruitment and employment decisions as high-risk under Annex III. High-risk status is not a ban; it is a set of obligations. Providers and deployers are expected to maintain risk management and technical documentation, ensure meaningful human oversight, keep logs that allow decisions to be traced, and be transparent with the people affected. For an assessment platform, each of those obligations maps onto a concrete product behaviour rather than a policy PDF filed away and forgotten.

Human oversight is the clause that most often gets reduced to theatre. A rubber-stamp approval step satisfies nobody. Genuine oversight means a reviewer can see what the system produced, change it, and have that change recorded with a reason. That is why a recruiter review queue that logs approve, edit and reject actions is more than a workflow convenience — it is the human-in-the-loop the Act envisions, captured as evidence. Our EU AI Act hiring guide walks through the deployer obligations in detail.

GDPR: erasure without destroying the audit trail

GDPR governs the data underneath all of this. Candidates give consent to be assessed, and they retain the right to have their personal data erased under Article 17. The naive implementation of erasure — delete everything — quietly defeats the very transparency the other regimes require, because it destroys the record that a decision was fair. The compliance-first answer separates the two concerns: erase the candidate's personal content on request, but retain anonymised integrity hashes so the audit trail survives. A deletion request should not be able to erase the evidence that you behaved lawfully.

Consent, likewise, is not a single checkbox. Data-processing consent and proctoring consent address different things and should be recorded separately, so that a candidate who agrees to be assessed but withdraws from proctoring leaves a coherent, honest record. For the full picture on candidate data rights, see our guide to GDPR and candidate data.

Turning three regimes into one specification

The practical value of a compliance-first approach is that it collapses three legal regimes into one coherent set of product requirements. Read side by side, LL144, the EU AI Act and GDPR ask for overlapping things: evidence that content was checked for bias, evidence that a human stayed accountable, and evidence that individuals can see and control their data. Build for the union of those demands once, and you are close to satisfying all three.

Bias scanning before content is used

Every generated question should be scanned for bias signals before it can enter the bank, and the result of that scan recorded. The point is not the mechanism — it is the discipline: unscanned content is held back rather than treated as audited-clean. That way, when an auditor asks whether the material candidates saw had been checked, the answer is documented rather than assumed. This matters because bias in an assessment is rarely deliberate; it hides in a phrasing that assumes a cultural reference, or in a question that rewards a background rather than a skill. Scanning at the point of generation catches those signals before a single candidate is exposed to them, which is far cheaper — and far more defensible — than discovering them in a post-hoc adverse-impact analysis after the offers have gone out.

Human oversight as a logged step

The recruiter review queue is where oversight becomes real. Approve, edit and reject actions are logged with the actor who took them, so oversight is a matter of record rather than assertion. This is the same discipline that underpins reducing bias in hiring: a decision you can explain is a decision you can defend.

Audit trails for every decision

• Evaluation events — what was assessed and when, captured as candidates move through the pipeline rather than reconstructed afterwards.
• Consent records — data-processing consent and proctoring consent held separately, each with its own timestamp.
• Decision reasons — why a candidate advanced or was rejected, attached to the decision itself.
• Recruiter overrides — every manual change recorded with the actor and a reason, so human judgement is visible, not invisible.

What to ask a vendor before you buy

If regulation is a specification, then vendor selection is where you test whether a platform actually meets it. The questions that matter are not about marketing claims but about artefacts — the concrete records a vendor can produce on demand. A tool that cannot show you these today will not conjure them the week your auditor arrives. Treat the demo as an audit rehearsal: ask to see the evidence for a real decision, not a description of how evidence would theoretically be captured.

• Can you show me a bias-scan record for a piece of generated content, including the timestamp and the verdict?
• Can you show me a human-oversight log where a recruiter edited or rejected a result, with the actor attached?
• Can you produce the full decision trail for a rejected candidate — what was assessed, how it scored, and why the outcome was reached?
• How does your erasure flow satisfy a GDPR Article 17 request without destroying the audit trail?
• Are data-processing consent and proctoring consent recorded separately, each with its own timestamp?

A vendor who answers those five questions with live screens rather than slides has built for the regulated future. One who deflects to a compliance certificate or a policy document has not. The difference is the difference between buying evidence and buying a promise, and only one of those helps you when the audit is real.

The honest part

Tooling supports compliance; it does not confer it. An LL144 bias audit is something an independent auditor performs on your usage, and adverse-impact analysis is something your organisation owns. What a vendor can legitimately promise is to make those exercises possible — by generating the records they require. That is the promise worth making, and the one you should want from any vendor you buy. Be wary of anyone who sells you a certificate; be reassured by anyone who hands you evidence.

There is a market observation here too. Most assessment vendors publish no quality-control or audit methodology at all. As enforcement of these regimes matures, 'we can show our work' stops being a differentiator and becomes table stakes. The organisations that treat regulation as a specification now will not scramble when the audit arrives — the paperwork will already be written. That is the argument for doing this work responsibly: the compliance evidence is a by-product of the system working as designed, not a separate project bolted on under deadline. The organisation that waits for its first regulatory letter before building any of this discovers, too late, that you cannot retroactively record a decision reason that nobody wrote down at the time.

Compliance-first hiring AI is, in the end, a bet that the regulated future is the default future. Building for it does not slow good hiring down — it makes every decision explainable, which is what fair hiring required all along. You can see how the evidence is captured in practice on our AI Sandbox feature page, or walk through a live assessment via a demo.