EU AI Act provider vs deployer duties

Provider or deployer: which EU AI Act duties apply to us

If your organization is buying, building or reselling AI, the first question is which role you hold. A provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority for anything beyond personal non-professional use (Article 3(3) and (4)). The Act applies to providers wherever they are established, to deployers established or located in the EU, and to non-EU providers and deployers whose AI output is used in the EU (Article 2(1)). Confirm the role for each system before you plan anything else, because the duties attached to each role differ.

The role is decided per system and per use, not per company. One organization can be a provider of a product it sells and a deployer of a vendor's tool it uses internally, and the same system can carry different duties depending on what it is used for. Two rules can change a role mid-life. Under Article 25(1), a deployer, distributor, importer or other third party becomes the provider of a high-risk system if it puts its name or trademark on it, substantially modifies it, or changes its intended purpose so that it becomes high-risk. Under Article 25(2), as amended in 2026, the original provider must then share documentation, known limitations and technical access with the new provider, unless it clearly stated that the system must not be turned into a high-risk system. Check your product roadmap and any customization work against these triggers before launch.

Contracts decide how the remaining duties move along the value chain. Providers of high-risk systems and their suppliers must agree in writing the information and assistance each needs, except for free and open-source components other than general-purpose AI models, and breaches of this duty can now be fined (Articles 25(4) and 99(4)(da)). Ask each vendor for the documentation, instructions for use and logging support it will provide, and ask your customers what they will require from you. Confirm with counsel which clauses the Article 25 duties need, since the Act sets the minimum and the contract records who does what. Note also that fines of up to EUR 15 million or 3% of worldwide turnover apply to both roles for breaches of high-risk or transparency obligations (Article 99(4)).

What each role owes for high-risk and transparency duties

The provider carries the design and market-entry duties for a high-risk AI system. It develops the system, or has it developed, and places it on the EU market or puts it into service under its own name or trademark. Those duties cover the Section 2 requirements for the system itself, a quality management system, the conformity assessment, the EU declaration of conformity, CE marking, registration and post-market monitoring. Articles 16, 72 and 73 set out the core provider obligations, and Article 49 covers registration of Annex III systems in the EU database.

Design and documentation: Build the system to meet the Section 2 requirements and keep the technical documentation that shows how it does.
Quality management: Run a documented quality management system across the system's lifecycle.
Conformity and registration: Complete the conformity assessment, issue the declaration, apply CE marking and register Annex III systems in the EU database under Article 49.
Post-market monitoring and incidents: Collect performance data after launch and report serious incidents under Article 73.
Value chain agreements: Give downstream users the information and assistance they need, and agree it in writing under Article 25(4).

Confirm with your counsel which of these duties apply to your system's Annex category, because the conformity route differs between Annex III and Annex I products.

When a deployer, importer or distributor becomes the provider

A deployer, importer, distributor or other third party takes on the provider's duties for a high-risk system in three situations under Article 25(1): it puts its own name or trademark on the system, it substantially modifies a high-risk system, or it changes the intended purpose of a system so that it becomes high-risk. The role follows the act, not the contract. An organization that rebrands a vendor's scoring tool under its own name, or repurposes a general tool for credit or employment decisions, can become the provider without signing anything new. Map each system in your inventory against these three triggers before you assume the vendor carries the provider obligations.

The 2026 amendment added Article 25(2). When a new provider takes over under one of these triggers, the original provider must share the documentation, known limitations and technical access that the new provider needs to comply, unless the original provider clearly specified that its system must not be turned into a high-risk system. Your vendor contracts should therefore ask two questions now: does the supplier exclude high-risk use in its instructions for use, and what documentation and access would it hand over if you changed the system's purpose. Ask for the exclusion wording in writing and record the answer in the system's technical file.

