Article 72 of the EU AI Act requires every provider of a high-risk AI system to keep watching it after release, yet many providers have no route for field data to come back from deployers and no threshold that turns a drifting metric into corrective action. Post-market monitoring is the provider's system for collecting and analysing performance data across the lifetime of the AI system, based on a written plan that forms part of the technical documentation. It is the feed for serious incident reporting under Article 73, corrective action under Article 20 and updates to the risk management system and instructions for use. This guide covers what Article 72 requires, what changed under the Digital Omnibus, what a workable plan contains, which data sources to use, how to link monitoring to incident reporting, and how to measure that it works. It is written for providers of high-risk systems, deployers who must feed them data, and the quality, risk and security teams that run the process.
Source note: provisions are paraphrased from the consolidated text of Regulation (EU) 2024/1689 shown on the European Commission's AI Act Service Desk (EUR-Lex consolidated version as at 27 July 2026, including Digital Omnibus amendments), checked on 11 November 2026. Confirm against the official text before relying on it.
Key takeaways
- Monitoring is a lifetime duty with a written plan. Article 72(1) to (3) require a documented post-market monitoring system, proportionate to the technology and its risks, based on a plan that sits in the Annex IV technical documentation.
- The goal is continuous compliance. Data must be collected, documented and analysed actively and systematically to evaluate continued compliance with the Chapter III Section 2 requirements, including interaction with other AI systems where relevant.
- The Commission template is now guidance due in 2027. The Digital Omnibus replaced the original implementing act, due by 2 February 2026, with Commission guidance including a template, due by 2 September 2027.
- Deployers are a required data source in practice. Article 26(5) obliges deployers to monitor on the basis of the instructions for use and inform providers in line with Article 72, so the plan must define how that information arrives.
- Monitoring must be wired to the incident clock. A serious incident found through monitoring starts Article 73 reporting periods of 15, 10 or 2 days from awareness, so triage has to be fast and recorded.
What Article 72 requires
The table paraphrases Article 72 of Regulation (EU) 2024/1689 as shown on the European Commission's AI Act Service Desk (consolidated text as at 27 July 2026, checked 11 November 2026), which marks paragraph 3 as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744.
| Paragraph | Requirement (paraphrased) | Practical consequence |
|---|---|---|
| 72(1) | Providers establish and document a post-market monitoring system proportionate to the nature of the AI technologies and the risks of the high-risk system | Depth of monitoring scales with risk; a recruitment screener and a safety component will not look the same |
| 72(2) | The system actively and systematically collects, documents and analyses relevant data, which may be provided by deployers or collected through other sources, on performance throughout the lifetime, to evaluate continued compliance with Chapter III Section 2; where relevant it includes analysis of interaction with other AI systems; sensitive operational data of law enforcement deployers is excluded | Passive complaint handling is not enough; monitoring must cover accuracy, robustness, cybersecurity, oversight and data requirements |
| 72(3) | The system is based on a post-market monitoring plan, part of the Annex IV technical documentation; the Commission shall adopt guidance, including a template, on the plan by 2 September 2027 (amended) | The plan is assessed with the rest of the documentation; build it now and align with the template when it appears |
| 72(4) | For Annex I Section A products already under a post-market regime, providers may integrate the required elements into existing systems and plans if this achieves an equivalent level of protection; the same option applies to Annex III point 5 systems of financial institutions subject to Union internal governance rules | Medical device and machinery makers, banks and insurers can extend existing processes rather than build parallel ones |
Article 3(25) defines the post-market monitoring system as all activities carried out by providers to collect and review experience gained from AI systems they place on the market or put into service, to identify any need to immediately apply corrective or preventive action. Annex IV point 9 requires the technical documentation to include a detailed description of the system for evaluating performance in the post-market phase, including the plan.
Status and dates
| Item | Date or status | Source |
|---|---|---|
| Original deadline for the Commission template (implementing act) | 2 February 2026, replaced | Original Article 72(3), Regulation (EU) 2024/1689 |
| Commission guidance including a template | By 2 September 2027 | Article 72(3) as amended by the Digital Omnibus |
| High-risk obligations for Annex III systems (Article 6(2)) | 2 December 2027 | Article 113(c)(i) as amended |
| High-risk obligations for Annex I systems (Article 6(1)) | 2 August 2028 | Article 113(c)(ii) as amended |
| Draft serious incident guidance and reporting template | Published for consultation 26 September 2025, feedback closed 7 November 2025; final version not dated on the consultation page | European Commission consultation page |
The Service Desk does not list Article 72 separately in Article 113, so its practical start follows the high-risk obligations it monitors. Dates have already moved once; confirm them in the EU AI Act Implementation Timeline Tracker and the EU Digital Omnibus Guide before relying on them.
What goes in the post-market monitoring plan
Until the Commission template exists, structure the plan around the questions an assessor will ask. The headings below are an NHI Mgmt Group recommendation built from Articles 72, 73, 12, 26 and Annex IV, not text from the Act.
- Scope and system identification: system name and version, intended purpose, deployers and markets, and the link to the Annex IV file and instructions for use.
- Monitoring objectives: which Section 2 requirements each activity checks: risk management (Article 9), data (Article 10), logging (Article 12), transparency (Article 13), oversight (Article 14), and accuracy, robustness and cybersecurity (Article 15).
- Indicators and thresholds: the metrics declared in the instructions for use, the acceptable range for each, and the threshold that triggers investigation, corrective action or incident triage.
- Data sources and collection methods: what comes from logs, deployers, complaints, testing and external sources, at what frequency, and under what data protection basis.
- Analysis methods: statistical tests for drift, disaggregation by group where performance was declared per group, and review cadence.
- Roles and escalation: named owners for collection, analysis and decisions, and the path to the Article 73 reporting decision.
- Feedback loops: how findings update the risk register, technical documentation, instructions for use and training data, and when a change becomes a substantial modification.
- Records and review: what evidence is kept, for how long, and when the plan itself is reviewed.
See the EU AI Act Article 13 Guide for the declared metrics the plan should monitor against.
Data sources
| Source | What it shows | Collection mechanism | Limits |
|---|---|---|---|
| Automatic logs (Article 12) | Inputs, outputs, confidence, timing, errors, oversight actions | Log export or telemetry from deployer environments, designed into the system; Article 12 logging is meant to facilitate Article 72 monitoring | Logs held by deployers (Article 26(6), at least six months) need agreed access |
| Deployer reports (Article 26(5)) | Observed malfunctions, risks, suspensions, serious incidents | Contractual reporting channel, structured form, named contacts | Quality depends on deployer monitoring and the instructions they were given |
| Ground truth and outcome sampling | Real accuracy, false positives and negatives against later outcomes | Periodic labelled samples agreed with deployers | Costly; outcomes may arrive months later |
| Complaints and affected person feedback | Harms and errors noticed outside the system | Provider and deployer complaint routes, Article 86 explanation requests | Under-reporting; personal data handling |
| Security monitoring and vulnerability intake | Adversarial inputs, prompt injection, model extraction, data poisoning attempts | Security telemetry, vulnerability disclosure programme, threat intelligence | Often owned by a different team from quality monitoring |
| Interaction with other AI systems | Behaviour when chained with agents, models or tools | Integration testing, trace data from orchestrators | Required "where relevant" by 72(2); visibility depends on deployer architecture |
| Upstream changes | New versions of underlying models, libraries or data sources | Supplier notices, AI-BOM tracking | Third-party models may change without notice |
- Law enforcement deployers: 72(2) excludes their sensitive operational data, so the plan needs alternative indicators such as aggregated performance or synthetic test results.
- Personal data: logs and outcome samples often contain personal data; document the GDPR basis, minimisation and retention for monitoring use. See the Privacy in Security Logging and Monitoring Guide.
Linking monitoring to incident reporting and corrective action
Monitoring produces signals; the plan must say what happens next. Article 3(49) defines a serious incident as an incident or malfunction that directly or indirectly leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law obligations intended to protect fundamental rights, or serious harm to property or the environment.
| Signal | Decision | Clock or duty |
|---|---|---|
| Metric drifts outside declared range, no harm identified | Investigate, consider corrective action, update risk register and instructions | Article 20 corrective action if the system is not in conformity |
| Incident with causal link or reasonable likelihood of one to a serious incident | Report to the market surveillance authority of the Member State where it occurred | Immediately, no later than 15 days after awareness (Article 73(2)) |
| Death of a person | Report | Immediately, no later than 10 days after awareness (Article 73(4)) |
| Widespread infringement or serious and irreversible disruption of critical infrastructure | Report | Immediately, no later than 2 days after awareness (Article 73(3)) |
| Any reported serious incident | Investigate with risk assessment and corrective action; do not alter the system in a way that affects evaluation of causes before informing authorities | Article 73(6) |
- Incomplete first reports: Article 73(5) allows an initial incomplete report followed by a complete one, so do not wait for root cause.
- Other regimes: under 73(9) and 73(10), providers already under equivalent Union reporting obligations, and AI in medical devices under Regulations (EU) 2017/745 and 2017/746, report under the AI Act only for fundamental rights infringements (point (c)).
- Preserve before you patch: the 73(6) restriction means monitoring data, model versions and logs must be snapshotted before hotfixes. See the AI Incident Reporting Guide for the full reporting process and the AI System Incident Report Template.
Implementing post-market monitoring in phases
- Baseline from conformity work: take the validated metrics, operating envelope and residual risks from the Article 9 and 15 work as the reference values.
- Design telemetry into the product: logging fields, export interfaces and privacy controls that let deployers share data without manual effort.
- Agree deployer data flows: contract terms for log access, outcome sampling, incident reports and contacts, aligned with what the instructions for use promise.
- Pilot with one deployer: run the plan end to end for a quarter, including a tabletop exercise in which a monitoring signal becomes a reportable serious incident.
- Automate alerts: threshold breaches create tickets with owners and a recorded triage decision on Article 73 reportability.
- Close the loop: feed findings into risk management, documentation and model updates, checking whether each change is pre-determined under Article 13(3)(c) or a substantial modification under Article 3(23).
- Rollback path: keep the last conforming model and configuration deployable so corrective action can revert quickly, after evidence is preserved.
Decision guidance
- Integrate or build: Annex I product makers and regulated financial institutions should extend existing post-market or governance processes under 72(4) and document why protection is equivalent; others need a dedicated process, ideally inside the quality management system.
- Small provider: a handful of indicators, monthly review, a single incident triage owner and a shared deployer reporting form are proportionate under 72(1) for a narrow system.
- Large provider or many deployers: central telemetry, automated drift detection per deployer and per group, and a standing triage rota with authority to file Article 73 reports.
- Systems built on general-purpose models: add upstream model change monitoring, since a provider update can shift performance without any change on your side.
Where identity fits
Monitoring depends on data access across organisational boundaries, which is an access design problem as much as a quality one.
- Telemetry credentials: the service accounts, API keys or certificates that ship logs from deployer environments to the provider are non-human identities with access to potentially personal data. Scope them to export only, rotate them, and give each deployer its own.
- Attributable oversight data: overrides, stops and reviews in logs should carry the overseer's identity so monitoring can measure oversight quality. See the AI Agent Audit Trails for Regulators Guide.
- Agent interactions: where 72(2) requires analysis of interaction with other AI systems, distinct identities per agent and tool make traces interpretable. See the AI Agent Observability and Incident Response Guide.
Detection and measurement
- Telemetry coverage: share of deployments sending monitoring data on schedule.
- Time to triage: from threshold breach or deployer report to a recorded Article 73 reportability decision; it must sit well inside the 2-day shortest clock.
- Declared versus observed performance: gap between Article 13 declared metrics and field results, overall and per group.
- Loop closure: share of findings that led to a documented update to the risk register, instructions or model within the agreed time.
- Deployer reporting health: reports received per deployer per quarter; zero from a large deployer usually means the channel is not working.
Framework mapping
| Article 72 element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Other references |
|---|---|---|---|
| Monitoring system and plan | CA-7 Continuous Monitoring; PM-31 Continuous Monitoring Strategy | DE.CM-09 | NIST AI RMF 1.0 Measure and Manage functions |
| Log-based data collection | AU-2 Event Logging; AU-6 Audit Record Review, Analysis, and Reporting | PR.PS-04 | AI Act Article 12 |
| Deployer and supplier data flows | SR-8 Notification Agreements | GV.SC-07 | AI Act Article 26(5) |
| Incident escalation and reporting | IR-4 Incident Handling; IR-6 Incident Reporting | RS.CO-02 | AI Act Article 73 |
| Feedback into risk and design | RA-3 Risk Assessment | ID.IM-03 | AI Act Article 9; ISO/IEC 42001:2023 continual improvement |
Common failure patterns
- A plan with no data: the document exists in the technical file but no deployer has agreed to share logs or outcomes, so nothing is analysed.
- Complaints only: relying on inbound complaints is passive and misses silent degradation that 72(2) expects active collection to find.
- Thresholds without owners: drift alerts land in a dashboard nobody reviews, and the Article 73 clock may already be running by the time anyone looks.
- Fixing before preserving: engineers hotfix a model after a harmful output, destroying the state needed to evaluate causes, contrary to 73(6).
- Ignoring interactions: monitoring the model in isolation when it runs inside an agent pipeline, so failures caused by tool or agent interaction are invisible.
- Monitoring credentials as a leak path: one shared, long-lived API key used by every deployer to send telemetry becomes a single point of exposure for personal data.
Practitioner checklist
- Write the post-market monitoring plan now and file it in the Annex IV documentation.
- Tie each indicator to a declared metric in the instructions for use and set investigation thresholds.
- Agree log access, outcome sampling and incident reporting with each deployer in contract.
- Cover security signals, interaction with other AI systems and upstream model changes.
- Name owners for analysis and for the Article 73 reportability decision, with a time target under 2 days.
- Snapshot models, configuration and logs before any corrective change.
- Route findings into the risk register, documentation and change control, checking for substantial modification.
- Issue each deployer its own scoped, rotated telemetry credentials.
- Track the Commission template due by 2 September 2027 and align the plan when it is adopted.
Standards and references
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- European Commission AI Act Service Desk: Article 72 Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems
- European Commission AI Act Service Desk: Article 73 Reporting of serious incidents
- European Commission AI Act Service Desk: Article 3 Definitions
- European Commission AI Act Service Desk: Article 26 Obligations of deployers of high-risk AI systems
- European Commission AI Act Service Desk: Annex IV Technical documentation
- European Commission: Draft guidance and reporting template on serious AI incidents
- European Commission AI Act Service Desk: Article 113 Entry into force and application
This guide summarises Article 72 of the EU AI Act and related provisions as shown in the consolidated text on 11 November 2026 and is not legal advice. Related NHI Mgmt Group resources: EU AI Act High-Risk AI Systems Guide · AI Incident Reporting Guide · LLM Observability Guide · EU AI Act Provider vs Deployer Obligations Guide