EU AI Act Requirements for Companies That Build or Sell Recruitment Software

Guide18 June 2026· 17 min read

EU AI Act recruitment software requirements for vendors: why Annex III point 4 makes your tool high-risk, plus the build stack, conformity and CE marking.

You build a CV-ranking tool. You sell it to employers under your own name. Under the EU AI Act that tool is high-risk, and the full provider obligation stack must be satisfied before you can lawfully place it on the EU market — not after the first sale, not when a customer asks. Classification, an Article 9–15 build stack, technical documentation, conformity assessment, CE marking, and registration are a go-to-market gate.

This page is the recruitment-software vendor's product-launch playbook: what you must build in, in what order, to ship a hiring tool lawfully in the EU.

Why this guide is for the vendor, not the employer

The EU AI Act assigns obligations by role. A provider under Article 3(3) is the entity that develops an AI system — or has it developed — and places it on the market or puts it into service under its own name or trademark. A deployer under Article 26 is the entity that uses the system. If your company writes, packages, and sells recruitment, CV-screening, or candidate-ranking software, you are the provider, and Article 16 sets out your stack. The hiring employer who buys your tool is the deployer with a separate, narrower set of duties.

The thesis of this page is blunt: because Annex III point 4(a) lists recruitment and selection AI as high-risk, building or selling such a tool triggers the full provider obligation stack before the product can lawfully ship. This is a launch gate, not a post-sale compliance chore.

Provider vs deployer: which one are you?

If you control the system's intended purpose and put your brand on it, you are the provider. The line matters because the two roles carry almost no overlapping work: providers build conformity in, deployers operate within the provider's instructions. The rest of this page assumes you are the provider.

What "placing on the market" means for a SaaS recruitment tool

For SaaS, "placing on the market" — or "putting into service" — happens when you first make the system available to a deployer in the EU, whether by subscription, licence, or hosted access. There is no shipped box. The obligations attach to first availability, so the conformity work has to be finished before your first EU customer can log in.

How this page differs from our other recruitment guides

We cover this sector from several angles. The recruitment screening AI classification page explains how a tool gets classified high-risk. The HR and recruitment use-case map maps the whole sector across prohibited, high-risk, and minimal-risk zones. The in-employment decision AI page covers point 4(b) promotion, termination, and monitoring tools. The provider vs deployer guide explains the roles generically. This page is the recruitment-vendor product-launch playbook — the build-and-ship sequence none of the others walk end to end.

One deadline note up front: plan against 2 August 2026 for stand-alone high-risk Annex III systems. A deferral to 2 December 2027 has been agreed but is not yet law as of June 2026. The deadline section below sets out exactly why.

What makes recruitment software high-risk under Annex III point 4

Annex III point 4(a): the exact wording

Annex III point 4(a) of Regulation (EU) 2024/1689 lists AI systems intended to be used for the recruitment or selection of natural persons — in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates. If your tool does any of those things, it is named in the high-risk list.

Article 6(2) and the intended-purpose test

Article 6(2) is the operative trigger: a system referred to in Annex III is high-risk. Classification follows the system's intended purpose as you, the vendor, define it — not how any single customer happens to use it. You cannot escape classification by pointing to a cautious customer; the purpose you market and design for governs.

When the Article 6(3) exemption actually applies to a vendor

Article 6(3) offers a narrow exemption: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights. A tool that only reformats CVs or checks that mandatory fields are filled may qualify. But the moment a system scores, ranks, profiles, or shortlists candidates, the exemption falls away — and Article 6(3) states plainly that a system performing profiling of natural persons is always high-risk. A vendor claiming the exemption must document the assessment and still register the system under Article 49.

Most commercial HR-tech marketed as "AI-assisted screening" profiles and ranks by design. The exemption rarely applies. Design choices, not marketing labels, decide classification.

The provider obligation stack: what you must build in (Articles 9–15)

This is the engineering work that has to exist inside the product and its paper trail before launch.

Risk management and bias — Articles 9 and 10

Article 9 requires a documented, iterative risk management system running across the system's lifecycle. For a recruitment model the dominant theme is discriminatory output — disparate rejection rates by gender, age, or national origin. That risk has to be identified, estimated, and mitigated, then re-checked as the model changes.

