Regulatory glossary

AI-Enabled Medical Devices: How FDA Regulates Them

FDA maintains a public list of AI-enabled medical devices it has authorised, and it now runs to more than a thousand entries. The striking thing about that list is how ordinary the regulatory story is: the overwhelming majority reached market through 510(k), the same premarket notification route as any other device, and radiology dominates by a wide margin.

There is no separate AI pathway. An AI-enabled device is a device, and it is regulated as one.

What makes it a device

Intended use, not technology. Software intended to diagnose, treat, cure, mitigate or prevent disease meets the device definition regardless of whether it is a decision tree or a foundation model. A wellness app that does none of those things is not a device, and a model that does is.

Most AI products land in the software as a medical device category, and the clinical decision support carve-out under the 21st Century Cures Act is where the line gets argued. That carve-out turns on whether a clinician can independently review the basis for the recommendation rather than relying primarily on it. A model that cannot explain its reasoning is, almost by construction, one the clinician has to rely on, which puts it back in scope. Output transparency is a regulatory variable, not only a product one.

The route to market

510(k) for the vast majority, citing a predicate. The predicate does not have to use the same technique: a deep learning model can be substantially equivalent to an earlier device using different methods, provided the intended use and technological characteristics support the comparison.

De Novo where the intended use is genuinely novel and no predicate exists. Several of the more distinctive AI authorisations came this way and then became predicates themselves.

PMA for the highest-risk applications, which remain rare.

Predetermined Change Control Plans

The mechanism that matters most for anything that gets retrained.

Normally, a modification that could significantly affect safety or effectiveness requires a new submission. For a model that improves as it sees more data, that is a submission treadmill.

A Predetermined Change Control Plan lets a sponsor specify in advance the modifications it intends to make, the methods it will use to develop and validate them, and the impact assessment. FDA authorises the plan alongside the device. Changes made within that envelope then do not require a new submission.

Two practical consequences. Without a PCCP, every meaningful model update is a regulatory event, which usually means the model does not get updated. And the plan has to be written before authorisation, because it is part of what is authorised. Retrofitting one is a new submission.

What else applies

Cybersecurity. Since section 524B was added in 2022, a premarket submission for a cyber device must include a plan to monitor and address vulnerabilities, a process for updates, and a software bill of materials. This is statutory, and submissions have been refused for omitting it.

IEC 62304 for the software lifecycle, with documentation scaled by safety class.

ISO 14971 for risk, applied to the clinical use and not only to failure modes in the code.

Post-market surveillance, which for a model means monitoring performance in deployment rather than only collecting complaints. Data drift is a device performance question.

Where AI submissions go wrong

• Training data that does not represent the deployed population. The most common substantive weakness. Performance on a dataset from three academic centres is not evidence of performance everywhere.
• No PCCP. Shipping an adaptive model with no authorised envelope for change.
• Intended use written for the pitch deck. It determines the predicate, the class and the evidence. Broad claims bought cheaply in marketing are expensive in the submission.
• Assuming the CDS carve-out applies. It depends on whether the output can be independently reviewed, which is an architecture decision made long before the regulatory conversation.
• Cybersecurity assembled at the end. A software bill of materials is generated from how you build, not written afterwards.
• No plan for drift. Post-market performance monitoring is part of the obligation, not an optional analytics feature.