AI Act

The EU AI Act and CV screening

If software helps decide who gets an interview, the EU AI Act treats it as high-risk. This page explains what that means in practice, when it starts to apply, and what to ask a vendor before you buy.

Last checked: 13 September 2026 · Source for the dates

Yes, screening counts

Annex III of the AI Act lists eight areas where an AI system is classified as high-risk. One of them is employment: recruitment and selection, including the filtering of applications and the evaluation of candidates.

That covers CV screening directly. It does not matter whether the tool makes the final call — filtering applications is named in the text. A keyword filter that ranks candidates is in scope just as much as a language model is.

The date: 2 December 2027

This changed recently, and a lot of material online is out of date. The obligations for Annex III high-risk systems were originally set for 2 August 2026. The AI Omnibus — political agreement on 7 May 2026, in force from 27 July 2026 — moved them to 2 December 2027.

So nothing is overdue today. What matters is that the systems bought now are the systems running then. A screening tool chosen this year without documentation, logging or human oversight will have to be replaced or rebuilt — and that is a far more expensive project than choosing correctly the first time.

What the regulation actually requires

Six areas, in plain language. None of them is exotic; most are things a well-built system does anyway.

Risk management

A documented process for identifying what can go wrong and what is done about it — maintained over the system's life, not written once.

Data governance

The data used to evaluate people must be relevant, representative and examined for bias. In screening, this includes the criteria themselves.

Technical documentation

A written description of how the system works, complete enough that a regulator or an auditor can follow the logic.

Record-keeping

Automatic logs of what the system did, kept for a defined period, so a past decision can be reconstructed.

Transparency and human oversight

The people using it must understand what it produces and be able to override it. Oversight has to be genuinely possible, not just permitted on paper.

Accuracy, robustness, cybersecurity

Consistent performance, sensible behaviour on malformed input, and resistance to manipulation — including attempts hidden inside the documents being processed.

The nine questions to ask a vendor

Ask these before you sign. A vendor who cannot answer them today will not be able to answer them in December 2027 either.

Can you show me, for one candidate, why they scored what they scored?
Where do the criteria live, and who can change them — you or us?
Is the score produced by the model, or computed from the model's inputs?
What happens when the model returns something invalid or nonsensical?
What does the system do with a CV containing hidden instructions to the model?
What is logged, for how long, and can we export it?
Which provider processes the CV text, in which country, and what is retained?
Can a person override a decision, and is the override recorded?
What technical documentation will you hand over, and in what form?

How this system is built against those requirements

This is not a compliance retrofit. The design decisions below were made because they produce better screening; they happen to line up with what the regulation asks for.

Human oversight	The system ranks and explains. It does not decide. Every rejection carries a written reason precisely so a person can overrule it and see what they are overruling.
Transparency	Every criterion score carries a quote from the CV it was based on. Nothing is a black-box number.
Data governance	The criteria are a spreadsheet agreed in writing before screening begins — visible, reviewable, and changeable by the client, not buried in code.
Record-keeping	Every run is logged: inputs, scores, evidence, decisions and the rubric version used.
Robustness	Malformed files are filtered out before any model call and logged by name. If the model returns invalid output the run fails loudly instead of inventing a number.
Manipulation resistance	Instructions hidden inside a CV are ignored and quoted back in a separate field, so the attempt appears in the report instead of changing the score.
Technical documentation	Included in the compliance package: system description, risk notes, oversight design and the logging model.

This is not legal advice

This page is a practical summary written by an engineer, not a lawyer. Whether a specific deployment complies is a question for your own counsel, and responsibility is shared between the provider of a system and the organisation deploying it. What is offered here is a system built so that those conversations are short — and the documentation to support them.

Want to see what this looks like on one of your roles?

Send one live job advert. You get back the scoring rubric the system would generate from it, within 24 hours. No CVs, no agreement, no commitment.

Get a plan Back to the main page