MDR Meets the EU AI Act: The Trilemma for AI Software

AI software in a medical context is often treated as a pure market-access topic: first satisfy the MDR (Regulation (EU) 2017/745), then see whether the EU AI Act (Regulation (EU) 2024/1689) adds anything on top. That very sequence is misleading. The two regulations do not apply one after the other; they apply to the same product at the same time. Anyone who sets them up as separate projects with their own teams and their own sets of records builds the most expensive variant: two worlds of documentation that diverge from each other, contradict one another, and stand out in both during an audit.

Why two regulations turn into a trilemma

The problem has three poles. The MDR asks whether your software is a medical device and which risk class it falls into. The AI Act asks how the AI system is built, trained, and monitored. And in the end both demand evidence on the same artefact, the software that reaches the patient.

The pivot lies in Art. 6(1) EU AI Act: an AI system qualifies as high-risk AI when it is a safety component of a product, or is itself a product, that is subject to conformity assessment by a notified body under harmonisation legislation such as the MDR or the IVDR (Regulation (EU) 2017/746). The MDR or IVDR classification is therefore the trigger for the AI Act categorisation. Software that must be presented to a notified body as a medical device almost always falls automatically into the strictest tier of the AI Act. The regulatory categorisation under product law thus decides not only the MDR obligations, but at the same time opens the door to a second set of requirements.

What the AI Act requires beyond the MDR

Once the classification as high-risk AI is established, the requirements of Art. 8 to 15 EU AI Act apply. Many of them have an MDR counterpart, yet are not identical:

• Risk management (Art. 9): A continuous risk management system that overlaps with the MDR risk management under ISO 14971:2019, but must explicitly address AI-specific risks such as model drift and erroneous behaviour on atypical inputs.
• Data governance (Art. 10): This is where it gets tight for many manufacturers. The AI Act requires demonstrated representativeness of the training, validation, and test data, along with a bias review. This goes beyond the usual level of ML development and has no direct counterpart in classic MDR technical documentation.
• Technical documentation (Art. 11 + Annex IV): A dedicated documentation set that overlaps with the MDR technical documentation, but demands additional content on system description, training data, and performance metrics.
• Human oversight (Art. 14): It must be implemented and demonstrated as a design principle. The theoretical possibility that a user could intervene is not sufficient without a documented mechanism.
• Accuracy, robustness, cybersecurity (Art. 15): Closely related to the MDR requirements and the software perspective of IEC 62304, but with its own focus on the statistical performance of the model.

The decisive point: these are not two entirely foreign worlds, but heavily overlapping requirements with a different emphasis. That very overlap is the opportunity, and at the same time the trap if it is ignored.

The typical pitfalls at the interface

In practice, these projects rarely fail on a single requirement, but on how the interface is organised:

• Duplicate record-keeping. The AI Act and the MDR are run as separate undertakings, each with its own document set. The result is redundant maintenance effort and version states that drift apart. A risk recorded as "mitigated" in the MDR file appears unchanged and open in the AI Act file, and both versions are submitted to the notified body.
• Classification without documentation. The high-risk categorisation is discussed internally but not formally recorded. Art. 9 EU AI Act requires a documented risk management system; a categorisation that was merely debated counts as not fulfilled in an audit.
• Data governance at ML level. Training data is handled as in an ordinary ML project, without source evidence, bias review, and representativeness records under Art. 10. As a result, a central high-risk requirement remains open even though the model itself works.
• Missing integration in post-market. The AI monitoring under Art. 72 EU AI Act runs separately from the MDR post-market surveillance. Observations on model performance and undesirable outputs then do not feed into the same assessment as the rest of the field data.

There is also the matter of timing. For AI that falls under the MDR or IVDR as a product or safety component (high-risk AI under Annex I), the longer transition period of the AI Act applies. In the course of the recent amendments to the AI Act, this deadline was pushed back for the Annex I cases. This is not a conventional buffer: parts of the regulatory framework, such as harmonised standards and guidance, are not yet fully defined during this phase. Anyone who waits for final clarity loses the time needed to integrate the work into ongoing development.

What to do

The way out of the trilemma is not a third stack of records, but an integrated framework. Three steps are load-bearing:

1. Classify first. The MDR/IVDR risk class determines the AI Act categorisation via Art. 6(1). Both must be available in documented form before the scope of obligations can be derived.
2. Map requirements rather than duplicate them. The obligations under Art. 8 to 15 are mapped onto the existing MDR technical documentation, the QMS, and the software life cycle under IEC 62304. Each requirement is evidenced once and maintained consistently. An AI management system under ISO/IEC 42001:2023 can provide the organisational framework for this.
3. Integrate post-market. The monitoring under Art. 72 is embedded into the MDR/IVDR post-market surveillance, so that model drift and field data come together in a single assessment.

Entourage works at precisely this interface: classification under product law and the AI Act, a mapping of the requirements without duplicate documentation, and integration into the existing QMS. This way, two regulations become one piece of evidence per requirement instead of two diverging worlds of records.