AI for Employment Decisions Under the EU AI Act: High-Risk Classification and What It Means for Employers

If your organisation uses AI to promote employees, allocate shifts, monitor performance, or recommend terminations, that system is almost certainly high-risk under Annex III of the EU AI Act (Regulation (EU) 2024/1689). Classification is mandatory. The compliance deadline, deferred under the Digital Omnibus agreed in May 2026, is 2 December 2027 for stand-alone systems. Non-compliance carries fines up to €15 million or 3% of worldwide turnover — whichever is higher.

This guide explains the classification basis, who must do what, the critical prohibition on emotion recognition at work, and what deployers (employers) need to know about Article 26's worker-notification duty.

---

Which employment AI systems are high-risk?

Annex III, point 4(b) covers AI systems intended to be used to make decisions affecting the terms of work relationships, to promote or terminate contracts, to allocate tasks based on individual behaviour or personal traits, or to monitor and evaluate the performance and behaviour of individuals at work.

That scope is deliberately wide. It captures:

• Performance monitoring tools that score output, flag low performers, or feed into appraisal scores
• Task-allocation engines that assign work based on behavioural data or personal characteristics
• Systems that recommend promotion candidates or support redundancy selection
• Contract management tools that trigger or score termination recommendations

The trigger is intended purpose, not actual use. If the system is designed to do any of the above, it is high-risk even if a human makes the final call. "Decision support" is not a classification exemption.

Note that point 4(a) covers recruitment and selection AI (screening CVs, shortlisting candidates). This article focuses on the in-employment uses listed in point 4(b), though many of the compliance obligations are identical.

The Article 6(3) filter

Article 6(3) creates a narrow off-ramp: an Annex III system is not high-risk if it poses no significant risk of harm to health, safety, or fundamental rights — for example, it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without influencing human assessment, or does preparatory work. But any system that profiles natural persons is always high-risk, regardless of how narrow the claimed scope.

In employment, the filter rarely saves you. Performance monitoring that feeds into appraisal or termination decisions profiles individuals. Task-allocation based on behavioural traits profiles individuals. Providers claiming the Article 6(3) exemption must document the assessment and register the finding.

---

A hard line: emotion recognition in the workplace is prohibited

Before getting to the compliance obligations, one distinction matters enormously.

Article 5(1)(f) prohibits placing on the market or putting into service AI systems that use real-time or post-hoc emotion recognition in the workplace or educational institutions — subject to very limited exceptions set out in that article. This ban has been in force since 2 February 2025.

A system that infers a worker's emotional state (stress, engagement, frustration, deception) and uses that inference in performance scoring, task allocation, or termination recommendations is not a high-risk system that needs compliance steps — it is an unacceptable-risk system that is simply banned. Deploying one now exposes your organisation to fines up to €35 million or 7% of worldwide turnover under Article 99(3).

This distinction matters in practice. Many "engagement monitoring" or "productivity intelligence" tools on the market purport to assess worker mood or emotional state from webcam feeds, keystroke patterns, or voice analysis. If you are evaluating such tools, verify — in the product documentation and contractually — that no emotion inference is taking place.

Permitted performance monitoring (tracking output metrics, project completion rates, quality scores) is a separate category and remains subject to the high-risk requirements below, not the prohibition.

---

Provider vs deployer: who does what

Most employers are deployers, not providers. A deployer is any person or organisation that uses an AI system under its authority in a professional context (Article 3). An employer buying and running a third-party performance management tool is a deployer. The vendor who built and sells that tool is the provider.

The distinction matters because the obligations are different — though both are real.

Providers must, before placing the system on the market or deploying it:

• Establish a risk management system (Article 9)
• Govern training and validation data (Article 10)
• Create technical documentation per Annex IV (Article 11)
• Maintain logs (Article 12)
• Ensure the system enables transparency to deployers (Article 13) and human oversight (Article 14)
• Meet accuracy, robustness, and cybersecurity requirements (Article 15)
• Complete a conformity assessment under Article 43 — either Annex VI internal-control procedure or, in specific cases, a notified-body assessment under Annex VII
• Issue an EU Declaration of Conformity (Article 47) and register in the EU database (Article 49)
• Establish post-market monitoring (Article 72) and report serious incidents (Article 73)

Deployers must, under Article 26:

• Use the system in accordance with the instructions of use
• Assign human oversight to competent staff (Article 26)
• Monitor operation and report serious incidents or malfunctions to the provider and, where relevant, the market-surveillance authority (Article 26)
• Carry out a Fundamental Rights Impact Assessment (FRIA) under Article 27 before deployment — this is mandatory for deployers in employment who are bodies governed by public law, or private deployers using the system to profile individuals or assess creditworthiness/insurance risk; employers running large-scale performance monitoring should assess whether this obligation applies
• Inform workers and their representatives before deploying high-risk AI systems that affect them — this is Article 26, and it applies specifically to workplace AI. Before a performance monitoring or task-allocation system goes live, affected employees and applicable workers' representatives must be notified. This is an independent legal obligation, not just a transparency recommendation

