EU AI Act for HR and recruitment AI | what employers must do

Is our EU AI Act for HR and recruitment work a legal duty, and when does it bite?

If an HR or recruiting tool uses AI to recruit or select people, decide promotion or termination, allocate tasks, or monitor worker performance and behavior, it is a high-risk AI system under Annex III point 4 of the EU AI Act. Following the 2026 amendment, the high-risk rules for Annex III systems apply from 2 December 2027, not 2 August 2026. That date gives you a fixed planning horizon, but it does not mean the work can wait, because contracts, procurement reviews and works council consultations often start well before the obligations bite.

Whether the duty lands on your organization depends on three questions. First, are you the provider (the party that develops the system or places it on the market under its own name) or the deployer (the party that uses it under its authority)? An employer that buys a screening tool is usually a deployer, while a vendor that builds it is the provider, and a company that substantially modifies or rebrands a tool can take on provider duties. Second, what does the tool actually do? Ranking applications is covered by point 4, but a scheduling assistant or a document formatter may not be. Third, does any use fall under a prohibition? Article 5(1)(f) bans AI that infers emotions of people at work, except for medical or safety reasons, and that ban has applied since 2 February 2025.

Before you answer a customer, works council or regulator, confirm the facts in writing: the vendor's intended purpose for the tool, whether it has any emotion inference features (including those switched off by default), which workers or applicants it touches, and whether an Article 6(3) exemption argument has been documented. Ask the vendor for its classification reasoning and instructions for use, because those determine what you must do as deployer. Where the answer is unclear, treat the use as high-risk until a legal review says otherwise, and record that decision.

Why emotion recognition at work is banned outright

Article 5(1)(f) prohibits inferring the emotions of people at work and in education institutions, with one narrow exception for medical or safety reasons. The four cards below cover what the prohibition catches, the tools that most often trigger it, how narrowly the exception should be read, and the steps an employer or HR software vendor should take now.

What counts as emotion inference

The ban covers AI that infers emotions from biometric data such as facial expressions, voice tone, gait or physiological signals. It is about the inference itself, not the label on the product. If a system outputs a judgment such as stress, frustration, boredom, disengagement or satisfaction for a named worker, it is likely inferring emotions. Check what the model actually outputs, not only the marketing copy. Ask vendors to state in writing whether any feature produces emotional state estimates.

Typical tools that trigger it

Video interview scoring, meeting analytics that rate participant engagement or sentiment, call-centre voice analytics that flag agent mood, and webcam-based attention monitoring are the usual cases. Some of these tools are sold as productivity or wellbeing features. Employers should inventory any product that analyzes video or voice from staff or candidates, including features switched on by default in collaboration suites. Where a tool is used in a hiring context, it may also be high-risk under Annex III point 4.

The medical or safety exception

The prohibition does not apply where the system is intended for medical or safety reasons, such as monitoring a worker's fatigue to prevent a driving or equipment accident, or a clinical tool used for patient care. The exception is read narrowly. A general wellbeing or engagement goal is not a medical reason, and a safety purpose must be the actual intended purpose, documented and tested. Ask counsel to confirm the reading for each use case before relying on it.

What to do now

Start with an inventory of every system that processes worker or candidate video, audio or biometric data, and record the vendor, feature and intended purpose. Disable any emotion inference feature that lacks a documented medical or safety purpose, and confirm in writing that the vendor has done the same for your tenant. Keep a dated decision record for each exception you rely on, with the reasoning, the approver and the review date. Your implementation partner can prepare the inventory and evidence, but the decision remains yours.

What employers as deployers must do before and during use

Before an employer uses a high-risk recruitment or workforce system at the workplace, the AI Act expects the deployer to prepare. Article 26(7) requires the employer to inform workers' representatives and the affected workers before the system is put to use. Article 26(1) requires the deployer to use the system in line with the provider's instructions for use, through technical and organizational measures. Both duties depend on knowing exactly what the system does, so the instructions for use are the starting point for the deployer's own setup decisions.

Worker representatives: Identify the bodies that represent workers at each site and document when and how they were informed.
Affected workers: Record which groups of workers or applicants the system touches, such as candidates, employees under monitoring, or staff receiving task allocation.
Instructions for use: Keep the provider's instructions on file and map each stated use limit to a configuration or operating rule.
Technical settings: Document how the system is configured, including data inputs, thresholds and integrations with HR platforms.
Organizational measures: Write the procedures that stop use outside the stated purpose, such as access rules and approval steps.

Check that the notification record, the instructions for use and the configuration baseline all describe the same deployment before the system goes live.

What HR software vendors carry as providers

