AI resume screening: where AI helps, and where the law starts

Published 5 October 2026

AI resume screening: use AI to read the CV, think hard before it judges

AI resume screening covers two very different jobs, and they carry very different risk. The first job is reading: turning a PDF into a name, a list of roles with dates, a list of skills. AI is good at this and nobody is harmed when it gets a field wrong, because a person can see the field and correct it. The second job is judging: scoring, ranking or filtering people. That is the job regulators have written rules about, and it is the one where a confident wrong answer quietly removes a real candidate from a pipeline.

This article is for the developer adding AI to a job board, an applicant tracking system or an internal hiring tool, and for the recruiter deciding what to ask a vendor. It separates the two jobs, says what the rules say as of October 2026, and shows a build that gets most of the speed without handing a model the decision. We make ResumeJSON, a parsing API that does only the reading half, so treat that section as written by an interested party. The advice about the judging half holds whichever tool you use.

The two halves of AI resume screening

Most "AI screening" products blur these together. Pulling them apart is the most useful thing you can do before buying or building.

Reading is a transcription problem. Judging is a decision problem. AI helps with transcription because CVs are messy: two-column layouts, dates written five ways, scanned pages. A fixed rule cannot cope with that variety, and a language model can. Judging is different. The "right" answer depends on a role, a team and a hiring manager's priorities, and none of that lives in the CV.

What the rules say, as of October 2026

You are not the only one watching this split. Two instruments draw the line in the same place.

New York City. The city's consumer and worker protection department describes Local Law 144 of 2021 on its automated employment decision tools page. In its words, the law:

prohibits employers and employment agencies from using an automated employment decision tool unless the tool has been subject to a bias audit within one year of the use of the tool, information about the bias audit is publicly available, and certain notices have been provided to employees or job candidates.

The same page notes that enforcement began on July 5, 2023, and offers a complaint form for candidates and workers. The legal definition of the tool turns on a simplified output such as a score, a classification or a ranking used to substantially assist or replace discretionary hiring decisions. Read the law itself and its rule before relying on that summary.

European Union. Annex III of the EU AI Act lists high-risk uses. For employment it names:

AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates;

Filtering applications and evaluating candidates are on the list. Extracting a date from a document is not mentioned.

This is not legal advice. The point for a builder is narrower: both texts attach to what the system concludes about a person, not to whether it used AI. A rules engine that ranks applicants can fall into scope. A model that only transcribes a CV generally does not, though what you build on top of its output still may. Our own compliance page walks through that distinction for a parser, and says plainly that using one neither puts you in scope nor takes you out.

Where AI genuinely helps

Give AI the jobs where it is fast, checkable and low-stakes.

• Parsing CVs into fields. One schema for every document, whatever the layout. See convert resume to JSON for the three ways to do it.
• Reading scans and photos. OCR plus field extraction means a phone photo of a printed CV is still an application. The walkthrough is in OCR resume parser.
• Normalising. "Sept 2019" becomes 2019-09. "Sr. Eng." and "Senior Engineer" can map to one title family, with the original kept next to it.
• Summarising for a human. A three-line summary above the CV saves a reviewer's first thirty seconds, as long as the reviewer can open the original beside it.
• Drafting questions. A model can suggest interview questions from a job description. A person edits them.

Every item on that list produces something a person can verify against the source. That is the test: if a reviewer cannot check the output against the document in seconds, the AI should not be producing it.

Where AI should not decide alone

The jobs below are the ones where the failure is invisible.

1. Scoring a candidate against a job. A single number looks objective and hides every assumption inside it. The same CV can get a different score on a second run.
2. Rejecting. A rejection nobody reviews is the worst case under both instruments above. If automation must act, let it route ("needs a human look") rather than reject.
3. Inferring what the CV does not say. Seniority guessed from dates, gender from a name, nationality from a surname: each is a guess presented as a fact, and some are exactly what bias audits exist to catch.
4. Reading gaps as negatives. A career break is a fact about a timeline. A model that learned from past hiring decisions may have learned to penalise it.

A parser that returns null for anything the CV does not state is doing the safe thing here. It leaves the gap visible, so your rules can route it to a person instead of papering over it.

A build that keeps the decision in your hands

Here is the shape that gets most of the speed and keeps the judging half explainable. It is the same architecture as in automated resume screening, applied with AI in the right place.

1. Parse every CV into the same typed record. AI does the reading, once, at upload.
2. Validate the record. Check required fields are present, dates are ordered, and the number of roles is plausible. Send failures to a human queue, not into the pipeline.
3. Apply explicit rules in your own code. A hard requirement is a field and a comparison: holds a licence, has at least three years in the field, based in a given country. Each rule is a function you can read and test.
4. Route instead of rejecting. Three outcomes: meets the stated requirements, needs a human look, clearly lacks a hard requirement. Keep a person on that third bucket.
5. Log the reason. Store which rule fired and which field it read, so a candidate's question has an answer a week later.
6. Audit with people. Sample screened-out applications and have a recruiter read them. A screen checked only against itself proves nothing.

If you want semantic ranking on top, candidate matching covers where embeddings help and how to show reasons next to every rank. Whatever you add, keep that rule from step 5: no output without a reason a person can read.

For anonymised review, blind resume screening shows how to hide identifying fields from reviewers, which is a different use of the same parsed record.

Questions to ask an AI screening vendor

If you are buying rather than building, these questions separate the two halves quickly.

• What exactly is the output: fields, a score, a ranking, or a decision?
• Can a reviewer see which part of the CV produced each value?
• Is there a bias audit, who ran it, and is the summary public?
• What happens with a field the CV does not state: blank, or guessed?
• Can I turn off scoring and keep only extraction?
• Is the same CV given the same answer on a second run?
• Where does the document go, and is it kept?

A vendor that answers the first question with "a score" has sold you the judging half. That can be right for you, but the obligations in the section above then sit with your hiring process and not with the vendor's brochure.

When the manual way is enough

Not every hiring process needs AI. If you receive a few dozen applications per role, a recruiter reading each CV against a one-page checklist is faster than building anything, and it leaves nothing to audit except a person's notes. A shared spreadsheet with one row per candidate and a column per requirement is a perfectly good screen.

AI starts to pay for itself when volume makes reading the bottleneck: hundreds of applications per role, a backlog of past CVs you want to search, or a form that must prefill from an upload. At that point parse first, and then decide how much of the judging you actually want to automate. For a backlog, bulk resume parsing covers running it in batches.

Where ResumeJSON fits

ResumeJSON is the reading half and only that. You send a PDF, DOCX, plain text or a photo of a CV and get one typed JSON record back:

• Name, contact details, every role with dates as YYYY-MM or YYYY, education, skills, certifications and languages.
• null for anything the CV does not state, never a guess.
• One computed number, total_years_experience, which is the sum of the stated durations of the roles in the response, added up in code.

There is no score, rank or match field in the response, because the schema has none. That keeps the extraction step out of the argument, so any assessment of your system is about the decisions your own rules make. What you build on top of the fields, and whether it counts as an automated employment decision tool where you operate, stays your responsibility.

You can see the whole response for your own CV, without an account, on the free resume parser, and the quickstart has the request, the field reference and the current plans.

Start by deciding what you want AI to read, and what you want a person to decide. Write that down for one role, build the reading half, and leave the decision with the people who have to explain it.