AI Is Coming to the IVD — Can the Regulation Keep Up?

In diagnostics the potential is real: analysing complex datasets, spotting patterns a human reviewer would miss, combining multiple biomarkers, interpreting genomic data, and improving the speed and consistency of diagnostic decisions.

The problem is timing. The technology is developing faster than the frameworks built to govern it.

For an IVD manufacturer that abstract tension becomes a concrete question. How do you develop and commercialise an AI-enabled diagnostic when the product sits inside both the EU IVDR and the EU Artificial Intelligence Act (AI Act), and still has to satisfy the established expectations for software, performance evaluation, risk management and post-market surveillance — none of which the AI displaces?

The EU has started to answer this. In June 2025 the Medical Device Coordination Group and the EU Artificial Intelligence Board jointly published MDCG 2025-6, a FAQ on how the AI Act interacts with the MDR and IVDR. It is the first serious attempt to map the overlap for manufacturers, notified bodies and competent authorities — a start, not a settlement.

The technology is developing faster than the frameworks built to govern it

AI changes what an IVD actually is

A conventional IVD performs a defined function: a sample is collected, an analyte is measured, a result is produced. AI adds a layer on top. The system takes that result, combines it with other information, and generates an interpretation or a prediction — a disease classification, a risk score, a probability, a flag that a case needs further investigation, or support for a treatment decision.

That shift matters. The diagnostic is no longer only producing information; it is interpreting information and influencing a clinical decision. And the moment a device moves from reporting a measurement to shaping a decision, its regulatory weight changes with it — the intended purpose sharpens, the class can rise, and the evidence bar goes up.

There is no single rulebook

The first practical difficulty is that no single framework covers an AI-enabled IVD. Several sets of requirements overlap: the IVDR governs the diagnostic itself — classification, performance evaluation, clinical evidence, technical documentation and post-market surveillance; the AI Act governs the AI system, depending on how it is classified and used; software lifecycle requirements cover verification, validation, cybersecurity and change management; and the quality system has to hold all of it together.

These frameworks were not designed as a matched set, and it shows in the detail. MDCG 2025-6 has to spend time simply reconciling vocabulary — clarifying, for instance, that the “manufacturer” under the IVDR is the “provider” under the AI Act, and the “user” is the “deployer.” When guidance has to translate the words before it can align the obligations, that tells you how much integration work still sits with the manufacturer. The task is not deciding whether the AI is regulated. It is working out how the regulations fit together.

AI in an IVD does not automatically mean “high-risk”

It is tempting to assume any AI used in healthcare is automatically high-risk under the AI Act. The reality is more precise — and, helpfully, it keys off something IVD manufacturers already understand.

MDCG 2025-6 sets out the trigger clearly: an AI-enabled IVD is a high-risk AI system when the device requires third-party conformity assessment — that is, when a notified body is involved. In IVDR terms, that captures Class B, C and D devices. A self-certified Class A IVD, or an in-house test operated under the Article 5(5) health-institution exemption, is not classified as high-risk on that basis (though other AI Act obligations, including the prohibited-practice rules and transparency duties, can still apply). Just as important, being “high-risk AI” does not raise the device’s IVDR class. The relationship runs one way: the IVDR classification determines the AI Act status, not the reverse.

The timing is where it gets awkward. The AI Act’s high-risk obligations for AI embedded in regulated products — medical devices and IVDs among them — were originally due to apply from August 2027. The Digital Omnibus (Regulation (EU) 2026/1744), in force from 27 July 2026, pushed that date to 2 August 2028, in large part because the harmonised technical standards manufacturers would need to actually demonstrate compliance were not ready. That is the whole problem in miniature: the technology is deployable today, the IVDR requirements already apply in full, but the AI-specific layer arrives in 2028 — and even that date depends on the standards landing. Companies developing products now are making decisions against requirements that are still being written.

The hard problem is validation

For an AI-enabled IVD, the most difficult question is deceptively simple: how do you show the algorithm works reliably for its intended purpose?

