Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system that is proportionate to the nature of the technology and the risks of the system. The system must actively and systematically collect, document and analyse relevant data on the performance of the system throughout its lifetime, including data provided by deployers and other sources where relevant, so the provider can evaluate continuing compliance. The post-market monitoring plan is part of the technical documentation. Monitoring is therefore a lifetime obligation, not a one-off check at the point of conformity assessment.
What must a post-market monitoring system do?
A post-market monitoring system must actively and systematically collect, document and analyse relevant data on the performance of a high-risk AI system throughout its lifetime. The word actively matters: the provider cannot wait for complaints or incidents to arrive, but must seek the data that shows whether the system continues to meet the requirements of the Act in real operating conditions. The word systematically matters as well: collection and analysis must follow a plan, with defined data sources, review points and responsibilities, rather than depending on ad hoc checks by whoever happens to notice a problem. The system must be proportionate to the nature of the technology and the risks involved, so a higher-risk or more widely deployed system will need more intensive monitoring than a narrow, low-volume one. The monitoring system and its plan should be documented before the system is placed on the market, and the plan forms part of the technical documentation.
What data should monitoring collect?
Monitoring should collect relevant data on performance, including data from deployers and other sources where relevant, so the provider can evaluate whether the system remains compliant and whether its risk assessment still holds. Relevant data can include operational logs, performance measures against the intended purpose, feedback from deployers and users, incident and near-miss reports, complaints, and information about changes in the operating environment or the population affected. The plan should define which data are collected, how often, from whom, in what form and with what data protection safeguards, since monitoring data can include personal data and must be handled under the applicable data protection rules. Data that are collected but never analysed do not satisfy the provision: the plan must also define the analysis, the thresholds or signals that trigger action, and the person responsible for deciding whether a finding requires a corrective action, a documentation update or an incident report.
For the broader regulatory framework, see EU database, registration and post-market monitoring.
How does monitoring connect to risk management?
Post-market monitoring is the feedback loop for the risk management system required by Article 9. Risks identified before market placement are hypotheses tested against real use, and monitoring is how the provider learns whether those hypotheses were correct. Where monitoring shows a new risk, a changed risk, a performance shortfall or a pattern of misuse, the provider should update the risk assessment, consider whether the technical documentation, instructions for use or system design need change, and decide whether a corrective action is required. The connection should be documented: monitoring findings should be recorded with their date, source and disposition, and the risk management record should show which findings led to which changes. A monitoring system that is disconnected from risk management will accumulate reports without changing anything, and a risk assessment that is never revisited after market placement will gradually describe a system that no longer exists.
What role do deployers play in monitoring?
Deployers are an important source of monitoring data because they operate the system in its real context and see its outputs, its failures and its effects on affected people. Article 72 expressly includes data provided by deployers among the data the monitoring system must collect and analyse where relevant, and deployers have their own duties to monitor operation, assign human oversight and report issues under Article 26 and, where applicable, Article 73. The provider should therefore agree the feedback channel with deployers in advance: what should be reported, how quickly, in what form and to whom, and what the provider will do with the information. A deployer that cannot report a problem easily, or that does not know what the provider needs, will under-report, and a provider that receives deployer information but does not analyse it will miss the earliest signal of a developing problem. The channel, the expectations and the response times should be written into the instructions and the supply arrangement.
What happens when monitoring finds a problem?
When monitoring identifies a problem, the provider must decide what kind of response it requires. Some findings will lead to a documentation update, a change to instructions, or a design or configuration change. Others will require corrective action under the market surveillance provisions, withdrawal or recall of the system, or a serious incident report under Article 73 where the criteria for a serious incident are met. The plan should therefore define escalation routes, decision owners and timescales in advance, so a serious finding is not left waiting for a routine review meeting. The provider should also consider whether deployers, authorities or affected people need to be informed, and should record the decision, the action taken and the follow-up check that confirms the action worked. A finding that is recorded but never dispositioned is a supervision risk, because it shows the provider knew of a problem and did not act on it.
Continue with serious incident reporting under Article 73.
What does this guide not decide?
This guide does not set the monitoring plan for any particular system, does not decide which data are relevant for a given deployment, and does not determine whether a specific finding is a serious incident or requires corrective action. Those questions depend on the system's intended purpose, its risk profile, the deployment context and the exact wording of Articles 72 and 73, together with any Commission guidance or template that applies at the time. The guide also does not cover sector-specific monitoring duties, such as medical device vigilance, which can apply alongside Article 72. Where monitoring design or incident classification is in doubt, confirm the position with a competent authority or legal adviser, and keep the monitoring plan, findings and decisions with the system's technical documentation.
Frequently asked questions
Is post-market monitoring a one-off check?
No. Article 72 requires a system that actively and systematically collects and analyses performance data throughout the system's lifetime, with a documented plan forming part of the technical documentation.
Must deployer feedback be included in monitoring?
Yes, where relevant. Article 72 includes data provided by deployers and other sources among the data the monitoring system must collect and analyse, and providers should agree a feedback channel with deployers in advance.
Does monitoring replace conformity assessment?
No. Conformity assessment addresses the system at the point of market placement, while monitoring tests continuing compliance in real use. The two must be connected: monitoring findings should feed back into risk management, documentation and, where needed, corrective action.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689, as amended ↗AI Act Service Desk: Article 49 registration ↗AI Act Service Desk implementation timeline ↗