Whether an internal fine-tune, a retrained model, a new user interface or a rebrand for an internal business unit counts as a substantial modification or a change of intended purpose is a legal question that depends on the Act's definitions and the system's documented intended purpose. Confirm the position with counsel for each system before launch, and document the reasoning, because the answer decides whether your organization must run quality management, conformity assessment and registration itself. Treat any change to a high-risk system's purpose or performance as a trigger for a fresh review.

What the contract between provider and deployer must cover

Under the AI Act, responsibilities for a high-risk system are split between the provider that builds it and the deployer that runs it, and the written agreement is where that split becomes operational. The cards below cover the clauses a provider and deployer should settle before the system is used in the EU.

Information and assistance clause

Article 25(4) requires providers of high-risk systems and their suppliers of AI systems, models, tools and components to agree in writing the information and assistance each needs to meet its obligations. Free and open-source components other than general-purpose AI models are excepted, so confirm which parts of your stack fall under that exception. Since 2026, a breach of this duty can be fined under Article 99(4)(da).

Intended purpose and known limitations

The provider must state the intended purpose, and the deployer must confirm that its use stays inside it. Under Article 25(2), as amended in 2026, the original provider must share documentation, known limitations and technical access with a new provider. Check that the contract lists each limitation and names who updates the list when new risks appear.

Instructions for use and logs

Deployers must use a high-risk system according to the provider's instructions, and must keep the logs the system generates for at least six months under Article 26. The agreement should specify which logs the provider supplies, in what format, and who holds them if the contract ends. Confirm that logging access does not depend on a support ticket.

Incident and serious incident notification

Providers carry serious incident reporting under Article 73, while deployers must monitor and report risks and incidents under Article 26. The contract should set who notifies whom, through which channel, and how quickly, so that neither party learns of an incident from a regulator. Write the notification path into the operating procedures, not only the contract.

Change control for substantial modification

A deployer, distributor or importer becomes a provider if it substantially modifies a high-risk system or changes its intended purpose so that it becomes high-risk under Article 25(1). The agreement should define what counts as a substantial change, who approves it, and who repeats the conformity steps afterward. Fine-tuning, new data sources and new use cases are the usual triggers to review.

Audit and evidence access

Deployers and their assessors need evidence that the provider's controls work, including documentation, test results and technical access where the Act requires it. Specify which records the provider will produce on request, the notice period, and who pays for supporting an assessment. Ask whether the provider's evidence covers the EU database registration and post-market monitoring it owes.

Which role carries which obligation

This table compares which AI Act duties fall on the provider, the deployer, and the importer or distributor, row by row, with the article that sets each duty. Read each row as a question: who builds and places the system on the market, and who uses it under its own authority. The main takeaway is that the provider carries the design and market-entry duties, while the deployer carries duties for operating the system and for the people it affects. Importer and distributor duties are narrower, and you should confirm their exact scope in the consolidated text of the Act.

Obligation	Article	Provider	Deployer	Importer or distributor
Section 2 compliance (high-risk requirements)	Article 16	Ensures the system meets the Section 2 requirements before market entry	Does not design the system; uses it according to instructions	Checks that the provider has met requirements before placing on the market; confirm in consolidated text
Quality management system	Article 17	Establishes, documents and maintains it	Not applicable as a provider duty	Confirm scope in consolidated text
Conformity assessment and declaration	Articles 43 and 47	Carries out assessment and issues the EU declaration of conformity	Not applicable unless it becomes a provider	Verifies conformity marking and documents; confirm in consolidated text
CE marking and registration	Articles 48 and 49	Affixes CE marking and registers Annex III systems in the EU database	Public authority deployers register their use	Confirm marking and registration checks in consolidated text
Post-market monitoring	Article 72	Runs a monitoring system after the system is placed on the market	Monitors and reports risks and incidents under Article 26	Confirm reporting duties in consolidated text
Serious incident reporting	Article 73	Reports serious incidents to market surveillance authorities	Informs the provider and authorities of risks and incidents	Confirm reporting duties in consolidated text
Deployer duties for high-risk systems	Article 26	Supplies instructions and supports deployer obligations	Uses per instructions, assigns human oversight, keeps logs for at least six months, informs workers	Not the primary holder; confirm in consolidated text
Fundamental rights impact assessment	Article 27	Not a provider duty for this assessment	Required for public bodies, private providers of public services, and credit scoring or life and health insurance pricing use	Not applicable as a standard duty; confirm in consolidated text
Article 50 disclosures	Article 50	Discloses AI interaction and marks synthetic content	Discloses emotion recognition and biometric categorisation, labels deepfakes	Confirm applicable duties in consolidated text
AI literacy	Article 4	Takes measures to support staff AI literacy	Takes measures to support staff AI literacy	Confirm applicability in consolidated text

