EU AI Act Article 72: post-market monitoring obligations for high-risk AI deployers

Most compliance attention on the EU AI Act focuses on the obligations that apply before a system is placed on the market: risk management under Article 9, data governance under Article 10, technical documentation under Articles 11 and 17, conformity assessment under Article 43. Article 72 addresses what happens after the system is live: the obligation to systematically monitor its performance, collect data on real-world operation, and feed that data back into the risk management cycle. This obligation connects directly to the Article 73 serious incident reporting chain, to the Article 26 deployer obligations, and to the post-market surveillance powers of national market surveillance authorities. This guide explains who holds each obligation, what monitoring must cover, how to build the monitoring plan that Article 72 requires, and the enforcement architecture if that plan is absent.

What Article 72 actually says

Article 72 of Regulation (EU) 2024/1689 is titled "Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems." The provision is structured in six paragraphs.

Paragraph 1 establishes the core obligation: providers shall establish and implement a post-market monitoring system that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system. The system must actively collect, document, and analyse relevant data on the performance of high-risk AI systems throughout their lifetime, with a view to identifying opportunities to improve system quality and safety.

Paragraph 2 requires providers to have a post-market monitoring plan. The plan must be part of the technical documentation referred to in Annex IV. Where the plan addresses a system intended for the consumer market, the provider must comply with Regulation (EU) 2019/1020 on market surveillance, which is the general EU framework for market surveillance of products. This means providers cannot treat post-market monitoring as a purely internal documentation exercise: it must be structured in a way that is auditable by national market surveillance authorities.

Paragraph 3 specifies the minimum content of a post-market monitoring plan. The plan must include a procedure to collect and examine complaints or reports from users, deployers, and other relevant third parties; a procedure to feed any identified risks or incidents back into the risk management system under Article 9 and into the technical documentation; and a procedure for implementing necessary corrective actions.

Paragraph 4 requires providers to document and analyse serious incidents and to report them in accordance with Article 73. The connection between the monitoring plan (Article 72) and the incident reporting obligation (Article 73) is structural: monitoring is what generates the information that then triggers reporting obligations.

Paragraphs 5 and 6 address the specific obligations for providers of GPAI models and for the European AI Office's role in overseeing those providers, which are relevant primarily where a GPAI model is used as a component of a high-risk AI system.

The deployer's position in the Article 72 framework

Article 72 is a provider obligation. The deployer's connection to it runs through Articles 26(5) and 26(6).

Article 26(5) of Regulation 2024/1689 states that deployers who have access to relevant information shall, without undue delay, inform the provider or distributor and the relevant market surveillance authority of any serious incident or malfunctioning of the high-risk AI system that the deployer becomes aware of. The deployer's information obligation is therefore a specific and time-sensitive input to the provider's monitoring system.

Article 26(6) adds that where a deployer considers that it has grounds to believe that a relevant risk to the health, safety, or fundamental rights of persons arises from the high-risk AI system, the deployer shall inform the provider without undue delay. This is a lower threshold than Article 26(5): it does not require an actual serious incident, only reasonable grounds to believe a relevant risk exists that the current documentation does not address.

Together, these provisions mean that a deployer who identifies a potential problem with a high-risk AI system and fails to report it to the provider is in breach of the Regulation, regardless of whether the provider's own monitoring eventually catches the same problem. The deployer cannot take a passive position and wait for the provider to identify issues through their own monitoring. Real-world deployment generates information about edge cases and user populations that the provider's pre-market testing cannot replicate at scale. Article 26 makes it clear that this information must flow back to the provider systematically.

The Article 25 exception: when the deployer becomes the provider

Article 25 of Regulation 2024/1689 establishes the circumstances in which a deployer takes on the full obligations of a provider. This is directly relevant to the Article 72 question because a deployer who has become a provider under Article 25 must establish and implement the full post-market monitoring system themselves, not merely report to another provider.

Article 25(1) specifies that the deployer becomes the provider where: the deployer places a high-risk AI system on the market or puts it into service under its own name or trademark; the deployer substantially modifies a high-risk AI system; or the deployer changes the intended purpose of a high-risk AI system such that it becomes high-risk under Article 6 or Annex III when it was not previously.

Substantial modification is defined in Article 3(23) as a change to the high-risk AI system after it has been placed on the market or put into service which is not anticipated or planned by the provider in the original conformity assessment and which affects the compliance of the high-risk AI system with the requirements of Chapter III, Section 2, or results in a modification to the intended purpose for which the high-risk AI system has been assessed.

For enterprises deploying third-party AI agent platforms and customising them significantly, the substantial modification question is one of the most important compliance determinations to make. If the customisation triggers Article 25, the enterprise inherits the full Article 72 monitoring obligation and cannot rely on the original provider's monitoring plan. This is particularly relevant for Article 26 compliance planning.

Building a compliant post-market monitoring plan

For operators who hold Article 72 obligations, whether as original providers or as deployers who have become providers under Article 25, the monitoring plan must address the following elements as a minimum to satisfy the Annex IV technical documentation requirements.

