What is the complete compliance process for an AI medical device conformity assessment under current EU regulations?

The Dual-Regulatory Architecture of AI Medical Devices

The European regulatory environment for AI-driven medical devices has shifted from a fragmented landscape to a tightly integrated, dual-track compliance regime. Manufacturers must simultaneously satisfy the Medical Device Regulation (MDR) 2017/745 and the newly enacted EU AI Act. The MDR focuses on the clinical safety and performance of the device, while the AI Act mandates governance for the underlying machine learning models. This convergence means that a software-as-a-medical-device (SaMD) product is no longer evaluated merely on its clinical output, but on the integrity of its training data, the robustness of its architecture, and the transparency of its decision-making processes. Organizations that attempt to treat these as separate silos often find their technical documentation rejected by Notified Bodies due to inconsistencies between the clinical evaluation report and the AI risk management file.

Also worth reading: AI Act Conformity Assessment in 2026: What Must Providers Prove, and When? · What is the definitive agentic AI risk assessment checklist for legal compliance in 2026? · How do notified bodies integrate the EU AI Act with MDR compliance for medical devices?

Compliance begins with the recognition that the AI Act classifies most AI-enabled medical devices as "high-risk" by default, as they are already subject to third-party conformity assessments under the MDR. This creates a regulatory "double-bind" where the manufacturer must demonstrate compliance with the General Safety and Performance Requirements (GSPRs) of the MDR while simultaneously adhering to the high-risk AI requirements for data governance, logging, and human oversight. The legal burden is compounded by the fact that the AI Act requires a "conformity assessment" that mirrors the MDR process but focuses on algorithmic bias, cybersecurity, and model drift. Failure to harmonize these two frameworks early in the development lifecycle leads to significant rework, as technical documentation required for the MDR may lack the granular detail regarding training, validation, and testing datasets required by the AI Act.

Classification Thresholds and Risk Categorization

Determining the classification of an AI-based medical device is the most consequential step in the conformity assessment process. Under the MDR, software is classified according to Rule 11, which generally elevates most diagnostic or therapeutic software to Class IIa or higher. When the AI Act is overlaid, these devices are automatically categorized as high-risk systems under Annex III. This classification triggers mandatory conformity assessment procedures involving a Notified Body, which must verify that the AI system meets specific standards for accuracy, robustness, and cybersecurity. Manufacturers often make the mistake of assuming that a lower-risk classification under the MDR exempts them from the stringent requirements of the AI Act, but the intersection of these regulations rarely allows for such regulatory arbitrage.

The classification process requires a granular assessment of the intended purpose, the clinical context, and the level of human intervention. If an AI system is designed to provide diagnostic information that influences clinical decisions, it is almost certainly high-risk. The classification must be documented in the technical file, justifying the risk class based on the potential impact of a false positive or false negative result. As the device evolves, the classification must be re-evaluated, particularly if the algorithm utilizes continuous learning. If a device changes its performance parameters post-market, the manufacturer must determine if this constitutes a "significant change" under Article 120 of the MDR, which could necessitate a new conformity assessment.

The core of AI compliance lies in the quality and provenance of the datasets used for training, validation, and testing. Under the AI Act, manufacturers must implement data governance practices that ensure datasets are relevant, representative, and, to the best extent possible, free of errors and complete. This requires a rigorous documentation process that tracks the origin of the data, the methods of data collection, and the techniques used for data cleaning and labeling. For medical devices, this is further complicated by the need to ensure that the data is representative of the target patient population to prevent algorithmic bias. If a model is trained on data that does not reflect the diversity of the intended clinical environment, the device may fail to meet the GSPRs of the MDR regarding safety and performance.

Beyond initial training, the manufacturer must establish a system for continuous data monitoring. This involves tracking the performance of the model against real-world data to identify potential "model drift," where the algorithm’s accuracy degrades over time as clinical practices or patient demographics shift. The documentation must include a detailed description of the data lifecycle, including how the system handles outliers and how it manages the transition from training to production. Regulators are increasingly demanding evidence that the system has been tested against "edge cases" that might occur in a clinical setting. This requires a robust validation strategy that goes beyond standard cross-validation techniques to include stress testing against adversarial inputs and clinical scenarios that challenge the model’s decision boundaries.

Clinical Evaluation and Performance Validation

Clinical evaluation for AI medical devices is a continuous process rather than a one-time event. The manufacturer must produce a Clinical Evaluation Report (CER) that synthesizes clinical data to demonstrate that the device achieves its intended performance and safety goals. For AI, this requires a clear link between the technical performance metrics (such as sensitivity, specificity, and area under the curve) and the clinical outcomes for the patient. It is not sufficient to show that an algorithm is accurate in a laboratory setting; the manufacturer must demonstrate that the device provides clinical benefit in the intended use environment. This often necessitates clinical investigations or high-quality retrospective studies that mirror the actual clinical workflow.

