The EU AI Act for HR Tech: What Recruitment, People Analytics, and Workforce AI Companies Need to Know

Updated 6 October 2026. The Digital Omnibus on AI deferred high-risk obligations for Annex III systems, including all of Area 4 (employment), from 2 August 2026 to 2 December 2027. The bans on emotion recognition at work have applied since February 2025 and did not move. Dates and a few legal details below have been corrected. See what the Omnibus changed.

Earlier this year I spent two months talking to founders and CTOs at European HR tech companies. The pattern is consistent. They know the EU AI Act exists. They've read a blog post or two about it. Most assume one of three things:

"Our AI is just a tool, the recruiter makes the actual decision."

"We're B2B, so most of this doesn't apply to us."

"It got delayed to 2027, so we can park it."

All three positions are wrong. If your HR tech product uses AI in the hiring funnel, performance evaluation, workforce planning, or anywhere in the employee lifecycle, the regulation almost certainly classifies your AI as high-risk. That triggers about nine documented obligations, which now apply from 2 December 2027. Some things apply already: the emotion recognition ban, AI literacy, and Article 50 disclosure for any recruiting chatbot.

This isn't going to be a panic piece. The work is real but doable. What it requires is understanding exactly how the regulation treats HR-related AI, what your obligations actually are, and what a sensible compliance path looks like for a company that ships product instead of legal documents for a living.

Let me walk you through the specifics.

Why HR tech is squarely in Annex III

The EU AI Act has eight high-risk areas listed in Annex III. Area 4 is the one that catches almost every HR tech product. The exact wording covers AI used for:

• Recruitment or selection of natural persons, particularly for placing targeted job advertisements, analysing and filtering applications, and evaluating candidates
• Making decisions affecting the terms of work-related relationships, promotion, or termination
• Allocating tasks based on individual behaviour or personal traits
• Monitoring and evaluating performance and behaviour of persons in work-related relationships

Read that carefully. It covers almost every legitimate use of AI in HR. Recruitment automation? Covered. Candidate ranking? Covered. Performance prediction? Covered. Workforce analytics that affect specific people? Covered.

Some HR tech founders read this and think "well, we don't 'make decisions' — we just provide recommendations." That defense doesn't work. We'll get to why in a moment.

The kinds of HR AI that fall under Annex III

To make this concrete, here are real product categories I've classified for HR tech founders. Each one is high-risk:

• CV screening and parsing AI that ranks candidates by suitability for a role
• Job description matching AI that recommends roles to candidates or candidates to recruiters
• Video interview analysis AI that evaluates candidate responses, expressions, or speech patterns
• Reference check automation that synthesizes inputs into ratings
• Skills assessment scoring when the AI evaluates whether someone meets criteria
• Performance management AI that predicts who's at risk of underperforming, who's high-potential, or who's ready for promotion
• Engagement and pulse survey analysis when it produces individual-level scores or recommendations
• Workforce planning AI that recommends which teams to scale, restructure, or reduce
• Compensation benchmarking AI when applied to individuals rather than aggregate role data
• Internal mobility AI that recommends people for projects or roles
• Productivity monitoring AI that scores or ranks workers
• DEI analytics AI when it identifies specific individuals or groups for intervention

A common reaction here is "but we don't really make decisions, the manager/recruiter does." Let me address that directly.

The "we're just advisory" argument doesn't hold up

This is the single most common pushback I hear from HR tech founders. The product is positioned as an aid to human decision-making. The marketing emphasizes that humans remain in control. The product itself often surfaces recommendations rather than executing decisions.

The regulation doesn't accept this framing. Here's why.

The EU AI Act creates an exemption in Article 6(3) for systems that perform certain limited tasks. One of those tasks is "performing a preparatory task to an assessment relevant to Annex III use cases." So you might think: my AI screens candidates and surfaces top 20, the recruiter then decides. That's a preparatory task. We're exempt.

Except for the next sentence of Article 6(3). It says the exemption does not apply if the AI system performs profiling.

