AI Act post-market monitoring under Article 72: plan, metrics, escalation

A common misconception is: “We only buy, so we do not need to monitor anything.” Article 26(5) expressly requires deployers to monitor operation. The duty is leaner than the provider’s, but it is not optional. In practice, the oversight staff under Article 26(2) need a clear way to report anomalies, and someone has to collect those reports and pass them on to the provider.

Conversely, the provider cannot meet its duty without deployers. Article 72(2) expressly names data provided by deployers as a source. We recommend recording in the contract which data the deployer supplies in which form, how feedback is transmitted and how quickly the provider responds. That turns a general expectation of cooperation into a process that can be checked.

Two metrics deserve particular attention because many plans lack them. First, error rates by group of persons: overall accuracy can stay stable while performance for one group deteriorates markedly. Where the system is applied to people, the instructions for use under Article 13(3)(b) must state performance regarding specific persons or groups – those statements are the natural reference value.

Second, the override rate: the share of cases in which human oversight rejects the system’s recommendation. If it rises sharply, that points to declining quality. If it drops towards zero, it may indicate automation bias – oversight that merely rubber-stamps. Both are monitoring findings, not just staffing issues.

Generative systems have a particular feature: classic accuracy measures often do not apply. Regular samples with fixed assessment criteria, and the rule that every change of the underlying model is treated as an event, have proved useful. Whether an LLM assistant is high-risk at all depends on its use, for example in an area listed in Annex III – not on the technology.

What matters is the separation between automated alert and expert assessment. An alert from the monitoring tool is a prompt, not a decision. Whether level 3 or 4 applies is decided by a person with a documented rationale. It is exactly that rationale an authority will ask for later – not the raw alert data.

Equally important: false alarms belong in the record too. A plan showing that anomalies were reviewed and dismissed with reasons demonstrates a working system. A plan without a single case over twelve months raises the question of whether anyone is looking at all.

In most cases monitoring is where a serious incident first becomes visible: as an outlier in a metric, as a complaint, as a report from a deployer. The Article 73 deadlines run from awareness. The report must be made immediately after the provider has established a causal link between the AI system and the incident, or the reasonable likelihood of such a link – and no later than 15 days after becoming aware, or 2 or 10 days in the special cases. An incomplete initial report is permitted.

For the plan this means it must ensure relevant reports do not sit in an inbox. We recommend specifying in the plan that every level-3 finding is immediately checked for a reporting duty as well, and who carries out that check. For deployers there is an additional rule: a serious incident goes immediately to the provider first; if the provider cannot be reached, Article 73 applies mutatis mutandis.

The details – content of the report, competent authority, interplay with GDPR or NIS2 notifications, the investigation under Article 73(6) – are covered in our incident management guide. In Germany the KI-MIG makes the Federal Network Agency (Bundesnetzagentur) the market surveillance authority in principle, and BaFin for certain financial activities.

Besides incidents, monitoring can produce a second, often overlooked finding: the system has changed so much that the original conformity assessment no longer covers it. Article 3(23) defines a substantial modification as a change after placing on the market that was not foreseen or planned in the initial conformity assessment and that affects compliance with the requirements or changes the intended purpose. Article 43(4) then requires a new conformity assessment procedure.

For systems that continue to learn there is an important exception: changes the provider pre-determined at the time of the initial conformity assessment and described in the technical documentation under Annex IV point 2(f) do not count as a substantial modification. Monitoring is the tool that shows a system has stayed within that pre-described corridor.

For deployers the finding has its own weight. Whoever makes a substantial modification to a high-risk AI system so that it remains high-risk is considered a provider under Article 25(1)(b) – with all Article 16 duties, including its own Article 72 plan. In-house retraining, swapping components or a new purpose should therefore be checked in advance.

Articles 72 and 73 attach to high-risk AI systems. Following amending Regulation (EU) 2026/1744, the high-risk requirements in Chapter III Sections 1 to 3 apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028. From those dates the plan and monitoring become relevant in practice. Anyone placing systems on the market by then should not write the plan on the deadline: it depends on logs, reference values and deployer contracts that cannot be retrofitted at short notice.

For small and medium-sized enterprises and small mid-caps, Article 17(2) allows proportionate quality management. Article 72(1) likewise requires a system proportionate to the technology and the risks. A manageable plan with a few metrics, clear responsibilities and actual review is better than an extensive document nobody maintains.

For systems that are not high-risk, the AI Act does not require post-market monitoring. We still recommend a light form of monitoring – for a service chatbot, say – because purposes shift and complaints and malfunctions have to be handled anyway.