How is Article 72 different from Article 73?

Article 72 is continuous monitoring of the system's performance against the high-risk requirements. Article 73 is reporting of specific serious incidents to the market surveillance authority. The two interact: the monitoring system is what surfaces the incidents that trigger Article 73 reporting.

Does Article 72 apply to deployers?

The primary monitoring obligation sits with the provider. The deployer has cooperation obligations under Article 26: report serious incidents to the provider, retain Article 19 logs, make them available on request. Deployers that become providers under Article 25 inherit the Article 72 monitoring duty directly.

How frequently does the monitoring analysis need to run?

The cadence is proportionate to the risks. The regulation does not set a specific frequency. Clinical, safety-critical, or rights-affecting systems warrant continuous monitoring with formal review at least monthly. Lower-impact systems may justify quarterly review. The plan documents the chosen cadence and the rationale.

What data does the deployer have to share with the provider?

Article 26(6) requires the deployer to keep the Article 19 automatic logs and make them available to the provider on request. The deployer's proactive sharing obligation is narrower than the on-request obligation; the cooperation duty under Article 26(5) for serious incidents and Article 26(11) for general cooperation typically results in standing data-sharing arrangements between deployer and provider.

How does the GPAI obligation under Article 72(4) work?

GPAI providers participate in the monitoring of the AI systems that integrate their GPAI model, in proportion to their role. In practice, this means the GPAI provider responds to information requests from downstream providers and contributes data about the model's behavior that the downstream provider's monitoring plan depends on.

What if the system's intended purpose changes after deployment?

A change in intended purpose can trigger a fresh conformity assessment and updates to the post-market monitoring plan. The plan should be reviewed when the system changes substantially. A change that crosses the substantial-modification threshold under Article 25 turns the deployer into a provider for the

EU AI Act Post-Market Monitoring: Article 72 Obligations and the Plan That Survives an Audit

EU AI Act Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system that actively and systematically collects, documents, and analyzes data on the performance of the system throughout its lifetime. The monitoring system must be proportionate to the nature of the AI technologies and the risks, and it must allow the provider to evaluate continuous compliance with the requirements of Chapter III, Section 2. With the August 2, 2026 high-risk enforcement date 34 days away, providers and deployers operating high-risk systems in the EU need a clear read on what the monitoring plan must contain, what data feeds it, and what artifacts an auditor expects to see. I want to walk through Article 72 as the regulation actually writes it, the four operational components a monitoring plan needs, and the architectural patterns that hold up under audit.

What Article 72 actually requires

Article 72(1) requires the provider to establish a post-market monitoring system that is proportionate to the nature of the AI technologies and to the risks of the high-risk AI system. The system must actively and systematically collect, document, and analyze relevant data provided by deployers, or collected through other sources, on the performance of the system throughout its lifetime.

Article 72(2) requires the provider to base the monitoring system on a written post-market monitoring plan. The plan is part of the technical documentation required under Article 11. The Commission is expected to adopt an implementing act detailing the elements of the plan and a template, but the substantive requirements are already in Article 72 and Annex IV.

Article 72(3) requires the provider to assess whether the system continues to comply with the requirements of Chapter III, Section 2 (the requirements for high-risk AI systems: risk-management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy and cybersecurity, quality management). The monitoring is not a passive observation; it is an evaluation against the substantive requirements.

Article 72(4) requires GPAI providers to participate in the monitoring of the AI systems that integrate their GPAI model, in proportion to the role they play. The clause is short but operationally meaningful for systems that include third-party foundation models.

The four operational components a plan needs

A monitoring plan that holds up under audit has four operational components.

The data sources. The plan specifies what data the provider collects, from which sources, and at what cadence. The sources typically include the deployer's automatic logs (Article 19), the provider's own telemetry, deployer-reported incidents under Article 26(5), and complaints or feedback from affected persons. The plan specifies the data fields collected from each source and the retention period.

The evaluation methodology. The plan describes how the collected data is analyzed against the requirements of Chapter III, Section 2. The analysis typically includes accuracy metrics tracked over time, bias and fairness metrics on the populations the system serves, resilience metrics under adversarial or distribution-shift conditions, and the rate of incidents that approach or cross the Article 73 serious-incident threshold.

The cadence and triggers. The plan specifies when the analysis runs (continuously, monthly, quarterly), what triggers an out-of-cycle review (incident, drift detection, regulatory inquiry), and who participates in each review. The cadence has to be proportionate to the risk; a clinical decision-support system warrants more frequent review than a low-volume back-office automation.

