AI in Recruitment: Screening and Its Legal Exposure

Ranking people is the highest-exposure thing you can do with a model, and the exposure is not mainly about the model being inaccurate. It is about being accurate at reproducing a pattern you did not want to continue. This page is not legal advice; obligations for automated employment decisions differ sharply by jurisdiction and change, and nothing here should be read as a statement of what any of them currently require.

The label is the bias

Every serious attempt to build a screening model reaches the same question: what is the target variable. The available answers are all records of what humans previously decided — who got an interview, who got an offer, who was still there after a year, what rating a manager gave them. Those are not measurements of candidate quality. They are measurements of the organisation’s prior behaviour, including the parts of it that would not survive being written down as a policy.

So a model that fits the label well has succeeded at the wrong task. This is not a subtle statistical point and it is not solved by removing protected attributes from the input; the model is being asked to predict a variable that already encodes them. The engineering consequence is uncomfortable and worth stating plainly: for the ranking use case there is often no honest label available, and a project whose first deliverable is an accuracy figure against historic outcomes has not confronted this.

The one target that is defensible is narrower — whether a candidate meets a stated, job-related, objectively checkable requirement. “Holds the licence the role legally requires” is a fact about a CV. “Would be a strong performer” is a prediction fitted to the past. The first is an extraction task with an evaluable ground truth. The second is the one that produces litigation.

Redaction does not remove the proxy

Blind screening — stripping name, address, photo, dates of birth and graduation before scoring — is worth doing and is not sufficient, and it helps to know exactly why. Free text on a CV carries the same information indirectly, and a language model is unusually good at picking it up:

• Graduation year and early role dates reconstruct age even when date of birth is removed.
• Membership of a national or affinity society, a place of worship as a volunteering entry, or “captain of the women’s rowing club” each signal a protected characteristic in plain text.
• An employment gap correlates with caregiving, illness and military service. A model that has learned continuous employment predicts the label is penalising all three.
• Postcode, school and university correlate with almost everything — and unlike the others, they are usually left in deliberately.

There is also a purely mechanical problem that gets mistaken for model weakness. A large fraction of CVs are two-column PDFs, and naive text extraction interleaves the columns, so a skills sidebar is spliced line by line into the employment history. The resulting text is nonsense, and it is nonsense in a way that correlates with which CV template someone used, which correlates with how much help they had. Layout-aware extraction is a fairness intervention as much as an accuracy one; see document understanding for what actually reads a two-column page correctly.

The analysis you should be able to produce

Whatever any given jurisdiction requires, one artefact is worth producing on your own initiative because it is the thing anyone asking questions will ask for, and because building it forces you to be able to reconstruct what the system did:

• Selection rates by stage and by group. For each stage where the system advances or rejects, the proportion advanced within each group for which you hold data, and the ratio of each group’s rate to the highest group’s. Comparing selection rates as a ratio is long-established practice in employment analytics; producing the table is not a legal conclusion, but not being able to produce it is a position you do not want to be in.
• Counts alongside the rates. A ratio computed over eleven candidates is noise. Report the denominators and a confidence interval, or the first quarter’s numbers will start an argument nobody can settle. The general problem is in evaluation statistics.
• The counterfactual set. Rejected candidates who would have advanced under the previous process, sampled and reviewed by a recruiter. This is the only way to learn what the system is actually screening out, and it has to be built into the rollout because once the old process is gone the comparison is gone.
• Version history. Which prompt, which model, which scoring rules were live on the day a given candidate was assessed. When someone asks about a decision from eight months ago, this is the only way to answer.

A rejection someone has to explain

Somebody eventually asks why they were rejected — a candidate, a hiring manager, a works council, a court. “The model scored you 61” is not an answer, and neither is a post-hoc explanation generated by asking a model to justify its own output, which produces a fluent rationalisation with no causal relationship to the score. The faithfulness problem is the reason that trick does not work.

The architecture that can answer is the same one that appears in insurance and finance: the model extracts checkable facts from the application, and a set of stated, job-related criteria — written by a human, versioned, and published to candidates if you are brave — decides. Then the explanation is real: this role requires a current licence and none was found in your application. It is also correctable, because a candidate can point at the licence you missed, and a false negative in extraction becomes a fixable error rather than an unexplained rejection.

The work that carries none of this

Recruiting has plenty of language work that never touches a ranking. Drafting and de-jargoning job descriptions. Turning interview notes into a structured scorecard against pre-agreed criteria, after the interview, from what the interviewer actually wrote. Scheduling. Answering candidate questions about process and benefits from an internal knowledge base. Summarising a role’s applicant pool for a hiring manager in aggregate rather than individually. Writing the rejection that is at least specific.

These are unglamorous, they are where recruiter hours actually go, and none of them requires you to be able to defend a score attached to a person. If a team wants to start in recruitment, starting here is not a compromise; it is the part where the technology is good and the exposure is ordinary.