AI Screening, Scheduling, and Onboarding for HR and Recruitment Teams That Have to Pass a Bias Audit

The regulatory reality: your hiring model is a regulated tool, not a feature

Two regimes now govern AI in hiring, and they are not symmetric. NYC Local Law 144 is enforced today. Any Automated Employment Decision Tool used to screen or rank a candidate who lives in the five boroughs, including remote roles, requires an independent annual bias audit that computes selection rates and impact ratios across sex and race and ethnicity categories, a public summary posted on your careers site, and at least ten business days of notice to candidates. The law does not care where your company is headquartered. It cares where the applicant sits.

The EU AI Act is the larger obligation on a longer clock. Recruitment, candidate evaluation, targeted job advertising, and decisions on promotion or termination are named high-risk uses under Annex III. Under the 2025 Omnibus agreement the deployer obligations for these systems now apply from 2 December 2027 rather than August 2026, but the requirements are heavy: risk management, technical documentation, logging, human oversight, transparency to candidates, and post-market monitoring, with fines reaching EUR 15 million or 3 percent of global turnover. We treat both regimes as design inputs from day one, because retrofitting an audit trail onto a model that was never instrumented for one is a rebuild, not a patch.

This is where our security and compliance posture stops being a line on a slide. GDPR governs the candidate data these systems touch, and Article 22 gives applicants a right not to be subject to solely automated decisions with legal or similarly significant effect. Our HR builds are designed so a human, not the model, owns the reject decision, and so every automated step is documented well enough to answer a data subject access request or a regulator's file review.

Why this problem is retrieval and orchestration, not a fine-tuned scoring model

The instinct in hiring AI is to train a model that scores candidates. We deliberately avoid that for the screening path, because a fine-tuned ranker learns whatever bias lives in your historical hiring data and then hides it inside opaque weights that no bias audit can cleanly decompose. When a regulator asks why a candidate was filtered, an owner needs an answer, and 'the model learned it' is not one that survives Local Law 144 scrutiny.

So the screening layer is built as retrieval-augmented extraction against the job's own documented requirements. The system reads a resume, extracts structured evidence of the stated skills and qualifications, and cites the exact span it drew each claim from, rather than emitting a black-box fit score. The job requisition and the competency framework are the knowledge base. This keeps the decision logic legible, keeps protected characteristics out of the feature set by construction, and produces exactly the traceable record an audit needs.

Agents earn their place in the workflow around the decision, not inside it. Scheduling coordination across interviewer calendars, onboarding task sequencing, and document collection are genuinely multi-step and stateful, which is where agentic orchestration pays off. Fine-tuning we reserve for narrow, safe transforms such as normalizing messy job titles or parsing inconsistent resume formats, trained and evaluated on data we can show you. Deciding which technique carries which part of the problem is the design work, and we do it explicitly rather than defaulting to whatever is fashionable.

What we build, with honest ranges

Resume screening and shortlisting: an evidence-extraction layer that maps each candidate against documented requirements with cited justifications a recruiter reviews. Teams typically recover 40 to 70 percent of the manual hours spent on first-pass review, with the human retaining every advance-or-reject call. The point is not to reject faster. It is to give recruiters defensible, consistent notes on more candidates.

Interview scheduling and coordination: an agent that reconciles candidate availability with panel calendars, handles rescheduling, and sends compliant candidate notices. This is where the largest wall-clock savings appear, often collapsing multi-day scheduling loops to same-day and reducing coordination overhead by 50 to 80 percent, because the work is mechanical rather than judgmental.

Onboarding automation: sequencing offer paperwork, provisioning requests, policy acknowledgements, and first-week logistics, with a knowledge assistant that answers new-hire questions from your actual HR policies rather than from the open internet. Onboarding coordination effort commonly drops 30 to 60 percent. We publish ranges, not a single hero number, because your ATS hygiene, hiring volume, and role mix move the result more than the model does.

Integration and the data pipeline: it lives inside your ATS and HRIS