Profiling, under GDPR Article 4(4) which the AI Act references, means any automated processing of personal data to evaluate certain personal aspects, particularly someone's work performance.

If your AI predicts, scores, or ranks candidates based on their likely fit for a role, you are profiling them. Period. The fact that a human reviews the ranking doesn't matter. The fact that you frame it as "preparatory" doesn't matter. The exemption is closed to you.

The regulator's intent here was very clear. They knew HR tech vendors would try to position their products as "just supportive" rather than "decisional." The profiling clause specifically prevents that escape hatch.

So if your product profiles candidates or employees, and you operate in the EU, you are high-risk. There is no version of this where you're not.

What being high-risk means for HR tech specifically

The nine obligations under Articles 9-72 apply broadly, but HR tech has some specific implications worth understanding.

Risk management (Article 9)

You need a documented process for identifying, evaluating, and mitigating risks the AI creates. For HR tech, the obvious risks include:

• Discriminatory outcomes based on protected characteristics
• Replication of historical biases in training data
• Privacy violations through inappropriate data inference
• Adverse effects on candidate experience
• Inaccurate predictions affecting career outcomes
• Lack of explainability when candidates question outcomes

The risk management plan needs to address each of these, document mitigations, and show this is an ongoing iterative process. Not a one-time document.

Data governance (Article 10)

Your training, validation, and testing data must meet specific quality criteria. For HR AI, this means:

• Documented sourcing of training data including consent and lawful basis
• Documented bias testing before deployment and ongoing
• Gap analysis if your training data has known underrepresentation
• Data minimization principles applied throughout
• Quality assurance procedures for the dataset over time

The bias testing requirement is the one most HR tech founders miss. The Act doesn't just want "we believe we don't discriminate." It wants documented evidence that you tested for bias across protected characteristics and what you did about findings.

That used to raise an awkward GDPR question: how do you test for bias against, say, ethnicity without processing ethnicity data? The Digital Omnibus added Article 4a, a legal basis for processing special category personal data where it's strictly necessary to detect and correct bias. It comes with strict safeguards: you have to show synthetic or anonymised data wouldn't work, use pseudonymisation and tight access controls, never pass the data on, and delete it once the bias is corrected.

Technical documentation (Article 11)

This is the longest document. It must include:

• Detailed system architecture
• Training methodology
• Performance metrics across demographic groups
• Known limitations
• Intended uses and uses that are explicitly out of scope
• Risk mitigation measures
• Validation procedures
• The full data governance setup
• Cybersecurity measures
• Post-market monitoring plan summary

For HR tech, the performance metrics section gets particularly detailed. You need to demonstrate accuracy and fairness across different groups, not just aggregate performance.

Human oversight (Article 14)

The Act requires that humans have meaningful ability to intervene in the AI's operation. For HR systems, this typically means:

• Recruiters can see why a candidate was ranked where they were
• The AI's recommendations can be overridden without burden
• Patterns that suggest the AI is being deferred to without scrutiny get flagged
• Training is provided to humans who oversee the AI

Note the word "meaningful." A recruiter who has 200 candidates and 30 minutes to review the top 20 is not exercising meaningful oversight. The product needs to be designed in a way that supports actual human judgment, not just human rubber-stamping.

Transparency (Article 13)

Users of the AI (your customers, not the candidates) must understand:

• What the system does and doesn't do
• Its limitations
• How to interpret outputs
• What decisions it should not be used for

For HR tech, this means clear documentation that recruiters and HR teams actually receive and understand. Not just buried in your terms of service.

Informing workers and candidates (Articles 26 and 86)

This is where HR tech differs from almost every other vertical. Your customers, the employers, take on specific duties as deployers, and your product decides how easy those are to meet:

• Before using high-risk AI at work, employers must inform workers' representatives and the affected workers (Article 26(7)). In many EU countries, works councils also have co-determination rights over monitoring tools, so this is often a negotiation, not a notification.
• People subject to decisions made or assisted by a high-risk system must be told that the system is being used (Article 26(11)).
• Affected people can request an explanation of the role the AI played in a decision that significantly affects them (Article 86).
• Under GDPR Article 22, where decisions are solely automated and have significant effects, people also have the right to human intervention and to contest the decision.

