Provider vs deployer under the EU AI Act: which are you?

Before you draft a single page of an EU AI Act file, answer one question: for this system, are we the provider or the deployer? Everything downstream hangs on it — whether you owe technical documentation and a conformity assessment or a shorter set of operational controls, whether you register in the EU database, and what a mistake costs. Most SMEs are deployers of several systems and providers of one or two without having noticed.

Two definitions, and two hinges

Article 3(3) defines a provider as a body that “develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge”. Article 3(4) defines a deployer as a body “using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity”. Two hinges do all the work. The provider hinge is under its own name or trademark: you can outsource every line of code and still be the provider, and giving the system away for free changes nothing. The deployer hinge is under its authority: professional use, on your decisions, with your people. If the regulation itself is new to you, start with the plain-English overview of the EU AI Act.

Five SME scenarios, five answers

• A recruitment agency using an off-the-shelf CV-ranking SaaS — deployer. The tool runs under the agency’s authority but ships under the vendor’s brand. It falls under Annex III point 4(a), analysing and filtering job applications, so it is a high-risk system under Annex III and the agency carries the Article 26 duties, not the Article 16 ones.
• The vendor that built and sells that SaaS — provider. It developed the system and places it on the Union market under its own trademark, so it owes the full Chapter III package.
• A bank fine-tuning a vendor’s scoring model on its own loan book — provider. Credit scoring is Annex III point 5(b). Retraining on the bank’s own data is a change the vendor’s conformity assessment never foresaw, which is precisely what Article 25(1)(b) captures. The bank also sits in the narrow group that must run a fundamental rights impact assessment.
• A clinic using a CE-marked triage tool exactly as instructed — deployer. The device manufacturer is the provider under Article 25(3), because the system is placed on the market with a product under the manufacturer’s name. The clinic stays a deployer for as long as it stays inside the declared intended purpose.
• A company wrapping a foundation-model API into a customer-facing assistant — provider of that assistant. It trained nothing, but it built and ships an AI system under its own name. The underlying model carries separate GPAI model obligations on the model provider, and Article 50(1) still requires the assistant to tell users they are talking to a machine.

What a provider owes

The provider set is the heavy one. Articles 9 to 15 carry the substantive requirements for high-risk systems: a lifecycle risk management system (Art. 9), data governance for training, validation and testing sets (Art. 10), technical documentation drawn up before market placement (Art. 11, contents in Annex IV), automatic logging (Art. 12), instructions for use that let deployers comply (Art. 13), design for human oversight (Art. 14), and accuracy, robustness and cybersecurity (Art. 15). Article 16 adds the procedural chain: a quality management system (Art. 17), document and log retention (Arts. 18 and 19), conformity assessment (Art. 43), EU declaration of conformity (Art. 47), CE marking (Art. 48), registration in the EU database (Art. 49) and corrective actions (Art. 20). After launch, Article 72 requires a documented post-market monitoring system and plan, and Article 73 sets serious incident deadlines: 15 days as a rule, 10 days where a person has died, 2 days for widespread infringement or serious disruption of critical infrastructure. Our page on EU AI Act compliance software maps those artefacts to a working process.

What a deployer owes

• Use it as instructed. Article 26(1): technical and organisational measures ensuring use in accordance with the instructions for use.
• Assign human oversight to named people. Article 26(2): natural persons with the necessary competence, training and authority — and the support to act on what they see.
• Control your input data. Article 26(4): where you control the input, ensure it is “relevant and sufficiently representative in view of the intended purpose”.
• Monitor, suspend, escalate. Article 26(5): monitor operation, and where use presents a risk, inform the provider and the market surveillance authority and suspend without undue delay.
• Keep the logs. Article 26(6): retain automatically generated logs under your control for a period appropriate to the intended purpose, and in any case at least six months.
• Tell your workforce. Article 26(7): before putting a high-risk system into service at the workplace, inform workers’ representatives and the affected workers.
• Tell the people affected. Article 26(11): inform natural persons that a high-risk system is being used on decisions about them. Article 26(9) also requires you to feed the provider’s information into your GDPR data protection impact assessment.

Two duties sit on top. Article 27 requires a fundamental rights impact assessment before first use, but only from deployers that are bodies governed by public law or private entities providing public services, and from any deployer of Annex III point 5(b) creditworthiness systems or 5(c) life and health insurance risk assessment and pricing. It covers the process of use, the period and frequency, the categories of persons affected, the specific risks of harm, the human oversight measures and the complaint arrangements, and is then notified to the market surveillance authority on the AI Office template. Article 50 splits transparency across roles: providers disclose AI interaction (50(1)) and mark synthetic content machine-readably (50(2)); deployers disclose emotion recognition and biometric categorisation (50(3)) and label deep fakes and AI-generated text published to inform the public (50(4)), at the latest at first interaction or exposure (50(5)). The Article 4 AI literacy duty binds both roles. So far so tidy — except that the line between them moves. Article 25 provides that a distributor, importer, deployer or other third party “shall be considered to be a provider of a high-risk AI system” in three cases, and none of them requires you to have written a line of code.

