September 24, 2026·5 min read
Ai Agent Skills AssessmentAi In HiringAi LiteracyHands On AssessmentHow To Assess Ai Assisted Coding
If you use AI to screen or evaluate candidates and you hire in the EU, you are very likely a deployer of a high risk AI system under Regulation (EU) 2024/1689, the AI Act. That is a compliance question with obligations attached, not a procurement footnote.
This post is written for hiring managers and engineering leaders rather than lawyers, and it is not legal advice. Its purpose is narrower and more useful: to tell you which questions to ask your assessment vendor, and how to structure an interview process that you could still defend in two years when a rejected candidate asks why.
The AI Act sorts systems by risk. A small set of practices is prohibited. A larger set is classified as high risk, with real obligations. Everything else gets transparency duties or nothing.
Employment sits in the high risk tier. Annex III, point 4 covers AI intended to be used for the recruitment or selection of people, naming in particular systems that place targeted job advertisements, analyse and filter applications, and evaluate candidates. It also covers AI used for promotion, termination, task allocation and performance monitoring.
There is a carve out worth knowing, and most write ups skip it. Article 6(3) says an Annex III system is not high risk where it performs only a narrow procedural task, improves the result of a previously completed human activity, performs a preparatory task, or detects decision patterns without replacing or influencing the human assessment. The same article closes the obvious loophole: a system that profiles natural persons is always high risk. A model that evaluates candidates is profiling them, so in practice most assessment AI lands back in scope. This post takes the conservative reading, because the cost of assuming the derogation applies and being wrong is much higher than the cost of the obligations.
Two roles matter and they are easy to confuse. The provider is whoever puts the system on the market, usually your vendor. The deployer is you, the employer using it. Most of the engineering-heavy obligations (risk management, data governance, technical documentation, conformity assessment) fall on the provider. The deployer obligations are fewer and they are not nothing: use the system according to the provider's instructions, assign human oversight to people who are competent and have the authority to act on it, make sure the input data you feed it is relevant, monitor how it behaves, keep the logs it generates for a defined period, and inform workers and their representatives before putting such a system into use at the workplace.
There is also a right that will reach you directly. Article 86 lets a person ask for a clear and meaningful explanation of the role an Annex III system played in a decision about them, where that decision produces legal effects or similarly significantly affects them and they consider it to adversely affect their health, safety or fundamental rights. Whether an early funnel rejection clears that bar is genuinely contested. A candidate rejected at final stage on the back of a model assisted assessment is the obvious person to ask.
On timing: the Act entered into force in August 2024 and its obligations phase in. The AI literacy and prohibited practice provisions arrived first, in February 2025. The Annex III high risk obligations were originally legislated for August 2026, and the Commission subsequently proposed amendments to that schedule. Confirm where that landed with counsel rather than with a blog post, including this one, because the timing has moved more than once while the obligations themselves have stayed stable.
Most teams have never asked these. Ask them in writing.
What does the model actually output, and what is it used for? There is a large difference between a model that produces a rank order of candidates and one that summarises what a candidate did while a human decides. Both are in scope. Only one of them is easy to explain later.
Can a human override it, and does anyone? Article 26 requires you to assign oversight to competent people with the authority to act. If your process is technically overrideable but nobody ever overrides, you have oversight on paper. Look at your own data: how many times has a human reversed the model's recommendation this year? Zero is an answer that will not age well.
Can you produce the evidence behind a decision two years from now? Not the score. The evidence: what the candidate was asked, what they did, what the model said about it, and who decided. If the vendor retains only a number, you cannot answer the explanation request and you cannot audit yourself.
What did it learn from, and has it been tested for disparate impact? You are entitled to ask about data governance and bias testing, and the provider is obliged to have done it. Note that other regimes already demand more specific things here: New York City's Local Law 144 requires an independent bias audit for automated employment decision tools and publication of a summary of the results, and several US states have their own rules. If you hire across jurisdictions, the strictest one sets your process.
What is the retention and deletion policy for candidate data? This is where the AI Act meets the GDPR, including the existing right not to be subject to solely automated decisions with significant effects under Article 22. That article predates the AI Act and did not go away.
The compliance answer and the good hiring answer turn out to be the same answer, which is convenient and not a coincidence.
Make the artifact the evidence, not the score. If what you keep is a recording of a working session, the tasks, and the reasoning behind a decision, you can explain the decision to anybody who asks: a candidate, an auditor, or your own hiring committee six months later. If what you keep is 73 out of 100, you can explain nothing.
Keep the model on description, not on decision. This is the design choice we made in EasyEnv deliberately. The AI drafts an assessment of what a candidate actually did in the environment, with the session and the transcript attached as evidence for each claim. A person reads it and decides. The model narrows what a reviewer has to watch; it does not select. That keeps a human materially in the loop rather than nominally, and it makes every claim checkable against a recording. We wrote about the mechanics in AI graded technical assessments.
Structure the assessment itself. Same tasks, same conditions, same rubric, scored independently before discussion. Structured interviews were the fairness recommendation long before this law existed, and they are also what makes an explanation possible. See how to write a technical interview rubric and the bar raiser problem.
Tell candidates what is happening. What is recorded, what AI is involved, what it is used for, how long it is kept, and who decides. Say it before the session, not in a privacy policy. Candidates react far better to this than most teams expect, and disclosure is both a transparency obligation and basic courtesy.
Write down who the accountable human is. For every stage where a model contributes, name the person who can overrule it. If you cannot name them, you do not have oversight.
A lot of assessment tooling currently in use cannot answer the evidence question. It produces a score, the score removes people from the funnel, and what the score was made of is not retained in any form you could hand to a regulator or a candidate.
That was already bad practice for hiring quality reasons. It is now also a legal exposure, and the fix is the same in both cases: keep the evidence, keep a human accountable for the decision, and use the model to make the evidence reviewable rather than to replace it.
If your vendor cannot show you the evidence behind a rejection, you cannot defend the decision, whatever the score said.
Have you asked your assessment vendor any of these questions yet?
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
When the model has shell access, the question is no longer whether a candidate can write the code. It is whether they can supervise something that writes it faster than they can read it. Here is how to test that on a real repository.
Observability interviews usually become tool interviews, which sort candidates by which vendor their last employer bought. Here is how to test the actual skill: narrowing down a failure that only happens to four percent of requests.
Read more
Ask a candidate to describe a good CI pipeline and everyone gives the same clean answer. Hand them a build that passed yesterday and fails today, and you find out who has actually lived with one.
Read more