Article 25 governs role shifts: a deployer that puts its own name on a high-risk system, substantially modifies it, or changes its intended purpose steps into the provider role and inherits all provider obligations.

---

The obligation stack for providers

Risk management system — Article 9

Article 9 requires a documented, iterative process running across the system's lifecycle. For employment AI, the risk landscape has two dominant themes.

First, discriminatory outcomes. Training data drawn from historical employment records encodes past decision patterns. If your training set reflects years of decisions that favoured certain demographics, the system will learn those patterns. Article 9 requires you to identify this risk explicitly, estimate its severity and likelihood, test the system for disparate impact across protected characteristics before deployment, and adopt measures to reduce residual risk.

Second, asymmetric power. Performance monitoring creates an informational asymmetry between employer and worker. The Article 9 analysis must address whether the system can be used in a manner not intended — for example, to justify pre-determined termination decisions — and what controls prevent that.

Testing under Article 9(5) must be conducted before market placement and must identify the most appropriate measures. For employment AI, this means bias audits across gender, age, ethnicity, and disability status at minimum.

Technical documentation — Article 11 and Annex IV

Providers must create and maintain technical documentation before placing the system on the market. Annex IV specifies the required content: general system description and intended purpose; system architecture and logic; training, validation, and testing data; monitoring and control mechanisms; performance metrics; known risks and mitigation measures; and post-market monitoring procedures. This documentation must be retained for ten years after the system is placed on the market.

Transparency to deployers — Article 13

The instructions of use supplied to deployers must include: the system's capabilities and limitations; performance metrics and known failure modes; input data specifications; human oversight measures and technical interfaces; and circumstances in which the system may not perform as intended. An employer deploying a task-allocation engine has a right to know, in concrete terms, what the system cannot reliably do.

Human oversight — Article 14

The system must be designed so that a designated natural person can understand its outputs, intervene or override where necessary, and has not been lulled into automation bias. This is a design requirement on the provider — the system must facilitate genuine oversight, not merely permit it in theory.

Conformity assessment — Article 43

Before market placement, providers must conduct a conformity assessment. For most Annex III employment AI systems, this is the Annex VI internal-control procedure: the provider documents compliance across Articles 9–15 and issues a Declaration of Conformity. Systems using biometric categorisation or emotion recognition that have not already been caught by the Article 5(1)(f) prohibition may require a notified-body assessment.

Registration — Article 49

High-risk AI systems must be registered in the EU database before deployment. Providers submit; deployers are responsible for ensuring the system is registered before they use it.

---

The obligation stack for deployers

Most obligations listed above fall on providers. But Article 26 is substantive, and two parts of it deserve particular attention for employers.

Article 26 — informing workers before deployment. This is a specific, affirmative duty. Before a high-risk AI system is used to monitor, evaluate, or make decisions about workers, the employer must inform the affected workers and, where applicable, their representatives. The timing requirement is pre-deployment, not concurrent. This interacts with works council consultation rights under national labour law in Germany, France, and other EU jurisdictions — in many cases, those rights will impose stricter obligations than Article 26 alone.

Article 27 — Fundamental Rights Impact Assessment. For deployers that are public bodies, or that use high-risk AI to make decisions affecting a large number of people, Article 27 requires a structured assessment covering: the purpose and deployment context; the categories of natural persons affected; any foreseeable impact on fundamental rights; and the measures adopted to mitigate those impacts. The FRIA must be submitted to the market-surveillance authority on request. Confir's FRIA workflow runs the seven-section assessment and generates an audit-ready output.

GDPR Article 22. Outside the EU AI Act, employers must also address GDPR Article 22, which restricts decisions based solely on automated processing that produce legal or similarly significant effects. For employment decisions, "legal effects" include termination and, arguably, promotion. Where Article 22 applies, the affected individual has the right not to be subject to a purely automated decision, the right to human review, and the right to an explanation. The EU AI Act's Article 14 human oversight requirement and GDPR Article 22 point in the same direction: you need a genuine human decision-maker, not a rubber-stamp.

---

Worked example: shift-allocation AI at a logistics company

A 300-person logistics company deploys an AI system that allocates delivery shifts and routes based on historical performance data, punctuality records, and driver ratings. Drivers with consistently lower scores receive fewer desirable shifts and, after three consecutive quarters below a threshold, are flagged for a performance conversation.

Classification. The system allocates tasks based on individual behaviour and evaluates performance — both squarely within Annex III point 4(b). It profiles natural persons. Article 6(3) exemption does not apply. The system is high-risk.

