Miriam Schulze

Miriam Schulze, CEO of
· Digital Health & Innovation

Julia Schliesch

Julia Schliesch
Marketing Generalist · Complex technical topics—communicated clearly.

Published on August 17, 2026

The EU’s AI Regulation (AI Act) has been generally applicable since August 2, 2026. Only the requirements for high-risk AI systems have been postponed—and for medical devices, they won’t take effect until 2028. For manufacturers, this means that classification as an AI system will be on the agenda sooner than the date might suggest. Anyone who concludes that this means the issue can be put off is misjudging the actual effort involved. Whether a manufacturer offers this service depends on its capacity and its own designation—so it’s worth addressing this question early on, just as it is worth addressing the classification of the AI system itself.

Anyone developing a software medical device with AI capabilities must consider its classification under the Medical Device Regulation (MDR). However, this does not complete the regulatory classification process. If the product contains an AI system, a second set of regulations applies—with its own classification, its own conformity assessment, and its own obligations.

In a previous post, we explained why the MDR risk class is determined not by the technology, but by the intended use and function. This post picks up where the MDR assessment leaves off.

Two classifications: The MDR classification affects the AI Act, not the other way around

First, the most important point—because it is frequently misunderstood in practice: Classification as high-risk AI under the AI Act does not change the MDR risk class. The European Commission clarified this in June 2025 in Guidance Document MDCG 2025-6. A Class IIa device remains a Class IIa device.

The reason lies in the classification systems of both frameworks. The MDR classifies risks based on the severity of potential harm—IIa, IIb, or III. The AI Act does not classify risks based on severity of harm, but rather on scope of application and type of use: A system is either high-risk or it is not; there is no gradation within this category. It asks whether there could be AI-specific causes for an erroneous output—lack of traceability, biases in training data, or lack of human oversight.

These factors have medical implications: A biased training dataset can lead to an incorrect recommendation, which ultimately affects patients. However, they do not alter the severity of the potential harm, but rather how likely it is to occur and how easily it can be detected. Therefore, the MDR classification remains unaffected, while the AI Act imposes additional requirements.

Conversely, the connection is very much real: The MDR category plays a role in determining whether the AI Act, with its high-risk obligations, applies at all.

When a Software Medical Device Is Considered High-Risk AI

The AI Act provides two pathways to the high-risk class. Annex III covers autonomous systems in application areas classified as sensitive. For medical devices, the other pathway generally applies: Annex I, Section A—that is, systems associated with products that are already subject to an EU product regulation. The MDR is one such regulation.

According to Article 6(1), two conditions must be met for this. First, the AI system must be used as a safety-related component of such a product—or the AI system itself must be such a product. Second, the product must be subject to a third-party conformity assessment.

The Digital Omnibus has clarified the definition of a safety component: AI systems used exclusively for non-safety-related aspects of user support, performance optimization, energy efficiency, automation, user-friendliness, or quality control are generally not considered safety components. However, this does not apply if their failure or malfunction would endanger health or safety. For software medical devices, this has fewer consequences than it might seem—in most cases, the second alternative in Article 6(1) applies: the AI system itself is the product. In such cases, the question of whether it is a safety component does not need to be addressed at all. It becomes relevant when the AI is a module within a larger product. The recitals explicitly clarify this point: The mere fact that an AI system is integrated into a regulated product does not, in and of itself, make it a safety component.

Where the MDR classification takes effect

The second condition is directly linked to the MDR risk class: Starting with Class IIa, a Notified Body is required; in Class I, this is generally not the case. Thus, the MDR classification helps determine whether the high-risk regime of the AI Act applies at all.

However, this correlation is not as absolute as it initially sounds. The Digital Omnibus clarifies that Article 6(1) does not mean that products with embedded high-risk AI systems must automatically undergo a third-party conformity assessment involving a notified body. (What the MDR refers to as a “notified body” is called a “notified body” in the AI Regulation—they mean the same thing.) If a product regulation permits a procedure based on harmonized standards without third-party involvement, that option remains available. This does not change anything for the MDR, because it does not provide for such an option for devices in Class IIa or higher—but it does for other product regulations listed in Annex I, Section A.

