The EU AI Act (Regulation (EU) 2024/1689) classifies AI systems intended for recruitment or selection of candidates as high-risk. That triggers obligations on the provider who builds the system and separate, lighter obligations on the employer who deploys it — including human oversight, informing affected workers, and keeping logs.
- Recruitment and candidate-evaluation AI sits in the Act’s high-risk category (Annex III, employment).
- Provider and deployer obligations are different. As an employer you are usually a deployer — but configuring or rebranding a system can make you a provider.
- Deployer duties centre on human oversight, using the system as instructed, informing affected workers, and log retention.
- The Act sits on top of GDPR and existing discrimination law. It replaces neither.
- Ask vendors for the instructions for use and the human-oversight design. If they cannot produce them, you cannot meet your own obligations.
This is general information, not legal advice. The AI Act's application timetable has been the subject of amendment proposals since adoption, and obligations differ by role and by system. Verify against the current consolidated text and take advice on your own circumstances.
Why hiring is in scope at all
The EU AI Act takes a risk-tiered approach: a small set of prohibited practices, a defined high-risk category carrying real obligations, transparency duties for certain systems, and a light touch for everything else.
Employment sits in the high-risk category. Annex III covers AI systems intended to be used for the recruitment or selection of natural persons — placing targeted job advertisements, analysing and filtering applications, and evaluating candidates — as well as systems used for decisions about promotion, termination, task allocation and monitoring.
The reasoning is straightforward: these systems allocate access to work, the affected person has little power in the transaction, and errors are hard to detect from the outside. That is a good description of hiring.
There is a narrow route in the Act for Annex III systems argued not to pose a significant risk, but it carries conditions and its own documentation and registration consequences. It is not a shortcut, and it is not somewhere to end up by accident.
The distinction that decides your obligations: provider or deployer
Almost every mistake in this area starts with getting this wrong.
| Provider | Deployer | |
|---|---|---|
| Who | Builds the system, or has it built, and places it on the market under its own name | Uses the system under its own authority |
| In hiring | The vendor — or you, if you built it | The employer using the tool |
| Weight | Heavy: risk management, data governance, technical documentation, logging design, conformity assessment, registration, post-market monitoring | Lighter: use as instructed, assign competent human oversight, monitor, retain logs, inform affected workers, cooperate |
Buying a hiring tool normally makes you a deployer. You can slide into provider territory in three ways that catch organisations out:
- Putting your own name or trademark on a high-risk system — including white-labelling it.
- Substantially modifying it.
- Changing its intended purpose so that it becomes high-risk.
And of course, building your own CV-screening or scoring model in-house makes you a provider of a high-risk system, with the full obligation set. Teams frequently plan this without realising what they are taking on.
What a deployer actually has to do
Concretely, as an employer using a high-risk hiring system:
Use it according to the instructions for use. Which means you must have them, and they must be usable. This is the single most practical thing to demand from a vendor.
Assign human oversight to people who can actually exercise it. Named individuals, with the competence, training and authority to interpret output and to disregard or reverse it. A reviewer who has 200 candidates and eight minutes is not oversight; nor is one who has no authority to override. More on what this means in practice in what "meaningful human oversight" requires.
Keep the input data relevant. To the extent you control input data, it needs to be appropriate to the system's intended purpose.
Monitor operation and escalate problems. If you have reason to believe use is creating a risk, you must act and inform the provider — not quietly continue.
Retain logs. For the retention period the Act specifies, so a decision can be reconstructed later.
Inform workers' representatives and affected workers before putting the system into use in the workplace.
Support the individual's right to an explanation of a decision made with a high-risk system that affects them.
What this changes about how you buy
Vendor diligence stops being a formality. Ask for, in writing:
- Confirmation of whether the vendor considers itself the provider of a high-risk system, and their conformity position.
- The instructions for use, including intended purpose, known limitations, and the accuracy levels the system was validated against.
- The human-oversight design — what a reviewer sees, what they can override, and how the override is recorded.
- Logging — what is captured, in what form, retained how long, and exportable how.
- Bias and performance testing across relevant groups, with methodology.
- Data-protection posture — legal basis, retention, residency, sub-processors.
A vendor who cannot answer these has not made your compliance harder; they have made it impossible, because your deployer duties are defined in terms of information only they hold.
It stacks on top of everything else
The AI Act does not displace existing law. In an EU hiring process you are typically holding several obligations simultaneously:
- GDPR — lawful basis, purpose limitation, data minimisation, transparency, and the provisions on automated decision-making and profiling. See GDPR and candidate data.
- National and EU discrimination law — outcome-level exposure regardless of what any tool intended.
- Works council and employee-representation requirements in several member states, which may bite earlier and harder than the AI Act itself.
- Sector rules for regulated industries.
If you also hire in New York City, there is a separate and quite different regime with its own annual audit and notice mechanics — see the NYC Local Law 144 checklist.
Where CalHire stands
CalHire is built for this shape of regulation rather than retrofitted to it:
- No PII ever reaches a model. Identity is stripped at a hard architectural boundary before scoring, the text interview, or ranking. Name, photo, age, school and employer are not on the evaluation surface at all, so they cannot influence an output.
- A human always decides. AI recommends and explains; a person makes the call and is recorded against it. No code path can auto-reject a candidate — below-threshold applicants are flagged for human review, never rejected automatically.
- Every person-affecting decision is logged, explainable, and tied to the human who made it, in a tamper-evident append-only audit trail, exportable for review.
- Data residency can be pinned per region, including the EU.
- Candidates always get an explanation. Every applicant receives a growth-framed report card — it is enforced in the product, not left to a setting.
You can see the compliance console and residency controls on the enterprise page, and our security and evidence posture in the trust center.
None of that discharges your own obligations as a deployer. It does mean the artefacts you need — oversight records, explanations, exportable logs — exist by default rather than having to be reconstructed after a request arrives.
Frequently asked questions
- Is AI used in recruitment high-risk under the EU AI Act?
- Yes. Annex III of Regulation (EU) 2024/1689 covers employment and worker management, including AI systems intended to be used for the recruitment or selection of natural persons — for example to place targeted job advertisements, to analyse and filter applications, and to evaluate candidates. The Act does provide a narrow route for Annex III systems that do not pose a significant risk, but that determination has conditions and its own documentation and registration consequences. Verify against the current consolidated text.
- Are we a provider or a deployer?
- An employer buying and using a hiring tool is normally a deployer. You can become a provider — with the much heavier obligation set — if you put your own name or trademark on a high-risk system, substantially modify it, or change its intended purpose so that it becomes high-risk. Building your own screening model in-house makes you a provider.
- Does the Act require a human in the loop?
- High-risk systems must be designed so they can be effectively overseen by humans, and deployers must assign oversight to people with the competence, training and authority to act — including the ability to disregard or reverse the system’s output. In practice that means a person must be able to decline the recommendation, and be positioned to actually do so, rather than nominally supervising an automated decision.
- Do we have to tell candidates and employees?
- Deployers that are employers must inform workers’ representatives and affected workers before putting a high-risk system into use in the workplace. Separately, transparency obligations and existing data-protection law shape what candidates must be told. Treat clear candidate-facing notice as the baseline rather than the ceiling.
- What are the penalties?
- The Act sets tiered administrative fines, with the highest band reserved for prohibited practices and lower bands for breaches of other obligations, calculated as a fixed maximum or a percentage of worldwide annual turnover, whichever is higher. Consult the penalties provisions in the current text and your own counsel for figures applicable to your organisation.