How to assign roles before the project starts

This sequence turns the provider and deployer question into a filed record for each AI system, so the compliance lead can show who owns which duties before design, purchase or rollout begins. Each step closes with an artifact that can be reviewed and updated when the system changes.

Inventory every AI system and its supplier
The compliance lead, with the business owners and procurement, lists each AI system the organization builds, buys, embeds or uses, including systems that arrive inside SaaS products and general-purpose AI models accessed through an API. For each entry, record the supplier, the contract owner, the business purpose and the markets or users affected. The step is done when the inventory has one row per system and no system is known only by its vendor's marketing name. The output is the AI system inventory, which every later step refers to.
Record who places the system on the market or uses it
For each inventory row, the legal or compliance team records whether the organization develops the system or has it developed, and whether it places it on the market or puts it into service under its own name or trademark. Where the organization only uses the system under its authority for professional purposes, it is recorded as a deployer. Importers and distributors are noted separately, because they carry their own checks. The step is done when every row has a role entry signed off by the system owner. The output is the role register, a dated table with one role per system.
Check the Article 25(1) triggers for every change
Before a deployer, distributor, importer or other third party relies on a system, the team checks whether it would become the provider. The checks cover putting its own name or trademark on a high-risk system, substantially modifying a system, and changing its intended purpose so that it becomes high-risk. Procurement and product teams should run this check at every change request, including fine-tuning, new integrations and new use cases, not only at purchase. The step is done when each change ticket has a recorded yes or no on each trigger. The output is the trigger log attached to the role register.
Classify each system as high-risk or transparency-only
The compliance lead, with legal counsel, assigns each system to a risk tier: high-risk under Annex III or Annex I, transparency-only under Article 50, or neither. The classification determines which set of duties applies to the provider and which applies to the deployer, so it must reflect the intended purpose as the organization describes it. Where a system could fall under the Article 6(3) exemption, the reasoning is written down before the decision is final. The step is done when every system has a tier and a named approver. The output is the classification record for each system.
Sign the Article 25(4) written agreement
For each high-risk system, the provider and the supplier of AI systems, models, tools or components agree in writing on the information and assistance each party must give. Legal and procurement draft the clauses, and the supplier's documentation, known limitations and access to technical information are listed as deliverables. Free and open-source components other than general-purpose AI models are outside this requirement, so the agreement should record that exclusion explicitly. Ask suppliers which components are open-source before the clause is drafted. The step is done when the agreement is signed by both parties. The output is the signed agreement, filed with the role register.
Record the role decision and its reasons
The compliance lead writes a short decision record for each system that states the role, the risk tier, the triggers checked, the agreement reference and the reasons for each conclusion. The record names the person who approved it and the review trigger, such as a new version, a new use case or a change of supplier. Auditors and market surveillance authorities look for this reasoning, not only the final label, so it should be readable by someone outside the project. The step is done when every system has a decision record that the accountable owner has signed. The output is the role decision record, which is reviewed whenever a trigger fires.

What the deployer and provider need in place before go-live

Before a high-risk AI system goes live, the deployer and the provider each need a short set of working records. These six checks cover what the deployer holds, what the provider must hand over, and which contract terms make the two sides work together. Each card says how to check the item and what evidence shows it is in place.

AI system inventory with suppliers

