Insights · EU AI Act Readiness
The Act doesn’t ask who you are. It asks what you did.
Provider and deployer are not company types. They are roles assigned per system, and an organization can move between them without a procurement decision, a contract amendment, or anyone in legal being told.
Most organizations answering this question get it wrong in the same way. They ask what kind of company they are, when the AI Act asks what they did with a particular system.
The answer changes system by system. It can change on a Tuesday because someone materially changed a vendor system.
Definitions
The short answer
A provider develops an AI system, or has one developed for it, and places it on the EU 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 capacity.
If you develop a screening system and put it into service under your own name, you are its provider. If you license a vendor’s chatbot and run it as shipped, you are a deployer. If you do both, which most organizations do, you can hold both roles simultaneously across different systems.
Scoping
Why the role, not the company, is the unit of analysis
Article 25 is where this stops being academic. A deployer or other third party can become the provider of a high-risk AI system if it puts its own name or trademark on the system, makes a substantial modification to it while it remains high-risk, or changes the intended purpose of a system in a way that makes it high-risk.
In practice, this means a deployer can walk into provider obligations without a procurement decision, a contract amendment, or anyone in legal being told. A team fine-tunes a vendor system on internal data to improve accuracy. Depending on the nature and effect of that change, it may amount to a substantial modification and shift the organization into the provider role.
What looks like a defensible engineering choice can also be a compliance event. The obligations that follow — technical documentation, conformity assessment, registration — assume you have been building toward them for months.
Obligations
The obligation split
Provider obligations sit primarily in Articles 16, 17 and 43. Deployer obligations sit in Article 26. The split runs through every operative requirement.
| Provider — Art. 16, 17, 43 | Deployer — Art. 26 |
|---|---|
| Technical documentation | Use in line with the provider’s instructions for use, via appropriate technical and organisational measures |
| Quality management system (Art. 17) | Human oversight assigned to people with the competence, training and authority to exercise it |
| Conformity assessment, by the route Article 43 specifies | Input data relevant and sufficiently representative, where the deployer exercises control over that data |
| CE marking and declaration of conformity | Monitoring of operation, and suspension where risks emerge |
| EU database registration | Retention of automatically generated logs under the deployer’s control, generally at least six months |
| Instructions for use | Notification to workers before a high-risk system is used in the workplace |
| Post-market monitoring | Serious incident escalation in accordance with the Act |
Logging is not solely a provider-side issue. Article 26 requires deployers to retain logs automatically generated by a high-risk system, to the extent those logs are under their control. In practice, provider-side telemetry will not necessarily prove how your organization configured, supervised or used the system locally. That evidence has to come from your environment, and it has to exist before anyone asks for it.
The failure mode is symmetrical. Deployers assume they only need to consume the provider’s documentation, while providers assume the deployer carries the runtime-evidence burden. Both gaps can end up visible at the same time.
Timing
What is actually in force, as of today
This is where most content on the subject is now out of date, and where reading the amending instrument matters more than reading a summary.
Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026 — six days before the AI Act’s original 2 August 2026 high-risk deadline. It is enacted law, not a proposal.
| Date | Status |
|---|---|
| 2 Feb 2025 | In force. Article 5 prohibited practices. Article 4 AI literacy, binding on providers and deployers directly; wording amended 27 July 2026. |
| 2 Aug 2025 | In force. GPAI obligations. |
| 2 Aug 2026 | In force. Article 50 transparency duties. Not deferred by the Omnibus. |
| 2 Dec 2026 | Transition ends for Article 50(2) machine-readable marking, for synthetic-content systems already on the market before 2 August 2026. |
| 2 Dec 2027 | Deferred from 2 Aug 2026. Standalone high-risk systems under Article 6(2) and Annex III. |
| 2 Aug 2028 | Deferred. High-risk systems under Article 6(1), tied to the product-safety legislation listed in Annex I. |
Annex III covers areas including recruitment and employment, creditworthiness, education, biometrics, law enforcement, and migration and border control.
The Commission confirmed on 31 July 2026 that Article 50 would apply from 2 August 2026 and published guidance on its scope, exemptions and practical application, alongside work on the Code of Practice on transparency of AI-generated content. The Code is voluntary. The underlying statutory obligations are not.
The deadline many providers may have missed. Providers of AI systems, including GPAI systems, that generate synthetic audio, image, video or text and were placed on the market before 2 August 2026 have until 2 December 2026 to take the necessary steps to comply with Article 50(2)’s machine-readable marking requirements. It reaches generative tooling already on the market — precisely the category people may assume is grandfathered.
Non-compliance with many provider and deployer obligations can attract administrative fines of up to €15 million or, for undertakings, 3% of worldwide annual turnover, subject to Article 99’s penalty framework. Other categories of infringement under the Act carry different maximum penalties.
Transparency
Article 50 splits by actor too
Worth separating, because it is the part currently applicable.
Article 50(2) places the machine-readable marking obligation on providers of AI systems generating synthetic audio, image, video or text content. Article 50(4) reaches deployers directly in two important cases: deepfakes, and AI-generated or manipulated text published for the purpose of informing the public on matters of public interest. The latter has an exception where the content has undergone human review or editorial control and a person holds editorial responsibility for publication.
If your organization publishes AI-generated or manipulated text on public-interest topics, or deploys systems to generate or manipulate deepfake content, Article 50 is not something to put on the 2027 implementation plan. Its relevant obligations already apply.
Sequence
What the deferral is actually for
Sixteen months is meaningful relief. Operationally, though, it is better understood as implementation runway than dead time.
Role classification depends in part on what organizations do with systems after procurement. The practical allocation of responsibilities also depends heavily on contracts — and contracts are renegotiated on renewal cycles, not on demand. If your vendor agreements do not allocate provider and deployer responsibilities explicitly, you may discover the gap when the obligation lands, at which point your leverage is gone.
The realistic sequence for the runway available
- Inventory. Every AI system relevant to your EU operations, with the organization’s role assigned per system and the Article 6 / Annex III question answered.
- Contracts. Amend on the next renewal, not the month before December 2027. Define permitted modifications, and responsibility for assessing whether a change may constitute a substantial modification, rather than leaving Article 25 to be reconstructed after the fact. Settle who produces instructions for use, who retains which logs, and who notifies whom on a serious incident.
- Evidence architecture. Deployer logs, oversight records, input-data controls. Build these against systems you already run, because the format is easier to fix now than under examination.
- Article 50 now. Transparency, disclosure and the December 2026 Article 50(2) transition are current obligations, not future ones.
The standards ecosystem is still catching up — harmonised standards and national supervisory infrastructure were behind schedule, which formed part of the context for the deferral. That is not a reason to wait. It means parts of the framework organizations will eventually be assessed against are still developing while they prepare, and organizations that document their reasoning as they go will be better placed to explain the decisions they made.
References
Primary sources for this brief
- Regulation (EU) 2024/1689 (AI Act) — Article 3 definitions; Articles 16, 17, 25, 26, 43, 50, 99; Annex I and Annex III
- Regulation (EU) 2026/1744 (Digital Omnibus on AI) — published in the Official Journal 24 July 2026, in force 27 July 2026; amended application dates under Article 113
- European Commission — guidance on the scope, exemptions and practical application of Article 50 transparency obligations, July 2026
- European Commission — Code of Practice on transparency of AI-generated content (voluntary)
FAQ
Common questions
Am I a provider or a deployer under the EU AI Act?
It depends on what you do with each system, not what kind of company you are. You are a provider if you develop an AI system, or have one developed for you, and place it on the EU market or put it into service under your own name or trademark. You are a deployer if you use an AI system under your own authority in a professional capacity. Most organizations hold both roles across different systems.
What is the difference between provider and deployer obligations?
Provider obligations sit primarily in Articles 16, 17 and 43 and cover the product-side controls: technical documentation, quality management system, conformity assessment, CE marking, EU database registration, declaration of conformity, instructions for use and post-market monitoring. Deployer obligations sit in Article 26 and cover use in line with the provider’s instructions, human oversight, input data relevance where the deployer controls that data, log retention, workplace notification and serious incident escalation.
Can a deployer become a provider?
Yes. Under Article 25, a deployer or other third party becomes the provider of a high-risk AI system if it puts its own name or trademark on the system, makes a substantial modification to it while it remains high-risk, or changes the intended purpose of a system in a way that makes it high-risk. Fine-tuning a vendor system on internal data may, depending on the nature and effect of the change, amount to a substantial modification.
When do the high-risk obligations actually apply?
Regulation (EU) 2026/1744 entered into force on 27 July 2026 and deferred standalone high-risk obligations under Article 6(2) and Annex III from 2 August 2026 to 2 December 2027, and Article 6(1) obligations tied to Annex I product-safety legislation to 2 August 2028. Article 50 transparency duties, GPAI obligations applicable since August 2025, and the Article 5 prohibited-practices regime stayed on their applicable schedules.
We only use vendor tools. Does any of this reach us?
Yes. Deployer obligations attach to the organization using the system under its own authority, not to whoever built it. Using a third-party product makes the vendor conversation harder, not the obligation smaller — and Article 25 means the position can change if you modify what you licensed.
Do you know which role you hold, system by system?
Our free assessment scores your AI governance against the EU AI Act, ISO/IEC 42001 and the NIST AI RMF, and shows the gaps an assessor would find first. Twenty to thirty questions, about ten minutes, no signup.
Related reading
This brief reflects published information as of 20 September 2026 and describes Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, with phased application dates through 2028. Commission guidance and harmonised standards continue to develop — verify the current regulation text and Commission guidance before relying on them. Advisory content, not legal advice.
AI GRC Advisory · Insights · AI Governance Brief 03 · 20 Sep 2026