AI Act provider vs deployer: map the role before building

Buying a model API does not settle your role in the finished AI system. Before commissioning an application, identify the system being discussed, whose name it carries and how it will be used. Those facts give your legal adviser a useful basis for assessing provider and deployer roles under the EU AI Act.

This guide concerns preparation for that review. It does not classify your system, determine its risk category or give a deployment deadline. The references below were checked on 10 October 2026.

What provider and deployer mean

Under Article 3, a provider develops, or commissions development of, an AI system or general-purpose AI model and markets it, or puts the system into service, under its own name or trademark. Payment is not required. A deployer uses an AI system under its authority, excluding personal, non-professional use. Putting into service can include own use. These definitions are in the consolidated AI Act text.

Article 25 addresses provider responsibilities for high-risk systems when another party rebrands a system, substantially modifies it while it remains high-risk, or changes its purpose so that it becomes high-risk. For rebranding, the provision also recognises contractual arrangements that allocate the obligations differently. These conditions need case-specific assessment; an ordinary configuration change is not automatically a transfer of responsibilities. See Article 25 and its surrounding provisions.

Start with a diagram of the actual product

Consider a fictional company commissioning an assistant that drafts answers from its service manuals. A model vendor supplies the API. An implementation company builds retrieval, permissions and the review screen. The customer decides who uses the application and which manuals it may read.

Calling the API vendor “the provider” leaves several questions unanswered. Is the review about the underlying model, the vendor's application or the assembled assistant? Who commissions the finished system? Under whose name does it enter use? What do the instructions and sales materials say it is for?

Draw those components separately. Record the organisation responsible for each one and attach the relevant agreement or product documentation. Mark unknown answers explicitly. These proposed preparation steps give the legal adviser material to assess.

Revisit the assessment when the job changes

In the fictional example, the first release prepares answers for staff to review. Later, the customer proposes turning the same application into a separate product for other businesses. The team should record the new distribution arrangement and obtain an updated role assessment before treating the first assessment as sufficient.

A second change could involve the purpose of the output. A tool that retrieves documents might be proposed for evaluating people or making consequential recommendations. That requires a fresh description of what the system will do, who is affected and how the output is used. This example does not determine whether a particular system is high-risk.

For an engineering handover, keep the old and proposed scopes side by side. Include changes to input sources, permissions and review steps. A note saying “same model, new feature” leaves the adviser to reconstruct the application from incomplete information.

Separate the role assessment from the operating plan

Once the role assessment is available, the implementation team still needs named owners for acceptance tests, access changes and incident handling. A legal role label does not tell an engineer which person can approve a new connector or where to send a failed test.

The operating plan should refer to the assessed version and purpose. If either changes, assign someone to check whether the assessment and implementation requirements need updating. Our guide to responsibility for AI agent decisions covers the practical handover between process owners, reviewers and implementation partners.

Data-processing arrangements also need their own examination. The GDPR and DPA review guide addresses the agreement and data flow. Do not use a provider/deployer label as a replacement for that work.

What to ask Syntalith to prepare

Syntalith can scope the technical material for a role review: the application boundary, component list, data flow and proposed changes. The implementation proposal can identify which tests and records are included. Legal classification and advice should be assigned separately; this preparation is not compliance certification.

For the fictional service-manual assistant, a proposed first deliverable could be a short system map with an unresolved-questions list. The map would separate the purchased model API, the retrieval application and the customer’s operating process. It would identify which organisation commissions each part and whose name appears in the user interface and instructions. The questions list could flag that a later plan to sell the assistant has no agreed product owner yet. Your legal adviser would then assess those facts.

Before agreeing that work, we would check which supplier documents already exist and who in your team can confirm the intended use. The quote should say whether preparing the map ends with a handover or also includes updating it after the adviser’s questions. That distinction affects the work to commission; it does not imply a legal opinion is included.

For a first discussion, bring a description of one application and the change you want to make. We can compare the technical work needed with the information already available from your supplier. Service pricing is on the pricing page; use the contact form to describe the scope without sending confidential documents.

Further implementation decisions

• Article 6 and Annex III: preparing the classification review
• Article 10: evidence about training and testing data
• Article 5: reviewing the proposed feature before purchase
• Article 50: chatbot disclosure and entry points
• The amended implementation timeline after August 2026