List every AI system in use, its intended purpose, its owner and each supplier that provided the model, component or tool. Check whether any use falls under Annex III, and record the reasoning. Evidence is a dated inventory that names the provider of each system and the supplier chain behind it. Ask whether a system's intended purpose has changed since it was first bought, because a changed purpose can change your role under Article 25(1).

Instructions for use from the provider

Confirm that the provider has supplied written instructions for use and that your team has read them against your planned use. Check that the instructions cover the system's intended purpose, its known limitations and the human oversight measures it expects. Evidence is the version of the instructions on file, a note of who reviewed them and any gaps raised back to the provider before launch.

Named human oversight owners

Assign a named person, with the competence and authority to intervene, to each high-risk deployment. Check that the owner understands the system's limits, can stop or override its output and has time allotted for the role. Evidence is a signed role description, a training record and an escalation procedure that names who acts when the system misbehaves.

Log retention of at least six months

Confirm that the logs the system generates are kept under your control for at least six months, unless other Union or national law sets a different period. Check that the logs are complete, protected against change and retrievable for an authority or an affected person. Evidence is a retention setting in your log platform, an access list for the logs and a test restore showing a sample is readable.

Worker and affected-person notice

Before a high-risk system is used in the workplace or on people, inform the workers' representatives and the workers concerned, and tell affected people that they are subject to the system. Check that the notice is written in plain language and that it reaches each group before go-live. Evidence is the dated notice, the distribution list and the record of the works council or staff consultation where one applies.

Contract clause set with providers

Agree in writing the information, documentation and technical assistance the provider owes you, and the duty to notify you of serious incidents and corrective actions. Check that the clauses cover the documentation the provider must share under Article 25(2) and the assistance it owes on Article 26 duties. Evidence is the signed contract or addendum, a schedule of deliverables and a named contact for incident notice.

Who owns the controls, who prepares the evidence, who assesses

The organization is the party that carries the legal duties. It decides whether a system is a provider or deployer system, which Annex III category applies, what the intended purpose is, and whether the Article 6(3) exemption is claimed. Those decisions cannot be delegated to a vendor or consultant, because the regulator will hold the organization accountable for them.

Role and classification decisions: Confirm whether you are the provider, deployer, importer or distributor for each system, and record the reasoning.
Intended purpose and risk tier: Own the written statement of purpose, since it drives which requirements apply.
Accountability and sign-off: Name the people who approve the quality management system, risk decisions and the EU declaration where the role requires it.
Operational duties: For deployers, assign human oversight, monitor the system in use, and keep logs and workforce notices.
Contracts along the value chain: Negotiate and sign the written information and assistance terms with suppliers.

Confirm internally which of these decisions have named owners before any external party starts work.

Common questions on provider and deployer duties

Can one company be both a provider and a deployer under the AI Act?

Yes. The roles attach to each AI system, not to the company, so one organization can be a provider of a system it builds and sells, and a deployer of a different system it uses internally. The same company can also hold both roles for a single system if it develops a tool and then uses it in its own operations. Map each system separately, record which role applies to each, and list the duties that follow from each role. Under Article 3(3) and (4), a provider places the system on the market or puts it into service under its own name or trademark, while a deployer uses it under its authority outside personal non-professional use.

Does using a SaaS AI tool make us a deployer?

In most cases, yes. If your staff or processes use an AI system under your authority for professional purposes, you are a deployer of that system, even though a vendor built and hosts it. The deployer role does not depend on who runs the infrastructure. Your deployer duties depend on the use case: if the tool falls within a high-risk category in Annex III, Article 26 applies, covering instructions for use, human oversight, input data, monitoring, log retention for at least six months, and informing workers and affected people. Ask the vendor which risk tier it assigns, what intended purpose it documents, and whether it provides the instructions for use you need.

Does fine-tuning or customizing a model make us a provider?

