EU AI Act post-market monitoring requirements: complete compliance guide for April 2026

The EU AI Act's post-market monitoring requirements go into effect April 2026, and most providers are still treating them as a documentation exercise. Article 72 actually describes a working monitoring system that collects performance data continuously, analyzes it against baseline thresholds, and surfaces incidents before they turn into compliance failures. Your high-risk AI system can't wait for quarterly reviews to catch drift or bias. The monitoring needs to run automatically, detect degradation at the inference level, and generate evidence regulators can audit on request.

TLDR:

• Post-market monitoring under Article 72 requires continuous data collection on high-risk AI systems throughout their entire lifetime, from deployment through decommission.
• Providers must report serious incidents within 15 days of awareness, 10 days if death resulted, or 2 days for widespread impact.
• The European Commission will publish a standardized monitoring plan template by February 2, 2026, weeks before April 2026 enforcement for high-risk systems.
• Automated monitoring infrastructure catches drift, bias, and security violations before they become reportable incidents, shortening compliance exposure windows.
• Openlayer automatically maps AI projects to EU AI Act requirements with continuous testing, real-time guardrails, and audit-ready evidence capture at enterprise scale.

What is post-market monitoring under the EU AI Act

Article 72 of the EU AI Act defines post-market monitoring as a mandatory, systematic process requiring providers of high-risk AI systems to actively collect and analyze data on system performance after deployment. It is not a one-time audit or a checkbox at launch. Regulators expect ongoing oversight throughout the system's entire lifetime.

The requirement sits within a broader compliance architecture that treats deployed AI as a living system, one that can drift, degrade, or behave unexpectedly as real-world conditions change. Where pre-market conformity assessments confirm a system meets requirements before release, post-market monitoring confirms it keeps meeting them. That distinction matters. Most AI failures do not happen at launch; they accumulate quietly in production.

Who must comply with post-market monitoring requirements

Post-market monitoring obligations fall primarily on providers of high-risk AI systems. If you develop or place a high-risk AI system on the EU market, you own the monitoring program. That responsibility does not transfer when a customer buys your system. The obligation has explicit extraterritorial reach. Providers based outside the EU are still subject to Article 72 if their system's outputs are used within the EU. A US-based insurer deploying a credit-scoring model used by European customers, a Canadian healthcare firm whose diagnostic tool runs in German hospitals, both are in scope. Geographic location of the provider is irrelevant if the impact lands inside EU borders.

Providers vs. deployers

The Act draws a clear line between those that provide technology and those that deploy them:

• Providers carry the primary monitoring obligation. They must build and maintain the post-market monitoring plan, collect performance data, and act on findings.
• Deployers carry secondary obligations. They must inform providers of serious incidents, cooperate with monitoring activities, and report malfunctions to market surveillance authorities.

As you can see, deployers are not off the hook entirely. If a deployer substantially modifies a high-risk system, they effectively become the provider and inherit the full monitoring burden.

Which AI systems trigger these obligations

Not every AI system is in scope. Post-market monitoring applies to high-risk AI systems under Annex III of the Act, covering areas like biometric identification, critical infrastructure, employment, education, law enforcement, and access to core services.

Core components of an AI Act-compliant post-market monitoring system

Article 72 is precise about what a post-market monitoring system must do. It requires providers to actively and systematically collect, document, and analyze performance data across the system's entire lifetime. Several components make up that compliance framework:

• Continuous data collection on system outputs, user interactions, and real-world performance against intended purpose
• Performance analysis against the metrics and thresholds defined during conformity assessment
• Documentation of incidents, near-misses, and any deviations from expected behavior
• Feedback loops that connect monitoring findings back to risk management and corrective action processes
• Evidence capture that is audit-ready and accessible to market surveillance authorities on request

The monitoring system must also cover data quality at the input level. If the data feeding a high-risk AI system changes in distribution or degrades in quality, that is a compliance signal, not a technical afterthought. Regulators expect providers to catch it before it affects outcomes.

The post-market monitoring plan template and documentation requirements

The post-market monitoring plan is not optional documentation. Under Annex IV, it must be included as part of every high-risk AI system's technical documentation before the system is placed on the market. What makes this deadline pressing is that the European Commission is required to adopt a standardized template for this plan by 2 February 2026, just weeks before the April 2026 enforcement date for high-risk AI systems under Annex III. That template will define the expected structure, which means providers building their plans now are working toward a moving target.

What the plan must cover

At minimum, the post-market monitoring plan should document:

