What post-market monitoring requires
Post-market monitoring is the system through which a provider collects and analyses relevant information about the performance of a high-risk AI system after it has been placed on the market or put into service. Its purpose is not to accumulate records for their own sake. It is to enable the provider to check whether the system continues to meet applicable requirements and whether problems have emerged that need investigation or action.
Article 72 of the AI Act makes the provider responsible for establishing and documenting this system. It must be proportionate to the nature of the technology and the risks posed by the system. The provider must also have a post-market monitoring plan as part of the technical documentation. In practice, the plan explains how data will be obtained and analysed, which signals may indicate a deviation, and how the provider will decide whether to intervene.
The obligation applies to high-risk AI systems. It does not mean that every provider must monitor every product with the same intensity or collect all available data. Proportionality matters: the sources, indicators and review frequency should have a reasonable relationship to the intended use, deployment context and risks the system may create.
It is useful to distinguish two levels. The legal requirement is to have an adequate, documented system and plan. The indicators, thresholds and routines proposed in this guide are design options for putting that obligation into practice; they are not a universal list imposed by the Regulation.
What to monitor and where the data may come from
The Regulation envisages relevant data provided by deployers as well as data obtained from other sources. This gives each provider room to design a system suited to its product, but does not remove the need to justify why a source is relevant or explain how it will be interpreted. The data should help assess the system’s performance throughout its lifetime and identify changes that could affect compliance or risks.
An initial inventory might include operational metrics, abnormal outputs, technical incidents, complaints, structured user feedback, support requests and changes in conditions of use. Depending on the system, it may also be relevant to observe changes in the user population, input data or processes with which the system is integrated. None of these signals is mandatory in every case: their usefulness depends on the context and the risk being monitored.
Interactions with other AI systems deserve attention when relevant to understanding performance or risks. For example, a tool may receive outputs from another system or feed its own outputs into an automated process. In such cases, a change in the connected system, data format or workflow may alter observed behaviour even if the model being monitored has not changed. The plan should identify relevant dependencies and explain how changes to them will be detected.
Cooperation with the deployer matters because the provider may not directly observe every real-world condition of use. An operational agreement can specify which data categories will be shared, who prepares them, how often, through which channel, and to whom urgent signals should be communicated. This is a practical recommendation: the Regulation does not make that particular list a mandatory form. Any exchange should be limited to what is necessary for monitoring and should respect other applicable obligations.
Possible sources and control questions
The selection should be adapted to the system. This table suggests sources and questions to help decide whether they provide useful signals.
| Source | What it may reveal | Question for the plan |
|---|---|---|
| Provider performance logs | Errors, interruptions or changes in technical metrics | Which events are recorded, and who reviews trends? |
| Information from the deployer | Real-world conditions of use, problematic outcomes or process changes | What data can the deployer provide, and how often? |
| Support requests and complaints | Recurring problems, unexpected effects or difficulties using the system | How are they categorised and linked to system versions? |
| Connected systems or dependencies | Changes in inputs, integration or behaviour across a chain of systems | Which changes must be reported to the provider? |
Designing a plan that can be put into practice
An operational plan starts with the intended use and the risks the system may pose in that context. It then identifies which data could reveal a relevant change and what decisions might follow. A table of metrics without owners, review criteria or routes to action is difficult to use and offers little clarity about how a signal was handled.
It is useful to assign distinct responsibilities. A technical team can validate data quality and analyse behaviour; product staff can assess changes in features or conditions of use; compliance staff can check applicable obligations and documentation; and a person or team with defined authority can decide whether a case should be escalated. In a small organisation, one person may cover several functions, but decisions and their rationale should remain identifiable.
Indicators should be formulated so that they support consistent review. They might include error rates, downtime, changes in the distribution of inputs, differences between groups relevant to evaluating the system, or an increase in outputs requiring human review. An indicator is useful only if the plan defines how it is calculated, what period it covers and what its limitations are. A metric should not be presented as conclusive proof if it is only a signal to investigate.
The provider can set internal alert levels. For example, a change above an agreed threshold could trigger a technical review; a repeated change or one appearing across several deployments could justify a broader assessment. These thresholds are recommended management tools, not values set generally by Article 72. They should be reviewed when use, available evidence or the risk profile changes.
Suggested monitoring cycle
An illustrative operational sequence for connecting observation with action.
- 01Define the intended use, relevant risks and the questions the monitoring system needs to answer.
- 02Select data sources and agree with deployers what information will be shared and when.
- 03Validate data quality, context and limitations before comparing the data with a reference point.
- 04Review indicators and signals at a frequency proportionate to risk and to how quickly the system may change.
- 05Investigate relevant signals, document the conclusion and escalate cases that may affect compliance or safety.
- 06Take action, keep the system under enhanced monitoring, or explain why no further action is considered necessary.
- 07Review the plan when the system, its context of use, available evidence or observed risks change.
Investigating signals and recording decisions
A signal does not automatically amount to non-compliance. It may result from incomplete data, a change in the client’s process, a temporary incident or a genuine degradation. The investigation should distinguish between these possibilities and record what information was reviewed. If the signal affects several deployments, it is worth checking for a common cause, such as a particular version, a shared dependency or a change in input conditions.
A useful decision record includes the date the signal was detected, its source, the affected system and version, a description of the signal, the person responsible for assessing it, the evidence reviewed, the conclusion and the next steps. If no action is taken, the record should explain why the available information did not justify action and what conditions would prompt the case to be reopened. This level of detail is good documentation practice, not a prescribed, fixed format under the Regulation.
Possible measures depend on the finding. They may include fixing a defect, updating instructions, changing an integration, strengthening human controls, temporarily limiting certain uses or starting a broader technical review. The chosen response should match the problem observed and be documented. If a signal suggests that the system no longer meets applicable requirements or that previously unconsidered risks have emerged, the provider should connect the finding to its assessment and risk-management processes rather than treating it as an isolated customer-support issue.
The deployer also needs to know what information matters for using the system appropriately and reporting relevant problems. The plan should therefore provide for an escalation channel and a way to feed information back to the provider. For products with several customers, a consistent route helps prevent similar signals from becoming scattered across different support teams.
Monitoring, risk management, impact assessments and incidents
Post-market monitoring does not replace risk management. Risk management is a broader process of identifying, analysing and addressing risks that should accompany the system. Monitoring provides information about the system’s real-world operation and may reveal that an earlier assumption no longer holds, a new risk has emerged or a control measure is not working as expected. The plan should allow those signals to reach the people who can review existing assessments and measures.
Nor is monitoring the same as a pre-deployment impact assessment. A prior assessment considers possible effects in a particular context before a specific use, where applicable. Monitoring observes information throughout the system’s lifecycle and helps detect changes that may only become visible in use. The activities complement one another: an assessment alone cannot demonstrate that the system will continue to behave in the same way after deployment.
The serious-incident reporting requirement in Article 73 has a different trigger and purpose: it concerns incidents that must be reported under the applicable rules. Monitoring, by contrast, should operate systematically and should not wait for a serious incident to occur. A signal may warrant investigation and preventive action even if it has not reached the threshold of a reportable incident. And if an incident that must be reported is identified, the monitoring process does not replace the required communication.
To avoid confusion, organisations can link these processes without merging them: the same event may open a monitoring investigation and separately trigger an assessment of whether incident reporting is required. The record should show which route was considered, who made the decision and what actions were started. This separation helps prevent an early signal from being underestimated or every minor deviation from being treated automatically as a serious incident.
Which process answers which question?
A functional distinction to help organise responsibilities and escalation.
| Process | Main question | When it is useful |
|---|---|---|
| Post-market monitoring | What does relevant data show about the system in use throughout its lifetime? | Continuously and proportionately, to detect changes or signals. |
| Risk management | Which risks should be identified, and how can they be prevented or reduced? | Throughout the system lifecycle and when findings are reassessed. |
| Impact assessment | What effects might arise in the context of an intended use? | Before deployment where applicable; it does not replace subsequent monitoring. |
| Serious-incident reporting | Has an incident occurred that must be reported under the applicable rules? | When an incident occurs that triggers a reporting obligation. |
Specific cases and the regulatory timeline
Article 72 includes a specific safeguard for certain high-risk systems in the law-enforcement area: the monitoring system does not cover sensitive operational data held by law-enforcement authorities. This is a specific exclusion. It should not be interpreted as a general monitoring exemption for every system used by an authority, or as permission to ignore other relevant signals that can be handled under the applicable rules.
The 2026 regulatory reform changed the provision concerning Commission guidance. The Regulation provides for the Commission to publish guidance and a voluntary template for the post-market monitoring plan by 2 September 2027. The template should therefore not be described as already available or as a requirement in itself. Until it is published, providers can structure their documentation around the applicable legal obligations and their operational needs.
The timetable for applying the rules to high-risk systems was also amended. The consolidated text sets different dates by category: for high-risk systems listed in Annex III, the relevant obligations begin to apply on 2 December 2027; for high-risk systems regulated by the harmonisation legislation listed in Annex I, they begin to apply on 2 August 2028. The classification and applicable date should be checked for each system; one date should not be assumed to apply to all AI products.
These dates do not diminish the value of preparing the monitoring cycle in advance. Setting up data sources, information-sharing arrangements and responsibilities often requires coordination between provider and client. However, operational preparation should not be confused with claiming that an obligation already applies to a particular system before its relevant date.
Checklist for reviewing the plan
The practical test of a plan is not its length, but whether it makes it possible to reconstruct how the system is monitored and what happens when a signal appears. The following questions can support an internal review. They do not replace legal analysis of the system, its classification or its specific obligations.
A strong plan identifies the system and its relevant uses, explains which information sources it uses and why, assigns responsibilities and defines an analysis routine. It also addresses how signals are communicated between provider and deployer, how decisions are retained, and how findings are linked to a risk review or corrective action.
The review should also check whether metrics can be interpreted, whether alerts lead to concrete action, and whether the team can distinguish a data anomaly from system degradation. If a version change, new integration or change in context could affect performance, the plan should explain how that change will be detected and how monitoring will be reconsidered.
Quick plan check
Questions to verify that documentation translates into a workable process.
- 01Does the plan describe the system, relevant uses and the risks monitoring should help detect?
- 02Are data sources identified, along with their relevance to performance or compliance?
- 03Is it agreed how and when the deployer will communicate relevant information?
- 04Are people responsible for validating signals, investigating them and deciding whether to escalate?
- 05Does the plan specify how evidence, conclusions and reasons for taking or not taking action are recorded?
- 06Does the process link findings to risk review, corrective measures and, where applicable, the incident-reporting route?
- 07Is the plan reviewed when the system, its dependencies, conditions of use or available evidence change?
Open questions
- The Commission’s future guidance and voluntary template should not yet be assumed to be available; their specific content cannot be anticipated.
- The indicators, thresholds, frequencies and record formats suggested in the guide are operational options, not uniform requirements expressly set for all systems by Article 72.
- The legal category and applicable date must be determined for each specific system, since the timetable distinguishes between categories of high-risk systems.
- The exclusion concerning sensitive operational data held by law-enforcement authorities is specific and does not amount to a general monitoring exemption.
Keep exploring
Sources consulted
Corrections and transparency
If you spot incorrect or outdated information, send us a correction with the page and source we should review.
Submit a correction