Traditional IVD validation rests on defined performance characteristics. AI adds variables that those characteristics do not capture. What data trained the algorithm, and does that population represent the one it will be used on? How was bias assessed? How does performance hold up across different sites, instruments, reagents and sample types? What happens when the model meets data unlike anything in its training set? And can the manufacturer explain how it reached its conclusion?

The recurring failure mode is well documented: a model posts excellent metrics on its development dataset, then slips in routine use when it meets an analyser, a sample-handling protocol or a patient population that was under-represented in training. Strong performance in the lab is not the same as strong performance in the field. That makes dataset quality, representativeness and generalisability first-order components of diagnostic development, not technical footnotes — and it makes them things a notified body will expect to see evidenced, particularly where the output drives a clinical decision.

What happens when the algorithm changes

This is where AI departs most sharply from conventional IVD development. An assay manufacturer changes an established product rarely. An algorithm can be updated constantly — because new training data arrives, performance can be improved, a bias is found, a component is replaced, or a model is retrained. Every one of those updates raises the same regulatory question: at what point does an algorithm update become a significant change to the device, and what evidence is needed before the new version can be released?

The two major frameworks answer this differently, and a global programme has to plan for both. In the US, the FDA has built a concrete mechanism — the Predetermined Change Control Plan (PCCP), grounded in statute and finalised in guidance in 2025 — which lets a manufacturer specify in advance what may change, how each change will be validated, and its impact, and have the regulator authorise that envelope up front, so listed updates can ship without a new submission (though not changes to intended use). The EU has no direct equivalent yet: the AI Act gestures at change protocols for systems that keep learning and treats a “substantial modification” as a trigger for fresh conformity assessment, while the IVDR runs its own significant-change rules — but the threshold itself remains undefined. The Digital Omnibus even grandfathers AI systems already on the market unless they are “substantially modified,” a line regulators have not yet drawn.

The practical conclusion is the same under either regime: assume the algorithm will change, and design the change-control strategy before launch, not after. It should define what can change, what evidence each change demands, who reviews it, whether it touches performance or intended purpose, and whether it pulls in the notified body. For AI-enabled diagnostics, software lifecycle management stops being a support function and becomes part of the core regulatory strategy.

Post-market surveillance becomes the safety net

An algorithm can validate well and still behave differently once it meets the full variety of real-world populations, samples and clinical environments. That makes post-market surveillance more important for AI than for almost any conventional IVD — and it has to be built to catch AI-specific signals: shifts in diagnostic performance, unexpected false-positive or false-negative rates, divergence between patient groups, model drift, changes in input data, and cybersecurity events.

The EU has sharpened its expectations here too. MDCG 2025-10, published in December 2025, is the first dedicated guidance on post-market surveillance under the MDR and IVDR, and its central message aligns exactly with what AI demands: PMS is a proactive, continuous system that begins at the design stage, not a report written after launch, and its outputs have to feed back into risk management, performance evaluation and the technical documentation. For an AI-enabled diagnostic, that feedback loop — real-world monitoring driving controlled model improvement — is not a compliance nicety. It is how the product stays safe.

AI changes what “performance” means

There is a deeper question underneath all of this: what does it actually mean for an AI-enabled diagnostic to perform well?

Analytical performance still matters, but it is no longer sufficient. Take an algorithm that combines several biomarkers into a clinical risk score. Each individual biomarker can show excellent analytical performance, and the algorithm can show excellent technical performance, and the combined system can still fail to improve the clinical decision it is meant to support. The industry has to think beyond whether the diagnostic produces the correct result, and towards whether the diagnostic result improves the decision it informs. That is the distinction between technical performance and clinical utility — and it becomes decisive as AI moves further into clinical decision support.

The quality system has to evolve with it

AI cannot be bolted onto an existing development process as one more software component. The quality system has to support what makes these products different: AI-specific risk management, dataset management and data provenance, algorithm development and model validation, bias assessment, verification and validation, cybersecurity, version control, performance monitoring and post-market surveillance.

