Putting AI inside a medical device without breaking the rules

When your software is the medical device, or sits inside one, the bar moves. You need a quality system regulators recognise, a development lifecycle you can evidence, and a clinical and risk case that stands up to scrutiny. Adding a model that learns makes all of that more interesting, because the regulators' classic assumption, that you validate a fixed thing once and ship it, no longer holds. The good news: the framework already has room for AI, if you use it deliberately.

The regulated foundation still applies

ML features don't get a pass on the fundamentals. You still need an ISO 13485 quality management system, an IEC 62304 software lifecycle proportionate to the safety class, risk management traced through to verification under ISO 14971, and clinical evaluation backing your safety and performance claims. The model is a component within that system, not an exception to it.

Designing for a model that learns

Where AI changes things is change itself. Good Machine Learning Practice treats data governance, representativeness, and bias control as part of the design history, not an afterthought. A predetermined change-control plan describes, in advance, how the model may update after deployment and the limits within which it stays inside its cleared intended use. And verification becomes evidence: reference datasets, performance thresholds, and held-out evaluation, so a model's behaviour is something you can defend rather than something you hope holds.

The job isn't done at launch

A fixed device can, in principle, be validated and forgotten. A model can drift: the population shifts, inputs change, performance quietly degrades. That's why post-market surveillance of model performance is part of the design, not a bolt-on: you monitor real-world behaviour against the thresholds you set, and you have a route to act when it moves. Done well, AI in a medical device isn't a loophole to manage, it's a discipline that makes the device genuinely safer.