AI Candidate Screening: How It Works and Where Humans Decide

AI candidate screening converts a CV and a job description into vectors, scores the match, applies knockout rules, and returns a ranked shortlist. It does not hire anyone. A recruiter sets the knockout rules, reviews the middle of the ranking, and owns every rejection the system proposes.

I have spent two years building screening pipelines for employers drowning in applications, and what surprises clients is how little of the work is machine learning. Most of it is data hygiene, threshold policy and audit plumbing. The model is maybe a fifth of the build.

What follows walks the ai candidate screening pipeline stage by stage, shows the arithmetic behind an adverse impact test with numbers you can check, and sets out what each jurisdiction actually requires with a link to the statute or the regulator rather than to somebody's summary of it. Nothing here is legal advice. Post one in this series, AI hiring law in 2026 and every rule that changed in the last 90 days, owns the legal change log; this page owns the screening mechanics.

What automated resume screening does between upload and shortlist

A production pipeline has five stages. Vendors compress them into one marketing word, which is why buyers compare candidate screening software on features that do not exist.

Parsing and normalisation. The CV becomes structured text: employment spans, titles, education, certifications, achievements. PDFs from design tools, two-column layouts and scans all degrade parse quality. We log a parse-confidence score per document and route anything under threshold to a human queue rather than letting it score badly and vanish. A candidate whose CV failed to parse is not a weak candidate, and conflating those two states is the most common defect in inherited systems.

Knockout criteria. The hard, legally defensible facts: right to work, a required licence, a security clearance, minimum shift availability. Knockouts are deterministic and auditable. They are not a model. Years of experience is what clients most want to hard-code and the thing I push back on hardest, because it correlates with age and predicts performance poorly.

Skills extraction. The system pulls explicit skills and infers implicit ones from context. Someone who shipped a Kubernetes migration has container orchestration experience whether or not the phrase appears. Extraction runs against a controlled taxonomy, usually ESCO or O*NET plus a client extension, so "program management" and "PMO lead" collapse to one node.

Matching. This is where ai candidate matching happens. The job description and the candidate profile both become dense vectors produced by a text embedding model, and similarity is computed in that space. Because vectors encode meaning rather than tokens, a CV saying "predictive modelling" matches a posting saying "machine learning engineer" without either string appearing in the other.

Ranking. The output is an ordered list with a similarity value attached. That value is not a probability, not a percentage fit and not a grade. Misreading it causes a lot of bad hiring decisions.

Why applicant tracking keyword filters are a different, older thing

Buyers conflate two technologies that are twenty years apart.

Classic applicant tracking filtering is boolean. The requisition carries required terms, the system checks presence, candidates who miss them drop out. The Harvard Business School and Accenture study Hidden Workers: Untapped Talent, published September 2021, reported that 88% of surveyed employers agreed qualified high-skills candidates were vetted out of the process because they did not match the exact criteria in the job description, rising to 94% for middle-skills workers. That is a keyword problem, not an AI problem, and it predates every tool now marketed as ai screening.

Embedding-based ai candidate matching removes that specific failure. It does not remove bias, and anyone selling it as debiasing technology is misrepresenting the mechanism. Kyra Wilson and Aylin Caliskan's audit of text embedding models used for CV ranking, presented at AIES 2024 and revised on 30 August 2026, found the rankers significantly favoured White-associated names in 85.1% of cases and female-associated names in only 11.1% of cases, with Black male candidates disadvantaged in up to 100% of cases across the nine occupations tested. The layer that fixes the "programme manager" problem is the layer carrying name association from pretraining data.

Newer models behave differently. Zhenyu Gao, Wenxi Jiang and Yutong Yan audited fourteen mainstream language models with a paired-CV design, published 27 June 2026, running 24,024 paired postings per model. The single 2023-vintage model reproduced the pro-White callback gap seen in field experiments, at +2.12 percentage points. Every model released in 2024 or later showed either no gap or a significant reversal in the other direction, up to -3.01 percentage points. The direction flipped, which is not the same as the problem being solved, and neither result tells you what your own configuration does on your own applicant pool.

Most hr applicant tracking suites now ship both layers: legacy boolean filters an admin configured years ago, and a semantic ranker bolted on top. Check which one is discarding people before the ranker sees them, because that is where the silent losses happen, and because a filter nobody has reviewed since 2019 is still your decision in law.

How to trick AI resume screening, and why it mostly stopped working

