Provider vs deployer obligations for hiring AI: who carries which duties?

When a hiring tool is classified high-risk under the EU AI Act, the next question is who is responsible for what. The Act does not put every duty on one party. It splits obligations between the provider that builds and supplies the AI system and the deployer that puts it to use. Getting that split right tells you exactly what to produce yourself and what to demand from your vendor. This is a practical orientation, not legal advice; for your specific situation, speak to your own advisers.

Who is the provider and who is the deployer?

A provider is the party that develops a high-risk AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer is the party that uses an AI system under its own authority in a professional capacity. [Source: artificialintelligenceact.eu, Articles 3, 16 and 26, accessed 2026-06-18.]

For most employers the mapping is straightforward. The recruitment software vendor is the provider. You, running their tool to screen, rank or score candidates, are the deployer. The reason the distinction matters is that each role carries a different and largely non-transferable set of duties.

What does the provider have to do?

Providers carry the heavier conformity burden, because they are closest to how the system is built. Before a high-risk system reaches the market the provider must, among other things, operate a risk management system across the lifecycle, meet data governance standards for training and testing data, produce technical documentation, ensure record-keeping and logging capability, achieve appropriate accuracy and robustness, enable human oversight by design, and run a conformity assessment before placing the system on the market. After launch they must run post-market monitoring and report serious incidents. [Source: artificialintelligenceact.eu, Articles 9 to 17, accessed 2026-06-18.]

Note what is not on this list: a vendor self-certification badge. The Act has no vendor self-certification scheme for high-risk systems; conformity is assessed under its defined route, not asserted on a marketing page. Treat any vendor badge that implies a third-party stamp of approval with caution, because no such scheme exists for them to rely on.

What does the deployer have to do?

Deployer duties sit in Article 26, and they are yours to discharge even though you did not build the tool. As a deployer of a high-risk hiring system you must, among other things:

• Use the system as instructed. Operate it in line with the provider's instructions for use.
• Assign competent human oversight. Put oversight in the hands of people with the competence, training and authority to exercise it properly.
• Mind the input data you control. Where you control input data, make sure it is relevant and sufficiently representative for the system's intended purpose.
• Monitor operation and escalate. Watch how the system performs, and where you identify a serious risk or an incident, inform the provider and the relevant authority.
• Keep the logs under your control. Retain the automatically generated logs for the period defined for high-risk systems.
• Inform the people affected. Where the system makes or assists decisions about candidates, tell them it is being used. Inform workers and their representatives before putting it into service in the workplace. [Source: artificialintelligenceact.eu, Article 26, accessed 2026-06-18.]

These are obligations on you, the employer, regardless of how good your vendor is.

Can I outsource the deployer duties to my vendor?

No, and this is the single most important point. The deployer duties in Article 26 attach to the party using the system under its own authority. A contract can allocate commercial risk between you and the vendor, but it does not transfer the legal duty to assign oversight, inform candidates, or keep your logs. If your process never has a human who can understand, question and overrule the AI output, no clause in a supplier agreement fixes that.

There is also a sharp edge worth knowing. If a deployer substantially modifies a high-risk system, or puts its own name on it, or changes the intended purpose, the deployer can be treated as a provider and pick up the heavier provider obligations too. [Source: artificialintelligenceact.eu, Article 25, accessed 2026-06-18.]

When do these duties bite?

The high-risk obligations covering hiring currently apply from 2 August 2026. [Source: artificialintelligenceact.eu, application timeline, accessed 2026-06-18.] A provisional Digital Omnibus agreement reached on 7 May 2026 would defer stand-alone Annex III systems, recruitment AI among them, to 2 December 2027, but it is not yet adopted, so as of 18 June 2026 the 2 August 2026 date still stands. [Source: Gibson Dunn, Travers Smith, EU AI Act Service Desk, accessed 2026-06-18.]

The timeline being in flux does not change your preparation. Vendor due diligence and oversight design take longer than the gap to either date, so start now.

How to act on the split in practice

Treat the split as a two-column to-do list. In the provider column, list what you must demand: technical documentation, instructions for use, evidence of bias testing, logging capability, and the conformity basis. A provider that cannot produce these is asking you to carry their risk. In the deployer column, list what only you can do: name and train your oversight reviewers, write the candidate disclosure, configure log retention, and stand up outcome monitoring.

Part of: EU AI Act and recruitment.

For whether your tool is in scope at all, read is hiring AI high-risk under the EU AI Act. For what real oversight requires, see human oversight requirements for AI in hiring.

The vendor's gaps become your operational risk, so evaluate them as carefully as you discharge your own duties.