• The intended purpose of the system and the performance metrics used to measure it
• Data collection methods and sources, including what signals indicate degradation or drift
• Frequency and methodology for performance reviews
• Thresholds that trigger corrective action or incident reporting
• Roles and responsibilities for monitoring activities across the provider organization
• How findings feed back into the risk management system required under Article 9

Preparing before the template is finalized

Waiting for the Commission's official template before starting is a risk in itself. The structural requirements above are already implied by Articles 9, 17, and 72. Providers can build a defensible plan now using those articles as the framework, then adapt when the formal template lands. Documentation must be kept up to date throughout the system's lifetime. A plan written at launch and never revised will not satisfy regulators.

Serious incident reporting obligations and timelines

Article 73 sits alongside Article 72 and handles what happens when monitoring surfaces something serious. Post-market monitoring is how you detect problems; Article 73 governs what you do once a problem crosses a defined threshold. A serious incident is any malfunction or misuse of a high-risk AI system that results in death, serious injury, substantial property damage, or a serious breach of fundamental rights. Near-misses that could plausibly have caused those outcomes may also qualify depending on circumstance.

Reporting timelines

So, what happens when there is an incident? Article 73 has very strict timelines along three tiers:

• 15 days from awareness for incidents causing injury or substantial harm
• 10 days from awareness if the incident results in death
• 2 days from awareness for very serious incidents or those with widespread impact

"From awareness" starts the clock when the provider becomes aware, not when the incident occurred. A provider who detects a serious incident weeks after the fact due to inadequate monitoring faces both the original harm and a reportable delay.

Who receives the report

Reports go to the market surveillance authority of the EU member state where the incident occurred or where the affected user is located. Deployers notify providers first, who then carry the formal reporting obligation upstream.Documentation must cover what the system did, what harm resulted, what corrective action was taken or planned, and how the monitoring system detected the issue. Regulators will look closely at that last point.

The table below provides a high-level overview of incident types, reporting timelines, who the report must be sent to, and the required documentation for the incident.

Integration with existing monitoring systems and avoiding duplication

Most organizations subject to the EU AI Act are not starting from scratch. Financial institutions already run model risk management programs under EBA guidelines. Medical device manufacturers maintain post-market surveillance under MDR. Critical infrastructure operators answer to NIS2. Article 72 explicitly anticipates this overlap and allows providers to build post-market monitoring into existing surveillance frameworks instead of standing up a parallel system using separate AI compliance tools.

Where sector-specific law already imposes equivalent monitoring obligations, compliance with those requirements can satisfy Article 72, provided the monitoring covers the same scope. That "provided" is doing real work. The coverage must genuinely match, not merely resemble.

Where integration typically works

There are a number of use cases where integration with existing monitoring systems works very well such as:

• Banks with EBA model risk management frameworks: these banks can map performance monitoring and incident escalation processes directly to Article 72 requirements, since the data collection and review cadences already align.
• Medical device companies operating under MDR post-market surveillance plans: these companies have structural overlap with Annex IV documentation requirements and can extend existing plans to capture AI-specific metrics.
• Insurance and lending providers subject to GDPR's automated decision-making provisions: these providers already log model outputs and user interactions, which feeds directly into Article 72's data collection mandate.

What to watch for

Integration is not automatic, though. Regulators will expect providers to document explicitly how existing processes satisfy Article 72, beyond simply asserting that they do. A gap analysis comparing your current surveillance scope against the Act's requirements is your defensible record if a market surveillance authority asks. Sector-specific frameworks often focus on technical system performance. Article 72 also requires monitoring against fundamental rights impacts and societal risks through AI governance, which most EBA or MDR programs do not currently capture. That is typically where the gap lives.

Continuous data collection and performance analysis requirements

Article 72 requires continuous collection, meaning the monitoring system must run as long as the AI system does. Not quarterly. Not at annual audits. The data scope is actually broader than most teams anticipate. Providers must collect:

• Output data across real-world interactions, beyond test distributions
• Input data quality signals, including distribution changes from training baselines
• User feedback, complaints, and override rates where applicable
• Performance against the intended purpose metrics defined at conformity assessment
• Interaction logs where the AI system operates alongside other AI systems in a pipeline

That last point carries real weight. Agentic and multi-model workflows are increasingly common, and regulators expect providers to monitor how their system behaves within those chains. If a downstream model amplifies errors from yours, that remains your compliance surface. Raw data collection without analysis does not satisfy the requirement. Providers need documented review processes that detect degradation, compare current performance against baseline thresholds, and trigger defined corrective action when those thresholds are breached.

Deployer responsibilities in the post-market monitoring ecosystem