Candidates worked out the old game quickly: keyword stuffing, white text on white, invisible skill lists in the margin. The current version is prompt injection, instructions hidden in the CV aimed at a language model reading it. Mohan Zhang and colleagues, in work published at USENIX Security 2026, analysed roughly 200,000 real CVs collected over several years by hireEZ and found approximately 1% contained hidden prompt injections, with more than 90% of injected prompts avoiding explicit instructions.

One percent sounds small. On a requisition drawing 250 applications that is two or three documents, and if one reaches your interview slate because a hidden instruction worked, you have a governance problem. Any pipeline passing raw CV text to a language model needs a sanitisation pass: strip invisible and off-canvas text, compare rendered text against extracted text, flag discrepancies. We treat a mismatch as a hard stop.

Employers ask how to trick AI resume screening as often as candidates do, usually to learn what to defend against. The honest answer is that stuffing is now detectable and injection is now measured, while genuine specificity still works, because embedding models reward concrete achievement language over title padding. A good AI resume checker will tell an applicant their bullets are vague. It will not invent a Kubernetes migration for them.

Who decides at each stage

This is the table I put in front of every HR director before we scope a build. If they cannot agree the middle column, we do not start.

Two rows carry the weight. Reject is human-only in every system we ship, because rejection holds the legal exposure and the reputational cost, and because a person confirming it costs seconds when the queue is well ordered. Ranking is machine-recommends because ordering a queue is what the technology is genuinely good at.

The UK regulator has put a name to the standard that row is trying to meet. The Information Commissioner's Office, in its draft guidance on automated decision-making and profiling for recruitment and selection, states that data protection law restricts solely automated decisions with legal or similarly significant effects and that this "includes a decision about whether to shortlist a candidate, recommend them for interview, reject them or promote them". Automated systems may assist those decisions provided there has been meaningful human involvement. A reviewer who sees only a score and a name is not meaningful involvement in any reading of that sentence.

That split is the design philosophy behind ai agents in talent acquisition as we build them: agents own sequencing, retrieval and logistics, people own outcomes. For the wider control-plane pattern, our guide to agentic AI in the enterprise and its architecture, guardrails and ROI goes deeper, and choosing an AI agent development partner covers writing that oversight into a statement of work.

Calibration, and the candidates ranked in the middle

A cosine similarity of 0.83 means nothing on its own. It is not 83% fit. It is a position in a distribution whose shape depends on the job description you wrote, the model you chose and the pool that applied.

Calibration turns that number into policy. Take historical requisitions where you know the outcome, fit the ranking against those outcomes, derive the band boundaries empirically. Band boundaries are the part a vendor cannot set for you, because they depend on your pool and your role mix, and anyone quoting a universal cut-off is guessing.

The middle band is the real problem. In a pool of 250 the model is confident about maybe the top 15 and the bottom 100. The other 135 sit where ranking is close to noise, and the gap between rank 40 and rank 95 is smaller than the ranker's own measurement error.

Three things we do with that band, and none is reject.

Stratified sampling first: pull a random sample from the middle into human review every cycle, regardless of rank. If reviewers keep finding strong people at rank 90, your calibration is wrong and you have evidence rather than a hunch.

Second-signal routing next. Rather than ranking the middle harder, send it a lightweight structured task: a short work sample, role-specific questions, or a conversational ai recruiting flow that asks the four things the CV could not answer.

Band persistence last. Mid-band people go into the candidate management system tagged with role family and the reason they were held, so the next requisition starts from people you have already assessed. A candidate management system that discards ranking metadata throws that away, and the loss never shows up in a time-to-hire metric because the cost lands on the next requisition rather than this one.

What our own screening runs produced

We have one published engagement with numbers attached, and I want to be precise about what kind of numbers they are before quoting them.

The figures below come from our AI HR Agent time-to-hire case study, published 23 July 2026. They are first-party. They were measured on one client's Greenhouse instance, comparing a deployment quarter against that same company's trailing twelve-month average in the same system, using requisition-open and offer-accepted timestamps rather than estimates reconstructed afterwards. The client is anonymised at their request, the sample is one employer of roughly 600 staff over one quarter, and the case study itself states that the figures reflect the product's target performance for a company of that size and hiring volume rather than an independently audited third-party result. Treat them as XOVO design targets that one engagement met, not as an industry benchmark.

