AI-Enabled Medical Devices: How FDA Regulates Them

FDA maintains a public list of AI-enabled medical devices it has authorized, and it now runs to more than a thousand entries. 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.

The device definition

Intended use decides device status. Software intended to diagnose, treat, cure, mitigate or prevent disease meets the device definition 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. How transparent the output is can therefore decide whether the product is regulated.

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 novel and no predicate exists. Several of the more distinctive AI authorizations came this way and then became predicates themselves.

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

Predetermined Change Control Plans

Normally, a modification that could significantly affect safety or effectiveness requires a new submission. A model retrained on new data would need one for each significant update.

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.

Without a PCCP, every meaningful model update is a regulatory event, which usually means the model does not get updated. The plan also has to be written before authorization, because it is part of what is authorized; retrofitting one is a new submission.

Other requirements

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, because data drift degrades device performance.

Common submission failures

• Training data that does not represent the deployed population. The most common substantive weakness. Performance on a dataset from three academic centers is not evidence of performance everywhere.
• No PCCP. Shipping an adaptive model with no authorized envelope for change.
• Intended use written for the pitch deck. It determines the predicate, the class and the evidence, so every broad marketing claim needs evidence 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 comes from the build process and is hard to reconstruct afterwards.
• No plan for drift. Post-market performance monitoring is part of the obligation.