MDR–AI Act Interface: Technical Documentation and Notified Body Convergence

1. The Regulatory Interface: Why MDR and AI Act Must Be Read Together

The European regulatory landscape for medical software has shifted from a single-framework model to a layered, convergent model. The MDR governs medical devices on the basis of patient safety and clinical performance. The AI Act governs artificial intelligence systems on the basis of health, safety, and fundamental rights. When an AI system is embedded in or itself constitutes a medical device, both regimes apply concurrently. This is not a matter of choosing the stricter regime; it is a matter of satisfying all applicable requirements through one conformity assessment procedure.

The legal basis for this concurrency is found in the New Legislative Framework, which the AI Act explicitly references in its recitals. Regulation (EU) 2024/1689 states that its harmonized rules should apply consistently with Decision No 768/2008/EC and Regulation (EC) No 765/2008, and that more than one legal act may apply to a single product. The product may be placed on the market only when it complies with all applicable Union harmonization legislation. This principle of cumulative application is the starting point for every MDR–AI Act compliance strategy.

MDCG 2025-6, the Medical Device Coordination Group guidance on the interplay between the MDR/IVDR and the AI Act, reinforces this position. The guidance introduces the term Medical Device Artificial Intelligence (MDAI) to cover AI systems used for medical purposes, including MDR Annex XVI products, accessories, and in vitro diagnostic medical devices. It confirms that the MDR and IVDR address risks related to medical device software, while the AI Act complements these by introducing requirements specific to AI-related hazards and risks to health, safety, and fundamental rights. The result is simultaneous and complementary application.

For Regulatory Affairs Directors, the strategic implication is clear: compliance architecture must be designed for convergence from the outset. Attempting to bolt AI Act requirements onto an existing MDR dossier at the last stage of certification will create duplication, inconsistency, and likely delays. The organizations that succeed will be those that treat the AI Act not as an add-on but as an extension of the same product governance system.

2. Scope and Classification: When Does the AI Act Apply to a Medical Device?

Not every AI-enabled medical device triggers AI Act high-risk obligations. The threshold is defined in Article 6(1) of Regulation (EU) 2024/1689, which sets out two cumulative conditions. First, the AI system must be a safety component of a product, or the AI system itself must be a product, falling within the scope of listed Union harmonization legislation. Second, the product must be required to undergo a third-party conformity assessment under that legislation.

For medical devices, the relevant harmonization legislation is the MDR and the IVDR. Both are listed in Annex II, Section A of the AI Act. Therefore, an AI system that is itself a medical device, or that functions as a safety component of a medical device, and that requires notified body assessment under the MDR or IVDR, is classified as high-risk under the AI Act. MDCG 2025-6 provides a useful table illustrating this logic: the decisive factors are whether the device is a medical device or safety component, and whether a notified body is involved in conformity assessment.

It is essential to distinguish this AI Act classification from MDR risk classification. The AI Act high-risk label does not alter the MDR class assigned under Annex VIII of Regulation (EU) 2017/745. A Class IIa MDR software device with an embedded AI component remains Class IIa under the MDR, but the AI component is high-risk under the AI Act. This dual classification governs the documentation and assessment requirements that follow.

Devices that fall outside notified body assessment under the MDR are generally not high-risk under Article 6(1). This includes Class I medical devices that do not require notified body intervention, as well as in-house devices manufactured and used within a single health institution under Article 5(5) of the MDR. However, such devices may still fall under other provisions of the AI Act if they qualify as high-risk under Annex III standalone provisions or as general-purpose AI models.

3. The Single Technical Documentation Imperative

One of the most consequential provisions of the AI Act for medical device manufacturers is Article 11(2). It states that where a high-risk AI system is part of a product covered by Union harmonization legislation listed in Annex II, including the MDR and IVDR, a single set of technical documentation shall be drawn up. This provision directly addresses the risk of regulatory fragmentation and gives manufacturers a legal basis for integrating AI Act documentation into the MDR technical file.

