Deployer or provider? Why this distinction matters more than you think

Many organisations think the EU AI Act does not apply to them. "We do not build AI, we only use it." While that may be true, it does not absolve you of responsibility. In the terminology of the AI Act you are then a "deployer", and that brings its own obligations.

Provider versus deployer: the difference

The EU AI Act distinguishes two main roles:

Provider: the party that develops, trains and places an AI system on the market. Think of OpenAI (ChatGPT), Microsoft (Copilot), or the supplier of your HR screening tool.

Deployer: the party that uses an AI system for its own purposes. That is you, if your organisation uses Copilot, has an AI chatbot on your website, or uses a recruitment tool that screens CVs.

While this distinction sounds straightforward, practical borderline cases can have significant consequences for your legal obligations.

Why almost every organisation is a deployer

Does your organisation use Microsoft 365 with Copilot? Then you are a deployer. Do your staff have access to ChatGPT or Gemini? Deployer. Is there a chatbot on your website? Deployer. Does your HR department use a tool that screens or ranks CVs? Deployer, and of a high-risk AI system at that.

The threshold is low. As soon as you use an AI system in your organisation, even if it was made by someone else, you will usually be a deployer. Which obligations follow depends on the risk category and the way the system is used.

This can also apply to unauthorised use. If an employee uses a free ChatGPT account for work tasks, especially without policy, training or controls, that can still create deployer-related responsibility and organisational risk. Moreover, data entered into a personal account may, depending on the tool, account type, settings and contract, be used to improve the model. That is not only a deployer matter, but also a possible GDPR problem, including unlawful processing or, in some cases, a data breach. Shadow AI, meaning AI use that stays under the radar, can make you a deployer without you realising it.

The obligations of a deployer

Deployers have fewer obligations than providers, but there are more of them than most organisations think:

AI literacy (Article 4): you must take measures that support the AI literacy of your staff, so that they know what they are doing when they work with AI. This basic obligation has applied since 2 February 2025 and affects every organisation that uses AI. What demonstrably meeting Article 4 requires of you, we set out elsewhere.

Transparency (Article 50): for certain AI systems you must inform those affected that AI is being used. Applicants must be informed where high-risk AI is used in recruitment, including under the deployer duties for workplace use. Citizens must know when they are interacting with an AI chatbot, unless that is obvious.

Human oversight (Article 26): for high-risk AI (recruitment, education, healthcare, public services) there must always be a human who takes the final decision or can intervene.

Logging and monitoring (Article 26): you must keep track of how your AI systems are used, and be able to show what happened in the event of an incident.

Risk assessment (Article 27): for certain deployers and certain high-risk AI systems, Article 27 requires a Fundamental Rights Impact Assessment, especially in public-sector and essential-service contexts.

When do you change from deployer into provider?

Here is the nuance many organisations miss. Article 25 of the AI Act describes three situations in which a deployer automatically becomes a provider, but only for high-risk AI systems:

For systems that are not high-risk, Article 25 does not automatically shift the deployer into the provider role. But the general provider definition in Article 3 can still apply if you develop an AI system, have it developed, or place it on the market or put it into service under your own name.

A concrete example

Suppose you have a business that sells nutritional advice. On your website you place a chatbot that advises visitors about losing weight: "Ask our AI coach". Under the bonnet, ChatGPT is running. You present it to the outside world as your own service.

Are you now a provider?

Not necessarily. A nutritional-advice chatbot is not a high-risk AI system under the AI Act (Annex III), so Article 25 does not automatically make you the provider merely because you present it under your own service name. But you still need to assess whether, under the general provider definition, you have created or put into service your own AI system. In any case, Article 50 (you must clearly communicate that it is an AI, not a human) and Article 4 (your staff must be AI-literate) remain relevant.

Turn the example around: you run a recruitment agency and you rebrand an AI CV screener from a supplier as "OurHR-AI" and offer it to end clients. Then you are a provider, with all the obligations that entails. Why? CV screening is in Annex III as a high-risk AI application. High-risk AI plus your own name makes you a provider under Article 25(1)(a).

Another example: a healthcare organisation that fine-tunes a language model on its own patient data and deploys it as a diagnostic assistant. That may be high-risk AI, for example if it qualifies as a medical device or safety component under MDR/IVDR, or falls under a relevant Annex III use case. If the fine-tuning amounts to a substantial modification, provider obligations may follow.

And what about fine-tuning?

Fine-tuning is often mentioned as the great danger through which organisations unintentionally become providers. The reality is more nuanced. On 10 July 2025, the European Commission published guidelines for providers of general-purpose AI models (GPAI). Those guidelines are not legally binding, only the Court of Justice can interpret the law bindingly, but they do give an indicative criterion: a fine-tuner of a general-purpose AI model in principle only becomes a provider when the modification uses more than a third of the original training compute. SMEs almost never reach that threshold, they usually use light RAG or prompt-engineering techniques, not massive retraining. This criterion concerns provider status for general-purpose AI models. It does not replace the separate Article 25 analysis for high-risk AI systems.

In short: fine-tuning does not automatically make you a provider. Deploying it for a high-risk purpose, or rebranding a high-risk AI system, does.

The fines: what is really at stake?

The EU AI Act has a tiered fine system (Article 99):

The highest ceiling of 35 million euros or 7% is therefore reserved solely for the prohibited practices of Article 5. For all other obligations, including the provider and deployer obligations this article is about, the lower ceiling applies.

For comparison: the GDPR has a maximum of 20 million euros or 4%. So the heaviest AI Act ceiling goes beyond that.

Two important nuances:

For SMEs and startups, the lower of the two amounts applies, not the higher. An SME with 2 million euros in turnover therefore risks at most 140,000 euros for the heaviest infringement, not 35 million. Though still a substantial amount, it at least keeps the penalty proportional.

Article 4 (AI literacy) has no separate direct fine. Article 99 does not name Article 4 among the specifically fineable infringements, and so there is no EU fine schedule of its own. Member states can, however, impose proportionate penalties under national rules. Moreover, a lack of AI literacy is treated as an aggravating factor in other infringements. If your organisation has an AI incident and a supervisory authority establishes that your staff never had AI literacy training, that weighs heavily in the penalty that follows. The argument "we did not know any better" does not work if you cannot demonstrate that you trained your staff.

What you must do now

Step 1: Determine your role per AI system. Go through your AI systems and assess for each one: am I a deployer, or have I triggered one of the Article 25 triggers?

Step 2: Inventory your obligations. As deployer of a non-high-risk AI system (spam filter, translation tool, productivity chatbot) your obligations are limited to AI literacy and, where relevant, transparency. For high-risk AI systems, much more is involved.

Step 3: Check for unintended provider status. Have you rebranded high-risk AI under your own name? Changed its purpose? Modified it substantially? Then you must review your compliance position.

Step 4: Train your staff. Article 4 applies to all organisations that use AI. Your IT administrators must also know the difference between provider and deployer, so that they do not unnoticed cross the line during implementations.

Step 5: Document and prove. You must be able to demonstrate your own compliance steps. An overview of who followed which training, with certificates per employee that list the learning outcomes and the AI Act articles covered, is the most concrete way to demonstrate that you have met your Article 4 obligation.

In closing

The EU AI Act is not written to hold back innovation. It is written to make sure that AI is used safely and responsibly. As a deployer you do not have to panic, but you do have to know what your role is, what your obligations are, and where the line lies.

The difference between an organisation that understands this and one that does not can amount to serious fines and reputational damage.

Do you want to know whether your organisation is a deployer or a provider? Our AI literacy training covers this in detail in Module 4 (IT/Technical). See our training or download the free compliance checklist.