There is one classification question in the EU AI Act that will shape more of your compliance work than any other. It is not the risk tier. It is not the sector. It is: are you a provider or a deployer?
The distinction matters because providers and deployers have entirely different obligations. Providers carry the heavy load: risk management systems, technical documentation, conformity assessments, CE marking, post-market monitoring. Deployers have lighter obligations, but they are still significant, and they can shift dramatically depending on what the deployer actually does with the system. And crucially, a deployer can become a provider without realising it, by modifying a system in specific ways or by putting their own name on it.
This article walks through the distinction, the specific obligations on each side, the cases that reclassify a deployer as a provider, and the practical implications for enterprises that are almost always both.
The definitions
Article 3 of the Act provides the definitions. I will translate.
A provider is a natural or legal person, public authority, agency, or other body that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under their own name or trademark, whether for payment or free of charge.
A deployer is a natural or legal person, public authority, agency, or other body using an AI system under its authority, except where the use is a personal non-professional activity.
Read carefully. The provider is the entity whose name is on the system as it enters the market. The deployer is the entity using the system in the course of its work. Both roles are professional. Both can attach to any organisation.
Two things follow immediately. First, most large organisations are both. They build some systems, they buy others, and they use both. Second, the “under their own name or trademark” language matters. If you take an existing model, rebrand it, and put it into service in your organisation, you may have become a provider even if you did not build the underlying technology.
Article 25 elaborates on how a deployer can become a provider. There are three specific triggers.
The first trigger is putting your own name or trademark on a high-risk system already on the market. This includes rebranding a purchased solution as your own product.
The second trigger is making a substantial modification to a high-risk system already on the market such that it remains a high-risk system. What counts as substantial is a live question and will be shaped by implementing acts, but the general principle is that if the modification changes the system’s intended purpose or its risk profile materially, it is substantial.
The third trigger is modifying the intended purpose of an AI system that was not classified as high-risk in such a way that it becomes high-risk. This is the trap most enterprises walk into. You buy a GPAI-based tool marketed for one purpose; you deploy it for a different purpose that lands it in Annex III; you are now the provider.
Provider obligations
If you are a provider of a high-risk AI system, the substantive obligations from articles 8 through 15 of the Act apply directly to you. Let me summarise what this looks like operationally.
You are responsible for the risk management system. It has to run through the entire lifecycle, from design through decommissioning, and it has to identify, analyse, evaluate, and mitigate risks that could materialise for health, safety, and fundamental rights.
You are responsible for data governance. Your training, validation, and testing data must meet quality criteria. You must document data sources, collection methods, and preparation. You must examine data for biases and mitigate them. You must document what you have done and why.
You are responsible for technical documentation meeting Annex IV requirements. This documentation must exist before the system is placed on the market, and it must be updated as the system evolves. It has to be made available to national competent authorities and to notified bodies on request.
You are responsible for conformity assessment before placement. For most Annex III systems, this can be an internal assessment; for some, it must involve a notified body. Successful assessment is documented in a signed EU declaration of conformity and evidenced by CE marking on the system.
You are responsible for registration in the EU database of high-risk AI systems. This is a public database. Registration includes the system’s identification, its intended purpose, and its provider.
You are responsible for post-market monitoring. You have to design a monitoring plan appropriate to the system, actively collect data on its performance in the field, and take action when the monitoring reveals problems.
You are responsible for serious incident reporting. Incidents that cause or could cause serious harm must be reported to national competent authorities within specified timeframes.
You are responsible for quality management, running through your organisation’s technical, personnel, and organisational structure to ensure ongoing compliance.
You are responsible for cooperation with authorities on request. This includes access to your system, your documentation, and your operations.
This is a substantial list. It is why, for many organisations, staying a deployer is the strong preference where it is legitimately possible.
Deployer obligations
Deployer obligations under Article 26 are lighter but not trivial. They also expanded modestly under the Digital Omnibus. Let me summarise.
You must use the system in accordance with the instructions for use provided by the provider. This sounds simple. In practice, it means reading the instructions, following them, and documenting that you have done so.
You must implement human oversight in the way the provider’s instructions specify. If the provider says the system requires human review before decisions are acted upon, you have to actually run that review. If the provider says particular use cases are outside the system’s intended purpose, you have to actually not use it for those.
You must ensure the input data you feed the system is relevant and sufficiently representative for its intended purpose. Bad inputs produce bad outputs, and the deployer carries responsibility for the inputs it provides.
You must monitor the operation of the system based on the instructions and notify the provider of risks or serious incidents.
You must maintain the automatic logs generated by the system for at least six months (unless a longer period applies under other law).
For high-risk systems deployed to make decisions affecting individuals, you must inform those individuals that they are subject to the use of a high-risk AI system.
For certain high-risk systems, particularly those used by public authorities and those making decisions with significant effects on individuals, you must conduct a Fundamental Rights Impact Assessment (FRIA) under Article 27. The FRIA is not the same as a GDPR Data Protection Impact Assessment, though they overlap. It focuses specifically on fundamental rights risks.
You must cooperate with authorities in the same way providers must.
If you procure high-risk systems from providers, you carry procurement due diligence responsibility. You need to satisfy yourself that the provider has done what the Act requires. Contract terms should reflect this.
Figure 1: When a deployer becomes a provider
Figure 1 shows the three specific triggers under Article 25 that convert a deployer into a provider. Each trigger is illustrated with a representative enterprise scenario. Notice how ordinary each scenario is. Rebranding a purchased chatbot as your customer service assistant. Fine-tuning a foundation model on your data to change what it does. Deploying a general-purpose LLM in a hiring workflow. Each of these is common enterprise practice, and each can move you from deployer to provider without you noticing.
The fine-tuning trap
The scenario that catches the most organisations is fine-tuning.
Foundation models are marketed as general-purpose tools. You take one, fine-tune it on your data, and deploy it. Are you still a deployer, or have you become a provider?
The answer, unhelpfully but honestly, is “it depends.” The Act and the emerging AI Office guidelines look at what the fine-tuning actually did. Modest fine-tuning that adapts the model to your organisation’s tone or terminology without changing its intended purpose or capabilities is unlikely to make you a provider. Substantial fine-tuning that changes what the model can do, expands its capabilities, or changes its intended purpose is likely to trigger provider status.
The line is not always clear. Retrieval-augmented generation, where the model is unchanged but is grounded in your documents, is generally not fine-tuning in the substantive sense. Adapter-based tuning that adjusts specific behaviours may or may not trigger. Full fine-tuning that changes the weights of the model substantially is more likely to trigger.
If you are unsure, the pragmatic answer is to plan as if you have triggered. The cost of getting this wrong (deploying a high-risk system without provider obligations in place) is materially higher than the cost of preparing to comply as if you were a provider.
Importer and distributor roles
Two additional roles are worth flagging, because they can catch out organisations that think they are just resellers.
An importer is a natural or legal person established in the EU that places on the market an AI system bearing the name or trademark of a natural or legal person established outside the EU. Importers have specific obligations under Article 23: verifying that conformity assessment has been carried out, verifying documentation, and ensuring the provider has established a representative in the Union.
A distributor is a natural or legal person in the supply chain, other than the provider or importer, that makes an AI system available on the EU market. Distributors have lighter obligations under Article 24, focused on due diligence checks before making the system available.
Most enterprises are not importers or distributors in the strict sense, but organisations that resell white-labelled AI tools, offer AI capabilities within broader platforms, or intermediate between foreign AI providers and EU customers can find themselves in one of these roles. The obligations are real and worth understanding.
What contracts should say
If you are a deployer procuring from providers, your contracts need to work harder than they used to.
You need representations and warranties that the provider has completed conformity assessment. You need to be able to see the technical documentation for the system, or at least the parts of it relevant to your deployment. You need commitments on post-market monitoring, incident notification, and cooperation with authorities.
If you are a provider selling to deployers, your contracts also need to work harder. You need to make clear what your instructions for use require, so deployers who ignore them cannot claim your indemnification. You need to specify what modifications by the deployer would move them into provider territory, so you are not held responsible for what they do to your system after purchase. You need to specify how incidents will be reported and investigated.
If you are procuring GPAI models from major providers, you are dealing with terms of use rather than negotiated contracts for the most part. Read them carefully. Understand what representations the provider is making, what use restrictions they impose, and what happens if the model is deprecated or repriced. Substitute planning starts here.
Practical guidance for enterprise organisations
Three moves matter most, in my experience.
Map your systems to roles carefully. For each AI system in your inventory, determine whether you are a provider, a deployer, or both, and document why. Do not do this in a spreadsheet column. Do it with a written classification that references the specific facts of the deployment. When authorities ask, or when internal audit reviews the classification, you want the reasoning on paper.
Design deployment to preserve deployer status where legitimate. In many cases, sticking with the provider’s intended purpose and not modifying the system substantially is both good governance and good compliance strategy. Where you have genuinely changed the system’s purpose or capability, take on provider obligations rather than pretend you have not.
Build the process before you build the systems. The temptation is to build the AI system first and figure out compliance later. This produces expensive rework and, in some cases, systems that cannot be brought into compliance without redesign. Get the classification, the risk assessment, and the documentation approach right before development, not after.
Figure 2: The compliance flow
Figure 2 shows the compliance flow for a typical enterprise AI system, starting from inventory and running through classification, role determination, obligation mapping, control implementation, evidence collection, and monitoring. Each step generates artefacts that regulators will look for. The flow is more useful than any single obligation list because it makes clear that AI Act compliance is a process, not a document.
Where this leaves you
The provider/deployer distinction is where AI Act compliance stops being an abstract regulatory topic and starts touching every AI system in your organisation. If you get it wrong, you either take on obligations that do not apply to you, wasting money and time, or you fail to take on obligations that do, exposing yourself to fines that can reach €35 million.
Most large enterprises are both. Both roles need to be managed. And the systems in your organisation right now, especially those built on foundation models and adapted for specific purposes, are almost certainly a mix.
The next article moves out of the EU and into the United States. The regulatory landscape there is genuinely different in shape and in intent. Understanding both is what lets you build a governance program that works across the jurisdictions your organisation actually operates in.