And it has to hold up when the AI is outsourced. An IVD manufacturer often relies on an external software house, AI specialist or technology provider for part of the solution — but the manufacturer remains responsible for the final product against every applicable requirement. The principle is the one that already governs outsourced assay development: outsourcing the work never outsources the accountability.

Regulation is not the enemy of innovation

There is a genuine worry that regulation will slow the adoption of AI in diagnostics. There is a stronger counter-argument. Diagnostic AI will only be adopted at scale if clinicians, laboratories, patients and health systems trust its performance — and trust requires evidence. The regulatory job is not to block innovation but to build a framework that lets it proceed while keeping AI-enabled diagnostics safe, reliable, transparent and clinically meaningful. The difficulty is doing that while the underlying technology keeps moving.

What IVD manufacturers should be doing now

Waiting for every regulatory question to resolve is not a workable strategy — development is already moving. Six steps are worth taking now:

1. Define the intended purpose precisely. Be explicit about what the AI is meant to do and, just as important, what it is not. Everything downstream — classification, evidence, the AI Act status — flows from it.

2. Establish the classification early. Assess the product under the IVDR and work out how the AI component interacts with the AI Act and applicable software requirements. The IVDR class is what sets the AI Act high-risk status.

3. Build the evidence strategy up front. Identify what will be needed to demonstrate analytical, software, clinical and algorithm performance — plus robustness, generalisability and, where relevant, clinical utility.

4. Design change control before launch. Assume the algorithm will change, and define how changes will be assessed, validated and controlled before the product reaches the market.

5. Plan post-market performance from the start. Decide what data will be collected after launch and how it will feed back into risk management and development.

6. Map the whole ecosystem. AI-enabled diagnostics usually involve several organisations. Define responsibilities between the IVD manufacturer, software developer, laboratory and clinical partners before the work begins.

So — can the regulation keep up?

For now, the honest answer is that it is catching up rather than caught up. MDCG 2025-6 and MDCG 2025-10 are real progress, and the Digital Omnibus delay, frustrating as it is, shows the system flexing to the reality that manufacturers cannot comply with standards that do not yet exist. But the gating item — the harmonised standards that turn principles into testable requirements — is still being written, and the deadlines hold only if those standards land.

For manufacturers, that settles the strategy. Waiting for the landscape to stabilise is not an option, because the technology will not wait. The workable approach is to build regulatory flexibility into the development programme from the outset — so the product can absorb requirements as they crystallise, rather than being re-engineered around them later.

The future of AI in IVD

AI will change the IVD industry. But the products that win will not be the ones with the most sophisticated algorithms. They will be the ones that combine good science, robust assay technology, high-quality and representative data, reliable software, appropriate clinical evidence, and effective quality and regulatory controls — as a single, coherent product.

The message for IVD manufacturers is simple to state and hard to do: do not treat AI as an add-on to the diagnostic. Treat it as a fundamental component of the product, and design the regulatory, quality and evidence strategy around it from the beginning.

Consultancy perspective

The manufacturers who struggle with AI-enabled diagnostics rarely struggle with the algorithm. They struggle with the seams — an AI Act obligation and an IVDR obligation that no one mapped onto each other, a brilliant model validated on a dataset that does not match the deployed population, a change-control process that assumed the algorithm was as stable as an assay, a software vendor whose work the manufacturer is accountable for but never really scoped.

Working with manufacturers and sponsors across the UK, Ireland and the EU, the work that pays off is consistent: pinning down the intended purpose and classification early enough to know which regime bites and when, building an evidence strategy that covers generalisability and clinical utility rather than technical performance alone, designing change control and post-market monitoring as core deliverables rather than afterthoughts, and putting real oversight around outsourced AI and software development — particularly in companion diagnostic and clinical trial programmes, where accountability stays with you whoever writes the code.

Dolmen Diagnostics advises on AI-enabled IVD and companion diagnostic strategy, the IVDR/AI Act interface, performance evaluation and clinical evidence planning, software lifecycle and change-control design, QMS and external-partner oversight, and post-market surveillance. If the seams above look familiar, that is usually where the value is.