How to Build a Post-Market Monitoring Plan Under Article 72

A drift alert fires on a recruitment model in production. Who reads it, against which threshold, on what cadence, and which document told them to? If you cannot answer in one breath, you do not yet have a post-market monitoring plan — you have a monitoring system with no documented basis, which under Article 72(3) of Regulation (EU) 2024/1689 is the part regulators read first. This guide builds the artefact, section by section, for providers of high-risk AI systems.

This is the build-the-plan playbook, not a recap of the duty. For the full obligation — scope, the Article 9 loop, integration with sector law — read the Article 72 post-market monitoring obligation explained. Here you leave with a fillable skeleton, the metric and threshold choices, and a worked example wiring detection to reporting and corrective action.

---

What a post-market monitoring plan is — and what this guide builds

The distinction matters because the statute splits the duty. Article 72(1)-(2) require the provider to establish and operate a monitoring system that actively and systematically collects and analyses performance data across the high-risk system's whole lifetime. Article 72(3) requires that activity to rest on a documented plan. The system is the operating capability; the plan is its written basis. This guide builds the plan.

The duty is the provider's (Article 16) and applies only to high-risk systems. Deployers feed data under Article 26 — they keep logs and notify you of incidents — but they do not build the plan. The line can move: a party that puts its own name or trademark on a high-risk system, substantially modifies it, or changes its intended purpose becomes a provider under Article 25 and inherits the Article 72 duty whole.

Where does the plan live? Not in a standalone file. It forms part of the Annex IV technical documentation via Article 11 — section 9 of that documentation. The Commission is to issue a template (Article 72(3)); until it does, draft against the statute and align later. Build the plan before conformity assessment, not after launch.

---

The seven building blocks every Article 72 plan needs

Each block below maps to one decision you must make and record — the build checklist the rest of the article expands.

Performance indicators tied to intended purpose

Indicators must trace to the system's intended purpose and its Annex III use case — not a generic "accuracy" figure. For recruitment (Annex III point 4(a)), track selection-rate parity across candidate groups. For creditworthiness (Annex III point 5(b)), track default rate by approval cohort. The metric must mean something for this system's harm profile.

Thresholds and trigger conditions

Every indicator needs a number that does something when crossed. Define two bands, covered in detail below.

Data sources and collection mechanism

Name where each data point originates — your own infrastructure, deployer logs, API telemetry — and the right by which you collect it.

Review cadence and methodology

State how often and by what method you analyse the data. "Periodically" is not a cadence.

Roles and ownership (RACI)

Name one accountable owner and the decision path from finding to action.

Feedback loop into Article 9 risk management

The plan must describe how findings re-open the Article 9 risk assessment and trigger Annex IV updates.

Escalation links to Article 73 and Article 20

The plan must define when a finding becomes a reportable serious incident (Article 73) and when it triggers corrective action (Article 20).

Proportionality (Article 72(1)) governs how heavy each block is. The plan records the proportionality reasoning — "every output is reviewed by a human and volume is 200 cases a quarter" — not the assertion "we are small".

---

Choosing metrics and setting thresholds

Deriving metrics from the intended purpose and Annex IV

Anchor each metric to a claim you already documented. Your Annex IV file states performance, robustness and cybersecurity levels validated under Article 15; monitoring exists to verify those claims hold in production. So the metrics are not invented fresh — they are the production-side mirror of what conformity assessment already promised. Cover model drift and disparate performance across demographic groups, because both degrade silently.

Setting a baseline at conformity assessment

The launch baseline is the Article 9 residual-risk conclusion: the performance level at which you judged residual risk acceptable. Record it. Everything you measure later is measured against that line, which is why the baseline must be written into the plan rather than reconstructed after an incident.

Defining alert vs. escalation thresholds

Set two bands, not one. An internal alert band triggers analysis and a documented review — something has moved, investigate it. An escalation band indicates the system may no longer be in conformity or that a finding could be a serious incident. The escalation band is the wire to Article 73 and Article 20. Record the reasoning for each number so it is defensible, not arbitrary.

On data scope: aggregate-by-category data — group, jurisdiction, use-case scenario — is usually sufficient to detect systemic risk and avoids spinning up a new, GDPR-heavy personal-data operation for its own sake.

---

Data sources, collection cadence, and ownership