The AI HR Agent product page carries three headline metrics: 45% faster time-to-hire, 90% screening accuracy, and 4x more applicants reviewed. The first and third are the design targets the engagement above was measured against. The second one I would not buy from anybody, including us, without asking what it means, because "screening accuracy" has no agreed definition in this category. Accuracy against what label? Recruiter agreement on a shortlist, interview pass rate, offer acceptance? Until a vendor names the label and the sample, a single accuracy percentage is a marketing number rather than a measurement, and that applies to ours as much as to anyone else's.

What we do not have is an independently audited, named-client screening result. No anonymised case study is a substitute for one, and any vendor presenting a representative engagement as an audited outcome is overstating it. When a client agrees to be named and audited, we will publish that instead of this.

Vendor claims versus what the arithmetic allows

Our own product page says 45% faster time-to-hire. Here is how to work out whether a number like that can hold on your funnel, using quantities you already have.

Start by defining the window, because most disagreements about screening ROI are actually disagreements about what was measured. In the engagement above, time-to-hire runs from requisition open to offer accepted. The nine-day gap before a new hire had a laptop and system access sits after offer acceptance, so it contributes nothing to the 45%. Onboarding improvements are real and they are not in that number. Vendors routinely blur the two.

Now take the three quantities that decide what screening automation can return.

Applicant volume per requisition. Screening automation converts a queue into a task. If your reviewers are not queueing, there is nothing to convert. Count applications per requisition for your three highest-volume role families over the last two quarters.

Minutes per CV. Measure it rather than assume it. Manual screening hours per requisition = applicants x minutes per CV / 60. At an illustrative four minutes per CV, 250 applicants is 16.7 hours of reading for one opening. At 80 CVs, the number most reviewers stop at, it is 5.3 hours. The difference between those two is the effort your recruiters are currently not spending on the rest of the pool.

Pass-through rate. If the machine-built shortlist converts to offer at a lower rate than the hand-built one, you pay the saved days back in extra interview loops. Effective days saved = screening days removed minus (additional loops x days per loop). Track shortlist-to-offer conversion before and after, per role family, or the headline improvement is unfalsifiable.

Then compute the ceiling. The most screening automation can remove is the calendar time currently spent getting from application close to a shortlist, minus whatever the automated turnaround actually takes.

Maximum reduction from screening alone = (calendar days to shortlist today - automated turnaround in days) / total days in the hiring window.

Run it on the case-study numbers. Shortlist turnaround was 6 to 8 business days, which spans roughly 8 to 12 calendar days. Automated turnaround was under 24 hours, so call it one day. The hiring window was 38 days.

A 45% reduction on a 38-day window is 17.1 days. Screening explains 7 to 11 of them. The remaining 6 to 10 days have to come from somewhere else, and in that engagement they came from background-check tracking that stopped being an email chase and from approval steps that stopped waiting on a person to remember. If you buy screening software and change nothing downstream, the arithmetic above is your realistic ceiling, and 18 to 29 percent is a perfectly good result that no vendor puts on a landing page.

This is also the test to run on any vendor's headline. Ask which window the number was measured across, what the shortlist step cost in calendar days before, and what the pass-through rate did afterwards. If a vendor cannot answer the first question, the other two will not save the claim.

If you would rather not do this on a spreadsheet, the AI HR Agent team runs a free audit that rebuilds your funnel from six months of applicant data, computes the ceiling above on your own numbers, and shows impact ratios per stage. Book it here.

A worked four-fifths calculation you can check line by line

The test everyone means by bias audit is the four-fifths rule, and it is not vendor folklore. It sits in the Uniform Guidelines on Employee Selection Procedures at 29 CFR 1607.4(D), current in the Code of Federal Regulations as of 10 September 2026, which states that a selection rate for any race, sex or ethnic group that is less than four-fifths, or eighty percent, of the rate for the group with the highest rate "will generally be regarded by the Federal enforcement agencies as evidence of adverse impact". The same paragraph adds two qualifications people forget: smaller differences can still constitute adverse impact where they are significant in both statistical and practical terms, and greater differences may not, where they rest on small numbers.

Here is the arithmetic on illustrative numbers. These are invented for the worked example and are not client data. A support role drew 4,000 applicants and the advance band produced these outcomes.

Every line checks by hand. 338 divided by 2,600 is 0.1300. 90 divided by 900 is 0.1000. 46 divided by 500 is 0.0920. Group A has the highest rate, so it becomes the reference. 10.00 divided by 13.00 is 0.7692. 9.20 divided by 13.00 is 0.7077. Both fall under 0.80. Across the whole pool, 474 of 4,000 advanced, an overall rate of 11.85%, which is the number that would have looked unremarkable on a dashboard.

