EU AI Act + MDR/IVDR: The Double Conformity Burden for Healthcare AI Developers 2026

Post #1 of 5 in the sota.io EU Healthcare AI Compliance Series

If you are building AI for healthcare — a diagnostic tool, a clinical decision support system, a medical imaging analyser, or an AI-powered patient monitoring solution — you face a compliance burden that does not apply to other software developers. You must satisfy two overlapping European regulatory regimes simultaneously: the Medical Device Regulation (MDR, Regulation (EU) 2017/745) or the In Vitro Diagnostic Regulation (IVDR, Regulation (EU) 2017/746), and the EU AI Act (Regulation (EU) 2024/1689).

The August 2, 2026 AI Act deadline applies to you too. But unlike other high-risk AI developers, you cannot treat AI Act conformity as a standalone exercise. Your technical documentation, your quality management system, your risk management process, and your notified body relationship all need to work across both regulatory regimes at once.

This guide explains the legal mechanism that creates the double burden, what it requires in practice, and how to structure your compliance work so that MDR/IVDR and AI Act obligations reinforce each other rather than duplicate effort.

Why Healthcare AI Gets Double-Classified

The EU AI Act creates two routes to "high-risk AI" classification. The first route, defined in Art.6(1), catches AI that is embedded in safety-critical products already regulated by EU harmonisation legislation. If your AI system is either:

• a safety component of a product covered by a regulation listed in Annex I of the AI Act, or
• itself a product covered by that legislation and subject to mandatory third-party conformity assessment under that legislation

…then it is automatically classified as high-risk AI under the AI Act — regardless of what it actually does.

Annex I of the AI Act includes both MDR and IVDR. This means that medical AI software subject to third-party conformity assessment under MDR or IVDR — typically Class IIa, Class IIb, and Class III medical devices under MDR, and Class B, Class C, and Class D devices under IVDR — also falls within the scope of the AI Act as high-risk AI.

This is not an edge case. The European Commission deliberately included MDR and IVDR in Annex I because medical AI systems that perform diagnostic or therapeutic functions directly affect patient safety. A Class IIb AI radiology tool that identifies cancer, a Class III AI cardiovascular risk model that influences treatment decisions, or a Class C AI molecular diagnostics system — all are high-risk AI systems under Art.6(1) without any further case-by-case analysis.

What Changes When You Are Double-Classified

The practical effect is that you must satisfy the legal requirements of both regimes in the same product, across overlapping but not identical frameworks.

Under MDR/IVDR

Medical device software (MDSW) must satisfy:

• Annex I MDR/IVDR: General safety and performance requirements — safety, performance, usability, software lifecycle requirements
• Annex II MDR: Technical documentation including clinical evaluation, pre-clinical data, manufacturing processes
• Annex IX/X/XI MDR: Conformity assessment procedures depending on device class
• IEC 62304 (medical device software lifecycle processes) as the de facto standard for software development
• ISO 14971 (risk management for medical devices) for product-level risk assessment
• Post-market surveillance and vigilance reporting obligations (Art.83-92 MDR)
• EUDAMED registration (Art.31 MDR)

Under the EU AI Act

As a high-risk AI provider under Art.6(1), you must also satisfy:

• Art.9: Risk management system specific to the AI system's risks beyond physical device safety
• Art.10: Data governance and training data documentation
• Art.11 + Annex IV: Technical documentation that covers the AI model architecture, development choices, training datasets, validation methodology, and performance metrics
• Art.13: Transparency information — what the system does, its limitations, the conditions under which it should not be used
• Art.14: Human oversight measures — including the ability for users to override, correct, or shut down the AI system
• Art.15: Accuracy, robustness, and cybersecurity requirements
• Art.17: Quality management system covering the entire AI lifecycle
• Art.43: Conformity assessment — for Annex I products like medical devices, the AI Act allows the conformity assessment to be conducted as part of the existing MDR/IVDR conformity assessment, provided the notified body performing that assessment is also notified for AI Act purposes
• Art.49: Registration in the EU AI database (separate from EUDAMED)
• Art.72: Post-market monitoring plan covering AI-specific drift and performance degradation

The Overlap Is Intentional — But Incomplete

The AI Act's drafters explicitly tried to reduce duplication for products already subject to MDR/IVDR by allowing the conformity assessment to be folded into the existing notified body procedure. Art.43 states that for high-risk AI systems covered by Annex I, the conformity assessment shall be conducted according to the procedures established in the relevant Union harmonisation legislation. The notified body performing the MDR/IVDR assessment can also assess compliance with the AI Act requirements — provided it is notified for both.

