How AI candidate screening works, and where it fails

AI candidate screening is the use of software to read applications and decide which ones a human should look at. It is the oldest and most widely deployed form of recruitment AI, it is the one most candidates will meet, and it is the one regulators have written the most rules about. This chapter follows an application from the moment it arrives to the moment it appears, or does not appear, on a shortlist, and names the four places where the process goes wrong.

Why screening became the first thing to automate

A posted role at a recognisable company draws several hundred applications; popular remote roles draw thousands. Reading each one for two minutes is a full working week per role, which nobody has. So recruiters developed shortcuts: scan the current title, the last employer and the first education line, then decide. Screening software started as an attempt to make that shortcut consistent, and it inherited the shortcut's blind spots. The rise of AI-written applications has sharpened the problem: when every CV reads well, the surface signals a human skims for stop meaning anything.

The five steps, in order

1. Parsing

The application (a CV, a form, a LinkedIn import) is converted into fields: names, dates, employers, titles, skills, qualifications, locations. Parsers have improved sharply since language models replaced rule-based extraction, but they still misread unusual layouts, two-column designs, and careers that do not follow a title-employer-date pattern. Anything the parser drops is invisible to every later step.

2. Knockout rules

Before any ranking, most systems apply hard filters the employer set: work authorisation, a required licence, a location radius, a minimum years-of-experience figure. These are the cheapest step and the most dangerous, because a badly specified rule rejects silently and at scale. A minimum-years rule written as a proxy for seniority will exclude career changers who are stronger than the people it keeps.

3. Matching

The parsed application is compared with the role. Older systems count keyword overlap. Current systems use the embedding approach described in chapter 2: role and candidate are each turned into a vector and the distance between them is the match. Embeddings understand that revenue operations and sales ops are close and that a Django developer can probably learn Flask, which keyword systems cannot. They do not understand whether the person was any good at either.

4. Ranking against criteria

The better systems go beyond a single similarity score and evaluate each applicant against the criteria the hiring team actually wrote down: the must-haves, the preferences, the disqualifiers. A language model reads the application against each criterion and records whether it is met, partly met, not met or not evidenced, with a short reason. The output is a structured assessment rather than a number, which is what makes it auditable. Products such as Noon's inbound screening work this way: applicants are evaluated against the role's criteria and non-negotiables, hiring-manager feedback adjusts the weighting per role, and the advance or reject decision is written back to the ATS stage.

5. The decision and the hand-off

Finally the system does something with the result: tags the application, moves it to a stage, sends a rejection, or queues it for a human. This is where the legal character of the tool is decided. A system that recommends and leaves the move to a recruiter is treated differently from one that rejects automatically, and the difference is often a single setting.

What the system is actually predicting

Every screening model is a prediction machine, and the question to ask any vendor is a prediction of what? There are three honest answers and one dishonest one.

The third target is the one that produced the well-known failures: a model trained on a decade of hires learns the decade's preferences. Most current vendors have moved to the first two targets precisely because they do not require historical hiring data, but it is still worth asking.

Four places it fails

• The parser dropped it. Non-standard careers, scanned documents, and portfolios are under-read. Ask for the parse rate and what happens to applications the parser is unsure about.
• The rule was a proxy. Years of experience, degree requirements and continuous-employment filters stand in for qualities they correlate with weakly. The Harvard Business School Hidden Workers study found most employers acknowledged their filters reject qualified people.
• The text was the candidate. Similarity scoring cannot tell a strong engineer with a terse CV from a weak one with a polished, AI-written one. Fraudulent and duplicated applications, now common in remote roles, pass this step easily; detecting them is a separate job, covered by dedicated fraud-detection tools rather than by the screener.
• Nobody looked at the rejects. If the tool rejects automatically and no one samples the rejected pile, systematic errors persist for months. The simplest control is a weekly review of twenty random rejections.

The rules that apply

Screening is the recruitment AI use case regulators have addressed most directly. New York City's Local Law 144 requires an annual bias audit and candidate notice before an automated employment decision tool is used to screen; the EU AI Act classes recruitment screening as high-risk, with documentation, human-oversight and transparency duties; and under GDPR a candidate can object to a decision made solely by automated means. In the United States the EEOC has made clear that an employer is responsible for disparate impact produced by a vendor's tool. Chapter 6 covers these in detail; the practical consequence is that the screener should recommend, a human should decide, and the adverse-impact ratio by group should be measured, not assumed.

What good looks like

A well-run screening setup has written criteria per role, agreed with the hiring manager before the post goes live; knockout rules limited to genuine legal or logistical requirements; an assessment per applicant that cites evidence from the application rather than a bare score; a human making the final reject on anyone the model was unsure about; and a monthly check of agreement between the model and a human reviewer on a sample, alongside the adverse-impact ratio. The vendor questions in chapter 7 apply; the two that matter most here are what does the model predict and can I see why it rejected this person.

Further reading: the glossary entry; Noon's plain-language explainer on what AI resume screening is; and chapter 6 on the audit and notice rules.