The MDR technical documentation requirements are set out in Annex II of Regulation (EU) 2017/745. They include device description and specification, information supplied by the manufacturer, design and manufacturing information, general safety and performance requirements, benefit-risk analysis and risk management, product verification and validation, and clinical evaluation. For software devices, MDCG 2020-1 further clarifies the need to demonstrate clinical validity, technical performance, and clinical benefit.

The AI Act technical documentation requirements are set out in Annex IV of Regulation (EU) 2024/1689. They include a general description of the AI system, a detailed description of the elements of the AI system and its development process, design specifications, key design choices and rationale, data requirements, training methodologies, computational resources used to develop and train the system, validation and testing procedures, performance metrics, and information on changes to the system.

The practical approach recommended by MDCG 2025-6 is to maintain one technical documentation file that incorporates both MDR and AI Act elements. The MDR structure can serve as the backbone, with AI Act Annex IV content integrated as dedicated annexes or sections. This avoids duplication, ensures consistency, and aligns with the Article 11(2) single-file requirement. The critical success factor is traceability: every AI-specific claim must be linked to the corresponding MDR general safety and performance requirement, risk control, or verification activity.

3.1 Mapping MDR Annex II Against AI Act Annex IV

A disciplined mapping exercise is the foundation of an integrated technical file. The following table illustrates how MDR Annex II elements align with AI Act Annex IV content and where integration is most natural.

This mapping should not be treated as a one-time exercise. As the device evolves, changes to the AI model, training data, or intended use must be reflected across both the MDR and AI Act sections of the technical file. A change control process that updates only one regime while overlooking the other is a common source of non-conformity.

4. Quality Management System Integration

The AI Act imposes a quality management system obligation on providers of high-risk AI systems under Article 17. The requirement covers at least thirteen aspects, including a regulatory compliance strategy, design and development controls, data governance, technical specifications, risk management, post-market monitoring, serious incident reporting, communication with authorities, record-keeping, resource management, and accountability.

For medical device manufacturers, the good news is that Article 17(3) explicitly permits integration. It states that where a provider is already subject to quality management system obligations under sectoral Union law, the aspects listed in Article 17(1) may form part of that system. This means an ISO 13485:2016 quality management system can be extended to cover AI Act requirements without creating a parallel structure.

EN 18286:2026, titled "Artificial intelligence — Quality management system for EU AI Act regulatory purposes," provides the harmonized implementation framework. Approved by CEN-CENELEC on 12 July 2026, it is the first European standard from the JTC 21 work programme to reach publication. Its Annex ZA maps the standard's clauses to AI Act provisions, and it is explicitly designed to be integrated into existing sector-specific quality systems such as ISO 13485.

The standard is structured around two layers. Clauses 4 to 7 and clause 10 form an organizational management layer covering the quality system itself, management responsibility, planning, support, performance evaluation, and improvement. Clauses 8 and 9 form a product life-cycle layer covering AI system realization, data management, technical documentation, release, post-market monitoring, incident reporting, and retirement. The product life-cycle layer is where most implementation effort will land for medical device manufacturers, because it goes beyond what a generic ISO 9001 or ISO/IEC 42001 system typically contains.

Key integration points include extending design controls to cover AI model development, adding data governance procedures under clause 8.5, incorporating continuous-learning governance for predetermined changes under clause 8.8, and aligning serious incident reporting timelines with vigilance obligations. The standard specifies outer reporting limits counted from the provider's awareness of an event: two days for critical infrastructure cases, ten days for a death, and fifteen days otherwise.

5. Risk Management Convergence: ISO 14971 Meets AI Act Article 9

Risk management is one of the areas where the MDR and AI Act overlap most substantially, but also where the scope differs in important ways. The MDR requires a risk management system aligned with Annex I, Chapter I, and commonly implemented through ISO 14971:2019. This system focuses on risks to health and safety arising from the medical device.

The AI Act requires a risk management system under Article 9 that addresses reasonably foreseeable risks to health, safety, and fundamental rights. This is a broader risk aperture. It includes not only patient harm but also risks related to bias, discrimination, privacy, autonomy, and erroneous decision-making that may affect individuals or groups.

