2026-06-06·5 min read·sota.io Team

EU AI Act + MDR/IVDR Post-Market Surveillance: Dual Monitoring Requirements for Healthcare AI (2026)

Post #3 in the sota.io EU AI Act + MDR/IVDR Healthcare AI Compliance Series

EU AI Act and MDR/IVDR dual post-market surveillance requirements diagram

If your AI system is also a medical device, you face a surveillance obligation that doubles back on itself: the EU AI Act demands post-market monitoring under Article 72, while MDR Article 83 and IVDR Article 78 independently demand a post-market surveillance (PMS) system. These two regimes overlap, conflict, and create documentation gaps that auditors will find.

This guide maps the exact intersection for developers building AI-enabled medical devices — what each regulation requires, where you can unify documentation, and what cannot be merged.


Why Post-Market Surveillance Is Harder for AI Medical Devices

Traditional medical devices have fixed behaviour. Once a Class IIb cardiac monitor is approved, its performance characteristics are static until a significant change triggers re-evaluation.

AI-enabled medical devices break this assumption. A diagnostic AI that learns from new patient data, a surgical robot with updated motion models, a triage algorithm retrained on expanded datasets — each change potentially affects both the device's MDR/IVDR classification and the AI system's EU AI Act risk profile simultaneously.

This creates a surveillance challenge unique to healthcare AI:


EU AI Act Article 72: Post-Market Monitoring Plan

Under EU AI Act Article 72, providers of high-risk AI systems (which includes most AI-enabled medical devices listed in Annex III) must establish, document, and implement a post-market monitoring (PMM) plan.

What the Plan Must Cover

The PMM plan under Article 72 must include:

Article 72 Reporting Requirements

EU AI Act Article 72(2) requires providers to document PMM results and make them available to notified bodies and market surveillance authorities on request. For Class III medical devices equipped with AI, this means your notified body can request your AI PMM report at any audit — it is not a separate submission but must exist in your quality management system.

The PMM plan integrates with the risk management system under Article 9. Risks identified through post-market monitoring must feed back into the risk assessment cycle, not sit in a separate monitoring silo.

Serious Incident Reporting under Article 73

EU AI Act Article 73 mandates that providers report serious incidents and malfunctions to the relevant national market surveillance authority. For healthcare AI, the practical question is whether an incident triggers Article 73 reporting, MDR Article 87 reporting, or both.

A diagnostic AI producing systematically incorrect outputs that lead to patient harm triggers both:

The timelines differ. MDR requires serious incident reporting within 15 days for non-life-threatening events and immediately (or within 2 days) for incidents that may have led to serious deterioration or death. EU AI Act Article 73 timelines are set in implementing acts — expect alignment with MDR timelines in practice, but your SOPs must reference both obligations explicitly.


MDR Post-Market Surveillance: Articles 83–86

The Medical Device Regulation establishes a tiered PMS system whose burden scales with device classification.

Article 83: The PMS System

MDR Article 83 requires every manufacturer to plan, establish, document, implement, maintain, and update a PMS system. For AI-enabled devices, this system must capture:

For AI medical devices, "real-world performance data" extends to AI outputs: model confidence distributions, edge-case encounter rates, drift indicators. These metrics must appear in the PMS plan, not just in a separate AI monitoring system.

Article 84: The PMS Plan

MDR Article 84 requires manufacturers to draw up a PMS plan as part of their technical documentation. The plan must specify:

For AI-enabled devices, the PMS plan should explicitly reference the EU AI Act Article 72 PMM plan. In practice, many manufacturers are creating a unified document: a "PMS and PMM Master Plan" that satisfies both obligations through a single structured framework with regulation-specific appendices.

Article 85 vs Article 86: PSR vs PSUR

MDR creates a classification-based split in reporting:

Device ClassMDR RequirementFrequency
Class IPost-market surveillance report (PSR) — Art.85On request (no fixed cycle)
Class IIaPeriodic safety update report (PSUR) — Art.86At least every 2 years
Class IIb and IIIPeriodic safety update report (PSUR) — Art.86At least annually

For Class IIb and Class III devices — which includes most AI-enabled diagnostic, therapeutic, and predictive devices — the PSUR must be submitted to the notified body annually. The PSUR documents:

AI-specific content to add to your PSUR: a section documenting model performance stability over the reporting period, any retraining events, and whether retraining constituted a significant change requiring notified body notification.


IVDR Post-Market Surveillance: Articles 78–81

The In Vitro Diagnostic Regulation follows a parallel structure to MDR with classification-adjusted obligations.

Article 78: PMS System

IVDR Article 78 mirrors MDR Article 83. For AI-enabled IVDs (companion diagnostics, genomic classifiers, laboratory decision support), the PMS system must capture analytical and clinical performance data generated in real-world laboratory settings.

AI IVDs face a specific challenge: laboratory instruments often run in batch mode with statistical quality control cycles. Your PMS system must bridge the gap between traditional analytical precision metrics (CV%, trueness, interference) and AI-specific performance indicators (sensitivity drift, specificity degradation, population shift).

Article 79: PMS Plan

IVDR Article 79 requires a PMS plan as part of technical documentation, analogous to MDR Article 84. For AI diagnostic systems, specify:

Articles 80 and 81: PSR vs PSUR

IVD ClassIVDR RequirementFrequency
Class A and BPost-market surveillance report (PSR) — Art.80On request
Class CPeriodic safety update report (PSUR) — Art.81At least every 2 years
Class DPeriodic safety update report (PSUR) — Art.81Annually

Class D IVDs — which includes companion diagnostics and high-risk genomic tests — require an annual PSUR submitted to the notified body, directly paralleling MDR Class IIb/III obligations.


