Chapter 5 of 8

Provider vs Deployer Obligations for High-Risk AI: Two Stacks, Side by Side

16 min read

EU AI Act provider obligations (Articles 8–22) vs deployer duties (Article 26) for high-risk AI, side by side — with the agreed deadline of 2 December 2027.

Regulation (EU) 2024/1689 splits high-risk AI duties into two stacks tied to roles, not to companies. The provider is whoever develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark (Article 3(3)). The provider carries the design-and-market-entry stack in Articles 8–22, plus the conformity assessment steps in Articles 43, 47, 48 and 49. The deployer is whoever uses an AI system under its own authority in a professional context (Article 3(4)), and carries the operational stack in Article 26, plus the Article 27 fundamental rights impact assessment where it applies.

Roles attach per AI system, not per organisation. The same company is routinely the provider of the system it sells and the deployer of the tools it buys, and under Article 25 a deployer can move into the provider role mid-lifecycle. This chapter lays out both stacks, puts them side by side in one table, walks through the Article 25 role shift, and closes with the application dates. That last section comes with a caveat: the agreed 2 December 2027 deadline is not yet law.

One High-Risk System, Two Obligation Stacks

Roles, not technology, allocate the duties (Article 3)

The EU AI Act does not ask what kind of company you are. It asks what your relationship to each AI system is. For systems classified as high-risk under Article 6, namely product-embedded systems under the Annex I sectoral legislation (Article 6(1)) and stand-alone systems in the Annex III use-case areas (Article 6(2)), the Article 3 definitions allocate two very different workloads. The provider must make the system lawful before anyone can use it. The deployer must keep it lawful in operation. If you are unsure which definition catches you, resolve that first: am I a provider or a deployer walks through the edge cases.

Many companies carry both stacks

Because roles attach per system, a single organisation often carries both stacks at once: provider of the fraud-scoring model it built, deployer of the procured CV-screening tool in its HR department. Your obligation register has to record the role per system. A company-level label such as "we are a deployer" is the kind of shortcut that causes obligations to be missed.

The Provider Stack: Articles 8–22 Plus the Market-Entry Gauntlet

What the system itself must meet (Articles 8–15)

Article 8 anchors the stack: high-risk AI systems must comply with the requirements of Chapter III, Section 2, taking into account their intended purpose and the state of the art. Seven articles spell out what that means.

Risk management (Article 9). A continuous, iterative risk management process across the entire lifecycle: identify, estimate, evaluate and mitigate. We unpack it in the Article 9 risk management system.
Data governance (Article 10). Quality criteria for training, validation and testing datasets, covering relevance, representativeness, and examination for possible biases.
Technical documentation (Article 11). Drawn up before market placement or putting into service, covering the Annex IV elements, and kept up to date. The Annex IV technical documentation template gives you the full structure.
Record-keeping (Article 12). The system must technically allow automatic recording of events (logs) over its lifetime.
Transparency and instructions for use (Article 13). This is the hinge between the two stacks. The instructions the provider writes here are what the deployer is legally bound to operate within under Article 26(1).
Human oversight (Article 14). Oversight measures designed into the system, or identified by the provider for the deployer to implement.
Accuracy, robustness and cybersecurity (Article 15). Appropriate levels of each, performing consistently throughout the lifecycle.

The provider's conduct duties (Article 16)

Article 16 then layers the provider's own conduct duties on top: indicate your identity and contact details; run a quality management system under Article 17; keep the technical documentation for ten years (Article 18); retain the automatically generated logs under your control (Article 19); take corrective action and inform downstream actors when something does not conform (Article 20); and cooperate with competent authorities (Article 21). Providers established outside the EU must appoint an authorised representative in the Union before making the system available (Article 22). The line-by-line breakdown lives in Article 16 provider duties.

Market entry (Articles 43, 47, 48 and 49)

Nothing reaches the EU market until the provider has completed four steps:

Conformity assessment (Article 43). Internal control under Annex VI for most Annex III systems. For Annex III point 1 biometric systems, the provider chooses between Annex VI and the notified-body procedure of Annex VII where harmonised standards have been applied in full.
EU declaration of conformity (Article 47). Drawn up with the Annex V content and kept for ten years.
CE marking (Article 48). Affixed visibly, legibly and indelibly, or digitally for systems provided digitally.
Registration (Article 49). The provider registers itself and the system in the EU database established under Article 71 before placing it on the market.

That is the provider workload in outline. The deep dive is provider obligations in full.

The Deployer Stack: Article 26 in Operation

The deployer's stack is operational, not design-level. Article 26 does not ask you to re-engineer the system, only to run it responsibly.

Operate within the instructions for use (Article 26(1))

Deployers must take appropriate technical and organisational measures to use the system in accordance with the provider's instructions for use. The instructions are the legal perimeter of your use. Step outside them and you risk an Article 26 breach, and an Article 25 role shift if the deviation amounts to a new intended purpose.

Assign competent human oversight (Article 26(2))

Human oversight must be assigned to natural persons with the necessary competence, training, authority and support. A nominal owner without the authority to halt the system does not satisfy the article.

Control input data and monitor operation (Article 26(4) and 26(5))

To the extent the deployer exercises control over input data, that data must be relevant and sufficiently representative in view of the system's intended purpose (Article 26(4)). Deployers also monitor operation on the basis of the instructions for use (Article 26(5)). Where use may present a risk within the meaning of Article 79(1), they inform the provider or distributor and the relevant market surveillance authority without undue delay, and suspend use. On a serious incident, the deployer informs first the provider, then the importer or distributor and the authorities, feeding the provider's own Article 73 reporting duty.

Logs, workers and affected persons (Article 26(6), (7) and (11))

Automatically generated logs under the deployer's control must be retained for a period appropriate to the intended purpose, and for at least six months, unless other Union or national law provides otherwise (Article 26(6)). Before putting a high-risk system into service at the workplace, employer-deployers must inform workers' representatives and affected workers (Article 26(7)), and deployers must inform natural persons that they are subject to a high-risk AI system where it makes or assists decisions about them (Article 26(11)). Public-authority deployers also verify and complete registration under Article 49(3), and every deployer cooperates with competent authorities (Article 26(12)).

The fundamental rights impact assessment (Article 27)

A subset of deployers carries one more duty: a fundamental rights impact assessment (FRIA). It applies to deployers that are bodies governed by public law or private entities providing public services, and to deployers of systems under Annex III points 5(b) and 5(c), namely creditworthiness assessment and life and health insurance risk assessment and pricing. The FRIA is performed before first use, with notification to the market surveillance authority. The complete walkthrough is deployer obligations in full, and the article-by-article text is Article 26 deployer duties.

Side by Side: Provider vs Deployer Duties for the Same System

The table below sets both stacks against each other, duty area by duty area, for one and the same high-risk AI system.

Duty area	Provider	Deployer
Risk management	Runs the Article 9 lifecycle risk management system	Monitors live operation; feeds risks back to provider and authority (Article 26(5))
Data	Article 10 data governance for training, validation and testing data	Ensures relevant, sufficiently representative input data where it controls inputs (Article 26(4))
Documentation	Draws up Annex IV technical documentation (Article 11) and instructions for use (Article 13)	Operates within those instructions (Article 26(1))
Logging	Builds automatic logging into the system (Article 12); keeps logs under its control (Article 19)	Retains logs under its control for at least six months (Article 26(6))
Human oversight	Designs oversight measures into the system (Article 14)	Assigns competent, trained, supported people to exercise it (Article 26(2))
Accuracy, robustness, cybersecurity	Must achieve them by design (Article 15)	Suspends use when operation presents an Article 79(1) risk
Quality management	Maintains an Article 17 QMS	No deployer equivalent
Market entry	Conformity assessment (Article 43), EU declaration of conformity (Article 47), CE marking (Article 48), EU database registration (Article 49)	None — except registration of use by public-authority deployers (Article 49(3))
Incidents and post-market	Runs post-market monitoring (Article 72); reports serious incidents (Article 73)	Informs provider/distributor and market surveillance authority; suspends use (Article 26(5))
People affected	Informs via the instructions for use	Informs workers' representatives (Article 26(7)) and affected persons (Article 26(11)); certain deployers run the Article 27 FRIA before first use