MDCG 2025-6 confirms that manufacturers of high-risk MDAI may integrate the additional risk management requirements of Article 9 into their existing MDR/IVDR risk management documentation. The integration should ensure that AI-specific hazards are identified, evaluated, and controlled alongside traditional medical device hazards. This includes risks arising from data quality, model drift, adversarial attacks, insufficient human oversight, and unintended use outside the intended purpose.

A practical approach is to maintain a single risk management file structured according to ISO 14971, with an expanded hazard taxonomy that includes AI-specific and fundamental-rights hazards. For each hazard, the manufacturer should document the hazardous situation, sequence of events, foreseeable harm, probability of occurrence, severity, risk control measures, residual risk, and overall acceptability. Risk controls should follow the hierarchy of safety by design, protective measures, and information for safety.

The risk management file should also address the interaction between AI risks and MDR general safety and performance requirements. For example, a bias risk in an AI diagnostic algorithm may map to MDR Annex I requirements on accuracy, performance characteristics, and acceptability of benefit-risk ratio. Documenting these linkages explicitly strengthens both the MDR and AI Act conformity arguments.

6. Data Governance: Training, Validation, and Testing Datasets

Data governance is arguably the area where the AI Act introduces the most novel requirements for medical device manufacturers. Article 10 of Regulation (EU) 2024/1689 sets out specific obligations for training, validation, and testing datasets used in high-risk AI systems. These obligations go beyond the clinical data requirements of the MDR and require a structured approach to dataset quality, representativeness, and bias mitigation.

The AI Act defines training data as data used for training an AI system through fitting its learnable parameters, validation data as data used for evaluating the trained system and tuning non-learnable parameters, and testing data as data used for independent evaluation before placing on the market or putting into service. MDCG 2025-6 emphasizes that the data used must be representative of the intended patient population, taking into account characteristics such as age, gender, sex, race, ethnicity, geographical location, medical condition, intended use environment, and measurement inputs.

Article 10 requires providers to examine datasets with regard to possible biases that are likely to affect health and safety or fundamental rights, and to take account of the characteristics or elements particular to the specific geographical, contextual, behavioral, or functional setting within which the system is intended to be used. This aligns with the MDR requirement for clinical data that is robust, reliable, and derived from well-designed studies, but adds an explicit lens of algorithmic fairness and population representativeness.

For Regulatory Affairs Directors, the practical implication is that data management cannot be left entirely to data science teams. It must be governed by quality system procedures that define data collection protocols, inclusion and exclusion criteria, annotation workflows, inter-rater reliability, preprocessing steps, dataset versioning, and traceability to model training runs. These procedures should be documented in the technical file and available for notified body review.

The emerging harmonized standard prEN 18284 is expected to provide detailed technical specifications for data governance and dataset quality under Article 10. Until it is published and cited in the Official Journal, manufacturers should rely on established guidance from MDCG 2025-6, FDA guidance on AI/ML-enabled devices, and sector-specific standards such as those developed under the ITU-WHO Focus Group on Artificial Intelligence for Health.

7. Transparency, Human Oversight, and Instructions for Use

Articles 12 to 14 of the AI Act address transparency, record-keeping, and human oversight. These requirements intersect directly with the MDR obligations for instructions for use and information supplied by the manufacturer. Rather than maintaining separate labeling documents, manufacturers should integrate AI Act transparency content into the MDR instructions for use.

Article 12 requires high-risk AI systems to be designed and developed in such a way that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. Article 13 requires providers to supply instructions for use containing specific information, including the identity and contact details of the provider, characteristics, capabilities, and limitations of the system, intended purpose, foreseeable misuse, human oversight measures, expected lifetime and maintenance needs, and performance metrics.

Article 14 imposes human oversight obligations. High-risk AI systems must be designed to enable effective oversight by natural persons during their use. The instructions for use must include measures to facilitate human oversight, such as appropriate human-machine interface tools, the ability to correctly interpret outputs, the possibility to disregard or override AI output, and procedures for responding to anomalies or malfunctions.

