Global Regulations for Software and AI-Enabled Medical Devices: What You Need to Know Now

RegDesk’s Jodi Frasier recaps key takeaways from our webinar on navigating software and AI medical device regulations across the US, EU, UK, Canada, and Australia

Quick answer: If your software or AI-enabled device is going into more than one market, you can’t rely on a single global compliance strategy. The US, EU, UK, Canada, and Australia each define “medical device software” differently, classify AI risk differently, and require different documentation for model training, validation, and post-market monitoring. The one constant across all five: a clearly defined intended use, backed by strong lifecycle documentation, is the foundation everything else depends on.

Why this topic couldn’t be more timely

If you’re working in regulatory affairs for a company building software as a medical device (SaMD) or an AI-enabled device, you already know the ground is shifting fast. Every major regulator,  FDA, the European Commission, MHRA, Health Canada, TGA, has either just updated guidance or has new guidance in active development. Staying current isn’t optional anymore; it’s a moving target that touches your product roadmap, your submission strategy, and your total cost of compliance.

That’s exactly why we hosted our recent webinar, Global Regulations for Software and AI-Enabled Medical Devices: Navigating Evolving Requirements, presented by Apurva Kushare, PhD, RegDesk’s Regulatory Affairs Specialist Lead. Apurva specializes in regulatory intelligence and requirements analysis across US and EU markets, and she walked attendees through a detailed comparison of five major regulatory frameworks, what’s changing, and what your team needs to be doing right now to stay ahead of it. I’m recapping her key points here but the full session goes much deeper,  including the complete country-by-country comparison table and additional details on Good Machine Learning Practice principles. Watch the full replay below:

The starting point: intended use is everything

If there’s one idea you take away from this recap, make it this one. Across every single market Apurva covered, the clearly defined intended use is the anchor for your entire regulatory strategy. It determines your classification, your evidence requirements, your documentation scope, and as she pointed out for the UK specifically,  if you can’t assemble clinical evidence to support your stated intended purpose, that’s a sign the intended purpose itself is wrong, not just the evidence.

You should be defining your software functions, your users, your patients, and your clinical purpose before you lock in a regulatory pathway, not after.

United States: FDA pathway, AI documentation, and the PCCP

For US submissions, you’ll first need to determine your FDA pathway, 510(k), De Novo, or PMA, since that determines your classification route. From there, your software documentation needs to cover design requirements, verification and validation, and version history.

If your device uses AI or machine learning models, adaptive models, NLP, neural networks, or otherwise, you’re expected to clearly state your methods, models, frameworks, and platforms, along with details on your data population samples and how, when, and where that data was collected.

A few things worth flagging directly from Apurva’s presentation:

• The Predetermined Change Control Plan (PCCP) must be reviewed and established as part of your marketing authorization if your AI device software function includes one, regardless of whether you’re going through PMA, 510(k), or De Novo.
• FDA published draft guidance on AI-enabled device software functions on January 6, 2025, covering lifecycle management and marketing submission recommendations. If you haven’t reviewed it yet, this should be on your list.
• Your submission should distinguish clearly between training data, tuning data, and test data, each serves a different purpose in demonstrating your model’s performance, and FDA expects you to explain how each dataset was collected, processed, stored, and retained.
• Post-market performance monitoring is expected as part of your quality system, including evidence that your device benefits all relevant demographic groups, race, ethnicity, sex, and age, to ensure it stays safe and effective for your intended population.

European Union: MDR, IVDR, and the AI Act working together

Here’s a distinction I want you to walk away with clearly, because it’s one of the most common points of confusion Apurva addressed: complying with EU MDR does not automatically mean you’re complying with the EU AI Act. These are two separate sets of requirements that manufacturers need to satisfy side by side. MDR and IVDR address medical device safety and performance; the AI Act addresses AI-specific risks and obligations for high-risk AI systems.

On the MDR side for software:

• Software with a medical purpose falls within the MDR device definition, general-purpose software, or software intended for lifestyle and wellbeing, does not.
• MDCG 2019-11 (updated June 17, 2025) governs qualification and classification of software, and MDR Annex VIII, Rule 11, specifically addresses software classification.
• Minor software revisions require a new UDI-PI, not a new UDI-DI, a detail that’s easy to get wrong if your regulatory and engineering teams aren’t tightly coordinated.
• All four mandatory EUDAMED modules are now live, and economic operators and devices carry EUDAMED obligations depending on which modules apply to them.

On the AI Act side, for high-risk AI systems you’re looking at requirements around risk management, data governance, technical documentation, transparency, human oversight, and cybersecurity, and yes, a CE marking is required for high-risk AI systems too, which may need to be completed by a digital CE marking alongside the physical one.

My take: if your regulatory and AI compliance work are happening in separate silos right now, this is a good moment to bring them into the same room.

United Kingdom: intended purpose, and a classification framework in flux

The UK’s core law is the Medical Devices Regulations 2002 (as amended), and, as Apurva emphasized repeatedly throughout the session, intended purpose is the concept the entire framework hinges on. MHRA guidance lays out the specific elements you need to define: the structure and function of the device, the intended population, the intended users, and the intended use environment.

A few points worth your attention:

