Screening candidates with an LLM without building a discrimination engine

Screening applications is an obvious candidate for automation: high volume, unstructured input, repetitive judgement. It is also the place where a poorly built system causes real harm to real people and exposes the organisation to legal consequence — and where the harm is close to invisible from the inside, because rejected candidates never tell you what happened.

This one deserves the constraints stated plainly rather than as an afterthought.

Where the bias enters

Not usually through anything as crude as a protected characteristic in the prompt. Through proxies.

A CV carries a school, a postcode, a graduation year, a career gap, a name, a second language, a photograph, a phrasing style that correlates with whether English is a first language. A model asked to assess "fit" will use all of it, because it is all signal, and some of it is a proxy for exactly the thing you may not lawfully consider.

Career gaps deserve specific mention: they correlate strongly with parental leave, illness and caring responsibilities. A model penalising discontinuity is, statistically, penalising those.

The controls that do something

Score against explicit criteria, one at a time. Not "rate this candidate". Instead: "does this application evidence three years of Postgres in production — quote where." A model answering narrow, evidenced questions is auditable. A model producing a holistic score is not, and cannot be explained to a candidate or a tribunal.

Redact before assessment. Name, address, photograph, dates of education, nationality — removed before the model sees the document, not filtered out of the reasoning afterwards. This is straightforward and skipping it is difficult to justify later.

Never let it reject. The system's permitted outputs are: evidence found, evidence not found, needs a human. Rejection is a human decision. This is not caution for its own sake — the moment automated rejection exists, error becomes invisible, because nobody reviews what was already discarded.

Require the quotation. Every positive assessment cites the text supporting it, and the citation is verified to exist. This makes the assessment checkable and makes "the model liked them" impossible to pass off as a reason.

Test for disparate outcomes deliberately. Run the same application with names, schools and gap patterns varied and compare the results. If they differ, that is a defect with a reproduction case. This is a test suite, it can live in CI, and it is the single most useful thing on this list — because it converts a suspicion into a failing build.

What to write down before it goes live

Which criteria are assessed and who approved them. What is redacted. What the system may and may not decide. How a candidate can ask for a human review. How long assessments are retained. When the disparate-outcome tests last ran and what they showed.

Depending on jurisdiction some of this is legally required, and the regulatory direction across the UK and EU is towards more of it rather than less. But it is worth having regardless: an organisation that cannot answer these questions about its own hiring process has a problem whether or not anyone has asked yet.

The honest framing

The defensible version of this is not a screening system. It is an evidence-gathering system that saves a recruiter from reading two hundred documents to find which fifteen mention the thing they need — with the reading, the judgement and the decision left where they were.

That is a smaller claim than the pitch usually makes. It is also the version that still exists in two years, because it is the version that can be explained to the person it was used on.