The key phrase is "provided it is notified for both." Not every MDR/IVDR notified body is also designated for AI Act conformity assessments. The EU AI Office is responsible for overseeing notified body designation for the AI Act, and this process is still maturing as of mid-2026. This creates a practical risk: your existing MDR/IVDR notified body may not be able to cover your AI Act assessment, forcing you to either switch or add a second body.

Art.43 allows the conformity assessment for Annex I products (including medical devices) to be conducted as part of the existing harmonised legislation's conformity assessment — meaning a single notified body process can cover both regimes, provided the body has the necessary designation for both.

The Technical Documentation Overlap Problem

The most immediately painful consequence of double classification is that your technical documentation must satisfy two frameworks with overlapping but not identical requirements.

MDR Annex II technical documentation covers: device description, intended purpose, design and manufacturing information, general safety and performance requirements, benefit-risk analysis, and clinical data. For software, it also includes the software lifecycle documentation required by IEC 62304.

AI Act Annex IV technical documentation covers: general description of the AI system, description of elements and the development process, detailed information about the training methodology and training datasets, validation methodology, performance metrics, and monitoring procedures.

These overlap significantly but do not align precisely. Your AI model's architecture description, training dataset documentation, and validation methodology all belong in both documents — but the required level of detail and the specific headings differ. The practical approach most compliance teams are adopting is to create a master technical file that satisfies both regimes by including all required sections from both frameworks, with cross-references that map each section to the relevant MDR Annex II requirement and the relevant AI Act Annex IV requirement.

This approach avoids maintaining two separate documents (which creates synchronisation risk) while ensuring that an MDR inspector or an AI Act NCA inspector can find what they need.

Risk Management: ISO 14971 vs AI Act Art.9

MDR requires risk management according to ISO 14971:2019 (Application of risk management to medical devices). The ISO 14971 framework covers identification, analysis, evaluation, and control of risks to patients, users, and third parties from the medical device.

AI Act Art.9 requires a risk management system that identifies and analyses the known and foreseeable risks to health, safety, and fundamental rights associated with the AI system. It requires risk estimation and evaluation, and it includes residual risks after risk control measures.

The structures are compatible but not identical. ISO 14971 focuses on harm from the device's physical and operational characteristics. Art.9 extends to risks to fundamental rights — discrimination, privacy, autonomy — that ISO 14971 does not systematically address.

Healthcare AI teams building on an existing ISO 14971 risk file should add a dedicated section for AI-specific risks: model drift, training data bias, performance degradation in out-of-distribution populations, and the risk that clinicians will inappropriately over-rely on AI recommendations. These risks are not adequately captured by ISO 14971 alone.

The practical outcome: you do not need two separate risk management systems. You need one risk management system that covers both the physical device safety risks under ISO 14971 and the AI-specific risks under Art.9, with both frameworks explicitly referenced in the risk management plan.

Quality Management: ISO 13485 and AI Act Art.17

MDR requires a quality management system (QMS) that satisfies the requirements of Annex IX MDR (for Class II and III devices assessed by a notified body). In practice, this means ISO 13485:2016 — Medical devices QMS requirements — is the baseline QMS standard that notified bodies assess against.

AI Act Art.17 requires a QMS that covers the AI system lifecycle from development through post-market monitoring, including version control, data governance, validation procedures, and human oversight mechanisms.

ISO 13485 is a good starting point for Art.17 compliance because it already covers design controls, validation, and supplier controls. However, ISO 13485 does not explicitly address AI-specific lifecycle stages such as training data management, model versioning, and continuous performance monitoring.

The integration task: extend your ISO 13485 QMS to explicitly include AI model lifecycle management, aligned with Art.17 requirements. This means adding QMS procedures for training data governance, model version control, model retraining decisions, and performance drift monitoring. Many MDR-certified healthcare AI companies are doing this by adding a dedicated AI system lifecycle module to their existing ISO 13485 QMS.

Post-Market: EUDAMED, EU AI Database, and Two Surveillance Systems

After you place your healthcare AI system on the market, you face ongoing obligations under both regimes.

Under MDR, you must register the device in EUDAMED (the European database on medical devices) and submit periodic safety update reports (PSURs) for Class IIa and above.

Under the AI Act, you must register the system in the EU AI database (Art.49). This is a separate database from EUDAMED. Currently, the EU AI Office is building this database, and registration is expected to become mandatory for high-risk AI providers by August 2, 2026.