For medical devices, these requirements map naturally onto existing usability engineering and clinical workflow integration activities under IEC 62366-1. The human oversight interface should be validated as part of the device's usability evaluation, and the IFU should explain how the AI output supports rather than replaces clinical judgment. This is particularly important for decision-support devices, where the boundary between recommendation and autonomous action must be clearly understood by users.

8. Accuracy, Robustness, and Cybersecurity

Article 15 of the AI Act requires high-risk AI systems to achieve an appropriate level of accuracy, robustness, and cybersecurity. These requirements are complementary to the MDR general safety and performance requirements, particularly Annex I, Chapter I.17 on cybersecurity and the broader requirements on accuracy and performance characteristics.

Accuracy must be measured using appropriate metrics and documented in the technical file. The metrics should be selected based on the intended purpose and clinical context. For a diagnostic AI system, this may include sensitivity, specificity, positive predictive value, negative predictive value, and area under the receiver operating characteristic curve. For a prognostic system, calibration and discrimination metrics may be more relevant.

Robustness refers to the ability of the system to maintain performance under varying conditions, including changes in input data distribution, adversarial inputs, and environmental factors. Validation should include stress testing, edge-case analysis, and evaluation of model behavior on subpopulations. This aligns with the MDR emphasis on device performance across the intended user population and use environment.

Cybersecurity requirements under the AI Act must be read together with MDR Annex I, Chapter I.17, the Cyber Resilience Act for non-medical components, and relevant standards such as IEC 81001-5-1 and IEC TR 60601-4-5. The technical documentation should include threat modeling, security controls, vulnerability management procedures, and evidence of security testing. The software bill of materials required under the CRA should also be referenced where applicable.

9. Notified Body Convergence: One Assessment, One CE Mark

Article 43(3) of the AI Act is the cornerstone of notified body convergence. It provides that for high-risk AI systems covered by Union harmonization legislation listed in Annex I, Section A, the provider follows the conformity assessment procedure required under that legislation. The AI Act requirements set out in Articles 8 to 15, and the specific provisions related to assessment of the quality management system and technical documentation in Annex VII, points 4.3, 4.4, 4.5, and the fifth paragraph of 4.6, must be assessed or taken into consideration as part of that procedure.

For MDAI, this means the MDR conformity assessment procedure remains the governing procedure. The notified body designated under the MDR, if also designated under the AI Act, will assess AI Act compliance during the same audit and technical documentation review. There is no separate AI Act certificate, no second CE mark, and no additional declaration of conformity. The single CE mark attests compliance with both regimes.

This convergence is efficient in principle but demanding in practice. Notified bodies must build competence in both medical device regulation and AI system assessment. They must be able to evaluate data governance practices, model validation evidence, bias mitigation measures, and fundamental-rights impact assessments alongside traditional clinical, risk management, and quality system evidence. The limited pool of dual-designated notified bodies is widely expected to create bottlenecks as the August 2028 deadline approaches.

MDCG 2025-6 confirms that sampling rules under MDR/IVDR remain applicable. For Class IIa and Class B devices, technical documentation is assessed on a representative basis per category. For Class IIb and Class C devices, at least one representative device per generic device group is assessed. High-risk MDAI follow these same sampling rules, with AI Act elements incorporated into the sampled dossiers.

Notified bodies also have the authority to request access to training, validation, and testing datasets if necessary for conformity assessment. If the technical documentation does not provide clear evidence of AI Act compliance, the notified body may carry out its own tests. This underscores the importance of preparing datasets and model evidence in a form that is reviewable and auditable.

10. Predetermined Change Control and Post-Market Surveillance

AI systems are inherently iterative. Manufacturers seek to improve models over time based on new data, feedback, and research. This creates tension with the MDR requirement that devices placed on the market conform to the approved design and that substantial changes undergo a new conformity assessment. The solution lies in predetermined change control plans that define in advance what changes are permitted and how they will be validated.

