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.
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.