Article 10 governs data: training, validation, and test sets must be relevant, representative, and subject to error mitigation and active bias detection. Article 10(5) permits processing special-category personal data strictly where necessary to detect and correct bias, subject to safeguards — a narrow, explicit licence you should rely on deliberately rather than stumble into.

Documentation, transparency, oversight — Articles 11/Annex IV, 13, 14

Article 11, with Annex IV, requires technical documentation drawn up before market placement and kept current; under Article 18 it is retained for ten years.

Article 13 requires instructions for use that tell the employer-deployer the intended purpose, the candidate categories assessed, the ranking logic, the performance metrics, the limitations, and the human oversight required. This is a compliance artefact, not a sales brochure.

Article 14 requires human oversight by design. The product must expose its scoring rationale and let the recruiter override or disregard output. A black-box score-and-rank product with no override path fails Article 14. Full stop.

Accuracy across subgroups, QMS, and logs — Articles 15, 17, 19

Article 15 requires appropriate accuracy, robustness, and cybersecurity — including consistent performance across demographic subgroups. A model that is 90% accurate overall but 70% on women in technical roles has an Article 15 problem, not only an Article 10 one.

Article 17 requires a quality management system. Article 19 requires automatically generated logs to be kept for at least six months where the logs are under your control. Both feed post-market monitoring.

Annex IV technical documentation for a recruitment tool, section by section

Annex IV is abstract. Here is what each content area means for a hiring tool specifically.

Annex IV content area	What a recruitment-software vendor must write
§1 General description and intended purpose	The candidate populations and roles the system assesses; the markets and languages it is validated for
§2 Development and design choices	Model architecture, the ranking/scoring logic, and the design choices made to reduce discriminatory output
§2–3 Data and data governance	Training/validation/test dataset composition, provenance of the historical hiring data, and the bias-detection and mitigation measures (links to Article 10)
Performance metrics	Accuracy disaggregated by demographic subgroup — not just headline precision — the recruitment-specific evidentiary expectation
Human oversight	The oversight interfaces built for deployers under Article 14, including how a recruiter sees and overrides a score
Post-market monitoring	The monitoring plan under Article 72 covering the system's deployed lifetime

Mapping Annex IV to a CV-screening product

Work the table top to bottom. The intended-purpose section pins down who the tool assesses; the data section documents where your training data came from and how you tested it for bias; the oversight section describes the override UI. Each section should read as evidence, not aspiration.

Subgroup performance metrics: the recruitment-specific evidence

The single most distinctive expectation for hiring AI is subgroup-disaggregated performance. A market-surveillance authority assessing a recruitment model will look past the headline accuracy figure for how the system performs across gender, age bands, and other protected characteristics. Build that measurement into testing from the start; retrofitting it is expensive.

Why the technical file is the spine of everything else

The Annex IV file is the document an authority requests and the basis for your Article 47 Declaration of Conformity. Version-control it. Every later step — the declaration, the CE marking, the registration entry — points back to it.

Conformity assessment, declaration, CE marking, and registration before you ship

The Annex VI internal route (no notified body)

Recruitment AI sits in Annex III point 4, so under Article 43 it follows the Annex VI internal-control conformity assessment route. No notified body is required. This differs from certain Annex III point 1 biometric systems, which can require the Annex VII notified-body route. The Annex VI procedure: verify the system meets Articles 9–15, examine the technical documentation, and keep it available for ten years.

Declaration of Conformity, CE marking, EU database registration

Under Article 47, you draw up the EU Declaration of Conformity with the content set out in Annex V, in the official language(s) of each member state where the system is placed.

Under Article 48, you affix the CE marking — but only after the Article 43 assessment is complete. Article 48(4) prohibits affixing it earlier.

Under Article 49 and Annex VIII, you register the system in the EU database before placing it on the market. Registration is sequential and separate from conformity assessment. A vendor claiming the Article 6(3) exemption must register that finding too.

Post-market monitoring and incident reporting — Articles 72 and 73

Article 72 requires a post-market monitoring system for the system's lifetime. Article 73 requires reporting serious incidents to the market-surveillance authority within fixed timelines: 15 days generally, 2 days for widespread or critical-infrastructure harm, and 10 days where a person has died.

The Article 25 trap: building recruitment AI on a foundation model API

Why GPAI compliance does not pass through