Now run the same pool the way New York City's rule tells you to when the tool returns a score rather than a pass or a fail. The DCWP final rule at 6 RCNY 5-300, effective 5 July 2023, defines scoring rate as the rate at which individuals in a category receive a score above the sample's median score. With 4,000 applicants the median is the 2,000th score, so exactly 2,000 people sit above it.

1,404 plus 414 plus 182 is 2,000, so the median holds. 46.00 divided by 54.00 is 0.8519. 36.40 divided by 54.00 is 0.6741. The two views of the same pool disagree: the selection-rate view flags Group B and the scoring-rate view does not. That is not a contradiction. It means your band boundary, not the model, is what pushed Group B under the threshold, and moving the advance band is the cheapest fix available to you. Run both views before you touch the model.

Three more things the New York City rule requires that generic bias-audit tooling tends to skip. The audit must calculate selection rate and impact ratio separately for sex categories, for race and ethnicity categories, and for intersectional categories of sex, ethnicity and race. It must state how many people the tool assessed who fall into an unknown category and were therefore left out of the calculations. And an independent auditor may exclude any category comprising less than 2% of the data, which on a 4,000-person pool means any group under 80 people can drop out of the impact ratio entirely. If your smallest protected group is 60 applicants, the audit can be fully compliant and still say nothing about them.

What a flag does not tell you is why. Three causes produce identical arithmetic: the ranker genuinely disadvantages the group, the applicant pools differ in ways the ranker is correctly detecting, or your band boundary sits where small differences amplify. The third is the most common and the easiest to test. Move the advance band from the top 6% to the top 9%, recompute, and watch the ratios.

A defensible audit reports impact ratios, raw counts and a significance test at every stage of the funnel, because a pipeline can look clean at offer while a knockout rule does the damage at intake. An independent auditor needs five things, and gathering them is usually four to six weeks of client-side work: the applicant-level dataset with self-identified demographics and outcomes at each stage; the tool's inputs and outputs including ranking values; documentation of thresholds and band boundaries with change dates; the job descriptions in force during the period; and evidence the auditor has no financial interest in the tool. On that last point the New York City rule is specific: an auditor is not independent if they were involved in using, developing or distributing the tool, or hold a direct or material indirect financial interest in the employer or the vendor. A vendor cannot audit its own tool. It can, and should, coordinate the extract.

Screening obligations by jurisdiction

Every row links to the statute, the rule or the regulator page rather than to a commentary on it, with commencement status as it stood on 13 September 2026. Check the date at the source before you rely on it, because three of these six moved in the last eighteen months. This is a summary of published obligations, not legal advice.

Two observations from building against this table. The triggers are incompatible in a way that makes per-jurisdiction compliance pointless above about four states. Illinois asks whether the effect was discriminatory. Colorado asks whether the technology materially influenced the decision. New York City asks whether the tool substantially assisted it, which a human sign-off does not cure. The only artefact that satisfies all three is a decision record you can reconstruct, so build that once rather than three policy documents.

The second observation is about vendors. In the United States, whether a screening vendor can be liable alongside the employer is live litigation rather than settled law. Mobley v. Workday, Inc. is pending in the Northern District of California as case 3:23-cv-00770, filed 21 February 2023 and not terminated as of September 2026. For what each ruling in it has changed, the 2026 AI hiring law breakdown tracks the docket. The relevant point here is that a vendor's bias audit is an input to your obligation and never a discharge of it.

Best practices for implementing automated candidate screening

Compressed to what matters, the best practices for implementing automated candidate screening are: agree the human-decides table before anyone writes code, calibrate against your own historical outcomes rather than a vendor benchmark, log every ranking with the model version and the job description hash that produced it, run adverse impact analysis before go-live and on a fixed cadence after, and keep rejection a human action.

Logging is the one teams skip and regret. If you cannot reconstruct why a candidate ranked where they did on a given date, you cannot answer a regulator, a claimant's counsel, or an applicant who simply asks. Store the inputs, the model identifier, the extracted skills, the band boundary in force and the reviewer who acted. When you evaluate candidate screening software, ask to see that log before you look at a dashboard.

