EU AI Act: provider or deployer? The one word that decides your obligations

Two companies use the same AI recruitment tool. One must run a full conformity assessment, compile technical documentation, register the system in an EU database and affix CE marking. The other must assign trained human oversight, keep logs and monitor operation. Same software, radically different obligations, and the difference comes down to one word: role.

Most AI Act commentary fixates on risk tiers. Tiers matter, but in practice the planning-changing question is almost always the role question, because your role decides which obligation stack you carry. Get it wrong and you budget for the light list while owing the heavy one.

The two roles, in plain terms

A provider develops an AI system, or has one developed, and places it on the EU market under its own name or brand. A deployer uses an AI system under its own authority in a professional context. The vendor selling recruitment software is the provider; the employer screening applicants with it is the deployer.

Two supporting roles complete the cast: importers and distributors carry lighter gatekeeping duties, and a non-EU provider of a high-risk system must appoint an authorised representative established in the EU as its contact point.

Note what the definitions do not mention: where you are incorporated. The Act applies to providers placing systems on the EU market wherever they are established, and to providers and deployers outside the EU where the system's output is used in the EU. A Singapore SaaS firm with one Frankfurt customer is in scope. Geography of use is the test, not geography of headquarters.

What each role owes for a high-risk system

The provider of a high-risk system carries what amounts to a regulated product-development regime: a lifecycle risk management system, data governance with bias examination, technical documentation, automatic logging, instructions for use, human oversight designed in, declared and tested accuracy and robustness, a quality management system, conformity assessment and CE marking, EU database registration, and post-market monitoring with serious-incident reporting.

The deployer's list is shorter but real: operate the system according to the provider's instructions, assign named and trained human oversight, ensure input data relevance where you control it, monitor operation and suspend use on serious risk, retain logs, inform workers before workplace deployment, meet information duties toward affected people, and, for public bodies and certain private deployers (credit scoring and life and health insurance pricing among them), complete a fundamental rights impact assessment before first use.

The deployer list rewards organisations that already run basic AI governance: an inventory, named owners, oversight procedures and monitoring records are most of it.

The three traps that flip a deployer into a provider

The expensive mistakes in this area are rarely about misreading the lists. They are about changing role without noticing. Three patterns do it:

1. Rebranding. Put your own name or trademark on a high-risk system already on the market and you take on the provider's obligations for it. Article 25 allows one escape here that it allows nowhere else: the transfer applies "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated", so a white-label agreement can leave the duties where they were. The carve-out covers rebranding only. Nothing you write into a contract undoes the next two.
2. Substantial modification. Materially change a system, including by retraining it on your own data in ways that alter its behaviour or purpose. A bank that takes a vendor's credit model and substantially retrains it on its own lending book has most likely become the provider of the modified system, whether or not anyone in the building has used that word.
3. Repurposing. Use a system for a high-risk purpose its provider never intended, and you become the provider for that use.

The practical defence is unglamorous: record the role, per system, in your AI register, and treat any retraining, rebranding or new use case as a trigger to re-ask the question before it goes live.

The timetable, as amended in June 2026

In June 2026 the EU adopted a simplification package that moved the Act's biggest deadline. A large share of the guidance still in circulation cites the superseded dates, and an undated summary misleads silently. The operative table:

2 February 2025	Prohibited practices; AI literacy duty
2 August 2025	General-purpose AI model obligations
2 August 2026	Article 50 transparency duties: chatbots disclosing themselves, synthetic and manipulated content labelled, deepfakes disclosed
2 December 2026	End of the watermarking grace period for systems placed on the market before 2 August 2026
2 December 2027	High-risk obligations for stand-alone (Annex III) systems, deferred from 2 August 2026
2 August 2028	High-risk obligations for AI embedded in regulated products (Annex I), deferred from 2 August 2027

Read the deferral correctly: it is breathing room for standards bodies and regulators, not a policy retreat. The prohibitions, the AI literacy duty, the general-purpose AI duties and the Article 50 transparency rules are all in force today. Only the high-risk stack moved, and it moved to published dates you can plan against.

The transparency duties are the ones most often missed, because they arrived without a deferral and they catch ordinary products rather than exotic ones. If you run a customer chatbot, generate marketing images or publish synthetic audio, those obligations applied from 2 August 2026. Systems already on the market before that date have until 2 December 2026 to meet the machine-readable marking requirement; everything launched since has no grace period at all.

Article 50 splits by role as well

The same role question governs the transparency layer, and the split is not the intuitive one. The provider owes the chatbot disclosure, unless the AI nature is obvious from the circumstances, and the machine-readable marking of synthetic audio, image, video and text. The deployer owes notification to people exposed to emotion recognition or biometric categorisation, disclosure of deepfakes, and disclosure of AI-generated or manipulated text published to inform the public on matters of public interest where no human took editorial responsibility for it. A company that buys a generation tool and publishes its output carries the second list, not the first.

Two Commission documents now sit behind these duties. The Commission adopted non-binding guidelines on the Article 50 transparency obligations in July 2026, and the AI Office published a voluntary Code of Practice on Transparency of AI-generated Content in June 2026, which the Commission has assessed as an adequate route to the marking and detection duties; roughly 190 organisations had signed it by the time the obligations applied in August 2026. Neither replaces the Article, and signing the code is not a defence in itself, but a documented decision to follow published guidance is a stronger position than a documented decision to improvise.

What to do this quarter

• List your AI systems, and record a role for each one: provider, deployer, or both.
• Check the reach rules honestly: any EU customers, users or outputs puts you in scope.
• Screen every system against the prohibited practices list; anything close stops for legal review.
• Check your live products against Article 50 today, not in December: disclosure and labelling are already in force, and the grace period only covers systems that predate 2 August 2026.
• If you are a deployer of anything that will be high-risk, use the runway: oversight, logs and monitoring built now are evidence by December 2027.
• Wire the role question into change management, so retraining and rebranding trigger a re-check.
• If you white-label anyone's high-risk system, read the contract: rebranding moves the provider duties to you unless the agreement allocates them otherwise.