Artificial intelligence, medical devices

Seven Things Every Medical Device Manufacturer Must Know Before Integrating AI

By Jonathan Ripley, Ruaidhrí Primrose
Artificial intelligence, medical devices

No longer a horizon technology, Artificial Intelligence in healthcare has reached a level of real-world performance that makes clinical value demonstrable at a critical time in healthcare – a time of clinician shortages, backlogs, and rising costs that have made access to treatment a challenge.

Executive Summary: 

Artificial intelligence in healthcare is no longer a horizon technology; computational capability and cloud infrastructure have matured to the point where complex models can run efficiently, securely, and cost-effectively. AI tools too have reached a level of real-world performance that makes clinical value demonstrable: glucose monitors that predict dangerous hypoglycaemic events before they happen, oncology tools that match patients to the most effective treatment protocol for their specific tumour profile, and rehabilitation platforms that adjust physiotherapy regimes in real time based on recovery data. All this couldn’t come at a better time as clinician shortages, backlogs, and rising costs have made access to treatment a challenge.

However, integrating AI into a medical product is as much a regulatory undertaking as a technical one and while technology has reached a good level of maturity, its application to the highly regulated world of healthcare is still in its infancy. What follows is a practical guide to the seven things manufacturers cannot afford to be mistaken about.

1. Determine whether your product is a Software as a Medical Device (SaMD) from the onset.

This is the foundational question, and not always an easy one to answer. A heart rate monitor can be a fitness accessory or a clinical tool. Understanding where a specific device sits is critical to ensuring seamless market entry as well as to setting up appropriate post market surveillance mechanisms. The UK’s Medicines and Healthcare products Regulatory Agency (MHRA) has developed guidance for medical device stand-alone software including apps (including IVDMDs)[1] that currently represents the most practical starting point available, regardless of where the product is marketed. It establishes that if a product explicitly claims to diagnose, treat, prevent or monitor a medical condition and exerts a meaningful clinical effect, it is almost certainly subject to SaMD regulation. Manufacturers should therefore assess their labelling, instructions for use, promotional copy, and technical documentation systematically to establish whether functionality and intended use make the device an SaMD or not.

2. Treat training data as a regulated component of the device.

AI regulation diverges most sharply from conventional software regulation on this point in the healthcare environment. In standard development, traceability means tracking who built a feature, who reviewed it, and what requirement it satisfies. By contrast, for AI-enabled SaMDs, training data itself is an integral part of the device. Introducing a new dataset can trigger a full re-validation cycle and require updates to the technical file. Manufacturers who establish SaMD status early on and thus build Predetermined Change Control Plans into their initial regulatory submissions can avoid having to restart from scratch each time the model evolves.

3. Accountability for Software of Unknown Provenance (SOUP).

Every development team uses third-party libraries, pre-built models and external frameworks. In most industries, SOUP is adopted quickly and documented loosely but in the medical device world, the risk to human life is too great and therefore every piece of SOUP must be accurately catalogued: what it is, why it was chosen, which specific software requirements it addresses, and where a retained copy can be found. IEC 62304 compliance depends on this record being complete and current. Treating SOUP governance as an afterthought can cause damaging regulatory delay.

4. Build cybersecurity into the Quality Management System from day one.

A hacked drug delivery system is much more than just a data breach, it is a patient safety incident. In an SaMD cybersecurity must be treated as a clinical risk, not an IT concern so the QMS should reflect this level of scrutiny. Security architecture decisions, threat modelling, and vulnerability management processes should be documented and embedded in the development workflow from the outset, not bolted on at the end of the build cycle.

5. Choose your launch market based on regulatory readiness, not just commercial opportunity.

The US currently offers the most linear regulatory pathways for SaMD manufacturers, with established FDA guidance on general wellness devices and clinical decision support software, and relatively predictable timelines. The UK has historically provided a lighter-touch entry point, with more devices falling into Class I than in the EU, though this is changing as the MHRA tightens its approach ahead of new 2026 requirements. The EU is currently the most complex environment with the AI Act designating AI-integrated SaMDs as high-risk, although the Commission’s recent COM(2025) 1023 proposal may simplify the classification of lower-risk devices, if adopted.

6. Understand that the regulatory landscape is in flux.

The EU AI Act only came into force in August 2024, with phased implementation ongoing. The EU Data Act followed hot on its heels in in September 2025, while COM(2025) 1023 is under active consideration. In the UK, recent MHRA guidance on ambient scribes signals increasing scrutiny of AI-powered clinical tools. These are all relatively new and evolving regulations so manufacturers should ensure they stay up to date and fully understand all nuances of proposed changes before they come into effect. Building compliance management systems capable of absorbing change as the rules continue to evolve is also key.

7. Make compliance a design principle, not a pre-launch checklist.

The manufacturers who consistently struggle with SaMD regulation are those who treat it as an afterthought. By the time a product is complete, the cost of rearchitecting data pipelines, retroactively documenting SOUP, or redesigning security controls is enormous. Compliance that is built in from the start is not only safer but significantly cheaper in the long run. In a market growing at 44% annually, the window for first-mover advantage is appealing but grasping it requires planning. The manufacturers best placed to capture it are those who have already done the development and regulatory groundwork.

AI has arrived in the medical device manufacturing world. Engaging with it responsibly, sustainably, and in a way that survives regulatory scrutiny in every market the device enters is the challenge the market faces now. The seven steps above will not cover every scenario, but they address the most common points of failure and offer a starting point to build flexible and resilient compliance into development of SaMDs.


[1] MHRA, Guidance: Medical device stand-alone software including apps (including IVDMDs)

Related Articles

About The Author

About The Author