The FDA has developed a detailed framework for Predetermined Change Control Plans (PCCPs) for AI/ML-enabled device software functions. While not directly binding in the EU, the principles are highly relevant. A PCCP describes the specific planned modifications, the methodology to develop and validate them, and an assessment of their benefits and risks. The plan is reviewed as part of the marketing submission and, once authorized, modifications consistent with the plan can be implemented without additional submissions.

EN 18286:2026 addresses continuous-learning governance in clause 8.8. It requires predetermined changes to be documented at design time, verified and validated per change, logged, and reflected in the technical documentation and instructions for use. This aligns with the FDA PCCP approach and provides a structured way to manage AI model updates within the EU regulatory framework.

Post-market surveillance must also be integrated. The MDR requires a post-market surveillance system that actively and systematically gathers, records, and analyzes data on device quality, performance, and safety. The AI Act requires post-market monitoring under Article 72 to evaluate continuous compliance with requirements and to identify need for corrective action. A unified PMS plan can satisfy both by including AI-specific performance indicators, drift detection, real-world performance tracking, and signal detection for algorithmic bias or degradation.

11. Practical Implementation Roadmap

For Regulatory Affairs Directors charged with preparing an MDAI portfolio for the August 2028 deadline, the following phased roadmap provides a practical starting point.

Phase 1: Regulatory Mapping and Gap Assessment. Identify all devices that incorporate AI. For each, determine MDR classification, AI Act high-risk status under Article 6(1), applicable conformity assessment procedure, and current notified body designation. Document gaps between existing technical documentation and AI Act Annex IV requirements.

Phase 2: Technical Documentation Restructuring. Restructure the technical file as a single integrated dossier in accordance with Article 11(2). Populate AI Act Annex IV content as dedicated sections within the MDR Annex II structure. Establish cross-references between MDR GSPRs, risk controls, verification activities, and AI Act requirements.

Phase 3: Quality System Enhancement. Extend the ISO 13485 quality management system to cover AI Act Article 17 elements. Use EN 18286:2026 as the implementation guide. Update procedures for design control, data governance, model validation, change control, post-market monitoring, and incident reporting.

Phase 4: Risk Management Update. Expand the ISO 14971 risk management file to include AI-specific and fundamental-rights hazards. Update hazard analyses, risk control measures, and residual risk evaluations. Ensure traceability to MDR Annex I and AI Act Article 9.

Phase 5: Notified Body Engagement. Engage the notified body early to confirm dual designation under MDR and AI Act, agree on sampling strategy, clarify expectations for dataset review, and schedule assessment slots. Early engagement is critical given anticipated capacity constraints.

Phase 6: Predetermined Change Control Planning. Develop change control plans for AI models that may evolve after certification. Define permitted modifications, validation protocols, and documentation updates. Integrate these plans into the technical file and quality system.

Phase 7: PMS and Vigilance Integration. Update the post-market surveillance plan to include AI-specific performance monitoring, drift detection, bias surveillance, and incident reporting aligned with both MDR vigilance and AI Act timelines.

12. Common Pitfalls and How to Avoid Them

Even well-prepared manufacturers encounter recurring pitfalls at the MDR–AI Act interface. Recognizing them early can prevent costly remediation.

Pitfall 1: Maintaining separate technical files. Some organizations plan to create a standalone AI Act technical file alongside the MDR file. This contradicts Article 11(2), risks inconsistency, and creates duplicate maintenance. The integrated file should be the default approach.

Pitfall 2: Treating AI Act as a documentation-only exercise. Compliance requires procedural and cultural changes, not just paperwork. Data governance, model validation, and human oversight must be embedded in development and operations.

Pitfall 3: Overlooking fundamental-rights risks. Risk management focused solely on patient safety will miss AI Act requirements. The risk file must address bias, discrimination, privacy, autonomy, and transparency.

Pitfall 4: Assuming the notified body will interpret the interface. Manufacturers remain responsible for demonstrating compliance. The notified body assesses evidence; it does not design the compliance strategy.

