That distinction is the one thing most compliance write-ups get wrong, so it’s worth stating plainly before anything else: Article 72 is a provider obligation. If you’re a deployer, that is, an organisation using a high-risk AI system someone else built, you are not the one who has to write and run the formal Article 72 monitoring plan. You have a narrower but still binding duty under Article 26(5), and understanding where your responsibility starts and stops is the point of this guide.
Roles: Who this page is for, and who does what
The EU AI Act draws a hard line between two roles:
- Provider: Builds the AI system, or has it built and places it on the market under its own name. Carries the heavy lifting: risk management, technical documentation, conformity assessment, and the Article 72 monitoring system itself.
- Deployer: Uses the AI system under its own authority. That’s most organisations buying or licensing AI: HR teams running a recruitment tool, banks using a credit-scoring model, insurers using a claims triage system.
If you’re a deployer, Article 26(5) is your operative clause. It requires you to:
- Monitor the operation of the system based on the instructions for use the provider gave you.
- Inform the provider, in line with Article 72, of anything relevant you observe.
- Where you have reason to think the system presents a risk (as defined in Article 79(1)), tell the provider or distributor and the relevant market surveillance authority without undue delay, and stop using the system if needed.
- Where you identify a serious incident, tell the provider first, then the importer or distributor, then the market surveillance authorities. If you can’t reach the provider, Article 73 applies to you directly.
There’s one further wrinkle. If you fine-tune, rebrand, or substantially modify a system you’ve procured, you can trip Article 25 and become a provider yourself, at which point Article 72’s full obligations land on you. If your team is doing meaningful customisation on top of a vendor model, that’s worth checking before you assume you’re only ever the deployer.
What Article 72 actually requires (and why deployers should understand it even though it isn’t theirs to run)
Article 72 obliges providers of high-risk AI systems to establish and document a post-market monitoring system, proportionate to the technology and the risk involved. That system must:
- Actively and systematically collect, document and analyse data on the system’s real-world performance, throughout its lifetime.
- Draw on data supplied by deployers as well as data collected through other sources.
- Allow the provider to keep checking that the system continues to meet the requirements in Chapter III, Section 2 (the high-risk obligations: risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness).
- Sit on top of a documented post-market monitoring plan, itself part of the technical documentation, using a template the Commission is required to publish by 2 February 2026.
For deployers, the practical point is this: you are one of the data sources the provider’s monitoring system depends on. If your monitoring is patchy, so is theirs, and the gap shows up as a compliance finding against the wrong party during an audit or investigation.
What “serious incident” means, and the reporting clock
Article 73 defines the escalation path when something goes wrong. As a deployer, if you identify a serious incident, you must tell the provider immediately, then the importer or distributor, then the relevant market surveillance authorities.
The provider’s own reporting clock, once it’s aware, runs like this:
- 15 days: Standard reporting window from the point the provider (or deployer) establishes, or reasonably suspects, a causal link between the system and the incident.
- 2 days: For a widespread infringement or a serious incident of the kind defined in Article 3(49)(b), such as a serious and irreversible disruption to critical infrastructure management.
- 10 days: Where the incident has resulted in someone’s death.
- An incomplete initial report is permitted, followed by a full one, if that’s what timely reporting needs.
A serious incident, in the Act’s own terms, is one that directly or indirectly leads to death or serious harm to a person’s health, a serious and irreversible disruption to critical infrastructure, an infringement of fundamental rights obligations, or serious damage to property or the environment. If your monitoring can’t tell the difference between routine model drift and something that meets that bar, you can’t meet the reporting clock, because you won’t know you’re on it.
Building a deployer-side monitoring practice that actually supports Article 26(5)
None of the above is optional, and none of it happens by accident. A workable deployer-side monitoring setup usually needs:
- A named owner. Someone accountable for watching the system’s operation and deciding when something crosses into “inform the provider” or “inform the authority” territory.
- A live view of performance, not a quarterly report. Article 26(5) monitoring is an ongoing duty tied to the instructions for use, not a periodic check-in.
- A defined threshold for what counts as a risk under Article 79(1). Waiting for an obvious failure means you’ll miss the point where you were supposed to act.
- A contractual channel back to the provider. Article 26(5) only works if the provider has agreed to receive and act on what you send them. Build this into procurement, not as an afterthought.
- Log retention for at least six months under Article 26(6), for logs generated automatically by the system that are under your control.
- A record of what you monitored and when. Market surveillance authorities can ask for this during an investigation, and “we’re sure it was fine” isn’t documentation.
This is the layer where Deeploy sits: continuous monitoring of a deployed model’s real-world performance, drift, and anomalies, structured so the output maps directly to what Article 26(5) asks a deployer to watch for and what Article 72 asks a provider to receive.
Deadlines in The Digital Omnibus: what’s changing, and what isn’t
On 7 May 2026 the Council and Parliament reached a provisional political agreement on the Digital Omnibus on AI, which pushes back the application dates for high-risk obligations. The European Parliament approved the final text on 16 June 2026 and the Council gave final adoption on 29 June 2026. The Regulation (EU) 2026/1744 was signed on 8 July 2026, published in the Official Journal in July 2026, and entered into force on 27 July 2026, so the dates below are now the legally binding ones.
What the regulation changes, now that it’s in force:
- Stand-alone Annex III high-risk systems: Application deferred from 2 August 2026 to 2 December 2027.
- High-risk AI embedded in regulated products (Annex I): Application deferred from 2 August 2027 to 2 August 2028.
- Article 50 transparency obligations: Not deferred. Still apply from 2 August 2026.
- Watermarking under Article 50(2): A shorter grace period to 2 December 2026 for systems already on the market, rather than the original date.
What doesn’t change: the post-market monitoring obligation itself, the provider/deployer split, and the incident reporting mechanism under Article 73. The Omnibus moves the date high-risk obligations bite; it doesn’t rewrite what those obligations are. Treat the extra runway as time to build the monitoring practice properly, not as a reason to wait.
Frequently asked questions
The post-market monitoring plan is a formal, documented system that sits in the provider's technical documentation under Article 72. A deployer's Article 26(5) duty is operational: watch the system in your own environment and feed what you see back to the provider. You don't need to produce the provider's plan, but your monitoring needs to be good enough to be useful to it.
No. Article 26(5) is your obligation as deployer and can't be discharged by pointing to the provider's Article 72 system. You need your own visibility into how the system behaves in your environment, because you're the one who sees the real operating conditions.
Article 72 applies to providers of high-risk AI systems. Deployers have a separate, narrower duty under Article 26(5): monitor the system's operation and inform the provider of what you observe, in line with Article 72.
Not yet in law. The new dates (2 December 2027 for Annex III high-risk systems, 2 August 2028 for Annex I) were politically agreed in May 2026 and endorsed by Parliament and Council in June 2026, but they only bind once published in the Official Journal. Until then, the original 2 August 2026 date stands.
Article 50 applies from 2 August 2026 and is not affected by the Digital Omnibus. From that date, deployers must inform users when they are interacting with a chatbot, providers must ensure AI-generated content is machine-detectable, and deployers must disclose when emotion recognition or biometric categorisation systems are being used.
Potentially. If your fine-tuning constitutes a "substantial modification" to the original model, you may be reclassified as a provider and take on the associated obligations. The AI Office has provided partial guidance on this boundary but it remains a grey area. Extensive fine-tuning that changes the system's intended purpose or performance profile carries the higher risk of triggering provider status.
Deployers must retain automatically generated logs for at least six months. Providers must retain technical documentation for ten years after the system is placed on the market. These periods may overlap with GDPR retention obligations and should be reconciled in your data governance policy.
A serious incident is any incident that results in, or could plausibly result in, the death of a person, serious injury, significant damage to property, or a significant disruption to critical infrastructure. It also covers situations where fundamental rights are seriously and irreversibly affected. Providers and deployers of high-risk AI systems must report serious incidents to the relevant national authority without undue delay.
The Act does not specify a single reporting window but requires reporting "without undue delay." Guidance and national implementations are converging on 15 working days as the operative standard for most serious incidents, with shorter windows (72 hours in some national interpretations) for the most severe cases. Organisations should treat this as an operational planning constraint and build detection and escalation processes accordingly.