The validation process must explicitly address the role of the human user. Since AI medical devices are often used as decision-support tools, the clinical evaluation must assess how the AI output influences the clinician’s decision-making process. If the AI provides a recommendation, the manufacturer must prove that the clinician can interpret that recommendation correctly and that the system does not induce "automation bias," where the user blindly follows the AI’s suggestion. This requires human-factors testing as part of the clinical evaluation. The documentation must clearly state the limitations of the device and provide instructions for use that guide the clinician on when to override the AI. This human-in-the-loop requirement is a cornerstone of both the MDR and the AI Act.

Post-Market Surveillance and Continuous Learning

Post-market surveillance (PMS) for AI medical devices is fundamentally different from traditional hardware. Because the software is dynamic, the PMS system must be capable of detecting changes in performance that occur after the device has been deployed. Manufacturers are required to establish a Post-Market Clinical Follow-up (PMCF) plan that specifically monitors the AI’s performance in the field. This includes collecting data on adverse events, near-misses, and instances where the AI’s output was questioned or rejected by a clinician. The PMS system must be integrated into the quality management system (QMS) so that any identified issues trigger a formal investigation and, if necessary, a corrective and preventive action (CAPA).

The challenge of continuous learning algorithms is that they may evolve after the conformity assessment is complete. If the algorithm updates its weights based on new data, the manufacturer must have a pre-defined change control plan that has been approved by the Notified Body. This plan specifies the boundaries within which the AI is allowed to learn and the triggers that would require a new conformity assessment. If the learning process takes the device outside of these pre-approved boundaries, the manufacturer must treat the change as a significant modification. This requires a high degree of transparency and a robust version control system that allows the manufacturer to roll back to a previous, validated state if the new version fails to meet performance requirements.

Cybersecurity and Technical Documentation

Cybersecurity is no longer a peripheral concern; it is a fundamental requirement for medical device safety. The EU MDR and the AI Act both emphasize the need for a "secure-by-design" approach. Manufacturers must conduct a cybersecurity risk assessment that identifies potential vulnerabilities, such as unauthorized access to training data, model inversion attacks, or the manipulation of input data. This assessment must be documented in the technical file and updated regularly as new threats emerge. The technical documentation must also include a detailed description of the security measures implemented, such as encryption, access controls, and secure communication protocols.

The technical documentation required for conformity assessment is extensive and must be organized to facilitate review by a Notified Body. This includes the software development lifecycle (SDLC) documentation, the risk management file, the clinical evaluation report, and the AI-specific documentation required by the AI Act. The latter includes a description of the model architecture, the training process, the validation results, and the measures taken to ensure human oversight. Manufacturers often struggle with the sheer volume of this documentation. The key to success is to maintain a "living" technical file that is updated in real-time as the device is developed and refined. This ensures that when the Notified Body initiates the audit, the documentation is already complete, accurate, and ready for review.

Strategic Pitfalls and Compliance Failures

The most common failure in AI medical device compliance is the "black box" trap. Manufacturers often develop highly accurate models but fail to provide the necessary documentation to explain how those models arrive at their conclusions. Under the AI Act, transparency is a legal requirement; the system must be sufficiently interpretable for the user to understand the basis of the AI’s output. If the device cannot explain its reasoning, it may be deemed non-compliant, regardless of its performance metrics. Another frequent mistake is the failure to properly document the "intended use." If the AI is used in a way that deviates from its original scope, the manufacturer is in violation of its certification.

Another critical failure is the lack of coordination between the legal, technical, and clinical teams. Compliance is often treated as a "check-the-box" exercise performed at the end of the development cycle, but this is a recipe for disaster. The regulatory strategy should be defined at the very beginning of the project, with legal counsel and regulatory affairs experts involved in every design review. This ensures that the technical requirements are aligned with the regulatory requirements from day one. Organizations that fail to integrate these functions often find themselves with a technically superior product that cannot be legally marketed in the EU, resulting in millions of euros in lost investment and years of regulatory delay.

When to Act: The Timeline for Compliance

The regulatory clock begins ticking the moment a manufacturer decides to develop an AI-based medical device. The first step is to conduct a formal gap analysis to determine which regulations apply and what the specific requirements are for the device’s risk class. This should be followed by the development of a comprehensive regulatory roadmap that outlines the milestones for technical documentation, clinical evaluation, and Notified Body engagement. It is essential to engage with a Notified Body as early as possible, as their capacity is limited and the queue for conformity assessments is often long.

Manufacturers should aim to have their quality management system (QMS) certified to ISO 13485 and their AI governance framework aligned with the AI Act at least 12 to 18 months before the planned market launch. This allows sufficient time for the iterative process of documentation, review, and refinement. If the device involves a novel AI application, the manufacturer should consider seeking formal guidance from national competent authorities or the European Medicines Agency (EMA) through their innovation offices. Proactive engagement with regulators can help to clarify expectations and reduce the risk of unexpected hurdles during the formal conformity assessment process. The cost of early compliance is high, but it is significantly lower than the cost of a failed audit or a market withdrawal.