During the legislative process, there was also discussion about removing the MDR and IVDR from Annex I, Section A. In the end, only the Machinery Regulation was deferred. The AI Act remains applicable to medical devices and in vitro diagnostic medical devices.

The Deadlines—and What Already Applies

Where MDR processes can cover the AI Act

This is actually the good news for medical device manufacturers, and it's new.

The Digital Omnibus has inserted a paragraph 13 into Article 2 of the AI Act. According to this provision, the requirements of Articles 9 through 15 and the obligations of Articles 17 through 25 may be limited to the extent that the product requirements set forth in Annex I, Section A, provide an equivalent or higher level of protection. The Commission is to specify what this means in practice in delegated acts by August 2, 2027.

For MDR, this means that where its requirements provide an equivalent level of protection, AI Act requirements could be waived in the future. However, it is not yet clear which requirements these are—until the delegated acts are in place, the AI Act requirements remain in effect unchanged.

Regardless, Article 8(2), Article 9(10), and Article 17(3) of the AI Act already allow for the integration of AI-specific risk assessments into existing risk and quality management systems, rather than maintaining separate systems. Guideline MDCG 2025-6 recommends exactly that. And the Commission is required to publish guidelines on the application of these three provisions by August 1, 2027.

Any manufacturer who places a medical device containing an AI system on the market in accordance with the MDR is also considered a provider of that AI system under the AI Act. The main new requirements include data governance, requirements for training, validation, and test datasets, logging, transparency toward users, and human oversight.

What This Means for the Notified Body

Another simplification concerns the conformity assessment itself. Notified bodies that have already been designated under a product regulation listed in Annex I, Section A—the recitals explicitly mention the MDR and IVDR—may also assess the conformity of high-risk AI systems. This is contingent on their existing notification procedure having verified that they meet certain requirements of the AI Act applicable to notified bodies. They must apply for their own designation under the AI Act by January 28, 2028. In the future, conformity assessment bodies will be subject to a single application and a uniform assessment procedure.

In practice, this means that the Notified Body you’re working with for the MDR can generally handle the AI Act assessment as well. Whether they offer this service depends on their capacity and their own designation—so it’s worth asking early on.

Sanctions Framework

For violations of obligations related to high-risk AI systems, fines can range up to 15 million euros or 3 percent of global annual revenue, whichever is higher. The often-cited maximum fine of 35 million euros or 7 percent applies only to prohibited practices under Article 5.

Also relevant for DiGA manufacturers

The AI Act is already having an impact on national law. The Second Ordinance Amending the Digital Health Applications Ordinance requires manufacturers to specify whether and to what extent their digital health application falls under the AI Regulation. Anyone operating a digital health application (DiGA) with AI functions must therefore be able to classify the AI system during the application process with the BfArM—even if the substantive requirements do not take effect until later.

Conclusion

Two regulatory frameworks, two independent classification systems—and a common starting point. Those who establish the AI system classification in parallel with the MDR classification, rather than after it, do the work once instead of twice. The legislature has now paved the way for this itself by allowing exemptions where the MDR provides equivalent protection.

You have until August 2, 2028. That timeline is tighter than it sounds, because the requirements for training and validation data extend into development decisions that are being made today.

What you'll find on our website

  • AI in Medical Software Development – How we support manufacturers in the development, validation, and MDR-compliant approval of AI-powered medical devices.
  • QMS – Quality management systems in accordance with ISO 13485, MDSAP, and ISO 9001—the foundation into which the requirements of the AI Act can also be integrated.
  • AI Software and the MDR: Class I Is Rarely Sufficient – Why it is not the technology that determines the risk class, but rather the intended use and function.

If you have any questions about the blog post or our services, please feel free to contact us:

Preferred contact method
Data protection notice *