What Is a Deployer Under the AI Act?

Most companies adopting AI see themselves as users, not as regulated entities. But the EU AI Act singles out the user with a specific name – deployer – and attaches obligations to that role. Understanding when you become a deployer is the first step to getting it right.

The Definition – and the Line Against the Provider

A deployer is whoever uses an AI system in its operations. The provider is whoever develops the system and places it on the market. So you don’t need to have built any model to be covered: as soon as a model is put into use in your operations, your company is a deployer.

That applies even when the AI was bought as an off-the-shelf productivity tool. The fact that the tool is purchased and “only” used to draft or summarize doesn’t change anything – it’s the use that triggers the role. Many companies miss this and assume the responsibility lies entirely with the provider.

Obligations That Can’t Be Delegated

As a deployer, there are a number of obligations that fall on you, regardless of what the provider commits to in its contract. They can’t be contracted away:

• AI literacy among the staff who use the system.
• Human oversight of high-risk systems, so a human can understand and intervene.
• Logs for at least six months covering the system’s use.
• Informing employees before the system is put into operation.
• Transparency toward those affected – people impacted by the system’s output need to be able to find out about it.

The point is that responsibility for how the AI is used in your specific operations is yours, not the provider’s. The provider can assist, but the obligations come with the deployer role.

Several of these points are more concrete than they first sound. AI literacy doesn’t mean a formal certification, but that the people actually using the system understand what it can and can’t do – that a language model can sound confident and still be wrong, and when an answer needs to be checked. Human oversight is about a human being able to follow, question, and where necessary override the system’s output in a high-risk context, not just nominally “having a human in the loop.” And the logging requirement assumes you’re collecting logs at all – something that needs to be solved technically before the system goes into operation, not after the fact.

The Rule of Thumb: When Does It Become High-Risk?

Not all AI systems are regulated equally strictly, and a rule of thumb helps here. An internal productivity chatbot – for drafting, summarizing meetings, or searching documents – is, as a rule, not a high-risk system.

It only becomes one once the output is used in a process the Act designates as high-risk in its Annex III. Two classic examples are recruitment and credit scoring. Once the chatbot’s answers start determining who gets called in for an interview or who’s granted credit, Article 26 kicks in with its stricter requirements.

A concrete scenario makes the difference clear: the same AI assistant is a low-risk tool when HR uses it to draft job ads, but high-risk in the sense of the Act if it’s used to rank and screen candidates. It’s the use of the output, not the tool itself, that determines which level of requirements applies.

What This Means in Practice

For most companies, this means broad, internal AI use can be handled with reasonable routines: literacy, informing staff, and basic logging. But the moment AI is plugged into an Annex III area, you need to raise your game and meet the high-risk requirements.

Mapping where in your operations the AI’s output is actually used is therefore the most important exercise. That’s where the line between low-risk and high-risk falls – and where Article 26 is either irrelevant or absolutely central.

One more thing worth keeping in mind: the EU AI Act is phased in gradually, and different parts take effect at different times. Exactly which requirements are in force when therefore changes over time, and the same goes for the guidance supervisory authorities and EU bodies produce. Build your compliance on the Act’s roles and principles – who is a deployer, where the output is used, what can’t be delegated – rather than on a snapshot of which dates apply, and check the current status when you plan a rollout. The deployer role is the fixed point; the requirement level and the timeline are what you need to keep updated.

If you’d like to see how the deployer role connects to data protection, residency, and vendor choice across a full AI project, there’s more on our AI page. Need help figuring out where your AI use lands under the Act? Get in touch.