calhire
Regulation

The EU AI Act and hiring systems

Recruitment is named in the Act’s own list of high-risk uses. The interesting question is not whether it applies but which of the duties land on you rather than on your vendor.

Regulation (EU) 2024/1689 classifies AI systems used for recruitment or selection — including targeted job advertising, application filtering, and evaluating candidates — as high-risk under Annex III. Providers face conformity assessment, risk management, data governance, logging and technical documentation duties. Deployers, which is what an employer usually is, must use the system per its instructions, assign competent human oversight, keep the logs, and inform workers and candidates that a high-risk system is in use. Obligations phase in through 2026 and 2027.

Last reviewed

The short version

  • Recruitment AI is high-risk by listing, not by argument — Annex III names it. There is no threshold test to fail.
  • Provider duties and deployer duties are different sets. Buying a compliant system does not discharge yours.
  • Human oversight must be real: assigned to a competent person with the authority and the information to override.
  • Article 22 of the GDPR runs alongside this, and it is the older and sharper constraint on a fully automated rejection.
  • The Act applies to providers and deployers outside the EU where the system’s output is used in the EU.

Which role are you in?

Almost every dispute about this Act starts with someone assuming they hold the other party’s duties. The roles are defined and they do not overlap.

Provider
Develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A provider of a high-risk system carries the risk-management system, data governance, technical documentation, logging capability, conformity assessment and CE marking.
Deployer
Uses an AI system under its own authority in a professional capacity. An employer screening candidates is a deployer. Deployer duties are narrower but not light: use per instructions, competent human oversight, input-data relevance, log retention, and informing affected people.
High-risk, by Annex III
Employment, worker management and access to self-employment is one of the Act’s listed high-risk areas — covering recruitment and selection, targeted job advertising, application filtering, and candidate evaluation. Listing is the classification; you do not argue your way to a lower tier.
Human oversight (Article 14)
The system must be designed so people can oversee it — understand its capacity and limits, stay alert to automation bias, interpret the output correctly, and decide not to use it or to override, reverse or stop it. Oversight is a capability the system must give you and a person you must actually assign.

What a deployer has to have in place

These are the obligations that stay with you no matter how compliant the system you bought is.

  • A named, competent overseer

    A specific person with the training, authority and support to interpret the output and to override or stop it. "The recruiter will look at it" is not an oversight arrangement.

  • Logs, kept

    Automatically generated logs retained for an appropriate period — at least six months unless other law says longer. The provider must make logging possible; keeping the logs is yours.

  • Input data that fits

    Where you control the input data, it has to be relevant and sufficiently representative for the system’s intended purpose. Feeding a screening model historical decisions you would not defend is the classic failure here.

  • People told

    Workers and their representatives informed before a high-risk system is put into use, and candidates subject to a decision informed of the system’s role in it.

Where CalHire sits, stated plainly

CalHire is a provider of an AI system used in recruitment, and the honest reading of Annex III is that this is high-risk. We are building toward the provider obligations rather than claiming to have completed them, and the Trust Center is where that status is kept current rather than this page.

Several of the Act’s requirements were architectural decisions here before they were obligations, which is the useful thing to report. No code path can reject a candidate, so the "decide not to use the output" part of Article 14 is not a setting that can be switched off under hiring pressure. Every decision is attributed to the human who made it, which is what an oversight record has to contain. Anonymised evaluation means the model never receives name, photograph, school or employer — a data-governance position rather than a fairness slogan.

What you get from us toward your deployer duties: the decision log with the responsible human on each entry, exportable; the assessment methodology and what the composite score is made of; retained logs; and candidate-facing AI transparency notice text, which is published on this site rather than kept in a sales deck.

What we cannot do is be your deployer. Assigning the overseer, informing your workers and judging your input data are things that happen inside your organisation.

The GDPR constraint that arrived first

Article 22 of the GDPR has, since 2018, given people the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects. A rejection from a job is comfortably within that.

This matters because it is older, in force everywhere in the EU and UK, and in one respect stricter than the AI Act: it constrains the outcome, not the system. A hiring process that auto-rejects has an Article 22 problem whether or not anything in it is classified high-risk, and whether or not the tool is AI at all.

