EU AI Act: what it is, who it binds and what it means for your HR tech

Most companies that fall within the scope of the AI Act do not know it yet. Almost everything written about the regulation talks about foundation models and existential risk, and very little about the concrete case that is actually in the text: software that filters CVs. This guide is about that.

What the AI Act is and who it binds

The AI Act is Regulation (EU) 2024/1689, adopted in June 2024. It is the first horizontal artificial intelligence framework in the world: it does not regulate a specific sector, it regulates AI systems according to the risk their use creates for health, safety and fundamental rights. Being a regulation, it applies directly across every member state with no need for national transposition.

The regulation distinguishes two main roles, defined in Article 3, and obligations differ substantially depending on which one applies to you:

• Provider: whoever develops an AI system and places it on the market or puts it into service under its own name or trademark. It carries the bulk of the obligations when the system is high risk: risk management, data governance, technical documentation, logging, human oversight and conformity assessment.
• Deployer: whoever uses the system under its authority in its professional activity. Its obligations are lighter but real: use the system in line with the instructions, ensure human oversight and inform the people affected.

The regulation has extraterritorial reach. It also binds companies outside the European Union when they place a system on the EU market, put it into service here, or when its output is used within the Union. Being incorporated in Delaware or London does not take you out of scope if your customers recruit in Europe.

There is also one obligation that applies to everyone, providers and deployers alike, whatever the risk level: Article 4 requires ensuring a sufficient level of AI literacy among the staff dealing with the operation and use of these systems. It has been in force since 2 February 2025.

The four risk levels

The AI Act does not classify technologies, it classifies uses. The same language model can sit in minimal risk inside an internal documentation assistant and in high risk inside a product that scores candidates. The pyramid has four levels:

A single product can have pieces at different levels. An ATS with a candidate-facing chatbot, a matching engine and a job description generator is touching three cells of that table at once. Classification is done per system and per intended purpose, not per company.

Why HR tech is squarely in scope

Employment is not an expansive reading of the regulation: it is an express entry. Annex III, point 4, includes among high-risk systems those intended for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter applications and to evaluate candidates. The same point covers systems intended to make decisions on promotion or termination of contractual relationships, to allocate tasks and to monitor and evaluate performance and behaviour.

Translated into product features, that reaches things that are standard in any HR tech today:

• Automated CV screening that rejects or flags applications before a human sees them.
• Matching engines that rank a list of candidates by fit with the vacancy.
• Interview copilots that transcribe, summarise and score the person being interviewed.
• Publication of job advertisements targeted at specific population segments.
• Continuous performance evaluation or task allocation tools already inside the company.

The consequence is uncomfortable but clear: if you sell recruitment software with AI in it, the default position is that you are in Annex III. The relevant question is not whether the regulation applies to you, but whether you can justify in writing that a specific system of yours falls outside it.

The Article 6.3 exception and why it is narrower than it looks

Article 6.3 allows a system listed in Annex III not to be considered high risk when it does not pose a significant risk of harm to health, safety or fundamental rights, and in particular when it does not materially influence the outcome of decision making. The article itself lists the cases:

• The system performs a narrow procedural task.
• The system improves the result of a previously completed human activity.
• The system detects decision-making patterns or deviations from prior patterns, without replacing or influencing the human assessment already carried out.
• The system performs a preparatory task for an assessment.

There are two reasons why this door is narrower than people usually assume. The first is the profiling cut-off: the exception never applies if the system performs profiling of natural persons. A good share of matching engines build exactly that, an inferred profile of the candidate from their data, even if internally you call it scoring or fit.

The second is the ranking argument. It is common to argue that a matching engine only sorts and that the decision remains with the recruiter. In practice, if the system returns 400 ranked candidates and the recruiter opens the first ten, the ranking decided. Material influence on the outcome is measured by the real effect on the decision, not by where the final button sits.

And even if you conclude that the exception applies, it is not a silent self-exemption: the provider must document its assessment before placing the system on the market. Article 6.3 does not remove the analysis work, it turns it into a document you will have to show.