Deployers are not passive participants. While providers own the monitoring program, deployers are closest to real-world usage, making their cooperation a practical requirement. Under the Act, deployers of high-risk AI systems carry three core obligations:

• Monitor operation in the context of use and report any serious incidents or malfunctions to the provider promptly.
• Inform providers when the system's actual use diverges from the intended purpose documented at conformity assessment.
• Maintain logs of system operation where technically feasible, typically for at least six months.

The provider-deployer relationship only works if information flows in both directions. A provider cannot fulfill Article 72 data collection requirements without production signals from the deployer's environment using model monitoring tools. That dependency should be formalized in contractual arrangements before deployment, not surfaced for the first time during an incident.

Using AI governance and observability for automated post-market monitoring compliance

Meeting Article 72 on paper is one thing. Running it in production is another. The requirements, continuous data collection, systematic performance analysis, incident detection, and audit-ready evidence, describe an infrastructure problem as much as a legal one. It's probably pretty obvious that manual processes will not scale here. A high-risk AI system generating millions of inferences cannot be reviewed by hand. What the Act describes, whether or not it uses this language, is a monitoring system that runs automatically.

What automated compliance looks like in practice

Openlayer's continuous monitoring runs the same test suite against live production data that teams run during development. Drift, bias, accuracy degradation, PII exposure, and hallucinations surface automatically against defined thresholds, before they accumulate into reportable incidents. That directly supports Article 72's requirement for ongoing performance analysis against conformity assessment baselines.

The 100+ automated tests map to specific regulatory controls. Bias evaluations link to framework requirements. Security guardrails block prompt injections and PII leakage in real time. Each test run generates evidence automatically, with no manual evidence collection or retroactive documentation sprint before an audit.

For serious incident detection under Article 73, real-time anomaly detection means the clock starts earlier. Providers who detect incidents weeks after the fact face compounding compliance exposure. Catching degradation at the inference level, before a user complaint surfaces it, shortens that window materially.

Compliance mapping to the EU AI Act happens automatically within Openlayer's AI governance & compliance platform. Risk classifications, test results, and monitoring signals feed into dashboards that regulators can review directly. When a market surveillance authority requests documentation, the evidence already exists.

Post-market monitoring is infrastructure you run, not a report you file.

Final thoughts on running post-market monitoring for the AI Act

The regulatory expectations around EU AI Act post-market monitoring are clear: continuous data collection, systematic performance analysis, and audit-ready evidence throughout the system's lifetime. What makes this achievable is automating the parts that do not scale manually, drift detection, bias monitoring, incident flagging, and evidence capture. Your team already monitors production systems for uptime and performance, and this extends that same discipline to regulatory controls. You can start building the monitoring infrastructure now even before the Commission publishes the official template in February. Get in touch if you want to map your existing monitoring processes to Article 72 requirements.

FAQ

What's the difference between pre-market conformity assessment and post-market monitoring?

Pre-market conformity assessment confirms your high-risk AI system meets regulatory requirements before deployment, while post-market monitoring confirms it keeps meeting them throughout its lifetime. Most AI failures accumulate in production, not at launch, which is why the EU AI Act requires continuous oversight through Article 72 instead of one-time validation.

Can I use existing model risk management frameworks for EU AI Act post-market monitoring?

Yes. Article 72 explicitly allows providers to integrate post-market monitoring into existing surveillance frameworks like EBA model risk management or MDR post-market surveillance, provided the coverage genuinely matches. You'll need to document how your current processes satisfy Article 72 requirements and watch for gaps around fundamental rights impacts, which most sector-specific frameworks don't currently capture.

How long do I have to report a serious incident under Article 73?

You have 15 days from awareness for incidents causing injury or substantial harm, 10 days for incidents resulting in death, and 2 days for very serious or widespread incidents. The clock starts when you become aware of the incident, not when it occurred, so inadequate monitoring creates both technical and compliance exposure.

What data must I collect for post-market monitoring compliance?

You must continuously collect output data across real-world interactions, input data quality signals including distribution changes, user feedback and override rates, performance against intended purpose metrics, and interaction logs where your AI system operates within multi-model pipelines. Raw data collection alone doesn't satisfy the requirement; you need documented review processes that detect degradation and trigger corrective action when thresholds are breached.

When does a US-based AI provider need to comply with EU AI Act post-market monitoring?

If your high-risk AI system's outputs are used within the EU, you're in scope regardless of where your company is based. The Act has explicit extraterritorial reach, so a US insurer deploying credit-scoring used by European customers or a Canadian healthcare firm whose diagnostic tool runs in German hospitals both carry Article 72 obligations.