Hiring & Recruiting Agents

Two rules that between them dictate the design.

NYC Local Law 144 has been in force since 1 January 2023, with enforcement from 5 July 2023. If an automated employment decision tool is used to screen candidates for employment or promotion in the city, it must have passed an independent bias audit within the previous year, the results must be published, and candidates must be notified in advance. Penalties start at $500 per violation and reach $1,500 per day for continuing ones. The audit computes selection rates and impact ratios across race/ethnicity and sex categories — so the tool must produce a decision you can count.

The EU AI Act puts recruitment squarely in Annex III: systems used to place targeted job advertisements, to filter or analyse applications, and to evaluate candidates are high-risk. That pulls in risk management, data governance, logging, technical documentation, human oversight, and obligations on you as the deployer even when you bought the tool. The original application date for these Annex III duties was 2 August 2026; the Digital Omnibus package moved to defer them toward late 2027, so confirm the operative date before you plan a schedule around it. The obligations themselves are not in question — only when they bite.

Decide on purpose whether you are building a decision tool.

Every team reaches for the same escape hatch: our agent only advises, a human decides. That is a real distinction and it is narrower than it feels. A tool that ranks 800 applicants and surfaces the top 40 has substantially assisted the decision even if a recruiter clicks the buttons — the 760 nobody looked at were screened out by the model. Regulators reason about effect, not about where the click happened.

So make it an architectural choice rather than an accident, and be honest about which one you shipped:

• A genuine no-decision design does not order candidates by fit. It summarizes, extracts structured fields, drafts outreach, schedules interviews, answers candidate questions — work that changes how fast the pipeline moves without changing who is in it. This is where most of the value is, and it carries the lightest obligations.
• A screening tool ranks, scores, or filters people. Build it only if you are prepared to fund an annual third-party audit, publish the results, notify candidates, and keep the records that make the audit possible. That is a budget line and an owner, not a sprint task.
• The dangerous middle is a "summary" that is really a score — an agent that writes "strong fit, 8/10" into a field recruiters sort by. It has all the effects of a screening tool and none of the machinery, and it is what teams ship without noticing.

If it scores, make the score countable and attributable.

A bias audit is arithmetic over outcomes. It needs, for every candidate the tool touched, a discrete selection outcome and the demographic categories to group by. Free-text LLM output does not have a selection outcome, which is why teams who built that way discover at audit time that the data does not exist and cannot be reconstructed.

The engineering requirement, stated once: the tool must emit a discrete, stored, timestamped decision per candidate, tied to the exact version of the system that produced it.

# screening/decision.py — the record an audit is computed from
DECISION = {
    "candidate_id": "c_8f21",
    "requisition":  "req_2026_114",
    "outcome":      "advance",          # advance | reject | refer_to_human
    "score":        0.71,
    "threshold":    0.65,               # the cut, versioned like code
    "criteria":     ["years_python>=3", "has_shipped_service"],
    "system":       "screen-v4.2+claude-2026-05-14+rubric:sha256:7c1a",
    "decided_at":   "2026-07-29T11:04:22Z",
}
# demographics live in a SEPARATE store, joined only for the audit

Three details in that record matter more than they look. The threshold is versioned because moving a cut point changes impact ratios without changing a line of model code. The system string pins the triple from rollout, versioning and pinning — an audit covers a system, and a floating model alias means you audited something that no longer exists. And demographic data is stored separately and joined only for the audit, because the screening path must never see it.

Use the model where it widens the funnel, not where it narrows it.

The reliable rule for placing an LLM in a hiring pipeline: let it do work that adds candidates or adds information; keep it away from work that removes candidates. The two sides carry completely different risk and completely different evidentiary burdens.

• Widening work, low risk. Rewriting a job description to remove exclusionary language. Translating postings. Answering candidate questions about process. Drafting interview questions from a rubric. Scheduling across calendars. Sourcing outreach — with care, since targeted advertising is itself named in Annex III.
• Information work, medium risk. Extracting structured fields from a résumé so a deterministic rule can evaluate them. The model reads unstructured text and outputs facts; the rule decides. This keeps the decision inspectable and testable, and it is the highest-value safe pattern in the whole pipeline.
• Narrowing work, high risk. Ranking, scoring, rejecting, shortlisting. Possible, but only inside the machinery of STEP 3.
• Do not do it at all. Inferring personality, emotional state, or "culture fit" from video, voice or writing style. Emotion inference in the workplace is prohibited outright under the EU AI Act, and the rest is a discrimination claim with a transcript attached.

The extraction pattern deserves emphasis because it dissolves most of the problem. "Does this résumé show three years of Python?" is a question a model answers well and an auditor can check. "Is this a strong candidate?" is a question the model answers fluently and nobody can check.

Assume the résumé leaks protected class, because it does.

Removing names, addresses and dates is table stakes and it does not get you neutrality. A résumé encodes group membership through dozens of correlated signals, and a model trained on the open internet reads all of them: a women's college, a fraternity, a country of education, a religious volunteering organisation, a military discharge, a résumé gap the length of a parental leave, a phrasing register learned from a first language. Blinding the obvious fields removes the fields you would have been criticised for using; it does not remove the inference.

• Test for the leak rather than assuming it away. Take real résumés, perturb one group-correlated attribute at a time, and measure whether the outcome moves. If swapping a university changes the score more than swapping three years of relevant experience, you have found your problem before an auditor did.
• Prefer rubric fields to holistic judgement. A model asked for a single fit score has every proxy available to it. A model asked for eight specific, job-related facts is constrained to the ones you named.
• Watch the free-text box. Cover letters and "tell us about yourself" fields carry the densest demographic signal in the application, and they are the least job-related input you have.
• Run the audit continuously, not annually. The legal minimum is yearly; impact ratios drift with the applicant pool and with every silent model update. Compute them monthly and you find drift while it is still a config change — see policy enforcement.

Make human oversight real, and keep the records that prove it.

"A human reviews every rejection" is the most common oversight claim and the most commonly hollow one. A reviewer facing 300 model-written rejection rationales at four seconds each is not oversight; they are a rubber stamp with a payroll number, and the audit trail records exactly that. Real oversight needs three properties, all of which cost something.

• The reviewer can see what the model saw. The extracted fields, the rubric, the threshold, the specific evidence — not a paragraph of prose that asserts a conclusion. This is the review-cost problem in agent UX: an unreviewable artifact produces unreviewed decisions.
• Overturning is cheap and tracked. If the disagreement rate is near zero, oversight is not happening. A healthy pipeline shows humans reversing the tool at a measurable rate, and that rate is itself a monitoring signal.
• The record survives the person. Who reviewed, when, what they saw, what they changed, under which system version — retained for as long as the applicable rules require, which is typically years. See audit trails and accountability and roles for who signs.

One more obligation that surprises engineering teams: under the EU AI Act, deployers must inform affected workers and their representatives before putting a high-risk system into service, and candidates subject to a covered tool must be notified under Local Law 144 as well. Notification is a product surface — a page, a timestamp, a record that it was shown — not a line in a privacy policy.

Related: the EU AI Act for agents for the full obligation set, data governance for the separate demographic store, and legal agents for the neighbouring regulated domain.