AI and Machine Learning as a Medical Device: MDR, MDCG 2021-24, and the AI Act

Why AI/ML creates a different compliance problem

Most of the MDR compliance questions for software have reasonably settled answers — classification follows Rule 11, clinical evaluation follows Article 61, cybersecurity follows GSPR 17.2. AI and machine learning add a layer of complexity that the regulation's framers didn't fully anticipate: what do you do when the software changes over time?

Traditional software has a defined version. You validate version 1.0, release it, and if you make changes you go through change control. A machine learning model that continues to learn from real-world data, or that gets retrained on new data, blurs the line between a fixed product and an evolving one. This is the core challenge that MDCG 2021-24 addresses — and the core reason why AI/ML SaMD compliance work is not straightforward.

What MDCG 2021-24 actually covers

MDCG 2021-24 was published in 2021 and is the primary EU guidance on AI/ML-based medical device software. It addresses a specific question: given that the MDR was written before the current generation of AI/ML tools was prevalent, how should manufacturers and regulators apply the existing framework?

The guidance doesn't create new requirements — it interprets existing MDR obligations in the AI/ML context. The key positions:

The "locked" vs "adaptive" algorithm distinction matters for lifecycle management. A locked algorithm — one that does not change after training — is treated like conventional software. The IEC 62304 software development lifecycle applies, and changes to the algorithm go through standard change control. An adaptive algorithm — one that continues to update based on new data — requires documented controls over when updates happen, how they are validated, and how significant changes are managed. If the update changes clinical performance materially, it may trigger a new conformity assessment.

Transparency and explainability are addressed indirectly. GSPR requires that the device's instructions for use enable users to understand its performance and limitations. For AI/ML software, this means the IFU must explain what the model does, what patient populations and data types it was trained and validated on, what its known limitations are, and what outputs users should interpret with caution. "Black box" is not a defensible position from a GSPR standpoint.

Training data quality is part of the clinical and technical evidence. The data used to train a diagnostic AI model is directly relevant to its clinical validity. Your technical documentation should describe the training dataset: size, clinical source, demographic composition, labelling methodology, exclusion criteria. A model trained on a narrow population that is then deployed in a broader one has a known validity gap that needs to be addressed in the CER and PMCF plan.

Validation methodology for AI/ML follows the same clinical evaluation principles as other software — performance studies, comparison to reference standards, evaluation on clinically representative data — but the methodology needs to be designed to surface AI-specific failure modes: distributional shift, adversarial inputs, performance degradation on underrepresented subgroups.

Classification under Rule 11 — how AI/ML changes the analysis

The Rule 11 classification logic applies to AI/ML software the same way it applies to any other SaMD: the class is determined by the severity of harm that could result from the software providing incorrect information. What changes with AI/ML is the risk profile.

A few things to be aware of in the classification analysis:

AI diagnostic tools making claims about serious conditions — detecting cancer, predicting sepsis, triaging stroke — will almost always be Class IIb or III. The combination of high severity potential harm and the clinical weight given to the software's output drives this.

AI tools that "inform" rather than "drive" clinical decisions can sometimes be argued into a lower class, but this requires careful analysis of how clinicians actually use the output. If in practice a clinician routinely acts on the recommendation without independent verification, MDCG 2021-24 is clear that this weighs toward a higher class.

Class IIa AI tools exist — typically software that supports clinical workflow without making high-stakes clinical decisions. But if you're building AI diagnostic or therapeutic decision support software, assume Class IIb and plan accordingly unless you have a strong, documented basis for a lower classification.

The EU AI Act intersection

The EU AI Act entered into force in 2024, with phased application timelines running through 2026 and 2027. For SaMD developers, the most important intersection is this: AI systems intended for use in medical diagnosis or treatment monitoring that would be classified as high-risk under MDR are also classified as high-risk under Annex III of the AI Act.

What this means practically: if your AI/ML SaMD is Class IIa or above and involves clinical decision support, you almost certainly have obligations under both MDR and the AI Act. The two frameworks are designed to be complementary — conformity assessment under MDR counts toward AI Act conformity for covered requirements — but there are AI Act-specific requirements that MDR does not address:

General-purpose AI model documentation — if your system uses a foundation model or a large language model component, the AI Act has specific requirements about documenting the model's provenance, training data, and intended use.

Human oversight requirements — the AI Act has explicit requirements for high-risk AI systems to be designed to allow human oversight. This overlaps with usability engineering and intended purpose but has its own documentation requirements.

Post-market monitoring — the AI Act requires high-risk AI systems to have post-market monitoring plans that collect performance data. This overlaps substantially with MDR PMS requirements for SaMD, but the AI Act's framing and documentation requirements are distinct.

Prohibited practices — the AI Act prohibits certain AI techniques regardless of device class. Review this list early in development, not late.

The practical implication: if you are building AI/ML SaMD, your compliance team needs to be tracking both the MDR and AI Act frameworks, and your quality management system documentation should address both. This is a moving target — the AI Act's implementing acts are still being developed, and guidance specific to the medical device sector is expected.

Change management for adaptive AI/ML — the hardest part

The most difficult compliance question for AI/ML SaMD is change management: when does a change to the model require a new conformity assessment?

The answer depends on the nature of the change and its impact on clinical performance. MDCG 2021-24 frames this around whether the change is within the "predetermined change control plan" — a concept that allows planned model updates within defined boundaries without triggering full re-certification, if the boundaries are defined in advance and the update is validated within them.

In practice: if you plan to retrain your model periodically, define up front what constitutes an acceptable performance envelope. If a retrained model stays within that envelope, you document it through change control. If it falls outside it — or if the retraining changes the model's fundamental behaviour — you treat it as a significant change requiring a new clinical evaluation update and potentially new Notified Body review.

Build your change control process for AI/ML from day one. Retrofitting it after launch is significantly harder.