Post-Market Monitoring Plan for AI Agents: What EU AI Act Article 72 Requires

Start With Classification, Not Labels

AI agents are not a separate legal category under the AI Act. The trigger for Article 72 is not the word agent. The trigger is whether the system is classified as high-risk or forms part of a high-risk system.

An internal assistant that drafts meeting notes is not treated the same way as an agent used in credit underwriting, claims triage, hiring, identity verification, public-sector decision support, or other Annex III use cases. If you have not done the classification work yet, start with Classifying High-Risk AI Under the EU AI Act and AI Agent Compliance Under the EU AI Act. Once a system is in scope, post-market monitoring becomes part of the operating model, not an optional best practice.

What Article 72 Actually Requires

Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system proportionate to the nature of the AI technology and the risks of the system. The monitoring has to remain active throughout the system lifetime.

In practice, that obligation has five moving parts. You need to actively and systematically collect, document, and analyse relevant post-deployment data; evaluate continuous compliance with the Chapter III Section 2 requirements; include interaction with other AI systems where relevant; base the monitoring system on a post-market monitoring plan; and keep that plan inside the Annex IV documentation stack. Existing sectoral post-market processes can be reused where Union law already requires equivalent governance, but only if the integrated result still achieves the same level of protection.

• Collect relevant post-deployment data systematically, not ad hoc.
• Review the data against ongoing compliance requirements, not only product KPIs.
• Capture interactions with other AI systems and external tools where they matter.
• Document the plan inside Annex IV so a reviewer can inspect how monitoring actually works.
• Integrate with existing sectoral processes only where the protection level remains equivalent.

A Dashboard Is Not a Plan

The most common failure mode is confusing observability with compliance. A dashboard can tell you latency, success rate, cost, or token usage. A post-market monitoring plan should tell a reviewer which risks are being watched, which signals prove the controls still work, what thresholds trigger escalation, who reviews what, and how corrective action is documented.

That is why post-market monitoring is tightly linked to EU AI Act Article 17 Checklist, AI Agent Audit Trails: From Logs to Evidence, and your underlying evidence package. If you cannot show how telemetry becomes reviewed evidence, you do not yet have an Article 72 operating model.

• Which risks are monitored: tied back to the Article 9 risk register.
• Which signals matter: not just outputs, but tool calls, approvals, overrides, and downstream effects.
• Which thresholds matter: what is informational, what needs same-day review, and what freezes production.
• Which records survive audit: incidents, reviewer rationale, corrective actions, and version-linked evidence exports.

Why Article 72 Matters More for AI Agents

Static prediction systems can fail quietly. Agents fail across systems. They retrieve data, call tools, trigger workflows, hand work to other models, and operate with different levels of autonomy. That means monitoring for agents has to be workflow-level, not just model-level.

The logic behind post-market monitoring is especially relevant for agentic systems even when the model itself is not continuously retrained. Emerging risk can come from prompt changes, policy updates, model swaps, tool access expansion, retrieval changes, integration drift, or deployer-side workflow edits. The system can become riskier without a classic training cycle ever taking place.

• Tool execution: failed actions, retries, side effects, and unauthorized attempts.
• Policy control signals: denials, near-denials, approval queues, and override reasons.
• Cross-system behavior: what happens when the agent relies on other AI services or external automations.
• Rights-relevant outcomes: disparities, complaints, appeals, and materially harmful downstream effects.

What Belongs in a Defensible Article 72 Plan

A defensible plan is not long for the sake of looking serious. It is specific enough that a reviewer could understand how you detect degradation, who investigates anomalies, and how the evidence feeds back into conformity and change control.

For AI agents, the plan should usually include at least the following building blocks. This is also the point where many teams pair the legal requirement with the Post-market Monitoring Plan Template, Human Oversight Procedure Playbook, and Evidence Pack Checklist so the process is usable by engineering and operations teams, not just lawyers.