Performance metrics and thresholds. The plan must specify the metrics used to evaluate whether the system continues to perform as intended in real-world deployment. These metrics should be derived from the system's intended purpose and the risk assessment under Article 9. For an AI system used in employment screening, relevant metrics might include decision consistency rates across demographic groups, appeal rates, and error rates measured against a ground truth validation set. The plan must specify the thresholds at which degraded metrics trigger a review or corrective action.

User population characteristics. The monitoring plan must address the actual population of users and persons affected by the system in deployment, not just the population assumed in pre-market testing. If deployment reveals that the system is being used by a broader or different population than anticipated in the conformity assessment, that information must be fed back to the provider and addressed in a revised risk assessment.

Data collection methods and sources. Monitoring requires data. The plan must specify what data is collected, from what sources, at what frequency, and with what data quality controls. For AI systems in high-risk categories, the data collection obligation may include collecting feedback from deployers and users through systematic channels rather than ad hoc complaint handling. Article 13 transparency obligations require that deployers have sufficient access to system logs to fulfil this monitoring function.

Analysis methodology. Raw monitoring data is not sufficient. The plan must specify how collected data will be analysed, by whom, at what cadence, and with what analytical methods. Annual review is a minimum for most systems; systems in rapidly evolving deployment contexts or with high interaction volumes typically require more frequent structured review.

Escalation and reporting criteria. The most operationally critical element of the monitoring plan is the set of criteria that trigger escalation. These include: criteria for treating an event as a serious incident under Article 3(49) and triggering Article 73 notification; criteria for updating the technical documentation; criteria for recalling or withdrawing the system; and criteria for pausing deployment while an identified risk is assessed. These criteria must be defined in advance, not determined ad hoc after an incident occurs.

Article 72 and the Article 73 notification chain

Article 73 of Regulation 2024/1689 requires providers to report serious incidents to the market surveillance authority of the member state where the incident occurred. The definition of a serious incident in Article 3(49) covers incidents that directly or indirectly cause death or serious harm to health, property damage above a threshold defined in delegated acts, serious disruption of critical infrastructure, violation of fundamental rights, or other harms specified in delegated acts.

The notification timeline under Article 73(6) is: 15 working days after becoming aware of an incident causing death or serious health harm; 3 working days after becoming aware of an incident threatening the operation of critical infrastructure; and 10 working days after becoming aware of any other serious incident. These are tight timelines relative to the pace at which most compliance teams operate.

For the deployer, the practical implication is that the monitoring system must be configured to surface serious incidents rapidly enough to support the 15-working-day notification window after the deployer becomes aware. If the deployer is not the provider, they must notify the provider in parallel with any investigation, because the provider's Article 73 clock runs from when the provider becomes aware, and the deployer's notification to the provider starts that clock.

The Article 73 serious incident reporting guide on this site covers the notification procedure in full detail.

Interaction with the Article 9 risk management system

Article 72 monitoring is not a parallel obligation to the Article 9 risk management system. It is a required input to it. Article 9(6) of Regulation 2024/1689 requires the risk management system to be updated continuously as the AI system operates in the market. Post-market monitoring under Article 72 is the mechanism that produces the information on which that continuous update is based.

The practical architecture is: Article 72 monitoring collects performance and incident data from deployed operations; that data is reviewed against the performance metrics and risk indicators defined in the monitoring plan; findings that identify new or changed risks are fed back into the Article 9 risk management system; the risk management system updates the risk register and, where appropriate, the risk mitigation measures; those updates are reflected in revised technical documentation under Article 11; and the cycle continues throughout the system's operational life.

For compliance officers building documentation systems for high-risk AI, the implication is that Article 72 monitoring records must be structured in a format that feeds directly into the Article 9 risk register. A monitoring log that sits in isolation from the risk management documentation does not satisfy the regulatory intent of the provision. For enterprises evaluating whether their documentation architecture meets these standards, the Agent Certified assessment methodology at agentcertified.eu maps post-market monitoring requirements to the seven certification dimensions.

Enforcement architecture and penalty exposure

Failure to establish or implement a post-market monitoring plan under Article 72 constitutes non-compliance with Regulation 2024/1689. Market surveillance authorities in EU member states hold investigative and corrective powers under Article 74 et seq. of the Regulation and under Regulation (EU) 2019/1020 on market surveillance.

The penalty structure under Article 99 of Regulation 2024/1689 sets penalties for providers of high-risk AI systems who fail to comply with obligations under the Regulation at up to EUR 15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. The maximum penalties of EUR 35 million or 7% of turnover apply to violations of the prohibited practices in Article 5 and to the provision of incorrect or misleading information to authorities.

An absence of post-market monitoring documentation is also relevant evidence in civil liability proceedings. Where a claimant alleges that an AI system caused harm and the provider cannot demonstrate that it had a functioning monitoring system, the absence of monitoring records suggests the provider did not meet the applicable standard of care. Under the revised EU Product Liability Directive (Directive 2024/2853, applicable from December 2026), software including AI is treated as a product and producers across the supply chain can face liability without the claimant needing to prove fault. Post-market monitoring documentation is among the most direct forms of evidence available to rebut a product defect claim.