Pitfall 5: Neglecting dataset provenance and versioning. Dataset documentation must be precise enough to permit independent evaluation. Vague descriptions of training data sources will not satisfy Annex IV requirements.

Pitfall 6: Waiting until 2028 to begin. The conformity assessment pipeline will become congested. Early engagement, parallel workstreams, and iterative dossier development are essential.

13. Economic Operators in the MDR–AI Act Value Chain

The AI Act introduces a layered set of obligations for economic operators that mirrors, but is not identical to, the MDR economic operator framework. Understanding how provider, deployer, importer, distributor, and authorized representative map onto manufacturer, user, importer, and distributor under the MDR is essential for contractual clarity and liability management.

Under the AI Act, the provider is the natural or legal person that develops an AI system or has it developed with a view to placing it on the market or putting it into service under its own name or trademark. For MDAI, the MDR manufacturer is generally the AI Act provider. MDCG 2025-6 clarifies that references to "manufacturer" within the meaning of the MDR/IVDR should be understood as references to "provider" in accordance with the AI Act. This alignment avoids the need to designate a separate legal entity but does not eliminate the need to fulfill both sets of obligations.

The deployer under the AI Act is the natural or legal person using the AI system under its authority. This is distinct from the MDR concept of "user," which covers healthcare professionals and lay persons who use the device. A hospital deploying an AI-enabled diagnostic device is a deployer under the AI Act and a user under the MDR. The deployer has specific obligations under Articles 26 and 27 of the AI Act, including assignment of human oversight, monitoring of operation, and cooperation with market surveillance authorities. Manufacturers should ensure that instructions for use provide deployers with sufficient information to meet these obligations.

Providers established outside the EU must appoint an authorized representative in the Union under Article 25 of the AI Act. This obligation may overlap with the MDR authorized representative requirement, but the scope and location of the mandate may differ. A single authorized representative may be able to fulfill both roles, provided the mandate explicitly covers both frameworks. Importers and distributors also have parallel but not identical obligations under the MDR and AI Act, particularly regarding verification of conformity, storage, and transport conditions.

14. Clinical Evidence and Real-World Performance Data

Clinical evidence remains the cornerstone of MDR conformity, and the AI Act does not displace this requirement. What changes is the evidentiary breadth. For MDAI, clinical evidence must not only demonstrate safety and clinical benefit but also support the AI Act requirements for accuracy, robustness, and data governance.

MDCG 2020-1 requires medical device software to demonstrate clinical validity, technical performance, and clinical benefit. Clinical validity means the output of the device is correctly associated with the physiological state or condition in the target population. Technical performance means the device correctly and reliably generates the intended technical output. Clinical benefit means the device has a positive impact on patient management or health outcomes. For AI-enabled devices, these concepts must be applied to the model output, not just the software as a whole.

Real-world performance data plays a dual role. Under the MDR, it feeds into post-market clinical follow-up and supports the ongoing benefit-risk assessment. Under the AI Act, it supports post-market monitoring and the detection of performance drift or bias. Manufacturers should design their real-world evidence strategy to serve both purposes. This includes defining appropriate endpoints, data collection methods, statistical analysis plans, and thresholds for action.

The FDA's approach to real-world performance in its Predetermined Change Control Plan guidance provides useful conceptual guidance, even though it is not directly applicable in the EU. The key principle is that real-world data should be collected and analyzed according to pre-specified protocols, with clear criteria for when model updates or corrective actions are warranted. This principle aligns with the AI Act requirement for systematic post-market monitoring and with MDR vigilance obligations.

15. Market Surveillance, Enforcement, and Corrective Actions

Market surveillance under the MDR and AI Act is conducted by national competent authorities, with coordination at EU level through mechanisms such as the Medical Device Coordination Group and the AI Office. For MDAI, both sets of authorities may have jurisdiction, and manufacturers must be prepared to respond to inquiries, inspections, and enforcement actions under either framework.

