Regulation

EU AI Act: are you a provider or a deployer, and what changes

Most enterprises are deployers, and a few become providers without noticing. Digiton uses this test: who put the system on the market, whose name is on it, and who changed what it does.

By Brandon Da Costa, Founder, Digiton Dynamics. Reviewed 8 September 2026.

The test, in four questions

Work through these in order about one system, not about your company. A business can be a deployer of eleven systems and the provider of the twelfth.

1. Did you develop it, or have it developed, and put it on the market or into service under your own name or trademark? Article 3, point (3) defines a provider as the party that develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts the system into service under its own name or trademark, whether for payment or free of charge. If that is you, stop here. You are the provider.
2. Are you using it under your own authority, in a professional capacity? Article 3, point (4) defines a deployer as a natural or legal person, public authority, agency or other body using an AI system under its authority, except where the use is a personal non-professional activity. Buying a licence and switching it on for your staff makes you a deployer.
3. Is your name or trademark on it as customers see it? This is where a deployer flips. Article 25(1)(a) treats a distributor, importer, deployer or other third party as the provider of a high-risk AI system where they put their name or trademark on a system already placed on the market or put into service.
4. Have you changed what it does? Article 25(1)(b) covers a substantial modification to a high-risk system that leaves it high-risk. Article 25(1)(c) covers modifying the intended purpose of a system that was not classified as high-risk, including a general-purpose system, so that it becomes high-risk under Article 6.

Article 3, point (23) defines a substantial modification as a change made after the system was placed on the market or put into service, unforeseen and unplanned in the initial conformity assessment, that affects compliance with Chapter III, Section 2 or modifies the intended purpose the system was assessed against. Two things follow. Routine retraining inside the assessed purpose is not automatically substantial. Pointing a hiring tool at a credit decision is.

What a deployer owes

Article 26 is the deployer article for high-risk systems, and it survived the Digital Omnibus untouched. The duties that come up in every readiness engagement:

• Use the system according to the provider's instructions for use, with appropriate technical and organisational measures behind that (Article 26(1)).
• Assign human oversight to people with the competence, training and authority to exercise it, plus the support to do so (Article 26(2)).
• Where you control the input data, keep it relevant and sufficiently representative for the intended purpose (Article 26(4)).
• Monitor operation, tell the provider and the market surveillance authority when the system presents a risk, and suspend use (Article 26(5)). A serious incident goes to the provider first.
• Keep the automatically generated logs under your control for a period appropriate to the purpose, at least six months (Article 26(6)).
• Tell workers' representatives and affected workers before putting a high-risk system into use at the workplace (Article 26(7)).

Two more that catch specific deployers. Article 27(1) requires a fundamental rights impact assessment from deployers that are bodies governed by public law, private entities providing public services, and deployers of the Annex III point 5(b) and 5(c) systems, which are creditworthiness evaluation and credit scoring, and risk assessment and pricing for life and health insurance. The Digital Omnibus amended Article 27(4) so that where a data protection impact assessment under Article 35 of the GDPR already covers part of it, the deployer can cross-reference those sections rather than write them twice. Article 86 gives a person subject to a decision taken on the output of an Annex III high-risk system the right to a clear and meaningful explanation of the role the system played, and that right is exercised against the deployer.

Article 50 reaches much further than high-risk. A deployer of an emotion recognition or biometric categorisation system informs the people exposed to it (Article 50(3)). A deployer that generates or manipulates a deep fake discloses it, and a deployer publishing AI-generated text to inform the public on matters of public interest discloses that too, unless a human review process with named editorial responsibility sits behind the publication (Article 50(4)). The information goes to the person clearly, at the latest at the first interaction or exposure (Article 50(5)).

What a provider owes

Article 16 is a longer list, and it is a different kind of work. Compliance with the Chapter III, Section 2 requirements. Your name and contact address on the system, its packaging or its documentation. A quality management system under Article 17. The technical documentation under Article 18 and the automatically generated logs under Article 19. Conformity assessment, the EU declaration of conformity, CE marking, registration, corrective action and cooperation with authorities.

The practical difference: a deployer runs controls, a provider runs a conformity process. One is an operating discipline. The other is a product programme with a documentation burden that does not end at launch. This is why the three flip conditions in Article 25(1) matter more than any other paragraph in the Regulation for an enterprise that thinks of itself as a buyer.

Article 25(2) then does something buyers rarely expect. Where a flip happens, the provider that first placed the system on the market stops being the provider of that system, and has to cooperate with the new provider and hand over the information and technical access needed. That duty falls away where the initial provider clearly specified that its system is not to be changed into a high-risk system. Read your vendor's terms for that sentence, because it decides whether you inherit documentation or write it from nothing.

Where the December 2027 deferral applies, and where it does not

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and enters into force on the third day following publication. It moved the date of application of Chapter III, Sections 1, 2 and 3 to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I.

What did not move: the Article 5 prohibitions, the general-purpose model obligations, and the Article 50 transparency duties. The Omnibus did add a transitional route at Article 50, giving providers of generative systems placed on the market before 2 August 2026 until 2 December 2026 to comply with the Article 50(2) marking obligation. It also replaced Article 4, so the AI literacy duty is now framed as taking measures to support the development of AI literacy, with the amended text stating that no specific level has to be guaranteed for any individual.

So the deferral bought time on the heavy conformity work for high-risk systems. It bought nothing on transparency, nothing on the prohibitions, and nothing on knowing which of your systems are which.

What to write down now

Four lines per system, and they take an afternoon rather than a quarter.

1. Role. Provider or deployer, with the question from the test above that decided it, and the date.
2. Trademark position. Whether your name reaches the end user as the maker of the system. This is the flip condition people discover late, usually when marketing rebrands a white-labelled tool.
3. Intended purpose, as stated by the provider. Then your actual use, written next to it. The gap between those two sentences is the whole of Article 25(1)(c).
4. Change control. Who is allowed to change the purpose, the model or the data source, and who reclassifies afterwards.

Digiton keeps this record as part of readiness work rather than as a separate compliance artefact, because the version that lives beside the system gets updated and the version that lives in a shared drive does not. Where a role is genuinely arguable, the call belongs with your counsel. The four lines are what makes that a short conversation.

Frequently asked questions

Related