A vendor that places a recruiting, screening or workforce management system on the EU market is usually the provider of that high-risk system, and the provider chapter of the AI Act puts most of the design-stage and lifecycle duties on that party. For an Annex III system used in hiring or worker monitoring, this means the vendor is expected to run a risk management process, prepare technical documentation, design logging capabilities into the product, write instructions for use that employers can follow, and operate post-market monitoring after release. Conformity assessment, which for most Annex III systems is an internal-control route, also sits with the provider. Your customers, as deployers, cannot discharge these duties by configuring the product, so the question to settle early is which of these artifacts the vendor will actually deliver and when.

A customer can become the provider without buying a different product. If an employer substantially modifies the tool, changes its intended purpose so that it falls into a high-risk category, or puts its own name or trademark on a system it repurposes, the Act can treat that employer as the provider for that system. Typical triggers to review are retraining a ranking model on internal hiring outcomes, adding a new scoring feature for promotion decisions, or connecting productivity signals to performance reviews that the vendor never assessed. Before any such change, check the vendor's instructions for use and the contract, and confirm in writing whether the vendor's documentation still describes the configuration in production.

Contract language should state who holds each provider and deployer duty, which documents the vendor will supply, how often technical documentation and risk files are updated, how incidents and serious malfunctions are reported to the employer, and what the vendor will do if an EU date or harmonised standard changes the requirements. Ask for the intended purpose wording, the list of Annex III categories the vendor has assessed, and the log format the product produces. Have legal counsel confirm role allocation against the current consolidated text and the Commission's draft classification guidelines, because the answer depends on how each feature is used.

How an HR AI compliance project moves from inventory to evidence

The sequence turns a loose collection of HR tools into a classified inventory, a role map, a gap list against the deployer duties and an evidence file that shows what each worker-facing system does and who controls it.

Inventory every HR tool with AI features
Start by listing every system that touches recruiting, promotion, task allocation, scheduling, productivity tracking or performance review, including features switched on by a vendor update. For each entry, record the vendor, the AI functions used, the workforce affected, the data inputs and whether the feature can be turned off. HR and IT should both sign off the list. The step is complete when every AI-enabled tool has an owner and a named business purpose.
Classify each use against Annex III point 4
Test each inventoried use against Annex III point 4, which covers recruiting or selecting people, decisions on promotion or termination, task allocation based on behavior or personal traits, and monitoring or evaluating worker performance and behavior. Separately, check whether any feature infers emotions of workers, because Article 5(1)(f) bans that in the workplace unless it serves medical or safety reasons. Record a reasoned classification for each use, including uses you conclude are not high-risk. Legal and HR should review borderline cases, and the output is a classification register.
Map provider and deployer roles
For each high-risk use, decide whether your organization builds or substantially modifies the system (provider) or uses a system supplied by a vendor (deployer). Many employers hold both roles when they customize a vendor tool or repurpose it for a new purpose, so check contracts and configuration history. Document the role decision and the vendor's responsibilities alongside yours. The output is a role map that shows which obligations sit with the employer and which the vendor must meet.
Assess gaps against the Article 26 deployer duties
Compare current practice for each high-risk HR system against the deployer duties in Article 26, including use according to the vendor's instructions for use, assigned human oversight, log retention and worker information. Note where vendor documentation is missing, where no one holds oversight authority, and where logs are not kept under your control. Rate each gap by the work needed to close it. Confirm with counsel the timing that applies to your systems under the 2026 amendment. The output is a gap register with an owner for each item.
Build the worker and representative information plan
Design how workers and their representatives learn that a high-risk system is in use before deployment, as Article 26(7) requires. Separately, plan how individuals subject to a system that makes or assists decisions about them are told, under Article 26(11). Prepare plain-language notices, the channel for each audience and the process for answering questions about the role of the AI. Where Article 86(1) applies, prepare the explanation of the AI's role and the main elements of the decision. The output is approved notice text and a record of when each group was informed.
Design oversight and logging
Assign each high-risk system to named people with the competence, training, authority and support to oversee it, and document how they can review, override or stop outputs. Configure logging so that the deployer holds the records under its own control for at least six months, unless other Union or national law requires longer. Test that a sample decision can be traced from input to output to human review. This step is complete when the oversight roster, log settings and a test trace are on file.
Assemble the evidence file
Gather the inventory, classification register, role map, gap register, notices, oversight roster, log configuration, vendor instructions for use and records of worker information into one controlled file per system. Add dated approvals and a review schedule so the file stays current as vendors release updates. An independent auditor or the relevant authority decides whether the evidence is sufficient; DeployOpen prepares the file but does not issue assessments. The duration depends on the number of systems and jurisdictions, so request a timeline in your written scope.

What HR teams need in place before a conformity or customer review

Five items sit under almost every review of HR AI, whether a customer questionnaire, an internal audit or a regulator's request. Each one is a document or record you can produce on demand, and each one fails in a predictable way when it is missing.

Complete AI system inventory across HR