Securing deployer-supplied data by contract

Article 72(2) expressly contemplates deployer-supplied data. If you sell to many deploying organisations, the precondition is contractual: logging, retention and sharing obligations, plus agreed data formats, written into supply contracts before launch. You cannot monitor data you have no right to collect — and "we'll ask later" is not a mechanism.

Setting a review cadence (event-triggered vs. periodic)

Cadence is a design choice the plan must state explicitly. A workable pattern combines three layers: continuous telemetry where feasible, a fixed periodic review (monthly or quarterly), and event-triggered analysis the moment an alert threshold is crossed. "Reviewed periodically" is not a plan; "reviewed quarterly, plus within five working days of any alert breach" is.

Assigning the plan owner and the decision path

Name an accountable owner and a written decision path from finding to action. Auditors look for evidence that the loop actually closed — a finding analysed, a decision recorded, an action taken — not that a loop was merely described on paper. Ownership without a decision path is decoration.

---

Wiring the plan to incidents (Article 73) and corrective action (Article 20)

The detect → report path to Article 73

Define, inside the plan, the internal threshold at which a monitoring finding becomes a potential serious incident. Once that threshold is crossed and you become aware, Article 73 deadlines run: no later than 15 days by default, 10 days where the incident caused a death, and 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. The plan pre-decides who classifies the finding and starts the clock.

The detect → fix path to Article 20

Reporting is not fixing. Where monitoring shows the system is not in conformity, Article 20 requires the provider to take corrective action — bring it into conformity, withdraw it, disable it, or recall it — and to inform distributors, deployers, the authorised representative and importers. The plan should pre-define who is authorised to trigger this and how the downstream parties are notified.

Why an active plan fixes the "became aware" clock

An operating Article 72 system establishes when the provider became aware — the moment the Article 73 clock starts. A documented detection threshold turns "we noticed eventually" into a dated, traceable event. Findings then feed back into the Article 9 assessment and any Annex IV updates, closing the loop auditors trace from detection to documentation.

---

A post-market monitoring plan outline (table) you can fill in

Use this skeleton. Each row pairs the required content with its statutory basis and a one-line drafting prompt, so you leave with a structure rather than a set of concepts.

The plan sits in section 9 of the Annex IV technical documentation (Article 11) and should align to the Commission template once issued.

---

Worked example: a 180-person HR-tech provider building the plan

Take Talvera, a roughly 180-employee provider of an automated CV-screening system sold to mid-market employers. Screening for candidate selection is high-risk under Annex III point 4(a), so Talvera is the provider and owns the Article 72 plan. Walk one row — performance indicators and thresholds — to concrete values.

Talvera's plan lists: selection-rate parity ratio across protected-attribute proxies (alert if the ratio falls below an agreed band; escalate below a lower band), recommendation-acceptance rate, appeal-overturn rate, and accuracy measured against downstream hiring outcomes. Cadence: quarterly review plus event-triggered analysis on any alert breach. Data: deployer contracts require quarterly aggregate outcome logs, so Talvera never touches individual candidate records it has no right to hold.

Now the chain fires. A quarterly review shows the parity ratio drifting; the next month it breaches the escalation band. Talvera re-opens its Article 9 assessment, judges whether the drift is a serious incident reportable under Article 73, and — finding the system out of conformity — applies an Article 20 corrective action by disabling the affected scoring path pending a fix. Had Talvera held no documented system at all, the failure would fall under Article 99(4): up to €15 million or 3% of total worldwide annual turnover, whichever is higher. As an SME — under 250 staff, turnover within threshold — Talvera benefits from Article 99(6), which caps its fine at the lower of those two figures — protection, not a reason to skip the plan.

---

From plan to operating system: keeping it auditable

The plan is a living document. Update it whenever monitoring shows an earlier risk or performance assumption was wrong, and reflect the change in the Annex IV technical documentation (Article 11). A plan that never changes after a year of operation is a plan nobody is reading.

Caveat the deadline accurately. The statute reads 2 August 2026 for stand-alone Annex III high-risk obligations. The Digital Omnibus defers this to 2 December 2027: the European Parliament passed it in plenary on 16 June 2026 and the Council formally adopted it on 29 June 2026. Only publication in the Official Journal remains — expected before 2 August 2026 — a formality that does not affect the dates. The 2 December 2027 deadline is now settled for stand-alone Annex III high-risk obligations. Product-embedded Annex I high-risk sits at 2 August 2027 (agreed move to 2 August 2028, now adopted).