The actions and decision rights. The plan specifies the actions the provider takes when the monitoring identifies a deviation. The actions include corrective measures (configuration changes, retraining, model rollback), notifications (to deployers, to authorities under Article 20 corrective action obligations, to affected persons where applicable), and the decision rights for each action. The plan names the roles, not the individuals; the individuals are listed in the supporting records.

The data the plan needs from the operational record

The monitoring plan depends on data from the operational record. The Article 19 automatic logs are the primary source. The records the deployer retains for at least six months provide the request-and-response trail, the identity context, the policy state, and the model version that was in effect for each call.

A monitoring plan that relies on aggregated metrics without the underlying records is operationally fragile. When a deviation is detected, the investigation needs the per-decision records to understand what happened. A drift in accuracy in a particular sub-population needs the per-call records for that sub-population, including the prompts the model received, the responses it produced, and the identities that initiated the calls. Aggregated metrics alone do not support the investigation.

The architectural conclusion is that the monitoring plan and the Article 19 logging architecture are coupled. The logs that satisfy Article 19 are the substrate the monitoring plan analyzes. The logs need to be in a form that supports both the retention obligation and the analysis cadence.

The deployer's role in post-market monitoring

The provider runs the monitoring system. The deployer feeds it. Article 26(5) requires the deployer to inform the provider about serious incidents that meet the Article 73 threshold. Article 26(6) requires the deployer to keep the automatically generated logs under Article 19 and make them available to the provider on request.

The deployer's operational obligation is to produce the logs that the provider's monitoring plan depends on. A deployer that runs application-controlled logs that the application can suppress fails the deployer obligation and breaks the provider's monitoring chain.

In the integrated-deployer case, where the deployer is also the provider under Article 25, the obligations collapse into a single organization. The monitoring plan and the logging architecture are run by the same team. The internal split between "data we produce" and "data we analyze" still applies; the team owns both halves.

The artifacts an auditor expects

A market surveillance audit of Article 72 compliance typically examines six artifacts.

The written post-market monitoring plan itself, with version history and approvals. The plan should reflect the current system, not the system as designed two years ago.

The Article 11 technical documentation that the plan is part of, with the current risk management system, the data governance procedures, and the human-oversight measures.

The operational records the plan depends on, including a sample of Article 19 automatic logs covering the audit period. The auditor may request a random sample of decisions and ask the provider to reconstruct each decision from the logs.

The analysis records that show the monitoring system actually ran. Spreadsheets, dashboards, or formal reports that document each scheduled and triggered review. The records should show the inputs, the analysis performed, the findings, and the actions taken.

The corrective-action records under Article 20, which document each instance where the monitoring identified a deviation and the provider took action. The records link back to the analysis that triggered the action.

The deployer-cooperation records, which document the data the deployer provided to the provider and the timing of the cooperation. In the integrated-deployer case, the records show the internal flow from operational team to monitoring team.

The pattern that breaks monitoring chains

A common failure pattern in deployer organizations is the disconnected monitoring chain. The application team owns the AI workflow and its application logs. The compliance team owns the monitoring plan but has no operational visibility into the workflow. The audit happens, the auditor asks for the monitoring records, and the records do not exist because the data the monitoring plan describes was never collected.

The break in the chain is structural. The monitoring plan can be written without the operational data architecture being in place to feed it. The auditor's question, "show me the data your plan says you collect," surfaces the gap.

The fix is to design the monitoring data flow as part of the AI system architecture from the start. The Article 19 logging architecture is the substrate. The monitoring plan describes how the substrate is analyzed. The two artifacts cite each other.

How the gateway position fits

A policy gateway between authenticated users or agents and the model has the operational position to produce the data the monitoring plan needs. Every request and response passes through the gateway. The gateway has the identity context, the policy version, the model version, and the timing. The audit record at the gateway is the substrate.

The gateway position has three implications for the monitoring plan. The data is produced at the request boundary, outside the application's control. The data is uniform across applications that use the same gateway. The data is available in near-real-time for the monitoring cadence to draw on.

DeepInspect

This is the operational substrate DeepInspect was built to provide for Article 72 monitoring. DeepInspect sits inline between authenticated users or agents and the LLMs that high-risk AI systems call, writes a per-decision audit record with identity, policy version, model version, retrieval reference, and timestamp attached, and exposes the record set to the provider's monitoring analysis.

For the Article 72 monitoring plan specifically, DeepInspect produces the data the plan analyzes. The monitoring system reads the audit trail, runs the configured analyses, and surfaces the deviations the plan defines. The plan's cadence and the audit trail's availability are coupled; the data exists when the analysis runs.

If you are facing the August deadline and your Article 72 monitoring plan depends on data you have not yet captured, let's talk today.