List every tool in recruiting, promotion, task allocation and performance monitoring that uses AI, including features bought inside a larger HR suite, applicant tracking add-ons and scheduling tools that rank or filter people. Check the inventory against procurement records and vendor contracts, since shadow tools often enter through individual teams. For each entry, record the vendor, the business owner, the workforce affected and the locations where it runs.

Written risk classification per system

For each inventory entry, record whether it falls under Annex III point 4 and why, and whether the Article 6(3) exemption is claimed. The rationale should name the decision the system makes or supports and the people it affects. Check that the classification was reviewed when the tool's features or vendor changed, and that the reviewer is someone other than the person who requested the tool.

Named oversight owners with documented authority

Assign each high-risk system a named person responsible for human oversight, and document that person's competence, training, authority to override or stop the tool, and the support they receive. Article 26 expects oversight to be assigned to people who can act on it, so a job title alone is not enough. Check that the owner can show training records and that the escalation path is written down.

Log retention meeting the six-month minimum

Confirm that logs generated by each high-risk system are kept under the deployer's control for at least six months, unless other Union or national law requires longer. Check that logs from the vendor platform are exported or retained in your own storage, not only visible in the vendor's dashboard. Test a restore or retrieval request, and confirm that retention rules align with your data protection retention schedule.

Worker information notice and consultation record

Keep a dated record showing that workers' representatives and affected workers were informed before a high-risk system was used at the workplace, and a separate notice telling candidates or employees that an Annex III system makes or assists decisions about them. Check that the notice describes the system's role in plain language and that consultation minutes exist for each deployment. Missing records are often the first gap a works council or regulator raises.

In-house, partner-supported or vendor-led compliance: which fits

This table compares three ways to run AI Act obligations for recruiting and workforce tools: an in-house program, a partner that prepares systems and evidence, and a vendor-led model. Read each row to see who holds provider duties, who keeps deployer decisions, and which situations suit each model. The main takeaway is that the employer's deployer duties stay with the employer whichever option is chosen.

Option	Who holds what	When it fits
In-house program led by HR and legal	The employer owns deployer duties: worker information, human oversight, log retention, explanations and the inventory of workplace AI. Internal staff run the assessments and keep the records.	Organizations with few AI tools in HR, existing legal and HR capacity, and a team able to keep a current inventory and oversight records.
Partner-supported model	The employer keeps all decisions and sign-off. The implementation partner prepares systems, configuration, logs and evidence packs, while the employer approves what goes into them.	Organizations running self-hosted or customized HR platforms that need help with technical evidence, logging setup and documentation.
Vendor-led model	The HR software vendor carries provider duties such as technical documentation and conformity for its product. The employer still carries deployer duties for how it uses the tool.	Organizations using off-the-shelf HR software with no customization, where the vendor can supply conformity documentation and instructions for use.
Hybrid model (illustrative)	The vendor supplies provider documentation, the partner adapts configuration and logs, and HR and legal decide use cases and worker communications.	Organizations that use a mix of vendor tools and self-hosted systems, where responsibility must be split clearly in contracts.
Ownership of worker information	Employer in every model. Notices to workers' representatives and affected workers cannot be delegated away.	Use this row as a check: any model that leaves worker notices unassigned is incomplete.

Who owns the duties, who prepares evidence and who issues anything

As a deployer, the employer holds the duties that attach to using a high-risk system at work. Those duties sit with the company that makes hiring, promotion, task allocation or monitoring decisions, and they cannot be handed to a vendor or consultant. HR and legal own the decisions about which systems are used, for what purpose, and with whom the system is discussed before go-live.

Own the decisions: Decide which recruiting, promotion or monitoring uses are in scope, and document the purpose and the decision points where the output is used.
Own worker information: Inform workers' representatives and affected workers before a high-risk system is used at the workplace, and inform people subject to a system that makes or assists decisions about them.
Own human oversight: Name people with the competence, training, authority and support to oversee the system and to override it.
Own the explanation process: Prepare a way to give affected people clear explanations of the system's role and the main elements of a decision.
Outsource the groundwork: An implementation partner can help build the system inventory, configure log retention and assemble evidence packs, but the employer signs off on each.

Before you engage anyone, confirm with counsel which works council or employee consultation steps apply under national law in each country where you employ people.

How much effort, time and outside help does HR AI compliance need?

Can a small employer handle AI Act compliance for hiring tools alone?

A small employer can handle the deployer duties alone if it uses only a few tools, the vendor supplies usable instructions and documentation, and someone accountable has the time and authority to run them. The deployer work is mostly organizational: keeping an inventory of each AI system, assigning human oversight to people who are competent and empowered to act on it, informing workers' representatives and affected candidates or workers, keeping logs for at least six months under the employer's control, and giving explanations when a decision has significant adverse effects. Where the employer relies on a vendor's documentation, it still needs to confirm what that documentation says before relying on it. Outside help is most useful for checking scope and for building the evidence set, not for doing the daily oversight. Ask a qualified legal adviser to confirm how your national law and works council rules interact with these duties.