The AI Act provides for significant administrative fines for non-compliance, with the highest penalties applicable to prohibited AI practices and breaches of specific high-risk AI requirements. While the MDR has its own enforcement framework, the AI Act fines add a separate financial deterrent. Regulatory Affairs Directors should ensure that senior management understands this enforcement landscape and allocates appropriate resources to compliance.

Corrective actions must be managed through an integrated process. A field safety corrective action triggered by an MDR vigilance event may also constitute an AI Act non-compliance that requires notification or public reporting. Conversely, an AI Act incident involving bias or erroneous output may also be a reportable adverse event under MDR vigilance. The manufacturer should have a single incident triage process that evaluates each event against all applicable reporting regimes and determines the appropriate regulatory response.

Withdrawal, recall, and disablement procedures should also be harmonized. EN 18286:2026 requires a remedial menu for non-compliance, including bringing the system into compliance, withdrawing, disabling, or recalling it, with market surveillance authorities informed when a system presents a risk. These procedures should be consistent with the MDR field safety corrective action process and should be tested through mock recalls and crisis simulations.

16. Future Directions and Regulatory Intelligence

The MDR–AI Act interface will continue to evolve. Several developments are particularly relevant for Regulatory Affairs Directors to monitor. First, the harmonized standards under the CEN-CENELEC JTC 21 work programme are expected to be published and cited in the Official Journal over the coming years. prEN 18228 for AI risk management, prEN 18284 for data governance, prEN 18229-1 for logging and transparency, and prEN 18229-2 for accuracy and robustness will each provide additional technical detail that may affect conformity strategies.

Second, MDCG guidance will be updated. MDCG 2025-6 is described as a living FAQ document, and additional questions and answers are expected as implementation experience accumulates. Notified body guidance documents and coordination mechanisms will also mature, potentially clarifying expectations for dataset review, model validation, and assessment sampling.

Third, the interaction with other horizontal legislation will become more concrete. The Cyber Resilience Act and the European Health Data Space will apply to many of the same products, and the single declaration of conformity under Article 47(3) of the AI Act, Article 28(3) of the CRA, and Article 39(2) of the EHDS will require careful cross-mapping. Manufacturers that design compliance systems for all four frameworks from the outset will be best positioned to adapt.

Fourth, international convergence may accelerate. The FDA, Health Canada, TGA, and other regulators are developing their own approaches to AI-enabled medical devices. While the EU AI Act is the most prescriptive framework to date, alignment on principles such as predetermined change control, real-world performance monitoring, and risk management may reduce the burden of multi-jurisdictional compliance over time.

17. Strategic Implications for Regulatory Affairs Directors

The MDR–AI Act interface is not a temporary regulatory puzzle; it is the new normal for medical software in Europe. Regulatory Affairs Directors should view it as an opportunity to elevate the strategic role of the regulatory function within the organization.

First, regulatory strategy must be embedded in product architecture decisions. The choice of whether to embed AI in a device, offer it as a separate module, or deploy it as a cloud service has direct implications for MDR classification, AI Act high-risk status, CRA scope, and EHDS interoperability obligations. These decisions should be made with regulatory input from the earliest design stages.

Second, cross-functional collaboration is no longer optional. Regulatory affairs, quality assurance, clinical affairs, data science, software engineering, cybersecurity, and legal must work from a shared understanding of requirements. The integrated technical file is both a documentation structure and a collaboration model.

Third, compliance can become a competitive differentiator. Organizations that achieve smooth dual-framework certification before the deadline can market their products as fully compliant with the most advanced AI safety regime in the world. In procurement decisions, this may outweigh short-term cost advantages held by less prepared competitors.

Finally, Regulatory Affairs Directors should invest in continuous monitoring. MDCG guidance will evolve, harmonized standards will be updated, and notified body practices will converge through experience. A regulatory intelligence process that tracks these developments and translates them into actionable dossier updates will be essential for maintaining compliance over the product lifecycle. Organizations should therefore treat the next twenty-four months as a compliance runway, not a waiting room. The decisions made today will determine whether the 2028 deadline is met with confidence or with crisis.

References