You posted one role and 300 resumes came in over the weekend. You have an hour. The pitch from every tool in your inbox is the same: let the AI read them, and you'll walk into Monday with a clean shortlist.
Part of that pitch is true. AI reads a resume against a set of must-haves faster and more consistently than a tired human at 6pm. According to SHRM's 2025 Talent Trends report, 44% of organizations now use AI somewhere in screening, and 46% of staffing firms told Bullhorn's 2026 GRID survey that AI has already cut their screening time by at least half.
The other part is where recruiters get into trouble. "Read the resumes" and "decide who gets rejected" are two different jobs. AI is good at the first and legally restricted at the second. In 2026 that restriction is not theoretical: New York City, Illinois, and California all have rules on the books about automated tools that screen applicants, and federal anti-discrimination law applies everywhere.
So the useful question is not "can AI screen resumes." It can. The question is how far up the automation ladder you can safely go before a machine is making a hiring decision you're accountable for. This guide walks the three rungs, with a concrete setup for each, where each one breaks, and what stays human.
A note before we start: this is a practical guide to how the tools work, with a summary of the relevant hiring rules as of June 2026. It is not legal advice. These laws vary by state and change often, so check your specific situation with your own legal counsel or compliance officer before you automate any part of screening.
The job to be done
Resume screening is the step after people apply. You have a stack of applicants and a role definition, and you're deciding who moves to a phone screen and who doesn't. That is different from sourcing, where you go find passive candidates who never applied. The distinction matters more than it sounds, because the law treats the two differently, and so should you. (If you want the full split, we cover it in candidate sourcing vs recruiting.)
Screening itself breaks into three sub-tasks. First, parsing: pulling structured facts out of an unstructured resume. Second, mapping: checking those facts against your must-haves and nice-to-haves. Third, the call: deciding who advances. The first two are mechanical. The third is judgment, and it carries legal weight. Keep these three apart in your head as we climb, because the automation story is completely different for each.
The automation ladder
Every task on a recruiter's desk can be automated to a different degree, and it helps to name the rungs. We use three.
| Rung | What it means | Effort |
|---|---|---|
| L1: one-shot prompt | You paste a resume and a job description into a chat tool and ask for a structured read. One resume at a time, no setup. | Minutes |
| L2: saved playbook | You build a reusable rubric or project so every resume gets read against the same criteria, in the same format, at batch scale. | A few hours to set up |
| L3: full agent | An autonomous system parses, evaluates, and acts on applicants inside your ATS without a human in the loop. | Tool config, ongoing oversight |
For most tasks, L3 is the goal. For resume screening, the ladder stops short of it, and the reasons are the most useful thing in this article.
L1: the one-shot prompt
This is the rung almost everyone can use today, for free.
You take a single resume and your job description, paste both into a general assistant like Claude or ChatGPT, and give it a clear instruction. Something like: "Here is a job description and a candidate resume. List which of these five must-have requirements the resume clearly meets, which it doesn't mention, and which are ambiguous. Quote the line you based each call on. Do not give an overall verdict." That last sentence matters. You want a structured read you can verify, not a thumbs-up you'll be tempted to trust blindly.
What you get back is genuinely useful. For a Senior Backend Engineer role, the model will tell you the resume shows seven years of Python, names Postgres and Kafka, and never mentions the AWS requirement you flagged. It surfaces the relevant lines in seconds. For one resume, this is faster than reading top to bottom, and the "quote the source line" instruction keeps it honest.
Where it breaks: consistency and context. Run the same resume twice and the phrasing shifts. The model has no memory of how it read the last 40 candidates, so your criteria drift across the stack. It also reads literally. A candidate who built the exact system you need but described it in different words can get marked "doesn't mention" when a human would see the match immediately. L1 is a reading aid for one resume at a time. It is not a screen.
L2: the saved playbook
This is where most recruiters should actually live in 2026.
Instead of re-typing the prompt, you build it once. In a Claude Project or a custom GPT, you save your screening instructions, your must-have rubric, and the exact output format you want, then feed resumes through it in batches. Every candidate gets read against the same criteria, in the same structure. You can paste ten at a time and get back a consistent table: requirement met, not met, ambiguous, with the supporting line for each.
The payoff is consistency, which is also a fairness argument. A documented rubric applied the same way to every applicant is more defensible than a human skimming faster as the day wears on. You can version the rubric, audit it, and explain it. For a high-volume role, L2 turns a two-hour slog into a 20-minute review of structured summaries.
Where it breaks: bias scales with volume, and so does your exposure. The moment a rubric runs across hundreds of applicants, any flaw in it (a credential proxy, a phrasing the model systematically misreads, a gap it penalizes) repeats identically every time. A human's inconsistency is random noise. A rubric's bias is systematic, and systematic disparate impact is exactly what anti-discrimination law looks for. L2 is powerful, but it raises the stakes: you now need to check the rubric itself, not just its outputs. Teams running this at scale should plan for a periodic bias review, which is not optional in some jurisdictions (more on that below). Our broader guide to AI in talent acquisition covers where those bias rules apply.
Crucially, even at L2 the machine produces a summary, not a decision. You still read the structured output and decide who advances. The instant you remove that step, you've climbed to L3, and that's where both capability and the law push back.
L3: the full agent, and why screening stops short of it
L3 is an autonomous system that parses every applicant, evaluates them against your criteria, and acts on the result inside your ATS, advancing or rejecting without a person reviewing each call. For tasks like interview scheduling or activity logging, this rung works beautifully and you should use it. For resume screening, it runs into two walls at once.
The first wall is capability. The judgment screening actually requires is the part AI is worst at: spotting the non-obvious fit, reading a career change in context, weighing a strong portfolio against a thin resume. Tools are moving here. Knockout questions on the application form (work authorization, required license) already auto-filter, and that's fine, because the candidate answered an explicit yes/no, not because a model judged a resume. In Spring 2026 Lever added AI Screening by VONQ, which puts applicants through a short structured screening step at the point of application rather than filtering on the resume file alone. But none of this closes the judgment gap on the resume itself. The map's honest verdict for this cell: screening tops out at strong assist, not autopilot.
The second wall is the law, and in 2026 it's concrete.
| Jurisdiction | Rule | In effect | What it requires |
|---|---|---|---|
| New York City | Local Law 144 (bias-audit law) | Since July 2023 | Annual independent bias audit of any automated employment decision tool, public results, and candidate notice. Penalties run $500 to $1,500 per violation, per day. |
| Illinois | HB 3773 (amends the Human Rights Act) | January 1, 2026 | You must notify applicants when AI is used in hiring, can't use AI with a discriminatory effect, and can't use ZIP code as a proxy for a protected class. Applies to any employer with one or more Illinois employees. |
| California | FEHA automated-decision system regulations | October 1, 2025 | An automated system that makes or even helps make an employment decision can't discriminate, directly or by disparate impact. You must keep ADS data and applicant records for four years. Liability can reach the tool vendor, not just you. |
| Federal (US) | Title VII (EEOC) | In force | Selection tools, including AI, can't produce disparate impact on protected groups. Applies to covered employers nationwide. |
Read those together and the pattern is clear. The more autonomously an AI tool screens applicants, the more of this lands on you: audits, notices, recordkeeping, and liability for the outcome. California's wording is the sharpest, because it covers tools that merely "facilitate" a decision, which can include an L2 rubric, not just a fully autonomous L3 agent. Colorado nearly joined this list with a broad AI Act, but it was narrowed and pushed to January 1, 2027, with enforcement currently paused, so treat it as something to watch, not a present requirement.
None of this means you can't use AI to screen. It means the autonomous version, the one that emails a rejection with no human in the loop, is the version that turns these rules into real exposure. The safe ceiling is L2 with a person making every advance-or-reject call.
What still needs a human
Two things, and they're related. The judgment, because the calls that matter (the non-obvious fit, the candidate worth a conversation despite a messy resume) are exactly where AI is weakest. And the accountability, because every law above assumes a responsible human, not an algorithm, stands behind the decision. Keep AI on parsing, mapping, and summarizing. Keep yourself on the call. That's not a compromise forced by today's tools. For a decision this consequential to a person's livelihood, it's the right design.
If you want to reduce screening load without touching any of this risk, the biggest win is upstream: put fewer, better-matched people into the funnel in the first place.
How to evaluate a candidate when the decision comes back to you
L2 is the safe ceiling because the advance-or-reject call stays with you. That is also how this task is encoded on our Recruiter Automation Map: longlist review is technically automatable and legally restricted, so the machine narrows and the human decides. Which raises the question this guide has so far avoided. What does the human half actually look like?
Evaluating a candidate defensibly comes down to five steps. Define the criteria before you look at anyone. Gather evidence against those criteria rather than impressions. Assess each candidate independently. Compare only after that. Write down the reason.
1. Define the criteria before you see a single application. Write out what the role requires, separate the genuine must-haves from the preferences, and decide in advance how you would recognise each one in a resume or a conversation. Criteria written after you meet people are not criteria, they are a description of whoever you liked. This is also what makes the L1 and L2 setups above useful at all: the model can only check requirements you have actually stated.
2. Gather evidence, not impressions. For each requirement, note the specific thing that speaks to it: the system they built, the problem they owned, the decision they made and what happened next. "Strong communicator" is an impression. "Explained a migration rollback to me in two minutes without jargon" is evidence. AI is genuinely good at the first pass here, pulling out what the resume claims against each requirement, and reliably bad at judging what the claim is worth.
3. Assess each candidate against the criteria, not against each other. Work through one person completely before opening the next file. Side-by-side comparison this early is where the loudest resume wins and where standards drift, because a candidate looks different depending on who happens to sit next to them in your tab order.
4. Compare only once everyone has been assessed independently. Now put them side by side. What you are comparing is what each person showed you against a fixed set of requirements, which is a different and far more defensible exercise than deciding who impressed you more.
5. Write down the reason. One or two sentences per candidate on which requirements they met, which they did not, and what you decided. This is the only thing that reliably exposes a criterion nobody can actually assess, which is usually a sign the requirement was never real. It is also increasingly a legal artifact rather than an internal nicety: California's automated-decision rules require employers to keep hiring records for four years, and federal disparate-impact claims are argued on exactly this kind of documentation. A decision you cannot reconstruct in a year is a decision you cannot defend.
What to keep from a scorecard, and what to leave
Most guides reach for a scorecard template at this point. The template is not the problem and neither is structure. Fixed criteria written before you meet anyone, with evidence recorded against each one, is the best-evidenced way to assess a person and the thing that defends the decision later. Keep all of that.
The number is where it gets complicated, for two separate reasons, and only one of them is legal.
The practical one first. A composite figure compresses the reasoning out of the decision. When you have to explain why this person advanced and that one did not, a 7.4 is not an explanation. The evidence was the asset and the arithmetic discarded it. This is also why AI output is easy to over-trust here: a tidy figure feels like a conclusion, when what it summarises is what the document claimed.
The legal one depends on who produces the figure. A person filling in a form is not a regulated tool. But when software computes that figure and orders applicants by it to determine who advances, you are describing an automated employment decision tool, which is the category New York City's Local Law 144 covers, with an annual bias audit and candidate notice attached. Illinois and California have their own rules, and federal anti-discrimination law applies regardless. The boundary is narrower than most coverage suggests: the DCWP's own guidance places sourcing outside that scope. Deciding who to contact is not deciding who advances.
That boundary is also why you will not find a score or a rank attached to a person anywhere in Glozo. We work before anyone applies, and keeping the vocabulary clean is how the distinction stays legible, to you and to a regulator.
Two failure modes are worth naming, because AI makes both more likely rather than less. The first is criteria drift, where the requirements quietly reshape themselves around a candidate you have already decided you want. The second is deferring to the summary: a note that someone meets four of six requirements tells you what the resume claims, not whether the person can do the job. Treat it as a reading of the document, which is what it is.
None of this is new. Structured evaluation has been the better-evidenced approach for decades. What changed is that the AI layer raises both the volume you are assessing and the standard of proof you are held to, which makes the unstructured version harder to get away with than it used to be.
Where Glozo fits, and where it doesn't
Full disclosure: I work on Glozo, and I'll tell you exactly where it helps here and where it has nothing to offer.
Glozo does not screen your applicants. It isn't an automated employment decision tool, it doesn't sit in your application funnel, and it won't reject anyone. That whole layer, the one the laws above govern, is outside what Glozo does, by design.
Where Glozo earns its place is one step earlier. Most screening pain is really a sourcing problem: you're drowning in applicants because the top of the funnel is wide and untargeted. Glozo works before anyone applies. Its Smart Search reads intent rather than keywords, surfaces candidates from 30+ sources ordered by how closely they match what you actually need, and flags who is potentially open to a move. The Sourcing Agent runs that in the background and brings you a shortlist of people worth contacting. Build the longlist well and the screening stack on the other side gets smaller and cleaner, without handing any decision to a machine. That's a sourcing tool helping you spend less time screening, not a screening tool pretending the law doesn't apply.
If keyword search is still where your sourcing starts, Boolean and free resume-search tools are a fine on-ramp, and open-source ATS options cover the pipeline side.