Additionally, Art.72 requires a post-market monitoring plan specifically for the AI system — covering how you detect performance drift, concept drift, and changes in the operating environment that affect your AI system's accuracy. This is a more structured requirement than MDR post-market surveillance for AI-specific failure modes.

The practical recommendation: treat EUDAMED registration and EU AI database registration as separate but parallel tasks. They collect different information and serve different regulators. Your EU AI database registration will need to describe the AI system's capabilities, intended use, and the relevant risk classification under the AI Act — information that partially overlaps with but is not identical to your EUDAMED submission.

Choosing Your Notified Body Strategy

As noted above, the AI Act allows the conformity assessment to be conducted as part of the MDR/IVDR conformity assessment — but only if the notified body is designated for both. As of mid-2026, several major medical device notified bodies have sought or obtained designation for AI Act conformity assessments, including BSI Group (UK, but recognised under MDR Brexit transitional provisions), TÜV SÜD, TÜV Rheinland, SGS, and DEKRA.

Before August 2, 2026, healthcare AI developers should:

1. Confirm your existing notified body's AI Act designation status. Contact your body directly to ask whether they are currently designated or are seeking designation for AI Act conformity assessments under Annex VIII.
2. If not designated: Assess whether you can switch to a designated body before the deadline, or whether you need a separate notified body engagement for the AI Act components. Switching notified bodies for MDR purposes is possible but takes time; plan for at least 6-9 months.
3. If designated: Work with your notified body to scope the combined assessment — they should be able to design a single integrated assessment that covers both MDR Annex IX/X requirements and AI Act requirements.

The AI Act creates a new category of notified body obligations. Under Art.43, notified bodies performing AI Act conformity assessments must have the technical competence to assess AI systems, including machine learning models, training data management, and bias assessment. Not all MDR notified bodies have this competence today.

The August 2, 2026 Deadline in Context

The AI Act's high-risk provisions apply from August 2, 2026 — 24 months after the regulation entered into force on August 1, 2024. This deadline applies to all high-risk AI providers, including healthcare AI companies subject to MDR/IVDR.

However, there is a transitional provision for AI systems that are also regulated products (like medical devices): systems that are already placed on the market before August 2, 2026 under a valid MDR/IVDR CE mark may continue to be made available until August 2, 2027 without requiring separate AI Act conformity, provided they have not undergone significant changes. This gives healthcare AI companies already MDR-certified one additional year to complete their AI Act compliance work for existing products.

For new healthcare AI systems placed on the market after August 2, 2026, full AI Act compliance is required from day one of market placement.

The practical implication: if you are currently in MDR conformity assessment and expect to receive CE marking before August 2026, you should start your AI Act compliance work now in parallel rather than sequentially. The documentation and QMS work is highly overlapping, and doing them together is significantly more efficient than doing them separately.

Where EU-Native Infrastructure Helps

Healthcare AI systems process patient data — among the most sensitive personal data categories under GDPR Art.9 (data concerning health). Deploying your model training infrastructure, inference endpoints, and post-market monitoring systems on EU-native cloud eliminates the CLOUD Act exposure that exists when patient data transits through US-parent infrastructure.

US-headquartered cloud providers hosting healthcare AI infrastructure can be compelled under the CLOUD Act to disclose EU patient data to US government authorities. This creates a risk under both GDPR and MDR — your clinical evaluation data, your training datasets containing patient records, and your post-market surveillance data may be jurisdictionally exposed.

EU-native managed PaaS — deployed on Hetzner Germany, no US parent, no CLOUD Act exposure — provides a deployment environment where healthcare AI infrastructure stays within EU jurisdiction from development through post-market monitoring.

Key Takeaways

• Healthcare AI subject to MDR/IVDR Class IIa, IIb, III (or IVDR Class B, C, D) is automatically classified as high-risk AI under Art.6(1) without further analysis.
• The AI Act allows conformity assessment to be folded into your MDR/IVDR notified body process — but only if that body is also designated for AI Act assessments.
• Your technical documentation, risk management file, and QMS should be designed to satisfy both frameworks from the start. Retrofitting AI Act requirements onto an MDR-only structure is costly.
• Existing MDR-certified AI products have until August 2, 2027 (one additional year) before they must also satisfy AI Act requirements — provided no significant changes are made.
• Register in both EUDAMED and the EU AI database — they are separate systems.
• Start your combined conformity assessment strategy now: notified body designation delays of 6+ months can put you past both the August 2026 and August 2027 deadlines.

The next post in this series covers the MDSW risk classification framework and how Art.6(1) maps to specific MDR device classes — including which devices do and do not trigger the AI Act dual obligation.