EU AI Act and hiring systems
The EU AI Act classifies AI used in employment — recruitment, selection, promotion and termination decisions — as high-risk. That classification carries obligations that most vendors' marketing does not mention, and they land on the employer as deployer, not only on the vendor.
| Topic | Key point |
|---|---|
| Employment AI is named as high-risk, not left to interpretation | The EU AI Act takes a risk-tiered approach: a small set of practices is prohibited, a defined set is high-risk , and the rest carries lighter or no specific obligations. |
| The obligation lands on you, not only on the vendor | The Act distinguishes the provider who develops and places the system on the market from the deployer who uses it. |
| Why hiring is the hardest case technically | Setting compliance aside, recruitment is genuinely difficult ground for machine learning, and the reasons are structural rather than fixable with a be |
| Questions to put to a vendor before signing | Is this system high-risk under the AI Act, and where is your conformity documentation? |
| What this page is and is not | This is an orientation to why hiring AI is treated differently from other enterprise software, written for people specifying or buying it. |
Employment AI is named as high-risk, not left to interpretation
The EU AI Act takes a risk-tiered approach: a small set of practices is prohibited, a defined set is high-risk, and the rest carries lighter or no specific obligations. AI systems used in employment, worker management and access to self-employment sit in the high-risk tier — recruitment and selection, decisions on promotion and termination, task allocation, and monitoring or evaluation of performance.
This is not an inference from general principles. Employment is one of the named high-risk areas, on the reasoning that these systems materially affect people's livelihoods and can entrench discrimination at scale.
The practical consequence: a CV-screening tool is not an ordinary software purchase in the EU. It is a regulated one.
The obligation lands on you, not only on the vendor
The Act distinguishes the provider who develops and places the system on the market from the deployer who uses it. Both carry duties, and the widespread assumption that compliance is the vendor's problem is where employers get caught.
| Broadly the provider's duty | Broadly the deployer's duty |
|---|---|
| Risk management and data governance in development | Using the system in line with its instructions for use |
| Technical documentation and record-keeping capability | Assigning competent human oversight with real authority |
| Accuracy, robustness and cybersecurity | Ensuring input data is relevant and representative for your context |
| Conformity assessment and registration | Retaining logs and monitoring operation |
| Instructions enabling deployer compliance | Informing affected workers, and transparency to candidates |
Note the deployer column carefully. "Human oversight" is not a recruiter glancing at a ranked list. It means someone competent, with authority to override, who understands the system's limitations well enough to know when to.
Note also that modifying a system substantially, or putting your own name on it, can move you into provider obligations. Check that before white-labelling anything.
Why hiring is the hardest case technically
Setting compliance aside, recruitment is genuinely difficult ground for machine learning, and the reasons are structural rather than fixable with a better model:
- The training label is contaminated. Models are typically trained on who was hired and who succeeded — outcomes shaped by prior human decisions, including biased ones. The system learns to reproduce past hiring, which is precisely what you were trying to improve.
- Proxies survive removing protected attributes. Deleting gender or ethnicity does not remove the signal. Postcode, university, career gaps, sports, even writing style correlate with protected characteristics.
- Career gaps are penalised structurally. Parental leave, illness and caring responsibilities produce patterns a model reads as weak signal.
- Success is rarely measured. Very few employers know which of their hires worked out in a form a model could learn from, so systems optimise for passing interviews rather than performing the job.
- Feedback is one-sided. You observe outcomes only for candidates you hired. The rejected ones never generate evidence that the rejection was wrong.
Questions to put to a vendor before signing
- Is this system high-risk under the AI Act, and where is your conformity documentation? A vendor unsure of the answer is a finding in itself.
- What exactly was it trained on, and does that population resemble our applicant pool?
- What bias testing has been run, against which groups, on what data, and how recently? Ask for the method, not a certificate.
- What does the system output — a score, a ranking, a recommendation, a decision? The distinction matters for oversight.
- Can a reviewer see why a candidate scored as they did in terms they can act on?
- What logs are retained, for how long, and can we get them out?
- What do you tell us to tell candidates?
- What happens if we substantially modify it, or deploy it under our brand?
What this page is and is not
This is an orientation to why hiring AI is treated differently from other enterprise software, written for people specifying or buying it. It is not legal advice, obligations and dates depend on the system and on how you use it, and national implementation and guidance continue to develop. Take advice on your specific deployment.
No obligation dates, penalty figures or article numbers are quoted here. Those change, they are widely misreported, and reproducing them from secondary sources is how this kind of page becomes wrong without anyone noticing. Read the regulation, or ask someone who has.
Frequently asked questions
Is AI recruitment software high-risk under the EU AI Act?
Yes. AI used in employment and worker management — recruitment and selection, promotion and termination decisions, task allocation, and performance monitoring — is one of the named high-risk areas, because these systems materially affect livelihoods and can entrench discrimination at scale.
Who is responsible for compliance, the vendor or the employer?
Both, in different ways. The provider carries development-side duties such as risk management, technical documentation and conformity assessment. The employer, as deployer, must use the system according to its instructions, assign competent human oversight with real authority to override, ensure input data suits their context, keep logs, and inform affected workers. Assuming it is entirely the vendor's problem is the common mistake.
Does removing gender and ethnicity from CVs make screening fair?
No. Proxies survive removal — postcode, university, career gaps, activities and writing style all correlate with protected characteristics. Blinding the obvious fields addresses the appearance of the problem rather than the mechanism.
What counts as human oversight?
Someone competent, with genuine authority to override the system, who understands its limitations well enough to know when overriding is warranted. A recruiter accepting a ranked list without the standing or information to challenge it does not meet the intent.
Can we just use a US vendor and avoid this?
Not if you are hiring in the EU. The obligations follow the deployment and the people affected, not the vendor's registered address.
Related guides
AI recruiting software
Recruiting tools differ less in features than in where they sit relative to the decision. Sorting the market by that — sourcing, screening, assessment, workflow — makes the regulatory and practical trade-offs visible before you shortlist.
AI in HR
AI in HR splits cleanly into administrative work, where it is uncontroversial and already useful, and decisions about people, where it is regulated as high-risk in the EU. Most disappointment comes from buying the second while expecting the first.
AI resume screening
Resume screening tools range from keyword matching to trained ranking models, and the failure modes differ sharply between them. Knowing which you are buying determines what can go wrong and what oversight it needs.