Reading the table: complementary stacks, not duplicates

Almost no row contains the same duty twice; the stacks interlock rather than overlap. The provider's Article 13 instructions are the deployer's Article 26(1) rulebook. The provider's Article 12 logging design makes the deployer's Article 26(6) retention possible. The deployer's Article 26(5) monitoring feeds the provider's Article 72 post-market system and Article 73 incident reports. Cut a duty from either stack and the loop breaks for both parties.

Article 25: When the Deployer Becomes the Provider

Three triggers: rebrand, substantially modify, repurpose (Article 25(1))

Article 25(1) lists three ways a distributor, importer, deployer or other third party becomes the provider of a high-risk system:

Rebrand (Article 25(1)(a)). Putting your name or trademark on a high-risk AI system already on the market or in service. White-labelling a vendor's system makes you its provider, contractual arrangements notwithstanding.
Substantially modify (Article 25(1)(b)). Making a substantial modification to a high-risk system already on the market, in such a way that it remains high-risk.
Repurpose (Article 25(1)(c)). Modifying the intended purpose of an AI system, including a general-purpose AI system, that was not high-risk, so that it becomes high-risk. Repurposing a general tool for recruitment screening under Annex III point 4 is the textbook case.

What the role shift costs (Article 25(2))

The consequence is the full Article 16 stack in your name: fresh conformity assessment, new declaration of conformity, CE marking and registration. The original provider ceases to be the provider for that system but must cooperate and hand over the information and documentation the new provider needs (Article 25(2)). Fine-tuning, deep customisation and rebranding of procured systems are the most common accidental role shifts, so every change to a procured high-risk system should pass an Article 25 check before it ships.

When Both Stacks Bite: Dates, the Omnibus Caveat and Penalties

2 December 2027: agreed, but not yet law

Both stacks attach from the same application date. Providers and deployers go live together, with no deployer grace period. As enacted, Article 113 still reads 2 August 2026 for stand-alone high-risk systems under Annex III. The Digital Omnibus, the provisional political agreement of 6–7 May 2026 whose COREPER text was confirmed around 13 May 2026, agreed to defer Annex III stand-alone high-risk obligations (Article 6(2)) to 2 December 2027 and Annex I product-embedded systems (Article 6(1)) to 2 August 2028. As of June 2026 that is agreed, not yet law: the European Parliament plenary vote, formal Council adoption and Official Journal publication are still outstanding. The new dates are fixed calendar dates. The standards-contingent "stop the clock" proposal was rejected, so do not plan around harmonised-standards availability.

What already applies regardless

Not everything moved. The Article 5 prohibitions have applied since 2 February 2025, and the GPAI rules in Articles 51–55 since 2 August 2025. Most Article 50 transparency obligations are unchanged, with content marking and watermarking, plus the new CSAM/"nudifier" ban, applying from 2 December 2026. On classification, the draft Commission guidelines under Article 6(5) were published on 19 May 2026, with the targeted consultation open until 23 June 2026 and the final version expected later in 2026. The draft guidelines are not legally binding; authoritative interpretation rests with the Court of Justice of the EU.

The price of running the wrong stack (Article 99)

Breaches of provider obligations under Article 16 or deployer obligations under Article 26 draw fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). Breaches of the Article 5 prohibitions sit in the top tier, at up to €35 million or 7% (Article 99(3)). Supplying incorrect, incomplete or misleading information to notified bodies or competent authorities risks up to €7.5 million or 1% (Article 99(5)). SMEs and start-ups benefit from the proportional cap in Article 99(6), under which each fine is the lower of the percentage or the fixed amount.

Takeaway: Know Which Stack(s) You Carry, Per System

A three-question role check for every high-risk system

Run every system in your AI inventory through three questions:

Did we develop it, or place it on the market under our own name or trademark? If yes, you carry the provider stack: Articles 8–22 plus market entry.
Do we operate it under our own authority in a professional context? If yes, you carry the deployer stack: Article 26, plus Article 27 where the FRIA triggers catch you.
Have we rebranded, substantially modified or repurposed it? If yes, Article 25 has shifted the provider stack onto you, on top of whatever you carried before.

Many companies answer yes to question 1 for the product they sell and yes to question 2 for the HR, credit or biometric tools they buy. That is normal. What matters is that the compliance register records the role per system, not per company. The AI system register template is built around exactly that per-system role field.

Keeping both stacks evidenced in one place

Both stacks converge on the same evidence trail: technical documentation, logs, oversight records, incident reports. A provider's Annex IV file and a deployer's Article 26 operating evidence overlap heavily in the underlying artefacts, so treating roles per system lets you manage that evidence once rather than in duplicate.

For each high-risk system in your inventory, decide which obligation stack your organisation carries (provider, deployer, or both) and record the reasoning. Then check every procured system for Article 25 exposure: any rebranding, substantial modification or repurposing means the provider stack has landed on you, fresh conformity assessment included. That single per-system decision determines every deadline, document and duty that follows.

How Confir helps

Confir maps the role per AI system, whether provider, deployer, or both, and generates the matching obligation checklist: the Articles 8–22 and market-entry stack for provider-role systems, the Article 26 operational stack (plus the Article 27 FRIA where it triggers) for deployer-role systems, and an Article 25 flag whenever a procured system has been rebranded, modified or repurposed. The synthesis engine is deterministic and rule-based: the same logic every time, no model inference, no hallucination. The obligation register your auditors see is exactly the register the regulation derives.

Frequently Asked Questions

What are the provider obligations for high-risk AI under the EU AI Act? Providers must ensure the system meets the Section 2 requirements — risk management (Article 9), data governance (Article 10), technical documentation (Article 11), record-keeping (Article 12), transparency (Article 13), human oversight (Article 14) and accuracy, robustness and cybersecurity (Article 15) — plus the Article 16 duties: a quality management system, conformity assessment, EU declaration of conformity, CE marking and registration in the EU database.

What are deployer obligations under Article 26 of the EU AI Act? Deployers must use high-risk AI systems in line with the provider's instructions for use, assign human oversight to competent and trained staff, ensure relevant input data where they control it, monitor operation, report risks and serious incidents, retain automatically generated logs for at least six months, and inform workers and affected persons. Certain deployers must also complete a fundamental rights impact assessment under Article 27.

What is the difference between a provider and a deployer under the EU AI Act? 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. A deployer uses an AI system under its own authority in a professional context. For high-risk systems, providers carry the design and market-entry stack (Articles 8–22), while deployers carry the operational duties in Article 26.

Can a deployer become a provider under the EU AI Act? Yes. Under Article 25, a deployer is treated as the provider of a high-risk AI system if it puts its own name or trademark on the system, makes a substantial modification that keeps it high-risk, or changes the intended purpose of a non-high-risk system so it becomes high-risk. The full provider stack — including a fresh conformity assessment — then applies.

Who has to carry out a fundamental rights impact assessment (FRIA)? Article 27 requires a FRIA from deployers that are bodies governed by public law or private entities providing public services, and from deployers of high-risk systems for creditworthiness assessment or life and health insurance risk pricing under Annex III points 5(b) and 5(c). It must be completed before first use, and the market surveillance authority must be notified.

When do high-risk AI obligations start to apply? The statute currently sets 2 August 2026 for stand-alone high-risk systems under Annex III. The Digital Omnibus, provisionally agreed in May 2026, would defer this to 2 December 2027, and Annex I product-embedded systems to 2 August 2028 — but it is not yet law, pending the European Parliament plenary vote, Council adoption and Official Journal publication. The agreed dates are fixed calendar dates.

What are the penalties for breaching provider or deployer obligations? Breaches of provider obligations under Article 16 or deployer obligations under Article 26 can draw fines of up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Supplying incorrect, incomplete or misleading information to authorities risks up to EUR 7.5 million or 1% (Article 99(5)). SMEs and start-ups benefit from a proportional cap under Article 99(6).