Where data residency rules make a hosted model awkward, our guide to private LLM hosting and when to run models on your own infrastructure covers the trade-offs, and it applies to ai screening tools as much as to chatbots. If screening is one part of a wider programme, what to automate in HR and what regulators now require maps the same obligations across the rest of the employee lifecycle, and our AI automation service is where the integration work sits.

What a CV cannot tell you, and what to use instead

The uncomfortable truth about resume review AI of any kind is that the document is a weak instrument, and the evidence on selection methods got less flattering rather than more.

Paul Sackett, Charlene Zhang, Christopher Berry and Filip Lievens re-estimated the meta-analytic validity of selection procedures in the Journal of Applied Psychology in November 2022, after showing that the standard range-restriction corrections had produced substantial overcorrection. Their conclusion was that most procedures keep their relative rank but that mean validity estimates fall by .10 to .20 points, and that structured interviews emerge as the top-ranked selection procedure. A CV is not on that ranking at all, because it is an input to those methods rather than a method.

This is why I push clients toward ai candidate assessment software for the second signal rather than a better ranker for the first. It gives everyone in a band the same structured task and scores objective components automatically, leaving judgement items to trained reviewers. Any resume review AI, however well built, is still reading a marketing document the candidate wrote about themselves.

Video interviewing software fits here with a condition attached: use it to capture and structure responses for human review, never to score facial expression, tone or enthusiasm. Inferring emotions in the workplace is prohibited outright in the European Union under Article 5(1)(f) of the AI Act, which has applied since 2 February 2025, and the validity case for it was thin before the ban. If your vendor cannot say which features feed the score, that is your answer.

Sourcing runs on the same logic. Candidate sourcing engines and talent sourcing systems are rankers pointed at a passive pool, and they inherit the same calibration and audit obligations. If you use our AI Talent Scout for outbound talent sourcing, the adverse impact question applies to who it surfaced, not only to who you hired. Teams that treat candidate sourcing and talent sourcing as exempt from audit get surprised, because the ai candidate matching underneath is the same model against a different pool.

Does AI candidate screening cut time-to-fill, or move the work?

Both, and the industry data is blunt.

Greenhouse's benchmark report The Hire Standard, published March 2026 and drawn from more than 6,000 companies and over 640 million applications between 2022 and 2025, found applications per job rose 111%, from 116 in 2022 to 244 in 2025. Applications per recruiter rose 412%, from 146 to 746. Recruiters per organisation fell 56%, from 10.43 to 4.62. Across the same window time-to-fill rose 37%, from 43.64 days to 59.67. Note the metric: Greenhouse measures time-to-fill, not time-to-hire, and the two are routinely swapped in write-ups of that report. Adoption of ai screening tools climbed throughout the period and time-to-fill got worse anyway.

Automated resume screening removes the review bottleneck and exposes the next one, usually interview scheduling, hiring manager latency, or an approval chain nobody has examined since 2019. Automate screening and change nothing downstream, and you will process more candidates at the same speed.

Volume is rising from the candidate side too. SHRM's Recruiting Executives Priorities and Perspectives 2026, fielded 21 January to 4 February 2026 with 298 heads of recruiting, found 85% expect candidates to increasingly use AI applications to apply and 74% expect candidates to use AI in interviews. Every applicant now has an AI resume checker and a bulk-apply tool, and both are cheap. Buying ai resume screening tools without fixing your job descriptions and your funnel makes you a faster participant in that cycle.

What volume makes automated candidate screening worth building

My rule of thumb comes from engagements, not a study, so weigh it accordingly. Below roughly 40 applications per requisition, a recruiter reading everything is faster, cheaper and better than any ai applicant screening system you can buy or build. Between 40 and about 150, configure what your hr applicant tracking suite already ships and spend the money on structured interviews. Above 150 per requisition, sustained across a role family, a purpose-built layer pays for itself inside two quarters, mostly in recruiter hours and reduced drop-off.

The second threshold is repeatability. Automated CV screening only compounds when the same role family repeats. Screening 400 applications once a year for a unique role is not an automation problem. Screening 200 a week for the same three role families is. Our AI HR Agent is built for the second case, and I will tell a prospect the first case is not worth the build. That is the honest test for most candidate screening tools on the market: they are priced for repeat volume, and below it the licence costs more than the hours it saves.

Can candidates tell, and what you owe them when they ask

Mostly they cannot, and they know they cannot, which is worse.