Provider or deployer: Article 25

Many engineering teams assume that because the model belongs to someone else, so do the obligations. Article 25 says otherwise. A deployer, distributor or importer is considered to be a provider of a high-risk system, with everything that entails, in three cases:

• It puts its name or trademark on a high-risk system already placed on the market.
• It makes a substantial modification to a high-risk system already on the market or in service.
• It modifies the intended purpose of an AI system, including a general-purpose one, in a way that makes it high risk.

The typical HR tech case is "we only call the OpenAI API". If you wrap that model in your product, sell it under your brand and give it a purpose of screening or evaluating candidates, you are in the first and the third case at the same time. The heaviest obligations then travel with you and not with the lab that trained the model, and you will need enough technical information from it to be able to meet them.

The real timeline, including the Digital Omnibus deferral

The AI Act did not become applicable all at once: each block of obligations has its own date, and in 2026 that timeline moved. This is the current state:

The provisional Digital Omnibus agreement of 7 May 2026 introduced the first amendments to the AI Act and deferred the Annex III obligations by sixteen months, from 2 August 2026 to 2 December 2027. The reason was technical: the harmonised standards being prepared by CEN and CENELEC through committee JTC 21 were not ready, and might not be ready before December 2026. Without a published standard there is no presumption of conformity.

That presumption is often misread. Whoever develops in line with a harmonised standard enjoys a presumption of conformity with the corresponding requirements of the regulation, but only once that standard has been published in the Official Journal of the European Union. Working from a draft is prudent and saves redoing the work, but it grants no presumption at all.

In Spain, the Spanish Agency for the Supervision of Artificial Intelligence (AESIA) has full capacity to inspect, request evidence and impose penalties since 2 August 2026. Spanish law splits competences between AESIA and other authorities depending on the domain: the data protection authority AEPD, the General Council of the Judiciary, the Bank of Spain and the securities regulator CNMV. Top-tier fines reach 35 million euros.

What this means in practice for your HR tech

Here is the point that usually gets missed. The Omnibus deferral moved the date of the legal obligation, but not the date on which your customer asks. Procurement questionnaires and enterprise due diligence already include AI Act questions, because the buyer in turn needs to answer to its own risk function. A contract stalled by an unanswered questionnaire is a problem this quarter; a 2027 penalty can be planned for.

What those questionnaires ask is fairly consistent:

• Risk classification of the system and a written justification, including the Article 6.3 assessment if you rely on the exception.
• Your role in each system, provider or deployer, and how you determined it in light of Article 25.
• Inventory of models and versions in production, including third-party ones and dependencies on their APIs.
• What data is used to train or fine-tune and what bias testing has been carried out on the outputs.
• How human oversight is implemented: what the person sees, what they can change and whether it is logged.
• Traceability: which events are logged, how long they are retained and whether they allow a decision to be reconstructed months later.
• What the candidate is told and when, and how it fits with the GDPR: legal basis, Article 22 and the impact assessment.

The difference between answering that well or badly is rarely technological. It is documentary. Teams that get stuck do not have a worse system, they have the same information spread across the heads of two engineers, an outdated Notion page and a repository with no inventory. What has to be produced is verifiable evidence, not statements of intent.

What the AI Act is not

Three misunderstandings come up in almost every conversation, and all three lead to spending money in the wrong place:

• It is not a certification. There is no "AI Act certified company" badge you can buy and display on your website. For high risk what exists is a conformity assessment and the CE marking, and the technical route to evidence it will be the harmonised standards once they are published.
• It does not ban AI in human resources. It bans specific practices under Article 5, such as inferring the emotions of a person in the workplace except for medical or safety reasons, and subjects the remaining recruitment uses to quality, documentation and oversight requirements. Using AI for hiring is lawful if it is done with the controls the regulation demands.
• It does not replace the GDPR. They apply in parallel. A recruitment process involves personal data of candidates, frequently an automated individual decision within the meaning of Article 22 GDPR and, almost always, the need for an impact assessment. In Spain, AESIA supervises the AI Act and the AEPD supervises data protection.