This is a ready-to-use post-market monitoring plan for a high-risk AI system under Article 72 of the EU AI Act (Regulation (EU) 2024/1689). It is written to be referenced from section 9 of the Annex IV technical documentation dossier, of which it forms a part, and to feed the tiered clock in the serious incident reporting SOP when a monitoring signal turns out to be a serious incident. Replace every <<FILL: ...>> placeholder with your own specifics. A worked filled specimen follows. This is general guidance to adapt, not legal or regulatory advice; confirm the Article 72 text and any Commission-adopted template or implementing act against current sources before issue.
1. Scope and objective
To actively and systematically collect, document, and analyse relevant data on this system’s performance across its lifetime, so the provider can keep confirming the system still meets the high-risk requirements it was assessed against, and can detect degradation, drift, or an unforeseen risk before it becomes a serious incident. This plan is not a one-time validation exercise; it runs for as long as the system is in service.
2. Integration with existing sector monitoring
Where this system already sits inside another sector’s post-market surveillance framework, most commonly MDR or IVDR post-market surveillance for a device constituent of a combination product, state whether this plan is integrated into that framework or run in parallel with an explicit cross-reference.
3. Data sources
4. Signals monitored, thresholds, and cadence
5. Defined response when a threshold trips
State the response before a signal ever trips; deciding it after the fact is the most common failure mode this plan exists to prevent.
6. Link to serious incident reporting
At every review cycle, and immediately on any signal above its action threshold, assess whether the event meets the Article 73 definition of a serious incident, an incident or malfunction directly or indirectly causing death, serious harm to health, serious and irreversible disruption to critical infrastructure, infringement of fundamental-rights obligations, or serious harm to property or the environment. If it does, hand off immediately to the serious incident reporting SOP; do not let the monitoring review cycle’s normal cadence delay that handoff, since the reporting clock starts when a causal link is established, not at the next scheduled review.
7. Roles
8. Records and retention
Every monitoring cycle produces a controlled, retained, reviewable record: the data reviewed, the result against each threshold, any signal raised, the response taken, and the disposition. Retain per your records retention schedule, for not less than <<FILL: retention period>>. The monitoring evidence must be reconstructable end to end and must be reflected in the linked technical documentation dossier, not kept as a disconnected file.
9. Acceptance criteria
- Monitoring is live from before the system enters the field, not retrofitted after a problem surfaces.
- Data sources, signals, thresholds, and cadence are all named, not left generic.
- A defined response exists for every threshold before it is ever tripped.
- The handoff to serious-incident assessment is explicit and does not wait for the next scheduled review.
- Where an existing sector monitoring framework applies, the two are integrated or explicitly coordinated, not silently duplicated.
- Every cycle produces a controlled, retained record referenced from the technical documentation.
10. References
Regulation (EU) 2024/1689 (EU AI Act): Article 72 (post-market monitoring by providers) and Article 72(4) (integration with existing sector post-market surveillance); Annex IV, point 9; Article 12 (record-keeping) as the log source; Article 73 (serious incident reporting) for the handoff trigger.
Confirm the Commission’s implementing act and published template for the post-market monitoring plan (required under Article 72 by 2 February 2026) against the current AI Act service desk before finalising your plan’s structure.
Applicable sector post-market surveillance requirements (for example MDR/IVDR) where this system is also a device constituent.
11. Revision history
12. Approvals
Filled specimen (excerpt)
Illustrative for an example deviation-severity triage model used across multiple manufacturing sites, later determined to be Annex III high-risk because a subsequent redesign let it auto-close low-severity deviations without human review (a role-changing event under change control).
Common findings this plan prevents
- A monitoring plan that exists on paper but collects no data, so degradation is discovered by complaint rather than by design.
- Thresholds with no defined response, so a signal triggers debate rather than action.
- Monitoring evidence kept separate from the technical documentation, so the dossier goes stale relative to what the system actually does.
- No explicit handoff to serious-incident assessment, so a qualifying event is found weeks later during a routine review instead of on the day the causal link was established.
- Aggregate-only reporting that hides a single failing site or subgroup.
How to adapt this plan
- Name real data sources and a real cadence; a placeholder cadence is not a monitoring system.
- Set thresholds and the exact response before the system enters the field.
- Link section 6 firmly to the serious-incident SOP so the clock never starts late.
- Where a sector post-market surveillance plan already exists, state the integration explicitly rather than leaving two silent, possibly conflicting plans.
- Confirm the current Commission-published template and any implementing act before finalising the plan’s structure.