Enhancv surveyed 1,066 US job seekers in April 2026 with a margin of error of 3.0%, reported in its AI hiring statistics research. Half, 50.5%, had been rejected at least once in the previous year without a word from a human. Of that group 63.8% believed a machine made the call, yet only 9.7% of the full sample said an employer had ever clearly told them AI was involved, and 68.5% reported no disclosure at all. In the same data, 31.4% abandoned an application specifically to avoid a one-way AI video or chatbot screen.

Candidates are not objecting to the technology. They are objecting to being assessed by something nobody mentioned, which is a candidate experience software problem long before it is a legal one. In New York City the notice is not optional: the DCWP rule requires it 10 business days before the tool is used, and it has to include instructions for requesting an alternative selection process or a reasonable accommodation where one is available.

Should I opt out of AI resume screening?

Candidates ask this constantly, and the search volume behind "should I opt out of AI resume screening" measures how badly employers have communicated. My answer, as someone who builds these systems: opting out usually routes you into a manual queue that is slower and no more favourable, so the practical case is about data retention and downstream matching rather than your odds on this requisition. Asking what the system evaluates is the stronger move.

The employer obligation is simple. When a candidate asks how a decision was made, you owe four things: confirmation that an automated tool was used and at which stage; a plain description of what it evaluated, meaning skills matched against the posted requirements rather than "an algorithm assessed your fit"; the name of the human who made the final call; and a route to have the decision reviewed. In the European Union the last pair stops being a courtesy. Article 86 of the AI Act gives a person subject to a decision taken on the basis of the output of an Annex III high-risk system the right to obtain from the deployer clear and meaningful explanations of the role the system played in the decision procedure and the main elements of the decision taken. Colorado arrives somewhere similar from 1 January 2027, with a plain-language explanation within 30 days of an adverse outcome and a right to human reconsideration.

We build that as a templated response backed by the audit log, so a recruiter answers in under two minutes without a legal review each time. An ai recruiting chatbot is a reasonable front door for those questions as long as it hands off to a person on request, and the transcript belongs in the same audit log.

High-volume roles, specialist hires, and where we would not automate

The technique does not transfer evenly.

High-volume hiring is where ai for candidate screening is strongest: hundreds of applicants against a stable competency profile, with enough historical outcome data to calibrate. Contact centre, warehouse, retail, field service, graduate intakes. An ai recruiting assistant handling first-pass ranking and an ai recruiting chatbot handling availability will take real hours out of the week, and the volume gives you the sample size for a meaningful adverse impact analysis rather than a table of unstable ratios.

Specialist hiring is where it is weakest, and I say that as the person selling the software. When you hire four principal engineers a year from a pool of thirty, there is no calibration set, four-fifths arithmetic is meaningless at that sample size, and the qualities that matter are the ones a CV cannot carry. Use ai screening tools to organise the pool and brief the interviewer. Do not let them order it.

Third case, and people forget it: internal mobility. Pointing ai for candidate screening at internal applicants, scored against records your own HRIS generated, is the fastest route to encoding a decade of your own promotion patterns. If you must run automated CV screening internally, strip tenure and manager identity first and treat the output as a longlist.

Stopping the model from learning your past hiring bias

Fine-tune a ranker on who you hired historically and you have built a machine that reproduces your history. That is the Amazon lesson from 2018 and it has not stopped being true.

Four things we do. We do not train ranking models on hire or no-hire labels; the model does semantic similarity against the job description, and we calibrate the band boundary against downstream outcomes such as structured interview scores, which are less contaminated than hire decisions. We strip name, address, photograph, graduation year and institution before the text reaches the ranker, then test whether the ranking moves when we put them back, because if it does, the model was using proxies. We run adverse impact analysis at every funnel stage, not only at offer. And we re-audit whenever the model version, the job description template or the band boundary changes, because all three shift the distribution.

Where we would not automate at all: any role drawing under about 40 applications per requisition, safety-critical roles where a false negative on a qualification is catastrophic, and any process where the client will not name a human owner for rejections. The last is not a technical constraint. It is the condition that keeps everything else defensible.

None of this needs a big platform decision behind it. It needs a funnel you can reconstruct and a named person willing to own the reject. If you want to pressure-test your own ai applicant screening pipeline, we run a free audit that rebuilds your funnel, computes impact ratios per stage under both the selection-rate and the scoring-rate method, and tells you where the ranking is doing work and where it is doing damage. Book it here and bring six months of applicant data, or read the AI HR Agent capability set first if you would rather see the product before the call.