Your product needs to support all of this, either directly or by giving your customers the notices, explanations and audit trails they need.

The other obligations

• Article 12 (record-keeping): automatic logging of system events, decisions, and outputs
• Article 15 (accuracy, robustness, cybersecurity): consistent performance, resilience to errors
• Article 49 (registration): registering high-risk systems in the EU database before market launch
• Article 72 (post-market monitoring): ongoing monitoring of how the system performs in real conditions

The provider vs deployer question matters more in HR tech

You're a provider if you build the AI system. You're a deployer if you use someone else's AI under your authority. Both have obligations, but they're different.

Most HR tech vendors are providers. They built the AI, they ship it to their customers, they're responsible for most documentation. Your customers (the companies using your HR tech) are deployers. They have a smaller set of obligations focused on use, oversight, and informing affected individuals.

This matters strategically. Some HR tech founders have asked me whether they can shift the compliance burden to their customers. Generally, no. The provider has the bulk of obligations and that's almost always going to be the AI vendor.

But here's an interesting strategic angle. Your customers also have compliance obligations. If you make it easy for them to meet those obligations as part of using your product, you become more sticky. A customer who knows that switching HR tech vendors means rebuilding their AI Act compliance is a customer who stays.

Article 5 considerations specific to HR tech

Beyond high-risk classification, two things in HR specifically are prohibited under Article 5.

Emotion recognition in workplace contexts. AI that infers emotional states of workers or candidates in workplace and educational settings is banned outright. This includes interview AI that scores "enthusiasm," "confidence," or "engagement" from facial expressions or tone of voice. It includes employee monitoring systems that estimate emotional well-being from behavioral signals.

The narrow exceptions exist for safety or medical purposes (like detecting drowsiness for safety reasons) but these don't apply to general HR or hiring use cases. This ban has applied since 2 February 2025, and the Digital Omnibus did not change it. If your product still does emotion recognition in hiring or workforce contexts, it is already unlawful in the EU. Remove it now.

Biometric categorization for sensitive attributes. AI that infers race, political opinions, religious beliefs, sexual orientation, or trade union membership from biometric data is prohibited. This catches some video analysis tools and some "cultural fit" prediction systems that effectively backdoor into protected characteristics.

This ban has also applied since February 2025. If your product has features like this, address them now.

What sensible compliance work looks like

Here's roughly what HR tech compliance looks like for a company doing this properly. The total work is real but bounded.

Weeks 1-2: Classification and documentation foundation

• Inventory all AI systems in the product
• Classify each one (most will be high-risk Annex III Area 4)
• Document the classification reasoning for each
• Set up the system inventory in your compliance tooling

Weeks 3-5: Core compliance documents

• Risk Management Plan (Article 9)
• Data Governance Framework (Article 10)
• Technical Documentation (Article 11)
• Human Oversight Protocol (Article 14)

Weeks 6-8: Operational artifacts

• Transparency notices for customer-facing documentation
• Information to candidates/employees templates
• Post-market monitoring plan setup
• Internal training on the new compliance requirements

Weeks 9-10: Process integration

• Connect compliance work to product development
• Set up change management for AI system updates
• Establish quarterly review cadence
• Internal audit and gap closure

By week 10: You have documented compliance, established processes, and ongoing monitoring. From there, it's about maintenance, not creation.

For an HR tech company with 1-3 AI systems, this is roughly 80-120 hours of focused work split between product, legal, and compliance teams. With the deadline at 2 December 2027, a company starting now can spread that over a year. A company starting in autumn 2027 will be doing it badly under pressure.

The strategic angle most HR tech founders miss

Compliance is usually seen as a tax on doing business. For HR tech specifically, in 2026, that framing is wrong. Compliance is a competitive advantage.

Three reasons:

Enterprise buyers are asking. Every European enterprise procurement team is now asking AI Act compliance questions. HR tech vendors who can answer "yes, we're fully compliant, here's our documentation" win deals. Vendors who can't or have to scramble get filtered out. By the second half of 2026, this will be a standard procurement gate.