Here is the trap. Article 25 provides that a company integrating a general-purpose AI model into a recruitment feature and shipping it under its own name becomes the provider of the resulting high-risk system — and inherits the full Article 16 stack. There is no compliance pass-through. A GPAI model being compliant at the model layer does not make your recruitment application compliant. The application layer needs its own Articles 9–15, 43, 47, 48, 49, 72, and 73.

Annex XII as an input to your technical file

The model vendor owes downstream builders technical information under Article 53 (the content set out in Annex XII) on the model's capabilities, limitations, and known risks. That is an input to your Annex IV file — not a substitute for it. You still author the recruitment-specific documentation, the subgroup metrics, and the oversight design.

Substantial modification and the role reset — Article 3(23), Article 25

Article 3(23) defines substantial modification. If you materially change a third-party system's risk profile or intended purpose, the modified system is treated as a new system placed on the market by you, resetting provider obligations onto your company. The takeaway is brand-neutral education on EU AI Act concepts: foundation models and GPAI are regulatory terms here, and using one in your build does not move your obligations onto the model vendor.

Worked example: a recruitment-software vendor's path to market

Take TalentSift GmbH, a 45-person Berlin HR-tech vendor selling a CV-ranking and shortlisting SaaS to employers across the DACH region. Here is the full provider path, concretely.

Step 1: classify and confirm the provider role

TalentSift's product analyses, filters, and ranks applicants. That is squarely Annex III point 4(a), so it is high-risk under Article 6(2). Article 6(3) does not rescue it, because the system profiles and ranks. TalentSift puts its own name on the tool, so it is the provider under Article 3(3) with the Article 16 stack.

Step 2: build the Article 9–15 stack and Annex IV file

TalentSift stands up an Article 9 risk file targeting disparate rejection rates; audits the historical client hiring data it trained on under Article 10; writes an Annex IV file with subgroup-disaggregated performance; and builds an Article 14 oversight UI that exposes the per-candidate scoring rationale and lets a recruiter override it.

Step 3: assess, declare, CE-mark, register — then sell

TalentSift runs the Annex VI internal conformity assessment, signs the Article 47 Declaration of Conformity, affixes the CE marking under Article 48, and registers the system under Article 49 — all before its first sale.

What the SME penalty cap means in euros

Breaching high-risk obligations falls under Article 99(4): up to €15 million or 3% of total worldwide annual turnover, whichever is higher. But Article 99(6) caps SMEs and start-ups at the lower of the two. With turnover around €3 million, TalentSift's exposure under the 3% ceiling is roughly €90,000, not €15 million. The cap is real proportionality protection — but the obligations still apply in full. TalentSift plans against 2 August 2026, treating the agreed-but-not-yet-law deferral as a contingency rather than a guarantee.

Deadlines and penalties for recruitment-software providers

The 2 August 2026 vs 2 December 2027 question

The statute reads 2 August 2026 for stand-alone high-risk Annex III obligations. The Digital Omnibus reached provisional political agreement on 6–7 May 2026 (COREPER confirmed the text around 13 May 2026) to defer this to 2 December 2027, but as of June 2026 it is not yet law — it still needs a European Parliament plenary vote, formal Council adoption, and publication in the Official Journal. Until then the statute legally still reads 2 August 2026. Plan against 2 August 2026 until the deferral is enacted.

The deferral is fixed calendar dates; the standards-contingent "stop the clock" variant was rejected. Not everything is delayed. Product-embedded high-risk under Annex I (Article 6(1)) has its own date of 2 August 2027, agreed to defer to 2 August 2028 — also not yet law, and a category that does not usually apply to stand-alone recruitment SaaS.

Penalty tiers under Article 99

Article 99(4) sets the headline tier for high-risk obligation breaches: up to €15 million or 3% of total worldwide annual turnover, whichever is higher. Article 99(5) sets a lower tier — €7.5 million or 1% — for supplying incorrect, incomplete, or misleading information to notified bodies or authorities. Article 99(6) caps SMEs and start-ups at the lower of the fixed sum or the percentage.

What already applies regardless of the high-risk deadline

The high-risk deadline does not defer everything. Article 5 prohibitions and Article 4 AI literacy obligations have applied since 2 February 2025. Recruitment vendors should confirm their product includes no banned function — in particular, no workplace emotion recognition, which is prohibited under Article 5(1)(f).

How Confir helps recruitment-software vendors get to market

Confir's classification engine walks a vendor through the Annex III point 4(a) and Article 6(2)/6(3) criteria in plain English and returns a determined risk tier and role — provider or deployer, high-risk or exempt.