What makes HR AI compliance effort go up or down?

Effort scales with the number of systems in scope, how much the vendor discloses, and how many locations and works councils are involved. The main drivers are:

Number of tools: each recruiting filter, ranking model, scheduling or performance tool that makes or assists decisions about people needs its own inventory entry, instructions for use, oversight assignment and log arrangements.
Vendor transparency: if the provider can state the intended purpose, the input data, the known limitations and how logs are produced, the employer's work shrinks. If not, the employer must first obtain that information.
Locations and works councils: each EU country may impose its own information and consultation rules for workers' representatives, so a multi-country employer needs a map of obligations per site.
Use of tools for workforce decisions: task allocation and monitoring tools carry more duties than a tool used only to schedule interviews.

Ask for a written list of systems, their roles, and the vendor documents you will rely on before agreeing any scope.

Does an HR AI system need a notified body for conformity assessment?

For most Annex III point 4 systems, the provider does not need a notified body, because the conformity assessment is normally based on internal control under Annex VI. Notified bodies are involved for some biometric systems and for Annex I products, so an HR tool that is not biometric and not part of a regulated product usually falls outside that route. Confirm this for each system, because the classification depends on its actual function and intended purpose, and the draft Commission guidelines on classification should be checked as they stand. If a vendor claims a notified body was involved, ask for the certificate or the documented basis for it and check that it covers the system you use. Employers as deployers do not carry the provider's conformity assessment, but they should ask the vendor to confirm the route in writing.

What does the work require from HR and IT teams?

HR owns the decisions and the people-facing duties, and IT owns the systems, access and records. HR typically needs to identify which hiring and workforce decisions the tools influence, name the people who will oversee them, prepare worker and candidate notices, and coordinate with works councils or worker representatives. IT typically needs to confirm where the tool runs, how logs are captured and stored under the employer's control, who holds access, and how logs are retained for at least six months unless other law requires longer. Both teams should agree on an escalation path for contested decisions and on how explanations will be produced when a person asks for one. Allow time for these tasks to be scheduled alongside normal hiring and review cycles, since the reviews need people who are not already overloaded.

Do vendor contracts for HR software need to change?

Contracts often need updating so that the employer can meet its deployer duties. Ask the vendor to commit in writing to provide instructions for use, to explain the system's intended purpose and known limits, to support the employer with information needed for worker notices and explanations, and to state how and where logs are generated and how long they are available. Also confirm the vendor's own position as a provider, including its conformity route and how it will notify you of material changes. Check whether the contract allows the employer to obtain logs in a usable format at the end of the relationship. Have counsel review the wording, because the right terms depend on your jurisdiction and on how the vendor is organized.

What will an implementation partner not do for HR AI compliance?

A partner such as DeployOpen can prepare systems, controls and evidence, but it does not issue certificates, attestations, audit reports or legal opinions. Only an independent auditor, assessor or certification body can issue those, and a lawyer must give legal advice on how the Act and national employment law apply to your organization. A partner also does not take over the employer's accountability for decisions about people. In practice, a partner may help you map systems, set up logging and access on infrastructure you control, document oversight arrangements, and prepare evidence for review. Ask any partner to put in writing what it will deliver, what you must do yourself, and which parts require legal or notified body input.

How DeployOpen prepares HR AI systems and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the AI-enabled HR tools you run can produce the evidence the AI Act expects from deployers. We prepare systems, controls and records for your assessment, while your organization keeps ownership of its decisions and independent auditors or assessors issue any reports.

How we scope

We agree a written, fixed scope listing each recruiting, promotion, task allocation or monitoring system in your estate.
The scope states which systems fall under Annex III point 4 and which uses are excluded or still under review.
We confirm with your legal and HR teams which worker representatives and affected groups must be informed before use.

How we build

We configure logging so deployer records are kept under your control for at least six months, unless other law applies.
We set up human oversight roles, approval steps and override paths for people who review HR AI outputs.
We test the worker notification and explanation workflows, including requests for clear explanations of AI-assisted decisions.

How we hand over

You receive system documentation, configuration records, oversight procedures and the instructions for use applied in your environment.
We deliver an evidence pack mapped to the Article 26 deployer duties, with gaps and open actions listed for your owners.
Training materials for reviewers and HR staff are delivered so your teams can operate and maintain the controls after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can review changes to HR systems, vendor updates and the dates that apply to Annex III obligations.
Requests for an independent assessment or certification are referred to the auditor or body you choose, which we support with evidence.

EU AI Act for HR, recruiting and workforce management