Key findings

• Define essential job evidence before processing candidate data.

• Never use model output as the sole reason to reject or advance a candidate.

• Provide accessible alternatives and a clear accommodation channel.

• Log criteria, evidence, model version, reviewer action, and candidate status change.

• Treat bias and accessibility testing as recurring operations, not a launch task.

Choose low-risk automation before selection automation

Break recruiting into requisition approval, job description, sourcing, application intake, eligibility checks, evidence review, interviews, decision, offer, and disposition. Start with tasks that do not decide opportunity: scheduling, reminders, duplicate-record cleanup, candidate communications approved by HR, interview-packet assembly, and structured note formatting. These can remove friction while preserving the existing decision process.

Screening and ranking are higher risk because they affect who receives consideration. The U.S. Department of Justice explains that algorithmic hiring can screen out qualified people with disabilities, and the employer remains responsible when using another company's technology. NYC Local Law 144 adds bias-audit and notice requirements for covered automated employment decision tools. This guide is operational, not legal advice; identify applicable laws with qualified counsel across all candidate and job locations.

Define a job evidence schema

Before prompting a model, convert the approved role into structured, job-related evidence. Separate genuinely required qualifications from trainable preferences. For each criterion, define the evidence accepted, scoring rubric, reviewer guidance, accommodation considerations, and what must not be inferred. Avoid proxies such as school prestige, address, name, employment gaps, voice, facial expression, or writing style unless a validated, job-related reason and legal review supports their use.

A candidate record might store criterion ID, source excerpt, document location, model summary, reviewer assessment, confidence, and unresolved question. The model may organize evidence but should return unknown when the application does not support a conclusion. It must not infer age, race, disability, health, family status, religion, or other protected attributes. Use a fixed schema so the ATS receives explicit fields rather than an unreviewable narrative score.

• Required: criterion definition, business rationale, evidence type, reviewer owner.

• Forbidden: personality diagnosis, emotion recognition, protected-trait inference, unsupported culture-fit scoring.

• Reviewable: every recommendation links to candidate-provided evidence and the relevant criterion.

Design the ATS integration and human decision

Use the applicant tracking system as the system of record. Greenhouse's Harvest API, for example, supports candidate and application data and requires an On-Behalf-Of header for certain audited actions. Retrieve only the fields needed for the workflow, use a service account with narrow access, and map every write to a named business action. Do not let the model directly advance, reject, or delete an application.

Present reviewers with criterion-by-criterion evidence, missing information, and conflicts. Require a person to record the decision and reason. A rejection reason should refer to an approved criterion, not a model score. Lock the evidence snapshot used for the decision, then write the final status and reason to the ATS. If the integration fails, keep the case pending rather than telling the candidate a status that the ATS does not contain.

Build candidate notice, access, and accommodation paths

Tell candidates what technology is used, what information it evaluates, where human review occurs, how long information is retained, and how to request an accommodation or alternative process. Notices must match actual behavior. Provide a route that does not penalize a person for using assistive technology, needing more time, or declining an optional automated assessment.

Test the application and assessment flow with keyboard navigation, screen readers, captions, zoom, mobile devices, and interruption recovery. Do not ask an AI assistant to interpret an accommodation request or disability disclosure beyond routing it to authorized HR staff. Restrict such data from hiring-manager views unless needed for the accommodation process. Candidate-facing messages about legal rights, rejection, or offer terms should use approved templates and human review.

Govern data, vendors, and model behavior

Create a data inventory covering resumes, assessments, transcripts, notes, model inputs, outputs, logs, and derived scores. Define purpose, legal basis where relevant, retention, deletion, access roles, export location, and whether vendor systems use data to improve models. Prohibit production candidate data in personal AI accounts. Contractually document subprocessors, incident notification, deletion, regional processing, audit rights, and model-change communication.

Use versioned prompts and models, schema validation, input sanitization, least privilege, and an allowlist of ATS actions. Test prompt injection embedded in resumes, hidden text, links, and attachments. Candidate content must never alter system policy or trigger tools. Maintain a kill switch that stops AI processing while the standard application and human review path remains available.

Measure decision quality and adverse outcomes

Operational metrics include time in stage, scheduling failure, candidate response time, recruiter edit rate, missing-evidence rate, ATS write failures, and unresolved exceptions. Quality metrics require labeled review: criterion-evidence precision, unsupported inference rate, false omission of relevant evidence, reviewer agreement, and overturned recommendations. Segment by role and workflow version instead of blending unlike jobs.

Monitor selection outcomes at meaningful stages with counsel and qualified specialists. A statistical audit does not prove a process is lawful or fair, and a favorable average can hide accessibility barriers or harms to smaller groups. Investigate changes in pass rates, accommodation issues, complaint themes, and reviewer overrides. NIST's AI RMF functions of Govern, Map, Measure, and Manage provide a useful operating structure for assigning responsibility and responding to observed risk.

Roll out with independent review gates

First document the current process and historical decision criteria. Run the system in shadow mode with no candidate impact, using representative roles and enough cases to expose missing evidence and accessibility problems. Compare output with trained reviewers, perform legal and privacy review, test integrations and deletion, and publish candidate notices before any live assistance.

Enable one low-risk function at a time. For screening support, keep universal human review and prohibit automatic rejection. Define stop conditions such as unsupported protected-trait inference, inaccessible flow, material outcome disparity, unexplained model change, data leak, or incomplete ATS audit events. Review the system after role changes and vendor releases. Preserve a manual process that can continue immediately during suspension.

Sources and methodology

This article synthesizes the primary sources below as of the publication date. Forecasts and recommendations are directional scenarios, not guarantees; they should be tested against your workflow, data, risk tolerance, and current vendor documentation.

U.S. Department of Justice: Algorithms, Artificial Intelligence, and Disability Discrimination in Hiring (accessed 2026-07-30)

U.S. Equal Employment Opportunity Commission: EEOC artificial intelligence publications (accessed 2026-07-30)

New York City Department of Consumer and Worker Protection: Automated Employment Decision Tools (accessed 2026-07-30)

Greenhouse: Harvest API (accessed 2026-07-30)

NIST: AI Risk Management Framework (accessed 2026-07-30)