• Devices are classified as Class I, IIa, IIb, or III, with approved body involvement required for IIa, IIb, and III.
• MHRA has acknowledged that the current classification rules may not proportionately reflect the risk posed by SaMD or AI devices, and reform is underway — worth watching if you have products in this space.
• MHRA’s clinical investigation guidance was recently updated (July 23, 2026).
• FDA, Health Canada, and MHRA have jointly identified 10 Guiding Principles for Good Machine Learning Practice. Apurva specifically called out Principle 7 (performance of the human-AI team) and Principle 9 (providing clear, essential information to users) as worth close attention.
• Before you register with MHRA, you need to determine whether your device is being placed on the market, put into service, or both and that answer determines your registration obligations.

Canada: classification, licensing, and lifecycle evidence

Health Canada regulates under the Medical Device Regulations (SOR/98-282), with a risk-based classification system from Class I to IV. Classes II, III, and IV generally require a Medical Device License (MDL); Class I generally doesn’t, but importers and distributors must hold an active Medical Device Establishment License (MDEL) regardless of class if they’re importing or distributing devices in Canada.

For machine learning-enabled medical devices specifically, Health Canada considers product lifecycle information essential to demonstrating safety and effectiveness. The components you should have documented: good machine learning practices, design, risk management, data selection and management, development and training, testing and evaluation, clinical validation, transparency, and post-market monitoring. That’s a comprehensive list worth building into your documentation templates now rather than assembling reactively during a submission.

Australia: ARTG inclusion, evidence, and a UDI rollout worth tracking

In Australia, software is regulated when it meets the definition of a medical device under the Therapeutic Goods Act (section 41BD), and, with limited exceptions,devices generally need to be included in the Australian Register of Therapeutic Goods (ARTG) before legal supply. TGA updated its software-specific guidance, Understanding How We Regulate Software-Based Medical Devices, on February 24, 2026.

There’s currently no standalone comprehensive AI medical device law in Australia, AI and software fall under the existing medical device framework, with TGA’s AI and medical device software guidance updated February 5, 2026. Manufacturers need sufficient evidence to demonstrate compliance with the Essential Principles, including verification and validation appropriate to the AI function itself.

One date worth putting on your calendar: Australia’s UDI system is rolling out in phases, mandatory compliance begins July 1, 2026 for Class 3 and Class 2B devices, followed by Class 2A on July 1, 2027, and Class 1S on July 1, 2028, with IVD classes phased in on separate dates.

What to actually do with all of this

Apurva closed the session with practical guidance I want to underline, because this is where the real operational value is:

1. Maintain one global software/AI lifecycle framework that covers risk management, software verification and validation, cybersecurity, clinical evidence, AI model validation, change control, and post-market surveillance across all your target markets.
2. Run a country-specific regulatory impact assessment for every software or AI update, don’t assume a change that’s routine in one market is routine everywhere. The assessment should consider whether the change affects intended use, clinical functionality, algorithm performance, risk management, interoperability, cybersecurity, user interface, or your safety and performance evidence.
3. Continuously monitor FDA, EU MDCG, Health Canada, and TGA regulatory changes, and keep a centralized requirements matrix rather than tracking each market separately.
4. Take local medical device definitions seriously, some markets have very specific requirements around intended purpose that others don’t, and reading the current guidance from each health agency directly (rather than relying on secondhand summaries) matters.
5. Use PCCPs where applicable, and link your model/data version control to post-market surveillance and real-world AI performance data. That feedback loop is what lets you catch performance drift before it becomes a compliance problem.

During Q&A, Apurva addressed a question I think a lot of regulatory teams are wrestling with right now: how do you know if a software update is a new device, a significant change, or routine maintenance, when the answer differs by market? Her guidance: start from your approved intended purpose and the device’s risk profile, then assess the proposed change against each jurisdiction’s specific rules rather than assuming one global determination applies everywhere.

Image Credit: Magnific

FAQ: Global software and AI medical device regulations

Does complying with EU MDR automatically mean I’m compliant with the EU AI Act? No. MDR and IVDR address medical device safety and performance; the AI Act separately addresses AI-specific risks for high-risk AI systems. Manufacturers of high-risk AI-enabled devices need to satisfy both sets of requirements.

What’s the difference between training, tuning, and test data in an FDA AI submission? Training data is used to build the AI model. Tuning data is used to evaluate a small number of trained models. Test data is used to characterize the performance of the final AI device software function. FDA expects documentation on how each dataset was collected, processed, stored, and retained.

Do I need a separate AI model for every country I sell in? Not necessarily. A single global model can work if you can justify that your evidence is representative of the intended population, clinical setting, and workflow in each target market, accounting for differences in demographics, disease prevalence, clinical practice, and data acquisition that could affect performance.

How is software regulated differently in the UK compared to the EU? The UK’s Medical Devices Regulations 2002 places heavy emphasis on a clearly defined intended purpose, similar to the EU’s approach, but the UK operates its own classification and approval body framework (MHRA) separate from EU MDR, and MHRA has acknowledged its current classification rules may not proportionately reflect SaMD and AI risk, reform is in progress.

What should a global software/AI compliance framework include? At minimum: risk management, software verification and validation, cybersecurity, clinical evidence, AI model validation, change control, and post-market surveillance, applied consistently across every market where the device is sold, with a country-specific regulatory impact assessment run for every update.