How EU HR-Tech SaaS Becomes a High-Risk AI Provider

The question nobody wants to answer

"Are we a high-risk AI provider?"

Most founders building AI for HR ask this question once, get an uncomfortable answer, and move on. The problem is that the EU AI Act has a specific, non-negotiable answer — and the consequences of getting it wrong are significant.

This guide tells you exactly when you are a high-risk AI provider under the EU AI Act, what obligations that creates, and what the practical path forward looks like. No legal hedging. No "it depends."

Run the free Annex IV Readiness Check now to see where you stand.

---

The classification rule

The EU AI Act classifies AI systems as high-risk using a two-part test:

Part 1: Is the system listed in Annex III?

Part 2: Is it used as a safety component in a regulated product, or is it itself a listed system?

For HR-tech, the relevant entry is Annex III §4(a):

"AI systems intended to be used for recruitment or selection of natural persons, notably for advertising vacancies, screening or filtering applications, evaluating candidates in the course of interviews or tests"

And Annex III §4(b):

"AI systems intended to be used for making decisions affecting terms and conditions of work-related relationships, promotion or termination of work-related contractual relationships, for allocating tasks based on individual behaviour or personal traits or characteristics or for monitoring and evaluating performance and behaviour of persons in such relationships"

If your product does any of the following, you are almost certainly operating in Annex III §4:

• Parsing and ranking CVs or applications
• Scoring candidates against job requirements
• Shortlisting applicants automatically or semi-automatically
• Evaluating candidates during video interviews using AI
• Recommending candidates to hiring managers
• Automating rejection emails based on scoring
• Predicting employee performance or attrition
• Allocating shifts or tasks based on individual assessment

---

The "it's just a tool" defence does not work

The most common attempt to avoid classification is to describe the system as a "decision support tool" — a system that provides information to a human who makes the final decision.

This does not change the classification.

Annex III §4 applies to AI systems "intended to be used for" the listed activities. It does not require the system to make the final decision autonomously. If your AI ranks candidates, the ranking influences the human decision regardless of whether the human rubber-stamps it.

The European Parliament's deliberations on the Act explicitly considered and rejected exemptions for human-in-the-loop systems in high-stakes domains. The assumption built into the Act is that AI-generated rankings and scores influence human decisions, and that influence is what creates the risk.

---

The provider vs. deployer distinction

The EU AI Act distinguishes between who bears which obligations:

If you build the AI system and sell it (or licence it) to HR departments, you are the provider. The HR department is the deployer.

If you are a large company that built an AI system for your own internal HR processes, you are simultaneously provider and deployer.

When deployers become providers

Article 25 sets out conditions under which a deployer acquires provider obligations. This matters for companies that white-label or customise AI systems from third parties:

• If you substantially modify a third-party AI system (e.g., fine-tune a foundation model for your specific use case), you become the provider
• If you put a third-party system on the market under your own name, you become the provider
• If you change the intended purpose of a system in a way that makes it high-risk, you become the provider

Many companies that believe they are "just deployers" are actually providers under Article 25 because they have fine-tuned, customised, or rebranded a third-party model.

---

What high-risk provider status means in practice

Being a high-risk AI provider is not a death sentence for your product. It is a regulatory framework that requires you to document what you are already doing (or should be doing). The obligations are:

1. Annex IV technical documentation (Article 11)

You must create and maintain a technical documentation file covering eight sections defined in Annex IV: system description, design specifications, training data, validation results, monitoring plan, standards applied, change history, and cybersecurity measures.

This file must be accurate at the time of placing on the market and updated whenever the system is substantially modified. It is the file your enterprise buyers' security teams are now requesting.

2. Quality management system (Article 17)

You must document your processes for model development, testing, deployment, monitoring, and change management. This is closer to ISO 9001 than SOC 2 — it is about the process, not just the outcome.

3. Automatic logging (Article 12)

High-risk AI systems must be capable of automatically generating logs of each use of the system, including at minimum the period of operation, the reference database against which the system was verified, and any alerts or anomalies flagged.

4. Post-market monitoring (Article 72)

You must maintain a post-market monitoring system that actively collects and analyses data from deployed instances. Serious incidents must be reported to national market surveillance authorities.

5. Conformity assessment and CE marking (Articles 43–49)

Most HR-tech providers can conduct internal conformity assessment — no notified body required. Upon completion, you draw up an EU declaration of conformity and affix CE marking. This is not optional; it is a legal precondition for placing the system on the EU market.

6. EU database registration (Article 71)

High-risk AI systems must be registered in the EU's public AI database before being placed on the market.

---

The compliance timeline

You have until August 2026. That sounds comfortable. It is not.

A complete Annex IV technical file for a production AI system takes time to assemble properly — particularly the data governance documentation and the validated test reports. Companies that start in mid-2026 will be scrambling.

More practically: enterprise procurement timelines are already running ahead of the legal deadline. If your buyer's security team asks for your Annex IV file in 2025 — and they will — "we're working on it for 2026" is not an answer that closes the contract.

---

The commercial reality: documentation is now a sales asset

The companies that are winning enterprise AI deals in the EU right now are not the ones with the best models. They are the ones that can produce a complete, evidence-linked technical file in response to a security review request.

The typical enterprise security review for an HR-tech AI vendor now includes:

1. Request for GDPR Data Processing Agreement — most vendors have this
2. Request for ISO 27001 or SOC 2 report — most mature vendors have this
3. Request for EU AI Act technical documentation — almost nobody has a complete file

The third item is the new deal blocker. A self-completed questionnaire that says "yes, we validate our models" does not satisfy a security reviewer whose job is to verify claims independently. Evidence-linked documentation — where every claim links to a run log, a dataset, or a code path — does.

→ See Evidence-Based vs. Questionnaire Compliance for why assertion-based approaches fail security reviews, or run the free Readiness Check to assess your current file.

---

What to do now

1. Confirm your classification. If your product matches any of the Annex III §4 descriptions, you are a high-risk provider. Document the classification decision.

2. Inventory your existing evidence. Map what you already have: experiment logs, data sheets, test reports, monitoring dashboards. Most companies have more than they think — it is just not assembled into a coherent file.

3. Identify the gaps. The Readiness Check gives you a scored gap analysis in two minutes. The gaps that take longest to close are data governance documentation and reproducible test evidence.

4. Build the file continuously, not at deadline. The technical file is a living document. Start now, keep it updated with each model change, and you will never face a scramble before a renewal or a security review.

→ Start with the complete Annex IV requirements breakdown or jump straight to the Readiness Check.