Provider and Deployer Obligations

The AI Act allocates duties by role rather than by system, and the two principal roles carry very different burdens. Most organisations building on someone else's model are deployers, and most of them discover the distinction when they do something that reclassifies them as providers.

The split

A provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. For a high-risk system the provider owns the heavy obligations: the risk management system, data governance, technical documentation, logging capability, conformity assessment, registration, the quality management system, and post-market monitoring.

A deployer uses an AI system under its own authority in a professional capacity. Its obligations are narrower and real: use the system in accordance with the provider's instructions, assign human oversight to people with the competence and authority to exercise it, ensure input data is relevant and sufficiently representative where the deployer controls it, monitor operation and inform the provider of risks or serious incidents, retain logs where under its control, and inform affected people where required.

The design intent is that the party with the ability to control a risk carries the duty for it. A deployer cannot audit a model's training data and can control how the model is used, who oversees it, and what data it receives.

Becoming a provider without intending to

Several ordinary actions move a deployer into the provider role for the resulting system. Putting your own name or trademark on a high-risk system already on the market. Making a substantial modification to a high-risk system. Modifying the intended purpose of a system, including a general-purpose one, such that it becomes high-risk.

That last route is the one that catches teams. Taking a general-purpose model and building a hiring screening tool on it makes the resulting system high-risk and makes the builder its provider, with the full obligation set, even though they trained nothing.

What this does to contracts

Because the provider holds the documentation the deployer needs, and the deployer holds the operational evidence the provider needs for post-market monitoring, the split creates a mutual dependency that has to be contractual.

Deployers need the provider's instructions for use, technical characteristics, accuracy and limitation information, and commitments on notification of changes and support for incident investigation. Providers need deployers to report serious incidents and misuse, and to operate within the stated intended purpose. Where a general-purpose model sits upstream, its provider's obligations to downstream providers are the mechanism by which the information flows, and a contract that does not secure that flow leaves the downstream provider unable to compile its own technical file.

When it breaks

Teams assume being a customer means being a deployer. Building a product on an API and shipping it to your own customers under your own name generally makes you a provider of that system, and the obligations follow the system you placed on the market rather than the model you licensed.

Human oversight is treated as a person watching. The obligation is to assign oversight to people with the competence, training and authority to intervene, which means the reviewer must be able to override and must not face incentives that make overriding costly. A reviewer with a throughput target and no authority satisfies the form and not the requirement.

The instructions for use are load-bearing. A deployer's obligation is to operate within them, so a provider's documentation defines what deployment is compliant. Vague instructions transfer risk to the deployer in a way neither party usually notices until an incident.

Serious incident reporting has both parties in it. The deployer observes the incident and the provider owns the reporting duty, so a path from one to the other has to exist before it is needed rather than being improvised under a regulatory clock.