It can. Under Article 25(1), a deployer or other third party becomes the provider of a high-risk system if it puts its name or trademark on the system, substantially modifies it, or changes its intended purpose so that it becomes high-risk. Adjusting a model for your own use does not automatically trigger this, but substantial modification and a change of intended purpose do, and both are judged on the facts. Illustrative example: a company that retrains a general-purpose tool to score loan applicants would be changing the intended purpose into a high-risk use. Document each change, assess it against Article 25(1) before deployment, and confirm the outcome with counsel.

What must a provider put in writing for us?

Under Articles 25(4) and 99(4)(da), providers of high-risk systems and their suppliers of AI systems, models, tools and components must agree in writing the information and assistance needed for compliance. Since the 2026 amendment, breaches of this duty can be fined. Under Article 25(2), as amended in 2026, the original provider must also share documentation, known limitations and technical access with a new provider who takes over the system, unless it clearly stated the system must not be turned into a high-risk system. Ask for the intended purpose, instructions for use, known limitations, logging capabilities, and the process for serious incident notifications. Free and open-source components other than general-purpose AI models are excluded from this written-agreement duty.

What do we need from the provider before we launch a high-risk system?

Before launch, you need enough from the provider to meet your Article 26 duties. The checklist includes the instructions for use that tell you how to operate the system, evidence that the system is registered where required, a clear statement of the intended purpose and its limits, the information needed to assign competent human oversight, and details of the logs the system produces so you can keep them for at least six months. You also need a route for reporting risks and incidents back to the provider. If you are a public body or a private provider of public services, or you use credit scoring or life and health insurance pricing, Article 27 adds a fundamental rights impact assessment. Confirm each item in writing and keep the answers as deployer evidence.

Does open-source software escape these duties?

Not automatically. Open-source software can reduce some obligations, but it does not remove the duties for whoever places a high-risk system on the market or uses it. The written-agreement duty in Article 25(4) excludes free and open-source components other than general-purpose AI models, yet a company that builds a high-risk system on open-source parts is still the provider of that system and carries the design and market-entry duties. A company that deploys an open-source high-risk system in its own operations still owes the deployer duties. Check the license, the intended purpose, and whether your organization is the provider or the deployer before you assume an exemption applies.

How long does preparing the evidence take?

The timeline depends on the number of systems, their risk tier, how much documentation already exists, and how many roles you hold. The AI Act sets no fixed preparation period. Provider evidence for high-risk systems, such as the quality management system and technical documentation, usually takes longer than deployer evidence, which centers on instructions, oversight assignments, logs and worker notices. The high-risk rules now apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems, under the 2026 amendment, which sets the outer date for planning. Ask any implementation partner for a written scope, deliverables and a schedule per system before work begins.

How DeployOpen maps roles and prepares evidence

DeployOpen works on the provider and deployer split by first agreeing in writing which role each of your AI systems plays and which duties follow. We then prepare the systems, contracts and records that show each duty is met, while your organization keeps ownership of its controls and any conformity decisions stay with independent assessors.

How we scope

Written scope lists each AI system, its role for your organization, and whether you are a provider, deployer, importer or distributor.
Scope sets out which obligations apply to each role, including high-risk duties and Article 50 transparency where relevant.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.

How we build

We map the role-dependent duties to your systems, owners and existing documentation, and identify gaps against the agreed scope.
We set up the records a deployer must keep, such as instructions for use, human oversight assignments and log retention.
We prepare written value chain agreements covering the information and assistance each supplier must provide to you.

How we hand over

You receive the role map, the contract templates, and the evidence files defined in the written scope.
Documentation is organized so your compliance lead and any independent assessor can trace each duty to its evidence.
Ownership of every control, policy and record stays with your organization after handover, with a clear list of open items.

How we support

Ongoing support, upgrades and continuous testing are available as retainers when your AI systems or supplier chain change.
We can update role assessments when a system is modified, repurposed or sourced from a new supplier.
Confirm with your legal counsel and independent assessor how role changes under Article 25 apply to your specific contracts.

EU AI Act provider vs deployer