EU AI Act Art.72 Post-Market Monitoring Plan: A Developer's Guide to High-Risk AI PMS Requirements

Post #1607 in the sota.io EU AI Act Operations Series

The EU AI Act's August 2, 2026 deadline for high-risk AI systems covers many obligations — risk management, technical documentation, transparency requirements. But one obligation that often gets overlooked in the sprint to August compliance is Article 72: Post-Market Monitoring.

This isn't a check-box you fill in once and forget. Article 72 requires a living, operational system that continuously tracks your AI's real-world performance after deployment. If your monitoring plan isn't in place before August 2, you're non-compliant from day one of enforcement.

This guide covers what Art.72 actually requires, how to structure your Post-Market Monitoring (PMS) plan, what metrics matter, and how to connect monitoring to your Art.9 risk management system and Art.73 serious incident reporting.

What Article 72 Actually Requires

Article 72 of the EU AI Act (Regulation (EU) 2024/1689) establishes that providers of high-risk AI systems must establish and implement a post-market monitoring system.

The core obligations under Art.72:

Art.72(1) — Providers shall establish and document a PMS plan before placing the system on the market or putting it into service. The plan must be proportionate to the nature of the AI technology and the risks it poses.

Art.72(3) — The PMS plan must specify what data will be collected, how it will be analyzed, what performance indicators will be tracked, and when corrective actions are triggered.

Art.72(4) — Providers must actively gather, document, and analyze relevant data about AI system performance throughout its operational lifetime. This includes data received from deployers under Art.74 market surveillance cooperation.

Art.72(6) — Providers must register serious incidents discovered through post-market monitoring in the EU database under Art.71 and report them to market surveillance authorities under Art.73.

The PMS Plan: Required Components

Your Art.72 PMS plan must be a structured document that becomes part of your technical documentation (Annex IV). It needs these elements:

1. Scope and Objectives

Define which AI system components are covered, the intended purpose (as per Annex I/III), the risk level, and the monitoring objectives. This section establishes proportionality — a credit-scoring model for retail banking needs more intensive monitoring than a document classification tool.

Required content:

• System identification (name, version, intended purpose)
• Risk category under Annex III
• Monitoring objectives tied to identified risks from Art.9 risk management system
• Geographic scope of deployment

2. Performance Metrics and KPIs

Art.72 doesn't prescribe specific metrics, but your metrics must be traceable back to the risks identified in your Art.9 risk management system. The principle: if a risk scenario in your risk management plan could materialize, your monitoring metrics must be capable of detecting it.

Minimum required metric categories for most high-risk systems:

3. Data Collection Methods

Specify how monitoring data will be collected. Art.72 requires actual data collection — passive logging is not sufficient if risks can only be detected through active monitoring.

Data sources to document:

• System logs (prediction outputs, confidence scores, input feature distributions)
• User feedback channels (complaint intake, error reports from deployers)
• Third-party testing (periodic independent audits)
• External data (relevant regulatory databases, incident reports from similar systems)
• Deployer reports (data flowing back under Art.74 market surveillance)

Storage jurisdiction matters: If your monitoring data is stored on AWS/Azure/GCP, it's subject to US CLOUD Act access requests. For high-risk AI systems where the training data, inference data, and monitoring data are all under EU AI Act scrutiny, storing monitoring data outside EU jurisdiction creates a compliance gap — market surveillance authorities require access to this data, and CLOUD Act exposure could complicate that access. EU-hosted infrastructure (Hetzner Germany, Scaleway, OVHcloud) avoids this entirely.

4. Review Cycles and Triggers

Your PMS plan must define:

Regular review schedule:

• Continuous monitoring: automated alerts for threshold breaches
• Monthly review: performance trend analysis, bias metric check
• Quarterly review: comprehensive PMS report, risk management system update if needed
• Annual review: full technical documentation update, regulatory assessment

Event-triggered reviews:

• Performance metric drops below defined threshold → immediate investigation
• Bias metric exceeds defined ceiling → mandatory corrective action window
• User complaint cluster (≥N similar reports in T days) → escalated review
• Material change to deployment context → re-assessment of risk profile

Threshold escalation path:

Performance anomaly detected
    ↓
Automated alert + logging
    ↓
Human review within [24h for P1 / 72h for P2]
    ↓
Root cause analysis
    ↓
Corrective action OR Art.73 serious incident report
    ↓
Documentation update + regulatory notification if required

5. Corrective Action Protocols

Art.72(3) requires that your plan specify what happens when monitoring detects problems. This must be a concrete decision tree, not a vague statement about "taking appropriate action."

Required elements:

• Threshold definitions (what level of degradation triggers action)
• Action types: parameter adjustment, model retraining, feature removal, system suspension
• Authorization levels (who can approve what type of corrective action)
• Timeline commitments for each action type
• Documentation requirements for each corrective action
• Art.73 serious incident assessment checklist

6. Serious Incident Integration (Art.72 → Art.73 Pipeline)

Post-market monitoring is the primary detection mechanism for Art.73 serious incidents. Your PMS plan must include an explicit serious incident detection protocol.

Under Art.3(49), a "serious incident" is any incident or malfunction that leads to:

• Death or serious harm to health
• Disruption of critical infrastructure management
• Infringement of fundamental rights
• Serious damage to property or environment

Your monitoring system must be capable of detecting signals that could indicate any of these outcomes — not just technical performance degradation. A bias metric showing systematic unfavorable treatment of a protected group is a fundamental rights signal, not just a fairness metric.

Integration with Art.9 Risk Management System

Art.72 monitoring does not exist in isolation. The closed loop is:

Art.9 Risk Management System
  ├── Identifies risks and likelihood
  ├── Defines acceptable risk thresholds
  └── Feeds: what to monitor (Art.72)
  