An HR AI that cannot read and write your systems of record is a toy. Our builds integrate with the applicant tracking systems where hiring actually happens, such as Greenhouse, Lever, Workday Recruiting, and SmartRecruiters, and with the HRIS layer, such as Workday, Bamboo HR, and SAP SuccessFactors, that owns employee records once a candidate converts. Candidate and employee data typically moves over vendor APIs and webhooks, not brittle scraping, so a stage change in the ATS drives the next automated step.

The pipeline is designed around data minimization and residency. We pull only the fields a given task needs, we keep EU candidate data in EU regions where required, and we log every model call with its inputs, outputs, and the citations behind them so the record is audit-ready by default rather than reconstructed later. Latency-first engineering matters here too, because a recruiter working a live pipeline will not wait on a slow model, and a candidate abandoning a stalled scheduling flow is a real cost.

The evaluation loop is part of the integration, not an afterthought. We stand up a golden dataset of representative resumes and requisitions, run selection-rate and impact-ratio checks continuously across protected categories, and alert when a metric drifts outside tolerance. That turns the annual Local Law 144 bias audit from a fire drill into a report you can generate on demand, and it gives your compliance team the standing evidence the EU regime will expect.

Failure modes and guardrails: where hiring AI goes wrong, and how we contain it

The dangerous failure in HR is not a visibly wrong answer. It is a plausible fabricated one. A model that invents a qualification a candidate never claimed, or infers a protected characteristic from a name or a graduation year, causes real harm quietly. We constrain the screening layer to extract and cite only what the source documents state, flag low-confidence extractions for human review instead of guessing, and exclude proxies for protected attributes from the inputs by design.

Human oversight is architectural, not advisory. The system narrows and annotates. A person decides. Every advance-or-reject step routes to a named reviewer, the reasoning and citations are shown, and the reviewer's action is what the ATS records. This is what makes the deployment defensible under GDPR Article 22 and coherent with the EU AI Act's human-oversight requirement, and it is why we refuse builds that ask the model to make the final call.

Governance ties it together: role-based access to candidate data, immutable decision logs, continuous bias monitoring wired into alerting, and clear cost transparency so you know what each stage of the pipeline costs to run. We own this end to end, from LLM system design and the RAG knowledge layer through evaluation and the AI ops that keep it running, because in hiring the compliance guarantees only hold if the same team owns the whole chain.

Common questions

Does an AI screening tool trigger NYC Local Law 144, and does using your system make us compliant?

If the tool substantially assists or replaces a human in screening or ranking candidates who live in NYC, including for remote roles, it is an Automated Employment Decision Tool and the law applies. We build systems designed to be auditable: continuous selection-rate and impact-ratio logging across protected categories, plus the traceable decision records an independent auditor needs. We do not perform the independent bias audit ourselves, because the law requires the auditor to be independent of the tool. We make passing one straightforward by producing the evidence on demand rather than reconstructing it once a year.

The EU AI Act high-risk deadline moved to December 2027. Why build for it now?

Because instrumentation is not a feature you bolt on later. The high-risk obligations for recruitment systems require logging, technical documentation, human oversight, and post-market monitoring, and a model that was not designed with those from the start has to be rebuilt to acquire them. Building compliant now costs little more than building non-compliant, while retrofitting after 2 December 2027 costs a rebuild plus the exposure of running an undocumented high-risk system in the interim. Designing to the harder standard also satisfies the lighter regimes automatically.

Will this integrate with our existing ATS and HRIS, or is it a rip-and-replace?

It integrates. The system is designed to sit on top of your applicant tracking system and HRIS rather than replace them, connecting over vendor APIs and webhooks to platforms such as Greenhouse, Lever, Workday, SmartRecruiters, BambooHR, and SAP SuccessFactors so your systems of record stay authoritative. We pull only the fields each task needs, respect data-residency requirements for EU candidates, and drive automation from your existing pipeline stages. If a platform lacks a needed endpoint, we tell you that during scoping rather than after a signed statement of work.