We'd like to set analytics cookies to measure which pages are useful. They are not needed to run the site, and declining changes nothing about what you can do here. Privacy Policy.
Conformity is assessed once; behaviour changes continuously. The monitoring plan is what turns the technical file from a launch artifact into a claim that stays true — and it is what feeds the Article 9 risk-management system and triggers Article 73 reports.
Every template on this page is readable in full right here, copyable as Markdown, and downloadable as a PDF. No sign-up, no e-mail address, no click-to-reveal.
Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
The provider. The plan needs an engineering owner for the data and a compliance owner for the thresholds, because a plan that only one of the two understands does not get run.
Established before the system is placed on the market, and run for the system's lifetime. The plan is part of the Annex IV technical documentation.
With the high-risk regime for Annex III systems, from 2 December 2027.
Article 72 — Article 72, Article 9, Article 73
Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system proportionate to the nature of the AI technologies and the risks, based on a post-market monitoring plan, that actively and systematically collects and analyses data on the system's performance throughout its lifetime and allows continuous compliance to be evaluated.
Confusing uptime monitoring with post-market monitoring. Article 72 is about whether the system still meets the Chapter III requirements — accuracy across affected groups, drift, misuse in the field — none of which a latency dashboard measures.
5 sections. Each one carries what to write and — the part templates normally leave out — what an assessor is looking for when they read it.
What performance and operational data will be collected in the post-market phase, and from which sources — automatically generated logs, deployer reports, user complaints, field data.
Whether the data can actually reach you. A plan that depends on deployer reports with no contractual channel to receive them collects nothing.
How the collected data is analysed to evaluate continued compliance with the Article 9 to 15 requirements throughout the lifecycle — including performance broken down by the groups the system affects.
Disaggregation. An aggregate accuracy figure that never moves can hide a serious and worsening gap for one group, and that gap is exactly what Article 10 and Article 15 make you responsible for.
Who runs the monitoring, who reviews the findings, and who has authority to decide on corrective action, including suspension.
That the person who can stop the system is named, and is not the same person whose targets depend on it running.
The thresholds or events that trigger investigation or action, and the link to serious-incident reporting under Article 73.
Numbers set in advance. Thresholds decided after the fact are not thresholds, and their absence is what turns a slow degradation into a late incident report.
How often the monitoring output is formally reviewed, how findings feed back into the Article 9 risk-management system and the technical documentation, and the corrective actions taken.
Dated review records with outcomes, and a visible loop back into the technical file. Monitoring that never changed anything is monitoring nobody read.
The same document in two portable forms. The Markdown pastes into Notion, Confluence, Google Docs or a repository; the PDF is laid out to be printed and written on, with ruled fill-in areas and a sign-off block.
# Post-market monitoring plan
**Legal basis:** Article 72, Article 9, Article 73 — Regulation (EU) 2024/1689 (EU AI Act).
> Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
**Who fills this in:** The provider. The plan needs an engineering owner for the data and a compliance owner for the thresholds, because a plan that only one of the two understands does not get run.
**When:** Established before the system is placed on the market, and run for the system's lifetime. The plan is part of the Annex IV technical documentation.
| Field | Value |
| --- | --- |
| Organisation | |
| AI system | |
| Version / reference | |
| Document owner | |
| Date | |
| Version of this document | |
## 1. Data collection
*What to write:* What performance and operational data will be collected in the post-market phase, and from which sources — automatically generated logs, deployer reports, user complaints, field data.
*What an auditor looks for:* Whether the data can actually reach you. A plan that depends on deployer reports with no contractual channel to receive them collects nothing.
_[Your text here]_
## 2. Analysis and evaluation methods
*What to write:* How the collected data is analysed to evaluate continued compliance with the Article 9 to 15 requirements throughout the lifecycle — including performance broken down by the groups the system affects.
*What an auditor looks for:* Disaggregation. An aggregate accuracy figure that never moves can hide a serious and worsening gap for one group, and that gap is exactly what Article 10 and Article 15 make you responsible for.
_[Your text here]_
## 3. Roles and responsibilities
*What to write:* Who runs the monitoring, who reviews the findings, and who has authority to decide on corrective action, including suspension.
*What an auditor looks for:* That the person who can stop the system is named, and is not the same person whose targets depend on it running.
_[Your text here]_
## 4. Thresholds and triggers
*What to write:* The thresholds or events that trigger investigation or action, and the link to serious-incident reporting under Article 73.
*What an auditor looks for:* Numbers set in advance. Thresholds decided after the fact are not thresholds, and their absence is what turns a slow degradation into a late incident report.
_[Your text here]_
## 5. Review cadence and corrective actions
*What to write:* How often the monitoring output is formally reviewed, how findings feed back into the Article 9 risk-management system and the technical documentation, and the corrective actions taken.
*What an auditor looks for:* Dated review records with outcomes, and a visible loop back into the technical file. Monitoring that never changed anything is monitoring nobody read.
_[Your text here]_
---
Template by Conformly — getconformly.com/templates/post-market-monitoring-plan. Free to copy and adapt. Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
The nine-section technical file a provider of a high-risk AI system has to draw up before the system goes on the market.
The dossier you send to the market-surveillance authority, and the clock that starts the moment you become aware.
The provider's signed statement that a high-risk AI system conforms — one page, kept for ten years, produced on request.
Not sure this document is yours to write? Classify the system first — or browse all 7 templates.