Artificial Intelligence Recruiting: What It Does, What It Doesn't

“Artificial intelligence recruiting” is the label on most HR-tech homepages by now, and it covers at least four distinct jobs: turning a resume into structured fields, finding candidates a search hasn’t surfaced yet, scoring or ranking who applies, and compiling and checking what is actually true about a specific person. A vendor pitch rarely says which one it means. That is usually the first thing worth asking, because the four jobs do not fail the same way.

What “AI recruiting” actually bundles

Four jobs share the label, and they sit at different points on the same spectrum.

Parsing and matching. Turning a resume or a profile into structured fields — title, dates, company, keywords — and matching those fields against a requirement list. This is close to what a language model is actually built for: transforming text that is already in front of it into a different shape.

Sourcing and discovery. Finding people who plausibly fit a role but haven’t applied for it. A breadth task — cast a wide net, generate hypotheses about adjacent places to look, and don’t get tired by candidate four hundred the way a person doing this by hand eventually does.

Screening and scoring. Ranking or predicting who is likely to succeed, usually from resume text and assessment answers. This sits furthest from “read a document and extract what’s there,” because it asks the system to render a judgment about a person rather than report what a source says about them. It also inherits whatever pattern lives in its training labels: a model trained to predict “successful hire” from a company’s own hiring history learns the pattern in that history, including a pattern nobody would write into a job posting directly. That is a structural property of learning from past outcomes, not a claim about any specific tool — but it is a reason to ask what a scoring model was actually trained on before trusting its output.

Research and verification. Compiling and checking what is actually true about a specific candidate — role history, scope, credentials — with each claim traceable to where it came from. This is the category we work in, and it has its own version of the problem below, in a sharper form.

What holds up

The first two jobs above are where the technology earns its keep. Reading unstructured text at volume, normalizing “VP Operations” and “Operations Director” into the same bucket, generating a list of adjacent sectors worth checking — these are pattern-matching and extraction tasks, and a model does them faster and more consistently than a person doing the same task for the fortieth time in a week. None of it requires the system to know anything beyond what it was given. It requires processing a lot of given material without getting inconsistent partway through, which is exactly the kind of endurance a model doesn’t run out of.

What degrades, and why

The other two jobs — scoring people, and asserting facts about them — ask for something beyond what is directly stated in a source. This is where “it just needs more training data” undersells the problem, because the failure is not a capability gap that scale closes. It follows from what the system is optimized to produce.

A model generating text is rewarded for producing something fluent and internally consistent, not for producing “I don’t have evidence for this.” Given two records that plausibly describe the same person — one partial, one that reads as more complete — the more complete version comes across as more correct, even when it was arrived at by merging two different people or filling a gap with a plausible guess. That is not a defect that scale removes. It is what a system optimized for coherent output is good at doing, applied to a case where being wrong and being fluent look identical from the outside.

This is also where a bundled interface makes oversight harder rather than easier. A screening score and a sourced fact call for different kinds of skepticism from whoever reviews the output, and a single tool producing both through the same pass gives the reviewer no signal for which mode belongs on which line. The fix is not a more careful reviewer. It is separating the jobs enough that a modeled judgment and a claim of fact stop arriving looking like the same kind of output.

What to ask a vendor claiming this

Not thirty questions. The ones that locate where a given tool actually sits on the spectrum above.

The fourth question is worth pressing on longest, and it follows directly from the bundling problem above: if scoring and verification run through the same pass, whatever confidence produced the score is also underwriting the “confirmed” next to a fact — one process vouching for itself twice, not two. A genuinely separate pass is what actually answers the question; a second look from the process that already committed to an answer is not.

The line worth noticing regardless of vendor

Somewhere in the screening-and-scoring category, a tool stops describing a candidate and starts ranking people by predicted fit. That is a judgment call, not a research finding, whichever kind of system produces it — worth noticing as a category shift, not a feature. Where that line sits in practice is worth reading closely before trusting a “top match” label from any source, automated or not.

It is the same line we hold in our own pipeline: Cerna researches and sources what is true about a candidate against a spec, and stops there — it does not rank finalists or recommend a hire. That is not a limitation we are working around. It is the reason the fourth question above matters in the first place: a system that stops at “here is what’s confirmed, here is what isn’t” is a different, more checkable thing than one that hands over a verdict.

Related reading: why the high-volume tooling does not transfer, how AI is actually used in executive candidate research, where AI candidate screening breaks down, what “confirmed” actually means in a sourced shortlist, and what actually drives the research bottleneck in boutique search.