Role. The company bought the system from a fleet-management software vendor. The company is the deployer; the vendor is the provider.

What the vendor must have done. Before selling the system, the vendor needed: an Article 9 risk management file covering disparate-impact risk (e.g., does the scoring algorithm disadvantage drivers returning from sick leave or parental leave?); Annex IV technical documentation; an Article 43 conformity assessment; an Article 47 Declaration of Conformity; and registration in the EU database under Article 49.

What the company must do. Before switching the system on, it must inform affected drivers and any applicable workers' representative body under Article 26. It must designate a human supervisor with the competence and authority to review flagged-driver cases before any performance conversation is held. It must monitor operation and report malfunctions to the vendor. It should assess whether an Article 27 FRIA is required given the scale of the deployment and the employment consequences of low scores.

GDPR. Each driver whose scores feed a "flag for performance review" outcome has GDPR Article 22 rights. The company cannot rely on the AI's output alone; it must ensure a human reviews the flagged case meaningfully, considering context the algorithm may not capture (illness, equipment faults, unusual route conditions).

Deadline. Obligations apply from 2 December 2027 for this stand-alone Annex III system. Preparation — vendor due diligence, worker notification, oversight workflow design — should begin well in advance. The documentation alone takes months to assemble correctly.

---

How Confir helps

Classification and scoping. Confir's rule-based, deterministic classification engine takes plain-English answers about your system's intended purpose and derives the risk tier and role — provider or deployer — under Articles 5 and 6. Same inputs, same output, every time. There is no inference step and no guesswork.

Article 27 FRIA. For high-risk deployers in employment, Confir automatically triggers the Article 27 Fundamental Rights Impact Assessment workflow — a structured seven-section assessment that maps employment-specific risks to fundamental rights, documents mitigation measures, and generates an audit-ready output.

Conformity Package. For providers, Confir generates the Article 11 / Annex IV technical documentation pack and the Article 47 EU Declaration of Conformity across structured panes, pre-populated from your intake. It covers training data governance, bias-testing documentation, human oversight procedures, and post-market monitoring plans — the full set of documents an auditor expects to see.

---

Frequently asked questions

Does high-risk classification apply if humans make the final decision?

Yes. The classification follows the system's intended purpose, not who signs off the outcome. Under Annex III point 4(b), any system intended to allocate tasks based on individual behaviour, monitor and evaluate performance, or influence promotion or termination decisions is high-risk. "Decision support" does not reduce the classification. Human review is a required control measure under Article 14 — it does not change what the system is.

What is the compliance deadline for employment AI?

Under the Digital Omnibus agreed in May 2026, obligations for stand-alone high-risk Annex III systems apply from 2 December 2027 — deferred from the original 2 August 2026 date. The prohibition on emotion recognition in the workplace under Article 5(1)(f) has applied since 2 February 2025 and was not deferred.

What must employers do before deploying a performance monitoring tool?

Article 26 requires employers to inform affected workers and their representatives before deployment. Beyond that, employers must verify the provider holds a valid Declaration of Conformity and is registered in the EU database; assign oversight to a competent person who can interpret and override system outputs; and assess whether an Article 27 FRIA is required. Works council consultation rights under national labour law may impose additional requirements in Germany, France, and other jurisdictions.

Is emotion recognition in the workplace a compliance issue or a prohibition?

A prohibition. Article 5(1)(f) bans placing on the market or using AI systems for emotion recognition in the workplace, with narrow exceptions. This ban applied from 2 February 2025. A system that infers emotional states from face, voice, or keystroke data and uses those inferences in employment decisions is not a high-risk system subject to Article 9–15 obligations — it is unlawful. Fines reach €35 million or 7% of worldwide turnover.

What are the fines for non-compliance?

Breaching high-risk obligations (Articles 9–15, provider duties under Article 16, deployer duties under Article 26) carries fines up to €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). For companies that qualify as SMEs, Article 99(6) caps the fine at the lower of the percentage or the fixed amount — a genuine proportionality protection. Breaching the Article 5(1)(f) prohibition on emotion recognition carries fines up to €35 million or 7%.

Does GDPR Article 22 apply alongside the EU AI Act?

Yes, and the two regimes overlap. GDPR Article 22 restricts fully automated decisions producing legal or similarly significant effects on individuals — which includes employment termination and, in most cases, promotion. Where Article 22 applies, the affected worker has the right not to be subject to a purely automated decision and the right to human intervention. The EU AI Act's Article 14 human oversight obligation points in the same direction, but the GDPR right is independently enforceable and has applied since 2018. Both must be addressed.

---

Related guides

• Article 6 high-risk classification
• Annex III high-risk AI categories
• high-risk AI classification requirements
• Article 3 key definitions
• EU AI Act compliance checklist
• EU AI Act compliance software comparison