The gap between "it works" and "it's compliant" is bigger than most software teams expect, and it usually isn't visible until it's expensive to fix. Below are five areas of AI compliance under EU MDR and IVDR that catch teams out again and again, with where to start closing each one.
An AI-enabled medical device sits at the intersection of three regulated worlds: software, medical device, and artificial intelligence. Each carries its own regulatory expectations, and where they overlap, the obligations compound, covering not only the finished product but the process used to build it.
Understanding where a product sits in this overlap, and which obligations stack on top of each other, is the starting point for everything that follows.
"We'll handle compliance later."
Manufacturers who treat compliance as a later phase typically arrive at "later" having already collected training data without documented provenance and built an architecture that doesn't support explainability or monitoring. By then, the intended purpose is usually locked in too, along with a risk class for which the manufacturer hasn't prepared evidence.
Where to start: Define the intended purpose and derive the classification before finalizing the model architecture. These decisions determine which clinical and technical evidence is needed, which, in turn, shapes the data strategy. Treat the regulatory pathway as a roadmap from day one, not a checklist at the end.
"Our model is 98% accurate."
A strong test-set score shows the model performs well on data. It doesn't show that the device performs well in real clinical workflows, with patients, in the hands of its intended users. Analytical performance is not clinical performance. The IMDRF's Good Machine Learning Practice guidance is explicit that what matters is the real-world performance of the human–AI team, not the algorithm in isolation.
Where to start: Plan a clinical validation that tests the complete device in representative conditions: real users, real workflows, and a population that matches the intended use statement.
"Clinicians perform 25% better with our device."
The regulations don't just require a demonstrated benefit; they require it benchmarked against the state of the art. Existing software without an AI core can already deliver real benefits, such as digital workflows, structured data, and decision support. Because AI carries added risk, its use must be justified by a demonstrated benefit over a relevant comparator, not adopted for its hype factor. Clients with strong headline numbers have struggled to prove the AI itself moved the needle once the right comparator was applied.
Where to start: Benchmark against the real standard of care, including any non-AI software already in use. Make sure the trial isolates the AI's added value and justifies it against the added risk.
"Our training data is good quality."
The story behind the data matters as much as the test results themselves. Regulators expect to see:
Where to start: Begin documenting data decisions now, not during submission prep. Record the inclusion/exclusion logic, the labelling protocol, and the demographic breakdown, and put dataset versioning in place from the outset.
"The AI Act doesn't apply to us yet."
The AI Act's high-risk rules aren't in force yet, but its principles already shape what notified bodies treat as state of the art. Much of that substance already sits inside the Team-NB/IG-NB AI questionnaire, the document Notified Bodies use to assess AI in medical devices.
|
AI Act concept |
Team-NB AI questionnaire |
|
Human oversight (Art. 14) |
Intended user/context of use asks for "level of human oversight" (6.1.2) |
|
Data & data governance (Art. 10) |
Close correspondence to expectations of section 6.3 |
|
Accuracy, robustness, cybersecurity (Art. 15) |
AI-specific cyberattacks called out as "fundamentally different" from conventional threats (6.2.4) |
Where to start: Gap-assess the MDR/IVDR technical documentation against the Team-NB AI questionnaire and the key AI Act provisions. An early review can future-proof the process.
Every gap on this list gets cheaper, faster, and easier to close the earlier it's addressed. Compliance designed into the development process, rather than retrofitted after the fact, reaches market faster, costs less to maintain, and holds up better under review.