Post-Market Monitoring: What Happens After You Deploy

Compliance with the EU AI Act doesn’t end when you deploy. For providers of high-risk AI systems, Article 72 requires a post-market monitoring system that runs for the entire lifetime of the AI system. This isn’t an optional best practice. It’s a specific, documented obligation.

Many organisations focus their compliance efforts on the pre-deployment requirements: risk management, technical documentation, conformity assessment. These are substantial, but they’re the entry ticket.

What the Act requires

Article 72 requires providers to “establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system.”

The system must:

Actively and systematically collect, document, and analyse relevant data
Use data provided by deployers or collected through other sources
Allow the provider to evaluate the continuous compliance of the system
Enable the provider to identify and address risks throughout the system’s lifetime

The post-market monitoring plan is part of the technical documentation required under Annex IV. It’s not a separate document you write after deployment. It’s designed before deployment and executed continuously afterward.

What to monitor

Performance metrics

Track the AI system’s real-world performance against the benchmarks documented in your technical documentation. This includes accuracy, precision, recall, false positive and negative rates, and any domain-specific performance metrics.

Performance in production almost always differs from performance on validation datasets. The question is by how much and in what ways. Monitor for:

Overall performance degradation. Is the system becoming less accurate over time? This can indicate model drift, data quality issues, or changes in the population the system serves.
Differential performance across groups. Is the system performing worse for certain demographics, geographies, or user segments? If your hiring tool is 95% accurate for applicants from one background but 78% accurate for another, you have a bias problem that post-market monitoring should detect.
Edge case frequency. How often does the system encounter inputs outside its training distribution? If edge cases are increasing, the system may be operating outside its validated scope.

Input data quality and distribution

Monitor the data flowing into your AI system:

Data drift. Are the characteristics of input data changing over time? If your system was trained on data with certain statistical properties and the production data diverges, performance will degrade.
Data quality issues. Missing fields, formatting changes, corrupted data, or changes in upstream data sources can all affect system behaviour.
Volume changes. Significant increases or decreases in data volume may indicate changes in how the system is being used.

Output distribution

Track the distribution of the system’s outputs over time:

Approval/rejection rates. If a credit scoring system’s approval rate drops by 15% with no corresponding change in applicant quality, something has changed in the system or data.
Score distributions. Shifts in the distribution of numerical scores (clustering at extremes, bimodal distributions, systematic drift) are signals to investigate.
Override rates. If human reviewers are overriding the system’s outputs more frequently, the system may be degrading or the use case may be evolving beyond its capabilities.

Incidents and complaints

Collect and analyse:

User-reported issues. Deployers or end users who report problems, unexpected behaviour, or errors.
Near-misses. Cases where the system produced a potentially harmful output that was caught by human oversight before causing damage.
Complaints from affected individuals. People who believe they were unfairly treated by an AI-driven decision.
Serious incidents. Any event meeting the Article 73 threshold (death, serious health damage, serious disruption to critical infrastructure, serious breach of fundamental rights).

System health

Standard technical monitoring that feeds into compliance:

Availability and latency. System uptime and response times.
Error rates. Application errors, timeout rates, failed inference requests.
Resource utilisation. Whether the system is operating within its documented computational parameters.

Building the monitoring system

Define metrics and thresholds

For each monitoring dimension, define specific metrics and the thresholds that trigger action. These thresholds should be documented in your post-market monitoring plan and linked to specific response procedures.

For example:

If overall accuracy drops below 90% (vs. the documented 95%), trigger an investigation
If the rejection rate for any demographic group exceeds the overall rejection rate by more than 10 percentage points, trigger a bias review
If deployer-reported issues exceed 5 per month, trigger a root cause analysis

Establish data collection mechanisms

You need reliable data pipelines to feed your monitoring system. This might include:

Automated logging. System-generated logs of inputs, outputs, confidence scores, and metadata
Deployer feedback channels. Structured mechanisms for deployers to report issues and share operational data
User feedback mechanisms. Ways for affected individuals to report concerns
Integration with deployer systems. Where possible, automated data feeds from deployers’ monitoring infrastructure

Design response procedures

Monitoring is only useful if it triggers appropriate action. Define clear procedures for each type of alert:

Investigation. Who investigates when a threshold is breached? What information do they need? What’s the timeframe?

Corrective action. If a problem is confirmed, what are the options? Retraining, recalibration, use restriction, system update, or market withdrawal.

Communication. Who needs to be informed? Deployers must be notified of issues that affect their compliance. National competent authorities must be notified of serious incidents. The EU database entry may need updating.

Documentation. All monitoring findings, investigations, and actions must be documented. This documentation feeds back into the risk management system and technical documentation.

Plan for the full lifecycle

Your post-market monitoring system must operate for as long as the AI system is on the market or in service. For systems with long operational lifetimes, this means years or potentially decades of continuous monitoring. Plan for:

Staffing. Who is responsible for monitoring, and how is continuity maintained through staff changes?
Technology evolution. Will your monitoring tools remain adequate as the system and its operating environment evolve?
Cost. Post-market monitoring has ongoing costs: infrastructure, staff time, data storage, investigation resources. Budget for these as operational expenses, not project costs.

For deployers

Deployers don’t have the same formal post-market monitoring obligation as providers, but Article 26 requires them to monitor the system in operation and inform the provider of issues. In practice, effective deployer monitoring includes:

Monitoring the AI system’s outputs in the context of your specific use case
Tracking override rates and the reasons for overrides
Collecting feedback from the people who interact with or are affected by the system
Maintaining logs as required by Article 26(6)
Reporting issues to the provider promptly
Suspending use if you identify a risk to health, safety, or fundamental rights

Your monitoring data is also valuable to the provider. Establish structured feedback channels with your provider so that your operational experience feeds into their post-market monitoring system.

Common mistakes

Treating monitoring as IT operations. Standard uptime monitoring isn’t sufficient. Post-market monitoring under the AI Act is about compliance, performance, fairness, and safety, not just whether the server is responding.

Monitoring only what’s easy to measure. Accuracy on the test set is easy to measure. Fairness across demographic groups, impact on fundamental rights, and real-world performance in edge cases are harder — but they’re what the Act cares about.

Not acting on findings. A monitoring system that detects problems but doesn’t trigger action is compliance theatre. The value of monitoring is in the response, not the detection.

Stopping after launch. Post-market monitoring isn’t a launch activity. It’s a continuous obligation. If your monitoring intensity drops after the first few months, you’re not meeting the requirement.

The post-market monitoring obligation reflects a core principle of the EU AI Act: deploying a high-risk AI system is not a one-time event. It’s an ongoing responsibility. The businesses that build this into their operations, rather than treating it as a compliance bolt-on, will have the smoothest path to sustained compliance.