For a provider, the output is the conformity package: a print-ready Article 11 / Annex IV technical documentation pack and an Article 47 / Annex V Declaration of Conformity, generated from the assessment intake.

The engine is deterministic and rule-based — no model inference, no hallucination. Same intake, same finding, and every rule that fired is human-readable. That matters when a market-surveillance authority asks why a system was classified high-risk and which obligations were triggered. Confir makes no AI claim about its own engine and does not market GPAI-provider compliance as complete.

Frequently Asked Questions

Does our recruitment software count as a high-risk AI system if a human always makes the final hiring decision?

Yes. Classification under Annex III point 4(a) follows the system's intended purpose, not who signs off. A tool intended to analyse, filter, rank, or evaluate candidates is high-risk even when a recruiter reviews every output. "Decision support" is not an exemption. Human oversight is a required control under Article 14 — it does not change what the system is. As the company that develops and sells the tool under your own name, you remain the provider under Article 3(3) with the full Article 16 obligation stack, regardless of how much the customer reviews.

We build a CV parser that only extracts and reformats data — are we still high-risk?

Possibly not, but tread carefully. Article 6(3) can exclude a tool that performs a narrow procedural task — pure reformatting or completeness checks — with no role in scoring or ranking. But the moment the system profiles, scores, ranks, or shortlists candidates, the exemption falls away, and Article 6(3) confirms any system that profiles natural persons is always high-risk. Most commercial parsers that feed a match score or shortlist do profile. If you claim the exemption, you must document the assessment and still register the finding under Article 49.

Do we need a notified body to certify our recruitment software before selling it?

No. Recruitment AI sits in Annex III point 4, so the conformity assessment follows the Annex VI internal-control route under Article 43 — you self-assess against Articles 9-15, examine your technical documentation, and keep it for ten years. A notified body is generally required only for specific cases such as certain Annex III point 1 biometric systems under Annex VII. After the internal assessment you draw up the Article 47 Declaration of Conformity, affix the CE marking under Article 48, and register the system under Article 49 before placing it on the market.

We use a third-party foundation model API for candidate matching — does that make the model vendor responsible?

No. Under Article 25, integrating a general-purpose AI model into a recruitment feature you ship under your own name makes you the provider of the resulting high-risk system, with the full Article 16 stack. The model vendor owes you technical information about the model (Annex XII under Article 53), and that feeds your Annex IV file — but it does not substitute for it. GPAI compliance covers the model layer only; your recruitment application needs its own Articles 9-15, 43, 47, 48, 49, 72, and 73.

What is the actual deadline for recruitment software to comply?

Plan against 2 August 2026. The EU AI Act statute reads 2 August 2026 for stand-alone high-risk Annex III systems. The Digital Omnibus reached provisional political agreement on 6-7 May 2026 (COREPER confirmed the text around 13 May 2026) to defer this to 2 December 2027, but as of June 2026 it is not yet law — it still needs a European Parliament plenary vote, formal Council adoption, and publication in the Official Journal. The deferral is fixed calendar dates, not a standards-contingent pause. Build to the earlier date until the deferral is enacted.

What documentation do we have to produce before we can sell the product?

Before placing the system on the EU market you need an Article 9 risk management file, Article 10 data-governance records, the Article 11 / Annex IV technical documentation (retained ten years under Article 18), Article 13 instructions for use, evidence of Article 14 oversight design and Article 15 accuracy and robustness testing, an Article 17 quality management system, and Article 19 logging. You then complete the Annex VI conformity assessment, sign the Article 47 Declaration of Conformity, affix the CE marking, and register under Article 49. Annex IV is the spine an authority will request.

What fines does a recruitment-software vendor face, and is there relief for smaller companies?

Breaching high-risk obligations falls under Article 99(4): up to €15 million or 3% of total worldwide annual turnover, whichever is higher. Supplying incorrect, incomplete, or misleading information to authorities is a lower tier under Article 99(5): €7.5 million or 1%. Crucially, Article 99(6) caps SMEs and start-ups at the lower of the fixed sum or the percentage — so a vendor with €3 million turnover faces roughly €90,000 under the 3% ceiling, not €15 million. The cap is real proportionality protection, but the obligations still apply in full.

Manage your EU AI Act compliance in one place

Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.

Start free trial →