Providers, deployers and the value chain

Why roles matter

Duties in the EU AI Act depend on what you do with a system, not on your size or industry. The same company can be a provider of one system and a deployer of another. Getting your role wrong means planning for the wrong duties, so identify it early. The role guide asks six questions to give a first idea.

The roles in plain words

• Provider. You develop an AI system, or have one developed, and put it on the market or into service under your own name or trademark. Providers of high-risk systems carry the heaviest duties: risk management, data governance, documentation, logging, conformity assessment, registration and post-market monitoring.
• Deployer. You use an AI system under your own authority, for example inside your business. Deployers of high-risk systems must use the system as instructed, assign trained people to oversee it, monitor it, keep logs they control and tell workers and affected people. Some deployers, such as public bodies, must assess impact on fundamental rights.
• Importer. You bring a system from a provider outside the EU onto the EU market. You check the provider has done what it must.
• Distributor. You make a system available on the EU market without being its provider or importer.

General-purpose AI model providers have their own duties, such as technical documentation, a copyright policy and a training-content summary, which apply to the model itself.

The value chain

An AI system usually passes through several hands: a model developer, a provider who builds a product on it, a distributor or reseller, and finally a deployer. Each link depends on the others. A provider must give deployers clear instructions and information. A deployer must use the product as intended. If a deployer puts its own name on a system, changes its intended purpose or modifies it substantially, it can become the provider, with the provider’s duties.

When you buy a tool

A common mistake is to think “the vendor is responsible”. The vendor is usually the provider, but you remain the deployer, with duties of your own. In practice:

• Ask which role the vendor believes you each hold, and which risk tier it assigns the product.
• Get the instructions for use, limits and test results in writing.
• Agree in the contract who does what: incident notice, change notice, data use, audit and exit.
• Keep your own oversight and monitoring. You cannot outsource accountability.

The vendor due diligence tool turns this into sixteen questions you can send.

Other regions

Other regions use different words. Data protection law talks about controllers and processors (UK and EU GDPR) and data fiduciaries (India’s DPDP Act). US state laws often distinguish developers and deployers. The ideas overlap but definitions differ, so check the region page for the instrument that applies.

Example

A hospital buys a triage assistant from a vendor. The vendor is the provider; the hospital is the deployer. The hospital then retrains the assistant on its own patient data and brands it as its own tool. That may make the hospital a provider as well, with documentation and conformity duties it did not plan for. A short conversation with counsel before rebranding avoids a surprise.

What to do now

1. For each system on your register, record your role: provider, deployer or not sure.
2. Mark every “not sure” for review with counsel.
3. For vendor systems, send the due diligence questions before you sign or renew.