Where EU AI Act and MDR/IVDR PMS Overlap

The most dangerous assumption in healthcare AI compliance is that the MDR/IVDR PMS system automatically satisfies the EU AI Act Article 72 obligation. It does not.

What MDR/IVDR PMS Covers That EU AI Act Requires

MDR/IVDR PMS captures clinical and analytical performance data. EU AI Act Article 72 also requires this — specifically, data showing the AI system continues to perform within the parameters documented in the technical documentation. For AI medical devices, MDR/IVDR PMS data is the primary input to the EU AI Act PMM system.

Practical unification: Write a single data collection protocol that tags each data point with both its MDR/IVDR regulatory purpose and its EU AI Act PMM purpose. This avoids two parallel data collection efforts drawing from the same source.

What EU AI Act Requires That MDR/IVDR PMS Does Not

EU AI Act Article 72 goes beyond clinical performance:

  1. Bias and fairness monitoring: Does the AI system perform equally across demographic groups (age, sex, ethnicity)? MDR/IVDR does not require this. EU AI Act does.

  2. Human oversight effectiveness: Are clinicians using the AI outputs appropriately? Art.14 (human oversight) creates an ongoing obligation that feeds into Art.72 monitoring — are override rates within expected ranges? MDR/IVDR tracks device performance, not human-system interaction quality.

  3. Intended purpose drift: Is the device being used outside its intended clinical population? EU AI Act Art.72 monitoring must detect deployer misuse. MDR/IVDR vigilance captures reported incidents, not surveillance of off-label use patterns.

  4. Cybersecurity monitoring: EU AI Act-compliant systems must monitor for adversarial attacks and data poisoning attempts. MDR/IVDR cybersecurity requirements (MDR Annex I §17) address secure design — not live monitoring for active attacks.

Unified Documentation Architecture

The efficient approach for developers is a four-layer documentation structure:

Layer 1 — Common PMS/PMM Data Warehouse: All performance data from real-world deployment, tagged with both MDR/IVDR and EU AI Act metadata fields.

Layer 2 — Regulation-Specific Analysis:

Layer 3 — Shared Corrective Action System: Single CAPA process handling both MDR/IVDR non-conformities and EU AI Act serious incidents, with dual-coded notification obligations.

Layer 4 — Dual Reporting: Annual PSUR for MDR Art.86/IVDR Art.81 + EU AI Act Art.72 PMM documentation available on request.


Significant Changes: The Retraining Problem

The most operationally complex PMS scenario for healthcare AI is model retraining. When does retraining constitute a "significant change"?

MDR/IVDR Significant Change

Under MDR and IVDR, a significant change requires notification to the notified body and may require a new conformity assessment procedure. Competent authority guidance (MDCG 2020-3) identifies software changes as significant if they affect:

Retraining that improves model sensitivity by 2 percentage points on a new patient cohort is almost certainly a significant change under this guidance — it affects performance specifications.

EU AI Act Significant Change

EU AI Act Article 43(4) identifies significant changes to high-risk AI systems as events requiring the provider to notify the notified body where a new conformity assessment is required. Where changes to the AI system or to applied standards occur after a certificate has been issued, the provider must inform the notified body — and if those changes are likely to affect conformity with the regulation's requirements, apply for a new conformity assessment.

Practical Retraining Protocol

For AI medical devices, build a retraining decision tree with dual regulatory checkpoints:

  1. Define retraining triggers: data drift threshold, performance degradation threshold, new training data volume
  2. Pre-retraining assessment: would this change alter intended purpose? Performance specifications? Safety profile? If yes to any: notify NB before deploying
  3. Post-retraining validation: run the updated model against the validation dataset from original technical documentation
  4. PSUR documentation: document all retraining events in the annual PSUR, distinguishing significant changes (with NB notification evidence) from minor updates

Infrastructure Requirements for Compliant PMS

The infrastructure that supports your PMS system for healthcare AI must satisfy both MDR/IVDR technical file requirements and EU AI Act Article 72 obligations.

Data Residency and Access Control

MDR Annex II §1 requires technical documentation to be kept for 10 years (15 for implantables). Your PMS data warehouse must therefore retain historical performance data for the full device lifecycle — including AI model outputs and the clinical outcomes they influenced.

For EU-native deployments on infrastructure like sota.io, PMS data benefits from GDPR-native storage: no CLOUD Act exposure for patient-adjacent performance data, no cross-border transfer complications for multi-country clinical datasets.

Audit Trail Requirements

EU AI Act Article 12 (logging) requires high-risk AI systems to automatically log events at the level necessary for post-market monitoring. For healthcare AI, this means:

These logs feed directly into your MDR/IVDR PMS data collection and your EU AI Act Art.72 PMM review. Design the logging architecture once — tag it for both regulatory consumers.


August 2, 2026 Deadline Checklist

EU AI Act full application begins August 2, 2026 — less than two months away. For AI-enabled medical devices, PMS compliance requires:


What Comes Next in This Series

This series covers the full MDR/IVDR + EU AI Act dual compliance stack:

  1. ✅ Double Conformity Assessment Burden — two regimes, one device
  2. ✅ Technical Documentation Alignment — unified Annex IV / MDR Annex II architecture
  3. Post-Market Surveillance — this guide — dual monitoring, PSUR cycles, retraining triggers
  4. Clinical Evaluation for AI Medical Devices — Article 61 MDR + EU AI Act clinical evidence
  5. Significant Changes and Lifecycle Management — when retraining forces re-certification

Handling dual conformity assessment infrastructure? sota.io deploys your healthcare AI stack on EU-native infrastructure — no CLOUD Act exposure, GDPR-native from day one, full audit trail support for Art.12 logging obligations.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.