Art.72 Post-Market Monitoring
  ├── Continuously measures identified risks
  ├── Triggers corrective actions
  └── Feeds back: new risk discoveries → update Art.9

Art.73 Serious Incident Reporting
  ├── Triggered when monitoring detects serious harm
  └── Feeds back: incident learnings → update Art.9 + Art.72

Your technical documentation (Annex IV) must show this connection explicitly. Auditors and notified bodies will look for evidence that your monitoring plan actually covers the risks you identified — not just generic performance metrics that happen to be easy to measure.

Common Developer Mistakes to Avoid

1. Treating PMS as documentation, not operations Art.72 requires an operational system. A written plan without automated monitoring infrastructure is insufficient. You need logging pipelines, alerting infrastructure, and human review processes that actually run.

2. Monitoring only for technical accuracy, not for harms A model that gets 95% accuracy but systematically discriminates against a protected group has a serious incident risk — not a performance problem. Your monitoring must cover the harm scenarios from your risk management plan.

3. Not documenting monitoring data provenance Art.72(4) requires systematic data collection. You must be able to demonstrate to market surveillance authorities what data you collected, when, from where, and how you analyzed it. Informal dashboards aren't sufficient — you need documented, auditable data pipelines.

4. Forgetting deployer data flows Under Art.74, deployers have obligations to cooperate with providers on monitoring. Your PMS plan must include a mechanism to receive monitoring data from deployers. If you've deployed through an API, your Terms of Service must include data reporting obligations and your monitoring system must have an ingestion path for that data.

5. Static review schedules without event triggers A quarterly review cycle might miss a rapidly developing bias problem. Your plan needs both scheduled reviews and event-triggered reviews with defined response timelines.

Practical Implementation: Minimum Viable PMS Stack

For a high-risk AI system approaching the August 2026 deadline, here's a minimum viable monitoring stack:

Data collection:

• Structured logging of all predictions with input features (anonymized/pseudonymized per GDPR)
• Prediction confidence score tracking
• User feedback intake form with structured categories
• Deployer incident report API endpoint

Metrics computation:

• Daily automated performance metric computation (Python/SQL pipeline)
• Weekly bias metric computation against protected attribute proxies
• Distribution shift detection (PSI or Kolmogorov-Smirnov test on feature distributions)

Alerting:

• Threshold-based alerts for performance metrics (e.g., precision drops >5% from baseline)
• Bias metric alerts when fairness thresholds exceeded
• Distribution shift alerts when PSI > 0.2

Review workflow:

• Monthly PMS report template with automated data population
• Structured incident log for anything that reaches the review threshold
• Escalation path documentation (who gets paged, in what timeframe)

Documentation:

• PMS plan as versioned document in your technical documentation repository
• Monitoring data stored for minimum 10 years (Art.18 for certain systems, Art.72 minimum period)
• Change log for all corrective actions taken

Storage Infrastructure and CLOUD Act Considerations

One practical consideration that affects your monitoring architecture: where you store monitoring data determines who can access it.

High-risk AI monitoring data includes prediction outputs, performance metrics, incident logs, and user complaint data. This data:

• Must be accessible to EU market surveillance authorities on request
• May contain personal data subject to GDPR restrictions
• Is evidence in any regulatory proceeding

If this data lives on AWS (US parent company), Azure (Microsoft, US parent), or GCP (Google, US parent), it's reachable via US CLOUD Act warrants — independently of where the data center physically sits. An EU authority asking for your monitoring data to investigate a discrimination complaint could find that the same data is simultaneously accessible to US law enforcement. This is not a hypothetical; it's a structural exposure in the current cloud provider landscape.

EU-native infrastructure (Hetzner Germany, OVHcloud France, Scaleway France) operates without this exposure. Your monitoring data stays under EU jurisdiction only, with no CLOUD Act overhang. For high-risk AI systems where monitoring data integrity and sovereign access control matter, this is the correct default choice.

Summary: Art.72 PMS Plan Checklist

Before August 2, 2026, your Art.72 compliance requires:

PMS Plan Document:

• System identification and risk category
• Monitoring objectives linked to Art.9 risk assessments
• Performance metrics with defined baselines and thresholds
• Bias/fairness metrics covering protected groups relevant to use case
• Data collection methods and sources documented
• Review schedule (continuous + monthly + quarterly + annual)
• Event-triggered review conditions defined
• Corrective action decision tree with authorization levels
• Art.73 serious incident detection protocol
• Deployer data reporting mechanism

Operational Infrastructure:

• Automated logging pipeline active
• Metric computation pipeline running (at minimum daily)
• Alert thresholds configured and tested
• Review workflow documented and staff assigned
• Monitoring data stored with 10-year retention capability

Documentation Integration:

• PMS plan included in Annex IV technical documentation
• Link to Art.9 risk management system explicit and traceable
• PMS plan versioned and change-logged

The next posts in this series cover the specific MLOps implementation for drift detection and alert thresholds (Art.72 #2/5), bias monitoring in production (Art.72 #3/5), the Art.72 → Art.73 escalation pipeline (#4/5), and the complete PMS developer checklist finale (#5/5).

EU AI Act Article 72 requires a post-market monitoring system proportionate to the nature and risks of the AI system. Providers of high-risk AI must establish and document their PMS plan before the August 2, 2026 enforcement date.

See Also

• EU AI Act Art.73 Incident Detection Automation — Serious incident reporting pipeline
• EU AI Act Post-Market Monitoring Automation — DevOps automation for Art.72
• EU AI Act Risk Management System Documentation — Art.9 RMS hosting requirements
• EU AI Act Conformity Assessment: What Notified Body Auditors Check — NB audit preparation