Investors are asking. European investors increasingly do AI Act compliance due diligence as part of HR tech investment decisions. A documented compliance posture is now part of an investible package.

Differentiation is hard in HR tech. Every product category has 20 competitors. Saying "we're EU AI Act compliant from day one" is a meaningful trust signal at a time when many of your competitors are still figuring out whether the regulation applies to them.

A few HR tech companies I've spoken with are actively building "compliant by design" into their positioning. They're treating compliance as part of the product, not a cost center. This is the right read of the market.

What to do this week

If you're an HR tech founder reading this and feeling the pressure, here's a sensible order of operations:

1. Map every AI feature in your product. Even the ones you don't think of as "AI features."
2. Run each one through a classifier to confirm risk tier. Most will be high-risk Annex III Area 4. Some might be limited-risk or even minimal-risk.
3. Fix what already applies: remove any emotion recognition, add AI disclosure to recruiting chatbots, and put AI literacy measures in place.
4. Schedule the high-risk work across the next 12 months, documentation first. Leaving it to the second half of 2027 is asking for trouble.
5. Build the worker-information and explanation features your customers will need under Articles 26 and 86.
6. Treat compliance as a customer-facing feature, not internal overhead. Document it publicly. Tell customers about it. Use it to win deals.

The companies that use the extra time well will be in great shape in December 2027. The ones that park it will be paying double-rate consultants and skipping crucial documentation steps because they ran out of time.

If you want help with any of this, ActScope is built specifically for this use case. The free classifier handles your initial assessment. The Pro tier generates all the documentation you need, tailored to your specific systems. We're based in Amsterdam and have classified more than 100 HR tech systems in the past two months.

Run the free classifier →

The deadline is real. The work is real. But the work is also bounded and doable if you start now. Don't be the HR tech founder explaining to your customers in December 2027 why your AI features got pulled from the EU.

---

Common questions from HR tech founders

Do we need to do this for each region we operate in? The EU AI Act applies to AI that operates in the EU market or affects EU citizens. If you offer your product in any EU country, you're covered. The regulation is harmonized across the EU, so you do the work once.

What if we use a third-party AI for the actual model? You're still likely the provider for compliance purposes if you're delivering it to your customers as your product. The underlying model provider has separate obligations under the GPAI provisions if it's a foundation model. Your obligations don't disappear just because someone else trained the model.

Can we use the simplified obligations for SMEs? The AI Act gives SMEs some relief: lower fine caps, simplified technical documentation and quality management routes (extended to small mid-caps by the Digital Omnibus), and priority sandbox access. But the core obligations are the same. There's no general SME exemption.

Do we need to register every AI system separately? Under Article 49, high-risk systems must be registered in the EU database before market deployment. If you have multiple AI features, yes, generally each gets its own entry. The registration includes basic system info, intended purpose, and provider details.

What about UK companies? Post-Brexit, UK is not directly bound by the EU AI Act. But UK HR tech companies serving EU customers are covered the same way as US or any other non-EU company. The regulation applies based on market reach, not company location.

What about candidates outside the EU? The regulation primarily covers AI affecting people in the EU. If your AI processes data on candidates outside the EU exclusively, that's typically not in scope. But if you have any EU candidates flowing through the system, the AI is in scope.

Can we just turn off the AI features for EU customers? Yes, this is a valid (if undesirable) compliance path. Some HR tech vendors are seriously considering EU-specific feature limitations to avoid compliance burden. Strategically, this concedes the European market on the AI front. I'd argue compliance is cheaper than market loss.

---

Run the free classifier on your HR tech AI →

Related guides:

• The Digital Omnibus Explained: The New EU AI Act Timeline
• Is My AI System High-Risk Under the EU AI Act?
• Article 6(3) Exemption: When Annex III Doesn't Mean High-Risk
• EU AI Act vs GDPR: How They Overlap and Where They Don't
• The 2026 EU AI Act Compliance Checklist