Definition: Post-Market Monitoring (EU AI Act)
Post-market monitoring is the obligation under Article 72 of the EU AI Act requiring providers of high-risk AI systems to actively and systematically collect, document, and analyze data on how the system performs after it reaches the market, for as long as it stays in use.
Core characteristics of post-market monitoring
Unlike a one-time check, post-market monitoring runs continuously for the system’s operational lifetime, scaled to its risk level.
- Collects performance data from deployers and other sources, not only the provider’s own testing
- Evaluates whether the system still meets the requirements it was originally certified against
- Analyzes interaction effects when the system operates alongside other AI systems
- Feeds into the technical documentation as a formal, written monitoring plan
Post-Market Monitoring vs. Conformity Assessment
Conformity assessment is a point-in-time check completed before a system reaches the market. Post-market monitoring picks up where that check ends, tracking whether a system that passed assessment on day one still behaves the same way months into real-world use. A system can pass assessment cleanly and still drift out of compliance later, which is the gap Article 72 closes.
Importance of post-market monitoring in enterprise AI
Post-market monitoring keeps a certified system trustworthy after launch instead of treating the CE mark as a permanent guarantee. The 2025 AI Governance Survey by Pacific AI and Gradient Flow found that only 48% of organizations actively monitor production AI systems for accuracy, drift, and misuse, dropping to 9% among small companies.
Methods and procedures for post-market monitoring
Building a compliant monitoring capability means pairing a documented plan with a working data pipeline.
Post-market monitoring plan and system design
The plan becomes part of the Annex IV technical documentation and specifies what gets collected, how often, and by whom.
- Define performance indicators tied to the certified requirements
- Set collection intervals proportionate to usage and how fast risk could change
- Document against the Commission’s template once finalized, or Annex IV directly for now
Data collection from deployers and other sources
Article 26(5) obliges deployers to monitor the system and report any observed risk, making deployers a primary data source alongside logs and complaints.
Continuous compliance evaluation
Data only helps if someone reviews it against the certification requirements on a set cadence. Mature providers fold this into their broader AI governance program so a performance dip triggers the same escalation as any other governance signal.
Important KPIs for post-market monitoring
Tracking this obligation requires indicators distinct from general product analytics.
Operational monitoring metrics
- Data coverage: percentage of deployed instances feeding performance data back to the provider
- Review cadence: scheduled monitoring plan reviews actually completed
- Drift detection lag: time between a performance shift occurring and being flagged
- Deployer response rate: percentage of risk notifications acknowledged within a set window
Strategic risk metrics
Boards increasingly ask how many high-risk systems sit under active monitoring versus simply deployed. Bitkom’s 2026 AI study found 52% of German companies name a lack of rules and control over their AI systems as their single biggest concern, ahead of cost or skills gaps.
Quality and accuracy metrics
Well-run monitoring tracks the same accuracy and error-rate metrics used during conformity assessment, applied continuously. A meaningful divergence from the certified baseline should trigger a substantial-modification review, not wait for the next audit.
Risk factors and controls for post-market monitoring
Article 72 carries specific risks that a written plan alone does not eliminate.
Incomplete or reactive monitoring
The most common failure is a monitoring plan that exists on paper but collects no real data because deployers were never onboarded to report it.
- Contractually require deployer data sharing before a high-risk system ships
- Automate data collection wherever the deployment architecture allows it
- Assign a named owner accountable for reviewing, not just receiving, the data
Deployer-provider data gaps
Many Mittelstand deployers using a purchased high-risk system have no internal process for surfacing performance issues to the provider, starving the monitoring system of the field data Article 72 assumes it receives.
Template and documentation uncertainty
The Commission’s monitoring plan template was due by February 2, 2026 but had not been formally published as of mid-2026, leaving providers to build against Annex IV directly and re-align later.
Practical example
A 95-employee provider of AI-based credit scoring software for regional savings banks near Frankfurt classified its scoring model as an Annex III high-risk system. Before Article 72, the company checked model accuracy only during annual audits, missing a gradual drift from shifting applicant demographics. The team built a monitoring pipeline that pulls anonymized outcome data from each deploying bank monthly, flags accuracy deviations automatically, and routes borderline cases to a compliance reviewer.
- Monthly automated accuracy and fairness reporting per deploying bank
- Deployer onboarding checklist that contractually requires outcome data sharing
- Quarterly monitoring plan review signed off by the compliance lead
- Escalation path from a flagged deviation to a substantial-modification assessment
Current developments and effects
Three developments are shaping how providers plan their post-market monitoring work.
Digital Omnibus folds monitoring into the Annex III extension
The Digital Omnibus package postponed Annex III post-market monitoring obligations, alongside conformity assessment, from August 2, 2026 to December 2, 2027.
- Post-market monitoring for Annex III systems now applies from December 2027, not August 2026
- AI Incident Reporting under Article 73 stayed on its original schedule, unlike this obligation
- Providers already on the market before the extension still carry a live monitoring duty in practice
Delayed implementing act creates planning uncertainty
The Commission’s February 2026 deadline for the standardized monitoring plan template passed without a finalized act, leaving providers to build against Annex IV’s general requirements instead.
AI observability tooling convergence
Gartner predicts 40% of organizations deploying AI will use dedicated AI observability tooling to monitor model performance by 2028, overlapping with what Article 72 already requires providers to do.
Conclusion
Post-market monitoring turns the EU AI Act’s safety promise into a standing operational duty, not a one-time certification event. The December 2027 extension for Annex III systems buys planning time, but the data pipeline and review cadence still need building regardless of the exact deadline. Providers that treat monitoring as an extension of how they already track product performance, rather than a bolt-on exercise, are better placed once the template lands. Building the pipeline now, while the format is still flexible, beats retrofitting one later.
Frequently Asked Questions
What does Article 72 post-market monitoring actually require?
Providers of high-risk AI systems must run a system that actively collects and analyzes performance data throughout the system’s operational life, backed by a written monitoring plan filed with the technical documentation. The goal is to catch compliance drift before it becomes a safety problem.
How is post-market monitoring different from AI incident reporting?
Post-market monitoring is continuous internal tracking of performance. AI Incident Reporting under Article 73 is a narrower, event-triggered duty that fires externally only once something meets the serious-incident threshold.
Does a Mittelstand company with under 250 employees need to do this?
Yes, if the company is a provider of a high-risk AI system, the obligation applies regardless of headcount, though the monitoring system can scale proportionately to the system’s actual risk.
What does building a monitoring system cost and how long does it take?
Cost depends on whether deployer data already flows back automatically or needs building from scratch; a working pipeline with review governance typically takes a few weeks to a few months. Companies that already maintain an AI inventory tend to move faster.
Do we need our own IT team to run post-market monitoring?
No. Most Mittelstand providers combine internal compliance staff with an external partner for the data pipeline and dashboards. Companies like Superkind that build AI agents connected to real enterprise systems already log outputs and exceptions as part of the build, giving a monitoring plan a working data source instead of a blank page.
Does the Digital Omnibus mean we can wait until 2027 to start?
Not in practice. The December 2027 date applies to Annex III obligations, but systems deployed today generate real performance risk that a delayed monitoring plan will not retroactively cover. Providers building the data pipeline now avoid a scramble once the Commission’s template is finalized.