The practical consequence is that "no automated rejection" is the single design decision that does most of the work across both regimes at once. It is why it is an architectural invariant here rather than a policy.

Primary sources

Obligations phase in on different dates and the implementing acts and harmonised standards are still arriving. Read the text and the Commission, not a vendor timeline.

What this page does not do

It is not legal advice and it is not a conformity assessment. Whether a specific deployment meets the Act is a question for your own assessment and, where required, a notified body.

CalHire holds no CE marking for a high-risk AI system and makes no claim to have completed a conformity assessment. Where we are in that process is stated in the Trust Center, with dates.

It does not cover the Act’s general-purpose AI model obligations, which are a separate chapter with their own thresholds and are not what a hiring deployer is usually asking about.

Dates move. Several obligations phase in across 2026 and 2027, guidance is still being published, and harmonised standards are not all finished. Treat any date you read here as needing a check against the Commission.

Complying with the AI Act does not make a hiring process fair. It makes it documented, overseen and explainable, which is a precondition for fairness rather than a substitute for it.

Questions people actually ask

Is hiring AI automatically high-risk under the EU AI Act?
Employment, worker management and access to self-employment is a listed high-risk area in Annex III, covering recruitment and selection, targeted job advertising, application filtering and candidate evaluation. Classification comes from the listing rather than from a risk assessment you perform, so the starting assumption for a hiring tool is high-risk.
Does the Act apply to us if we are outside the EU?
It can. The Act reaches providers and deployers established outside the EU where the output produced by the system is used in the Union. Hiring for an EU-based role from elsewhere is the obvious case.
What is the difference between a provider and a deployer?
A provider develops the system and places it on the market under its own name; a deployer uses it under its own authority in a professional capacity. An employer screening candidates with a bought-in tool is a deployer. The duty sets are different, and buying a compliant system does not transfer your deployer duties to the vendor.
Does a human reviewing the output satisfy the human oversight requirement?
Only if that person can actually oversee: they must understand the system’s limits, be alert to automation bias, interpret the output correctly, and have the authority and information to override, reverse or stop it. A reviewer who approves whatever the ranking says is the automation bias the article is written about.
How does Article 22 of the GDPR interact with this?
It runs alongside and, for hiring, bites first. Article 22 restricts decisions based solely on automated processing with legal or similarly significant effects — a job rejection qualifies — and it has applied since 2018 regardless of whether the tool is AI or high-risk. Designing out automated rejection addresses both regimes at once.
Is CalHire EU AI Act compliant?
We do not make that claim, and a vendor that does before the standards are finished is worth a second look. Several requirements — no automated rejection, an attributed human decision on every outcome, and models that never receive identifying data — are architectural here rather than configurable. The current status of the formal work is kept in the Trust Center with dates.

Related

Where this connects to the rest of the platform.

  • NYC Local Law 144 and automated hiring tools

    A bias audit within the last year, a public summary of its results, and ten business days’ notice to candidates — before an automated tool substantially assists a hiring decision in New York City.

  • AI governance, bias auditing and the audit trail

    Adverse-impact analysis on the four-fifths rule, a hash-chained audit trail, candidate appeals, and DSAR handling. The evidence exists before anyone asks for it.

  • Enterprise controls

    SAML single sign-on, job-scoped permissions, departments and approvals, custom domains, white-labelling and data residency, with tenant isolation enforced in the database.

Read the reasoning

The evidence and the argument behind what is on this page.

Compliance9 min read

The EU AI Act and hiring: what recruitment teams are responsible for

AI used to recruit or evaluate candidates is high-risk under the EU AI Act. What that means for employers, what providers owe you, and what to ask vendors.

Read
Compliance9 min read

GDPR and candidate data: what recruiting teams get wrong

Consent is usually the wrong lawful basis for recruitment. What to rely on instead, how long to keep applications, and the rules on automated decisions.

Read
Compliance8 min read

What "meaningful human oversight" actually requires

A reviewer who rubber-stamps 200 rankings is not oversight. What regulators mean by meaningful human involvement, and how to build a process that holds up.

Read

Browse all topics on the blog

See a verified pipeline for one of your roles

Post a role free and review anonymous, skill-ranked candidates. No card, no sales call to get started.

Start hiring freeTalk to the team