Provider or Deployer: Which EU AI Act Role Does Your Organisation Hold
The obligations in the EU AI Act attach to roles rather than to industries, so the first governance question any organisation must answer is which role it holds for each system it touches. Article 3(3) defines a provider as a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trade mark, whether for payment or free of charge. Article 3(4) defines a deployer as a natural or legal person, public authority, agency or other body using an AI system under its authority, except where the system is used in the course of a personal, non-professional activity.
The practical consequence is that the great majority of organisations are deployers. If your finance team uses a commercial assistant to summarise contracts, if your marketing team uses an image generator, if your recruiters use a screening tool bought from a vendor, you are a deployer of those systems. The vendor who built and sold them is the provider. Your Article 4 duty is identical in kind to the vendor’s, but the content of what your people need to know is different, because you did not design the model and cannot inspect its internals. Deployer literacy is about the boundaries of appropriate use, the failure modes you will actually meet, and the conditions the provider set out in the instructions for use.
A private individual using an AI assistant to plan a holiday is neither provider nor deployer, because the definition of deployer excludes personal, non-professional activity. The same person using the same assistant to draft a client proposal at work is inside the definition. Staff routinely miss this line, which is why bring-your-own-tool use is a governance problem and not merely an information security one.
The roles are not permanent. Article 25 sets out the circumstances in which a distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system and takes on the provider’s obligations. Three of those circumstances matter to ordinary organisations. The first is putting your own name or trade mark on a high-risk system already placed on the market, which is what happens when a firm white-labels a supplier’s screening tool and presents it to candidates as its own.
The second is making a substantial modification to a high-risk system that remains high-risk. The third, and the one most often triggered by accident, is modifying the intended purpose of a system, including a general-purpose system, so that it becomes high-risk. A team that takes a general document-analysis tool sold for internal summarisation and rebuilds it into a sifting engine for job applications has changed the intended purpose, and the organisation may find it is now the provider of a high-risk system rather than the deployer of a general one.
Fine-tuning deserves its own mention because it is now common and cheap. Adapting a model on your own data can, depending on what you build and how you present it, move you across the line into provider territory. This is a decision that should never be made by a single enthusiastic team without governance involvement, and one of the practical goals of a literacy programme is to make sure the engineers and product managers who could trigger it know that the line exists.
General-purpose AI models sit in their own category. Obligations on providers of general-purpose AI models have applied since August 2025, covering matters such as technical documentation, information for downstream providers, and copyright policy. An organisation that merely uses a general-purpose model through an interface or an interface’s application programming interface is not a provider of that model. If your organisation trains or substantially adapts a general-purpose model and makes it available to others, you should take specialist advice rather than rely on a literacy course.
Why does the distinction matter for Article 4 itself, given that the literacy duty applies either way? It matters because it determines what a sufficient level looks like. A provider’s staff need to understand data governance, testing, technical documentation, post-market monitoring and the logic of the conformity assessment route their product takes. A deployer’s staff need to understand the intended purpose stated by the provider, the limits of the system in their own context, the human oversight arrangements, the record-keeping expectations, and the point at which a task should not be given to the system at all.
If you deliver provider-flavoured training to a room full of deployers, you will have spent budget and produced no useful capability, and an inspector reading your materials will see the mismatch immediately.
The practical step is a role register. For each AI system in use, record the system, the business owner, the vendor, whether you are provider or deployer, and whether anything in your configuration could trigger Article 25. That register is also the backbone of the evidence pack built in the final lesson, because it tells you exactly which populations need which training.