EU AI Act: Providers vs. Deployers — Who Is Responsible for What?

The EU AI Act splits obligations between providers (who build AI systems) and deployers (who put them into practice). Understanding which role you occupy determines your compliance burden — and whether you can shift liability to another party.

The Two-Actor Architecture of the EU AI Act

The EU AI Act does not create a single universal obligation for all AI stakeholders. It distinguishes systematically between two primary roles in the AI value chain:

• Providers — entities that develop, train, or fine-tune AI systems and bring them to market
• Deployers — entities that operate AI systems in a professional context without having built them

This distinction is not semantic. It determines which obligations apply, who holds which documentation, who registers in the EU AI database, who performs conformity assessment, and who is liable when something goes wrong. Getting your role right is the first step in any EU AI Act compliance programme.

A third role — authorised representative — applies to providers established outside the EU who must designate an EU-based representative to carry their regulatory obligations on EU territory.

Defining the Provider (Art. 3(3))

A provider is any natural or legal person, public authority, agency, or other body that:

1. Develops an AI system or has an AI system developed, and
2. Places it on the market or puts it into service under its own name or trademark — whether for payment or free of charge

The key indicators of provider status are development responsibility and market placement. An AI laboratory that builds and licenses a credit-scoring model is a provider. A consultancy that designs and builds a custom recruitment screening tool for a client, then hands it over, is also a provider (as long as it places the system on the market under its own name; if it is built under the client's brand, the client may be the provider).

The definition covers:

• AI startups and software vendors selling packaged AI products
• Enterprises building AI systems for internal deployment
• Research institutions publishing AI systems for general use
• Cloud providers offering AI-as-a-service under their own brand

Providers bear the heaviest compliance burden under the Act. For high-risk systems, this includes conducting conformity assessments, preparing technical documentation, registering in the EU AI database, affixing CE marking, and maintaining a post-market monitoring system.

Defining the Deployer (Art. 3(4))

A deployer is any natural or legal person, public authority, agency, or other body that uses an AI system under its authority for a professional purpose — except where use is in personal non-professional activity.

Deployers do not build AI systems. They use systems built by others — whether purchased off-the-shelf, licensed via API, or embedded in a SaaS product. The vast majority of European organisations that "use AI" are deployers: companies using ChatGPT or Claude via API, HR departments using AI-powered applicant tracking, hospitals using AI-assisted diagnostic tools, banks using vendor-supplied credit models.

Key deployer obligations (for high-risk AI systems):

• Use the system only in accordance with the instructions provided by the provider (Art. 26(1))
• Assign a human with competence, authority, and resources to perform human oversight (Art. 26(2))
• Ensure input data is relevant and representative for the intended purpose (Art. 26(5))
• Monitor system operation to detect anomalies (Art. 26(5))
• Retain logs produced by the system for the period required (Art. 26(6))
• Notify the provider and competent authority of any serious incidents (Art. 26(8))
• Conduct a Data Protection Impact Assessment where required by GDPR (Art. 26(9))

Deployers of emotion recognition and biometric categorisation systems must also comply with Art. 50 transparency obligations regardless of risk classification.

The Provider-Deployer Boundary in Practice

The boundary between provider and deployer is straightforward in theory but blurred in practice. Three scenarios illustrate the common grey areas:

Scenario 1: Off-the-shelf SaaS with no customisation

A company subscribes to a vendor's AI-powered HR screening platform with no modification. The vendor is the provider. The company is the deployer. The vendor owes the company instructions for use, conformity documentation, and logging capability. The company owes its employees transparency and human oversight.

Scenario 2: API integration with significant prompt engineering

A company integrates a GPAI model via API, adds a custom system prompt, builds a user interface, and releases the application to customers. For the underlying GPAI model, the original developer is the provider. For the application built on top, the company is the provider — it has developed an AI system and placed it on the market under its own brand. Both provider and GPAI obligations apply at different layers.

Scenario 3: Custom internal build

A bank builds its own creditworthiness assessment model, trains it on proprietary data, and deploys it internally for loan decisions. The bank is simultaneously the provider (it built and deployed the system) and the deployer (it operates the system for its own purposes). All provider obligations under the Act apply — including conformity assessment for this Annex III high-risk use case — as well as all deployer obligations.

When Deployers Become Providers (Art. 25)

Art. 25 establishes clear triggers by which a deployer assumes provider status and inherits all provider obligations:

1. Substantial modification — the deployer makes a substantial modification to a high-risk AI system beyond what the original provider intended
2. Purpose change triggering high-risk classification — the deployer uses a non-high-risk system in a way that meets the Annex III high-risk criteria
3. Own-name placement — the deployer places the AI system on the market or puts it into service under its own name or trademark
4. GPAI model modification — a deployer who makes a major change to a GPAI model in a way that alters its general-purpose use case

When Art. 25 is triggered, the original provider's obligations transfer to the new provider. The original provider is relieved of obligations for the modified or repurposed system. This is an important liability allocation mechanism: organisations that merely customise a system must understand where customisation ends and substantial modification begins.

Obligations Comparison Table

How to Determine Your Role

Three questions establish your role under the EU AI Act:

1. Did you develop the AI system, or have it developed under your direction? If yes — and you placed it on the market or into service — you are a provider.

2. Are you using an AI system built by someone else for a professional purpose? If yes, you are a deployer.

3. Have you substantially modified, repurposed, or rebranded an AI system? If yes, you may have become a provider for that modified system under Art. 25.

For organisations that are both — internal build for internal use — all obligations stack. There is no reduction for integrated operations.

Contractual Allocation of Responsibilities

The Act allows providers and deployers to contractually allocate specific obligations. Art. 25(1) explicitly permits this for certain obligations. However, two limits apply:

• Regulatory liability cannot be contracted away. If the deployer operates a high-risk system, it remains responsible for deployer obligations regardless of what the contract says. Contracts can establish internal recourse but cannot shift regulatory accountability to the other party.
• The information flow must be preserved. Any allocation must ensure the deployer has the information necessary to fulfil its obligations — instructions for use, logging access, incident reporting channels. Contracts that cut off this information flow are problematic for compliance, not just commercially.

Procurement teams should use AI vendor contracts to ensure providers supply what deployers need: instructions, conformity documentation, incident notification channels, update commitments, and data governance terms for any data shared for fine-tuning.