The role flip: when a deployer becomes a provider

1. You put your name or trademark on it — Article 25(1)(a). White-labelling a high-risk system already on the market makes you its provider with no technical change whatsoever. This catches resellers, and it catches groups that take a vendor tool, rebrand it as an internal product with its own name, support desk and terms of use, and push it across subsidiaries. The trigger is branding, not engineering.
2. You make a substantial modification — Article 25(1)(b). Article 3(23) defines this as a change after placing on the market or putting into service “which is not foreseen or planned in the initial conformity assessment”. Fine-tuning on your own data, altering decision thresholds or scoring rules, adding a component the provider never assessed, or rebuilding the data pipeline that feeds it are all candidates. Continued learning that stays inside limits the provider pre-declared and assessed is not. The test is documentary: is this change inside or outside what the conformity assessment covered?
3. You change the intended purpose — Article 25(1)(c). Article 3(12) ties intended purpose to what the provider specified. Take a system that is not high-risk, point it at an Annex III use, and it becomes high-risk with you as its provider. The recurring cases: a general text-analytics tool repointed at ranking job applicants, a generic model repurposed to assess creditworthiness, a workforce dashboard extended into promotion and termination decisions.

The consequences are not shared. Under Article 25(2) the original provider ceases to be the provider of that specific system, but must cooperate closely, make available the necessary information and provide the reasonably expected technical access and other assistance — unless it has clearly specified that its system is not to be changed into a high-risk one, in which case the burden lands entirely on you. Article 25(3) puts the product manufacturer in the provider seat where a high-risk system is placed on the market together with a product under the manufacturer’s name or trademark. Article 25(4) requires providers and third parties supplying components, services, tools or data to agree in writing on the information, capabilities, technical access and assistance needed for compliance, with free and open-source components carved out. Flip roles and you inherit the entire Article 16 chain, plus the Article 99 exposure that comes with it: up to EUR 15 million or 3% of worldwide annual turnover for breaches of provider or deployer obligations, capped for SMEs at whichever is lower. The tiers are set out in our guide to EU AI Act penalties and fines.

Importers, distributors and providers outside the EU

Three shorter roles complete the chain. An importer (Art. 3(6)) is an EU-established entity placing on the market a system bearing a third-country entity’s name or trademark; Article 23 requires it to verify that the conformity assessment was carried out and that documentation, CE marking, instructions and an authorised representative are in place. A distributor (Art. 3(7)) is anyone else in the supply chain making a system available on the Union market; Article 24 requires it to check CE marking and documentation, to refrain from distributing where it knows or should know the system is non-compliant, and to act on non-conformity. A provider established outside the EU must, under Article 22(1), appoint an EU authorised representative by written mandate “prior to making their high-risk AI systems available on the Union market”; that representative verifies the declaration and documentation, keeps them for 10 years and cooperates with authorities. All three flip to provider on any Article 25(1) trigger. Our solutions overview shows how roles are tracked system by system.

What to do this week

1. Inventory every system. Include AI features already embedded in SaaS you pay for — screening inside an ATS, scoring inside a lending platform, assistants inside your CRM. Undeclared provider status hides in shadow AI.
2. Assign exactly one role per system, per deployment. Roles attach to systems, not to companies. The same SME is routinely a deployer of five systems and the provider of one. If you resell or rebrand, settle that in writing before a customer asks.
3. Record the reasoning. One page per system: who developed it, whose name it ships under, whether and how you modified it, the declared intended purpose versus your actual use, the Annex III point it touches if any, and the role you concluded. That page is the first thing a market surveillance authority will ask for; our EU AI Act compliance checklist for SMEs gives the fields.
4. Re-check on every material change, and diary the dates. Contract renewal, model swap, fine-tune, new use case, new market. Prohibited practices and the Article 4 AI literacy duty have applied since 2 February 2025 and GPAI model obligations since 2 August 2025; stand-alone Annex III high-risk systems now apply from 2 December 2027 and product-embedded Annex I systems from 2 August 2028 — see the revised deadlines after the Digital Omnibus.

If you want a first pass in minutes rather than weeks, the free Risk Checker walks a system through role and risk tier and leaves you a record you can file. This article is general information, not legal advice; for a specific system, take qualified advice.