When an employer buys an AI-powered assessment tool and uses it to screen job applicants, two distinct legal roles come into play under Regulation (EU) 2024/1689, the EU AI Act. One party built and placed the system on the market. Another party operates it day-to-day. The Act calls them the "provider" and the "deployer," and it assigns meaningfully different compliance obligations to each. Getting this wrong doesn't produce a minor paperwork gap. It produces situations where no one owns the incident response process, no one has retained the required logs, and no one can produce the technical documentation an auditor requests.
This guide maps those legal roles onto the real-world structure of recruitment technology, so that HR leaders, procurement teams, and their vendors can allocate obligations clearly before contracts are signed.
Article 3 of the EU AI Act (consolidated text available on EUR-Lex under Regulation (EU) 2024/1689) establishes the definitions that govern the entire regulation. The AI Act Service Desk, operated by the European Commission, provides a plain-language summary of these roles.
Provider (Article 3(3)): the natural or legal person, public authority, agency, or other body that develops an AI system or has one developed, and places it on the market or puts it into service under its own name or trademark.
In recruitment terms, this is the assessment vendor. If a company builds and commercially licenses AI-scored assessments, it's the provider. The branding test matters: if a third-party model is embedded and re-released under a different name, the re-releasing entity takes on provider obligations.
Deployer (Article 3(4)): the natural or legal person, public authority, agency, or other body that uses an AI system under its authority in a professional context. Personal, non-professional use is excluded (DLA Piper Intelligence, quoting Article 3(4)).
In recruitment terms, this is the employer or HR team configuring and running the assessment in its hiring funnel. The deployer doesn't need to have built anything. Using the system to score, rank, or recommend candidates is sufficient to trigger deployer status.
One organization can hold both roles simultaneously. An employer that builds a proprietary AI screening tool and then rolls it out internally is both provider and deployer across different parts of the Act.
The table below covers the most frequent configurations.
| Scenario | Likely provider | Likely deployer |
|---|---|---|
| Assessment vendor supplies AI scoring via ATS integration | Assessment vendor | Employer |
| ATS vendor bundles third-party assessment logic under its brand | ATS vendor, as re-branded provider | Employer |
| Employer configures custom scoring thresholds on vendor models | Assessment vendor, for the base system | Employer, including for the configuration decisions |
| Employer builds internal screening tool and deploys it to HR teams | Employer, as provider | Employer, as deployer |
The deciding questions are: who placed or branded the system into service, and who controls operational parameters and uses the outputs to make decisions about candidates? Those answers determine where obligations land.
Under Article 16, providers of high-risk AI systems (which recruitment assessment tools used for employment decisions typically qualify as) carry upstream compliance responsibilities before the system reaches any deployer. The AI Act Service Desk summarizes these as including:
For a procurement team evaluating an assessment vendor, this translates into a specific documentation request. Before go-live, the vendor should be able to produce its technical documentation package, a risk management file, its instructions for use, and evidence of its conformity process. If the vendor cannot produce these materials, that is a compliance signal, not just a procurement inconvenience.
Article 26 governs deployers of high-risk AI systems and covers operational compliance during use. Per the AI Act Service Desk, these obligations include:
The recruitment-specific implication: these are not IT department tasks. The obligation to ensure trained, authorized human reviewers can override or stop an automated recommendation belongs to HR and People leadership. A CHRO cannot delegate Article 26 governance entirely to a technical team without retaining process ownership over who reviews outcomes and under what conditions a decision is escalated or reversed.
Several compliance controls don't fall cleanly on one side. Candidate transparency (informing applicants they're subject to an AI-based decision), log retention, incident reporting workflows, and change control when recruitment policies shift all require coordination between vendor and employer.
A practical RACI framework assigns the provider responsibility for drafting instructions for use and supplying compliance documentation; the deployer approves internal governance structures and operates human oversight processes; and both parties share incident escalation paths with defined SLA timelines.
Contract provisions worth including:
One point that often gets missed: threshold configuration is a compliance decision, not just a product setting. If an employer lowers a cut-score or adjusts ranking weights, that changes the system's operational behavior in ways that can affect fairness and defensibility. Contracts should specify that configuration changes require documented validation before being applied in production. On the candidate-facing side, our guide to communicating AI use transparently to candidates covers what the disclosure itself should say.
For vendors (providers):
For employers (deployers):
Evidence to request before signing a contract:
Compliance documentation is not something to gather after a system goes live. For organizations working with an assessment partner on a 2-to-10-week implementation timeline (a realistic window for integrated tools like Selection Lab's AI-driven assessment platform, which connects SmartChat candidate intake, skills assessments, and ATS reporting into a single workflow), the compliance paperwork exchange should happen in parallel with technical integration, not after it. Waiting until users are live to request a provider's technical documentation creates a gap that is difficult to close retroactively.
Classification of roles under the EU AI Act is fact-specific. Branding arrangements, contractual structures, and the degree of control each party exercises over the system's operation can all shift who holds which responsibilities. Legal counsel should be consulted for any case where the role classification is ambiguous, particularly where ATS vendors, assessment vendors, and employer configuration layers interact.
When an employer buys an AI-powered assessment tool and uses it to screen job applicants, two distinct legal roles come into play under Regulation (EU) 2024/1689, the EU AI Act. One party built and placed the system on the market. Another party operates it day-to-day. The Act calls them the "provider" and the "deployer," and it assigns meaningfully different compliance obligations to each. Getting this wrong doesn't produce a minor paperwork gap. It produces situations where no one owns the incident response process, no one has retained the required logs, and no one can produce the technical documentation an auditor requests.
This guide maps those legal roles onto the real-world structure of recruitment technology, so that HR leaders, procurement teams, and their vendors can allocate obligations clearly before contracts are signed.
Article 3 of the EU AI Act (consolidated text available on EUR-Lex under Regulation (EU) 2024/1689) establishes the definitions that govern the entire regulation. The AI Act Service Desk, operated by the European Commission, provides a plain-language summary of these roles.
Provider (Article 3(3)): the natural or legal person, public authority, agency, or other body that develops an AI system or has one developed, and places it on the market or puts it into service under its own name or trademark.
In recruitment terms, this is the assessment vendor. If a company builds and commercially licenses AI-scored assessments, it's the provider. The branding test matters: if a third-party model is embedded and re-released under a different name, the re-releasing entity takes on provider obligations.
Deployer (Article 3(4)): the natural or legal person, public authority, agency, or other body that uses an AI system under its authority in a professional context. Personal, non-professional use is excluded (DLA Piper Intelligence, quoting Article 3(4)).
In recruitment terms, this is the employer or HR team configuring and running the assessment in its hiring funnel. The deployer doesn't need to have built anything. Using the system to score, rank, or recommend candidates is sufficient to trigger deployer status.
One organization can hold both roles simultaneously. An employer that builds a proprietary AI screening tool and then rolls it out internally is both provider and deployer across different parts of the Act.
The table below covers the most frequent configurations.
| Scenario | Likely provider | Likely deployer |
|---|---|---|
| Assessment vendor supplies AI scoring via ATS integration | Assessment vendor | Employer |
| ATS vendor bundles third-party assessment logic under its brand | ATS vendor, as re-branded provider | Employer |
| Employer configures custom scoring thresholds on vendor models | Assessment vendor, for the base system | Employer, including for the configuration decisions |
| Employer builds internal screening tool and deploys it to HR teams | Employer, as provider | Employer, as deployer |
The deciding questions are: who placed or branded the system into service, and who controls operational parameters and uses the outputs to make decisions about candidates? Those answers determine where obligations land.
Under Article 16, providers of high-risk AI systems (which recruitment assessment tools used for employment decisions typically qualify as) carry upstream compliance responsibilities before the system reaches any deployer. The AI Act Service Desk summarizes these as including:
For a procurement team evaluating an assessment vendor, this translates into a specific documentation request. Before go-live, the vendor should be able to produce its technical documentation package, a risk management file, its instructions for use, and evidence of its conformity process. If the vendor cannot produce these materials, that is a compliance signal, not just a procurement inconvenience.
Article 26 governs deployers of high-risk AI systems and covers operational compliance during use. Per the AI Act Service Desk, these obligations include:
The recruitment-specific implication: these are not IT department tasks. The obligation to ensure trained, authorized human reviewers can override or stop an automated recommendation belongs to HR and People leadership. A CHRO cannot delegate Article 26 governance entirely to a technical team without retaining process ownership over who reviews outcomes and under what conditions a decision is escalated or reversed.
Several compliance controls don't fall cleanly on one side. Candidate transparency (informing applicants they're subject to an AI-based decision), log retention, incident reporting workflows, and change control when recruitment policies shift all require coordination between vendor and employer.
A practical RACI framework assigns the provider responsibility for drafting instructions for use and supplying compliance documentation; the deployer approves internal governance structures and operates human oversight processes; and both parties share incident escalation paths with defined SLA timelines.
Contract provisions worth including:
One point that often gets missed: threshold configuration is a compliance decision, not just a product setting. If an employer lowers a cut-score or adjusts ranking weights, that changes the system's operational behavior in ways that can affect fairness and defensibility. Contracts should specify that configuration changes require documented validation before being applied in production. On the candidate-facing side, our guide to communicating AI use transparently to candidates covers what the disclosure itself should say.
For vendors (providers):
For employers (deployers):
Evidence to request before signing a contract:
Compliance documentation is not something to gather after a system goes live. For organizations working with an assessment partner on a 2-to-10-week implementation timeline (a realistic window for integrated tools like Selection Lab's AI-driven assessment platform, which connects SmartChat candidate intake, skills assessments, and ATS reporting into a single workflow), the compliance paperwork exchange should happen in parallel with technical integration, not after it. Waiting until users are live to request a provider's technical documentation creates a gap that is difficult to close retroactively.
Classification of roles under the EU AI Act is fact-specific. Branding arrangements, contractual structures, and the degree of control each party exercises over the system's operation can all shift who holds which responsibilities. Legal counsel should be consulted for any case where the role classification is ambiguous, particularly where ATS vendors, assessment vendors, and employer configuration layers interact.
