After placing a high-risk system on the market, a provider must operate a post-market monitoring system under Article 72, proportionate to the nature of the system and the risks, to collect and analyse data on performance, including feedback from deployers and users, and to evaluate continued compliance. A provider must report serious incidents under Article 73 to the market surveillance authority, and must control changes to the system through the quality management system, reassessing classification, documentation and conformity where a change is substantial or changes the intended purpose. Post-market work is part of compliance, not a support function, and its findings must feed back into risk management, design and instructions.
What must a post-market monitoring system do?
Article 72 requires a post-market monitoring system that actively and systematically collects, documents and analyses relevant data provided by deployers or collected through other sources on the performance of the system throughout its lifetime, and that evaluates continuous compliance with the Chapter III requirements. The system must be based on a post-market monitoring plan, which forms part of the technical documentation. The plan should state the data collected, the sources, the analysis methods, the review intervals, and the triggers for action. For systems integrated into products, the plan should be coordinated with the product post-market system, so that AI performance data and product safety data are analysed together. A monitoring system that only collects complaints, without systematic analysis, does not meet the article.
How are serious incidents reported?
Article 73 requires a provider that becomes aware of a serious incident to report it to the market surveillance authority of the Member State where the incident occurred, immediately after establishing a causal link, or the reasonable likelihood of such a link, between the system and the incident, and in any event not later than fifteen days after becoming aware of the incident. A serious incident is defined as an incident or malfunctioning that directly or indirectly led, might have led, or might lead to death, serious damage to health, serious and irreversible disruption of the management and operation of critical infrastructure, infringement of obligations under Union law intended to protect fundamental rights, or serious damage to property or the environment. The report, the investigation, and the corrective action should be coordinated, and the provider should also inform deployers and other operators where the incident affects them.
For the broader regulatory framework, see provider responsibilities.
How should deployer feedback be handled?
Deployer feedback is a primary source for post-market monitoring. Deployers report performance issues, incidents, misuse, and changes in use, and the provider should have a channel for receiving that feedback, a process for triaging it, and a record of the action taken. Feedback that suggests non-conformity, a new risk, or a purpose change should trigger the corrective action and classification processes, not only a support response. The provider should acknowledge feedback, inform the deployer of the outcome where appropriate, and use aggregated feedback to update risk management, testing, instructions and training. A feedback channel that is not monitored, or that does not feed into the quality system, is not a post-market monitoring system.
How are changes controlled after release?
Changes after release must be controlled through the quality management system, with a change proposal, an impact assessment on compliance and purpose, a decision on substantial modification under Article 25, an update to technical documentation and instructions, and a conformity review where needed. Model updates, data changes, integration changes and configuration changes should all go through the same process, with the level of review proportionate to the risk. A change log should record every change, its classification, its reviewer, and its release date, so that the version on the market can always be matched to its documentation and conformity file. Emergency changes for safety or security should follow an expedited process that still records the assessment and triggers a retrospective review.
How do monitoring findings feed back into design?
Monitoring findings should feed into the risk management system, the design and testing procedures, the instructions for use, and the training and support provided to deployers. A recurring error, a new misuse pattern, or a performance difference in a subgroup should lead to a design, data, oversight or instruction change, or to a restriction of the intended purpose, as appropriate. The feedback loop should be evidenced: the finding, the analysis, the decision, the change, and the verification that the change worked. A monitoring system that collects data but never changes the system is not evaluating continued compliance. The provider should review the monitoring plan itself regularly, and update it where the system, the deployment, or the risks change.
Continue with Article 16 provider duties.
What is not decided by this guide?
This guide explains the post-market duties in outline. It does not design a monitoring plan for a specific system, does not decide whether an incident is serious, and does not decide whether a change is substantial. Those questions need the incident facts, the causal analysis, the change, and its effect on compliance and purpose, read against Articles 72, 73 and 25 in the consolidated text. Serious incidents and substantial changes should be confirmed with the market surveillance authority and with a competent authority or legal adviser, and the provider should act promptly where a risk to health, safety or fundamental rights is possible.
Frequently asked questions
How quickly must a serious incident be reported?
Immediately after establishing a causal link or its reasonable likelihood, and in any event not later than fifteen days after the provider becomes aware of the incident, to the market surveillance authority of the Member State where the incident occurred, under Article 73.
Does post-market monitoring apply to non-high-risk systems?
Article 72 is addressed to providers of high-risk systems. Providers of other systems should still monitor performance and respond to incidents under contract, product and general safety duties, but the Article 72 plan and reporting duties are tied to high-risk status.
Can a provider rely on deployers to monitor the system?
No, not entirely. The provider must operate its own post-market monitoring system, and must collect and analyse data including deployer feedback. Deployer monitoring under Article 26 is a separate duty, and the two should be coordinated through the information flow between provider and deployer.
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 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