For MedTech teams working on IVD software with AI or machine learning components, one question comes up first: do we now need a second quality management system?

The IVDR QMS is in place: risk management, design control, post-market surveillance, and technical documentation, all running. Then the AI Act enters the picture, with its own requirements on data governance, transparency, human oversight, and logging. The instinct is to open a parallel structure.

MDCG 2025-6, published in June 2025, gives a clear answer: don’t.

MDCG 2025-6 introduces the concept of Medical Device AI

The joint guidance from the Medical Device Coordination Group and the Artificial Intelligence Board defines a new term, Medical Device Artificial Intelligence (MDAI), to refer to AI systems used for medical purposes, including IVDs and their accessories.

For IVD manufacturers, the practical scope is wide. An MDAI becomes a high-risk AI system under Article 6(1) of the AI Act when two conditions are met:

• the AI is itself the device or a safety component of it
• the device is subject to third-party conformity assessment by a notified body

Under the IVDR, which covers Class B, C, and D devices, plus Class A sterile.

In short, most IVD software with embedded ML will fall under the high-risk regime.

The full obligations for high-risk MDAI apply from 2 August 2028

The AI Act has a phased entry into force. The general regime for high-risk AI systems applies from 2 August 2026, but IVDs and medical devices fall under a separate track. As products covered by Article 6(1), their high-risk obligations are expected to apply one year later, from 2 August 2028 (following the provisional Digital Omnibus agreement of May 2026).

Devices already on the market before that date are not retroactively reclassified, but any significant design change after 2 August 2027 triggers the full set of obligations. IVD software development cycles are long; gap analysis and process adaptation cannot start the month before the deadline.

‍

The guidance explicitly enables integration

The most important sentence in MDCG 2025-6, for any team running an established IVDR QMS, is in Article 8(2) of the AI Act and reinforced throughout the guidance: manufacturers can integrate the testing, reporting, information and documentation required by the AI Act into the procedures already established under the IVDR.

The guidance goes further. It states that manufacturers are strongly encouraged to use this flexibility, precisely to avoid duplication and additional administrative burden.

The AI Act QMS obligations are complementary to the IVDR QMS, not parallel. The integration concerns specific aspects - data governance, record-keeping, transparency, human oversight - that need to be layered onto the existing structure, not run in a separate one.

Four areas where the existing IVDR QMS needs to be extended

The integration work is concrete and bounded. In our experience, it concentrates on four areas of the QMS that already exist for IVDR purposes but need to be extended to address AI-specific risks.

Data governance manages bias in the dataset

Training, validation and testing datasets must be relevant, representative of the intended patient population, and examined for biases that could affect health, safety or fundamental rights. This extends the clinical and performance evaluation requirements already in place under the IVDR.

Transparency makes outputs interpretable

High-risk MDAI must be designed so that deployers can interpret outputs correctly and understand the system’s capabilities and limitations. For IVD software, this typically means revisiting the instructions for use, user interface design, and the presentation of AI-derived results in the diagnostic workflow.

Human oversight keeps intervention possible

The AI system must be designed with operational constraints that cannot be overridden by the system itself and that allow human intervention. The MDCG guidance frames this as a risk-mitigation measure to be incorporated into the existing risk management process under ISO 14971, rather than as a separate compliance stream.

Record-keeping logs system behavior

High-risk MDAI must automatically log events over its lifetime, both to support traceability and to enable detection of biases or performance drift that emerge only post-market. This connects directly to the post-market surveillance obligations already required under IVDR Article 78.

What changes in practice for an IVD software team

Translating this to engineering and process work means treating the AI Act as a set of additions to existing clauses, not as a parallel branch of the QMS.

Risk management procedures extend to cover AI-specific hazards (data bias, model drift, adversarial robustness, dataset representativeness). The risk file extends; it doesn’t fork.

Design control documentation captures the ML lifecycle: dataset definition, training methodology, validation strategy, and predetermined change control plans for when the model continues to learn after deployment. These artifacts integrate into the technical documentation already produced for the IVDR.

Post-market surveillance plans include monitoring model performance over time and a feedback loop in the risk file. MDCG 2025-6 explicitly states that the post-market monitoring elements introduced by the AI Act can be integrated into the existing IVDR plan, provided that an equivalent level of protection is achieved.

The conformity assessment procedure remains the one defined by the IVDR. For high-risk MDAI under Article 6(1), the AI Act requirements are assessed as part of the IVDR procedure, not in a separate one.

‍

Integration is an architectural choice, not just a documentation exercise

Teams that will navigate the 2028 deadline most cleanly are those that treat AI Act integration as an extension of the working mode they already use for IVDR compliance, rather than as a parallel project.

That means surfacing AI-specific risks during the same risk management activities, generating evidence about datasets and model behavior through the same design control process, and making logging and monitoring part of the system architecture from the start, rather than retrofitting them.

This is the kind of work we focus on at Aimasoft: helping IVD software teams design systems where compliance with multiple regulatory frameworks is a property of how the software is built and documented, rather than a separate layer added on top.

The AI Act does not require a second quality management system. It requires the existing one to be deliberately extended in the places where AI introduces risks that the IVDR was not written to address.