---

How Confir helps

Confir maps the post-market monitoring plan into section 9 of your Annex IV technical documentation and links each high-risk system to its Article 73 reporting deadlines. The synthesis engine is deterministic and rule-based — no model inference, no hallucination — so the same inputs produce the same structured plan every time, which is what makes the output audit-defensible. The plan section ships pre-structured to the Article 72 requirements and ready to align with the Commission template once issued.

---

Frequently asked questions

What is the difference between a post-market monitoring system and the monitoring plan?

The system is the operating capability — the people, data flows, and analysis a provider runs continuously under Article 72(1)-(2). The plan is the documented basis for that system under Article 72(3): it states the metrics, thresholds, data sources, cadence, ownership, and escalation paths. The plan is what an auditor reads; the system is what produces the records that prove the plan is real. The plan forms part of the Annex IV technical documentation via Article 11, so it is drafted before launch and kept current as the system operates.

What metrics belong in an Article 72 post-market monitoring plan?

There is no fixed statutory list — metrics must trace to the system's intended purpose and the performance, robustness and cybersecurity claims documented under Article 15 and Annex IV. For an Annex III point 4(a) recruitment tool that means selection-rate parity, recommendation-acceptance and appeal-overturn rates, and accuracy against hiring outcomes. For an Annex III point 5(b) creditworthiness tool it means default rates by approval cohort and approval-rate disparity by applicant category. Track drift and disparate performance; aggregate-by-category data usually suffices and avoids a heavier GDPR footprint.

How do I set thresholds in the plan?

Start from the baseline your Article 9 risk assessment used to conclude residual risk was acceptable at conformity assessment. Then define two bands. An internal alert threshold triggers a closer analysis and a documented review. An escalation threshold indicates the system may no longer be in conformity or that a finding could be a serious incident. The escalation band is what wires the plan to Article 73 reporting and Article 20 corrective action. Record the reasoning for each threshold so it is defensible rather than arbitrary.

How does the plan connect to Article 73 incident reporting?

The plan should pre-define the internal threshold at which a monitoring finding becomes a potential serious incident requiring external reporting. Once that threshold is crossed and the provider becomes aware, Article 73 deadlines run: no later than 15 days by default, 10 days where the incident caused a death, and 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. An operating Article 72 system also helps establish when the provider 'became aware', which is the moment the reporting clock starts.

What happens after monitoring detects a problem — is reporting enough?

No. Reporting under Article 73 and fixing under Article 20 are distinct steps. If monitoring shows the high-risk system is not in conformity, Article 20 requires the provider to take corrective action — bring it into conformity, withdraw it, disable it, or recall it — and to inform distributors, deployers, the authorised representative and importers. The plan should name who triggers corrective action and how. Findings also feed back into the Article 9 risk assessment and any necessary Annex IV updates, closing the loop auditors trace.

Who owns the post-market monitoring plan, and can a deployer build it?

The provider owns it — the actor that develops or places the high-risk system on the market under its own name or trademark (Article 16). Deployers are a data source under Article 26: they use the system per its instructions, keep logs, and notify the provider of incidents, but they do not design or run the monitoring system. The line can move: a deployer that rebrands or substantially modifies the system becomes a provider under Article 25 and inherits the Article 72 duty. Inside the plan, name one accountable owner and a written decision path.

When must the plan be in place, and what is the penalty for not having one?

The plan must be part of the Annex IV technical documentation at conformity assessment, before the system is placed on the market — you cannot launch first and draft it later. Stand-alone Annex III high-risk obligations were originally set for 2 August 2026; the adopted Digital Omnibus now defers this to 2 December 2027. Failing to establish or document the system is fined under Article 99(4) up to €15 million or 3% of worldwide annual turnover, whichever is higher; for SMEs Article 99(6) applies the lower figure.

---

Related guides

• Article 72 post-market monitoring: full guide
• the Article 72 post-market monitoring obligation explained
• Article 73 serious-incident reporting
• Article 20 corrective actions
• AI incident report template
• post-market monitoring (definition)