• System identification and intended purpose: the exact system name, version, provider entity, release scope, deployment context, affected users, boundaries, and high-risk classification logic.
• Monitoring objectives tied to the risk register: every material risk should have at least one monitored signal, one owner, and one escalation path.
• Data sources and collection methods: execution logs, tool traces, approval events, override records, complaints, sampled outputs, incident tickets, and integration-change records.
• Metrics, thresholds, and severity levels: task failure rate, tool error rate, hallucination or unsupported-action rate where relevant, override frequency, disparity indicators, rollback events, and threshold-triggered consequence logic.
• Sampling policy and review cadence: always-on telemetry, 100% review for critical actions, baseline sampling for lower-risk outputs, and intensified review after releases, model swaps, or incidents.
• Human oversight and intervention data: what was escalated, who reviewed it, what context they saw, what they changed, and whether the same failure pattern is repeating.
• Incident handling and Article 73 linkage: who investigates, what becomes an incident, which authority deadlines apply, and how the reporting clock is identified and evidenced.
• Corrective action and change control: who can pause, disable, roll back, or withdraw the system and how post-market findings feed back into Article 9 risk management and Article 17 quality management.
• Evidence retention and audit readiness: how logs, reviewer notes, incidents, and corrective actions are retained, protected, linked to versions, and exported for regulatory review.

When Monitoring Becomes Article 73 Reporting

Your monitoring plan should say clearly when an alert becomes an incident, who owns triage, and when Article 73 reporting is triggered. That clock should not be left to improvisation.

Under the current Article 73 framework, the outside limit is 15 days after the provider or deployer becomes aware of a serious incident. The outside limit is 2 days for widespread infringement of obligations intended to protect fundamental rights or serious and irreversible disruption of critical infrastructure, and 10 days where a person has died once causality or reasonable suspicion of causality is established. The key operational point is simple: your thresholds and escalation rules need to surface those scenarios fast enough that reporting is still possible.

• Death or serious harm to health requires the fastest triage and a clearly evidenced causality decision path.
• Serious and irreversible disruption of critical infrastructure should bypass slow internal review queues.
• Fundamental-rights infringements are not abstract legal issues; they need operational triggers tied to complaints, overrides, appeals, and harmful downstream outcomes.
• Corrective action under Article 20 should be wired into the same workflow so mitigation does not wait for final reporting paperwork.

Providers Own Article 72, but Deployers Feed It

Article 72 is a provider obligation, but the provider often does not control the full operational context. Deployers may hold the complaint records, human-review notes, frontline incident tickets, or downstream outcome data that make monitoring meaningful.

For agentic systems, provider-deployer contracts should specify which data the deployer must return, how fast serious incidents and near-misses are escalated, how override records are retained, and how workflow or integration changes are communicated. If you do not design this interface, the plan looks complete on paper and fails in production.

• Data return obligations for complaints, overrides, appeals, and outcome metrics.
• Incident reporting channels with named contacts and jurisdiction mapping.
• Change notifications when the deployer alters prompts, tools, workflows, or surrounding controls.
• Retention and export rules so post-market evidence does not fragment across systems.

The March 2026 Template and Timeline Position

The safest current-law framing is this: the template question is unsettled; the provider obligation is not. The current Article 72 text still refers to a Commission implementing act for a plan template. But on November 19, 2025, the Commission proposed replacing that prescription with guidance rather than a harmonised plan format. That proposal is still under consideration, so it does not change the law in force today.

The same caution applies to the timeline. Under the current AI Act, most high-risk obligations apply on August 2, 2026, while certain product-embedded high-risk AI systems have a longer transition to August 2, 2027. The Commission has proposed timeline changes, but those changes are not yet law. The practical move is to build a reviewable plan now and adjust the format later if the Commission finalises template-related guidance or legislative amendments.

• Current Article 72 text: AI Act Service Desk summary of Article 72
• Current serious-incident timelines: AI Act Service Desk summary of Article 73
• Commission implementation timeline FAQ: Navigating the AI Act
• Commission standardisation FAQ: Understanding the standardisation of the AI Act
• Commission proposal under consideration: COM(2025) 811 final

Common Mistakes That Make Article 72 Plans Fail Review

The failures are usually operational, not theoretical. Teams write the plan as if it were a memo, but regulators and auditors will treat it as evidence of a live operating capability.

If you want a practical review test, ask whether a third party could look at your plan and tell how the system is monitored, who investigates anomalies, how production changes affect sampling, and what gets reported or rolled back when thresholds are crossed.

• Treating post-market monitoring as a dashboard instead of an operating procedure.
• Monitoring only model quality while ignoring tool use, approvals, overrides, and downstream effects.
• Listing metrics without thresholds, named owners, severity logic, or response times.
• Forgetting interactions with other AI systems in agentic workflows.
• Keeping raw logs but not incident decisions, reviewer rationale, or corrective-action evidence.
• Disconnecting monitoring from change control so every release resets risk without tighter review.
• Assuming the model vendor documentation replaces system-level monitoring by the provider.