If you are building an AI product for healthcare — something that analyzes patient data, recommends diagnoses or treatments, interprets medical images, or supports clinical decision-making — the most consequential legal question you face before you write a line of product documentation is this: Is your software a medical device subject to FDA regulation?
The answer to that question determines whether you need premarket review before you can sell your product, what validation and testing standards apply, what your labeling must say, how you manage post-market changes, and whether your entire go-to-market strategy is permissible under federal law. Getting the classification wrong — in either direction — is expensive. Treating a regulated device as unregulated exposes you to enforcement action, injunction, and product liability. Treating unregulated software as a device imposes unnecessary compliance costs and delays market entry.
This post walks through the classification framework, the critical four-factor test that determines whether AI falls inside or outside FDA’s regulatory reach, the pathways for devices that do require review, and why classification is the foundational strategic decision for any AI healthcare product.
The Statutory Framework: What Is a Medical Device?
The Federal Food, Drug, and Cosmetic Act defines “device” broadly to include instruments, machines, contrivances, implants, and “similar or related articles” intended for the diagnosis, cure, mitigation, treatment, or prevention of disease, or intended to affect the structure or function of the body. Software is explicitly included in this definition.
Congress complicated the picture in the 21st Century Cures Act of 2016, which carved out several categories of software from the device definition. These carve-outs were codified at Section 520(o) of the FDCA. The most important carve-out for AI developers is the Clinical Decision Support carve-out, which exempts certain CDS software from device regulation — but only if the software meets all four factors of a specific statutory test.
In January 2026, the FDA issued updated final guidance on Clinical Decision Support Software, clarifying how it interprets the four-factor test and replacing its prior 2022 version. Understanding this guidance is essential for any AI healthcare product classification analysis.
Software as a Medical Device: The SaMD Framework
FDA uses the term “Software as a Medical Device” to refer to software that meets the device definition and is not part of a hardware medical device. The International Medical Device Regulators Forum (IMDRF), whose SaMD framework FDA has broadly adopted, defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
The operative element is the intended use. FDA’s regulatory jurisdiction over your AI product turns almost entirely on what your software is intended to do. The same underlying AI model can be regulated or unregulated depending on how it is positioned, what clinical claims are made for it, and how it is integrated into clinical workflows.
Intended use is determined by all available evidence — not just what you write in your labeling or product documentation, but what your marketing materials say, what your sales representatives say, what your website implies, and how clinical users actually deploy the product. If you market an AI tool as a “clinical decision support aid” but your sales materials describe it as helping physicians diagnose disease, you have made a clinical claim that brings your product inside FDA’s regulatory reach.
The risk-based classification system divides medical devices into three classes. Class I devices are low-risk, subject primarily to general controls (registration, listing, labeling, and quality system requirements). Class II devices are moderate-risk and typically require a 510(k) premarket notification demonstrating substantial equivalence to a legally marketed predicate device. Class III devices are high-risk and require Premarket Approval (PMA), the most demanding pathway, which requires affirmative proof of safety and effectiveness.
For AI SaMD, the vast majority of cleared products — as of mid-2024, about 97% of AI-enabled device clearances — have used the 510(k) pathway, which requires finding a predicate device in the same classification and demonstrating substantial equivalence. As AI products become more novel and move into higher-risk applications, the De Novo pathway (for novel devices that are low to moderate risk with no predicate) and PMA pathway (for high-risk applications) become relevant.
The Four-Factor CDS Test: The Critical Exemption
Section 520(o)(1)(E) of the FDCA exempts clinical decision support software from the device definition if — and only if — all four of the following criteria are met:
Factor 1: Does not acquire, process, or analyze medical images, signals from IVD devices, or patterns/signals from signal acquisition systems.
This factor excludes AI tools that work with raw physiological signals or medical images from the exemption. AI that analyzes EKGs, interprets radiology images, processes continuous glucose monitor data, or analyzes EEG waveforms does not pass Factor 1. These tools are SaMD regardless of whether their outputs are characterized as clinical recommendations. If your AI touches imaging data or physiological signals, stop here — you are in device territory.
Factor 2: Displays, analyzes, or prints medical information about a patient or other medical information.
This factor is relatively easy to satisfy. Most healthcare AI presents or analyzes some form of patient information. The factor does not limit the exemption; it describes the category of software the exemption is designed to cover.
Factor 3: Supports or provides recommendations to a health care professional about prevention, diagnosis, or treatment.
This factor has two critical elements: the recommendation must be provided to a healthcare professional (HCP), not to a patient, and it must relate to prevention, diagnosis, or treatment. Software that makes recommendations directly to patients — a chatbot that tells a user they may have a particular condition, or a wellness app that recommends a specific treatment — does not satisfy this factor. Software in the clinical workflow that presents options to physicians does.
Factor 4: Enables the health care professional to independently review the basis for the recommendation.
This is the factor that generates the most analysis and has been the subject of the most regulatory evolution. The 2022 FDA guidance required that the HCP be able to independently review the basis for the recommendation without primarily relying on the software. The January 2026 final guidance refined this: the HCP must be able to understand the basis, but the guidance now states that FDA will exercise enforcement discretion even for software that presents only a single “clinically appropriate” recommendation, as long as the HCP can review the basis. This is a meaningful liberalization from prior guidance.
What does “independently review the basis” mean in practice? The software must display or make accessible the clinical reasoning underlying its output — the data it relied on, the logic it applied, and the evidence supporting its recommendation. A black-box algorithm that outputs “recommend chemotherapy” without any explanation of what it analyzed does not satisfy Factor 4. An AI that presents the patient data it reviewed, the clinical criteria it applied, and a summary of the evidence behind its recommendation does.
The FDA’s updated guidance provides detailed examples. A software function that identifies a patient as high-risk for sepsis and explains that the determination is based on elevated lactate, fever, and elevated white blood cell count satisfies Factor 4. A software function that outputs a diagnosis risk score without any interpretive support does not.
All four factors must be met. If your AI fails any single factor, the CDS exemption does not apply and your software is SaMD subject to device regulation.
Device CDS: What Falls Inside Regulation
AI software that fails the four-factor test — whether because it processes medical images (Factor 1), makes recommendations directly to patients (Factor 3), or provides opaque recommendations without independent review support (Factor 4) — is a medical device. The regulatory pathway depends on the risk classification.
Radiology and imaging AI almost universally fails Factor 1 and is unambiguously SaMD. AI tools that analyze chest X-rays for pulmonary nodules, interpret mammography studies, detect diabetic retinopathy from fundus photographs, or flag stroke on CT imaging are all SaMD. Most such tools have been cleared through the 510(k) pathway, with the FDA identifying prior cleared products in the same classification as predicates. As of mid-2025, the FDA had authorized more than 1,000 AI-enabled devices, with a substantial portion in radiology.
AI diagnostic tools that operate without physician intermediation — tools that present diagnostic conclusions directly to patients, or that operate in a workflow where physician review is nominal rather than genuine — fail Factor 3 or Factor 4. These tools face a more demanding regulatory path, and the intended use characterization is critical.
AI for pathology, cardiac rhythm interpretation, and other signal-based applications involve either signal acquisition systems or images, failing Factor 1. These are regulated medical devices.
AI that integrates with in vitro diagnostic devices — analyzing the patterns produced by lab tests, blood glucose monitors, or other diagnostic instruments — fails Factor 1.
The Regulatory Pathways
510(k) Premarket Notification
The 510(k) pathway is the workhorse of AI medical device clearance. It requires demonstration of substantial equivalence to a legally marketed predicate device: same intended use, same technological characteristics (or different characteristics that do not raise new safety or effectiveness questions). The submission typically includes a software description, cybersecurity documentation, performance testing data demonstrating accuracy on a representative dataset, and labeling.
For AI SaMD, performance testing is the critical component. FDA expects data demonstrating that the device performs as claimed across the intended patient population, including subgroup performance data to identify potential disparate impact on different demographic groups. Data lockout — testing on held-out data that was not used to train the model — is required.
The 510(k) pathway does not require clinical trials in every case, though FDA may require clinical data if performance bench testing is insufficient to support substantial equivalence. Most AI radiology tools have been cleared on the basis of retrospective performance studies rather than prospective clinical trials.
De Novo Classification
When there is no valid predicate device — because your AI product is genuinely novel and no legally cleared device occupies the same classification — the De Novo pathway allows FDA to establish a new device classification for products that are low to moderate risk. De Novo grants the applicant’s product a new classification, which can then serve as a predicate for future 510(k) submissions by other companies.
De Novo submissions are more demanding than 510(k)s because the applicant must justify the appropriate risk classification, propose the special controls that will govern the device class, and demonstrate that those controls provide reasonable assurance of safety and effectiveness. The review timeline is longer, and the clinical data expectations are generally higher.
Premarket Approval (PMA)
PMA is the highest-burden pathway, reserved for Class III devices that cannot be cleared under 510(k) or De Novo. PMA requires affirmative demonstration of safety and effectiveness through valid scientific evidence, which typically means prospective clinical trials. AI products in high-risk diagnostic or therapeutic applications — AI that directly drives treatment decisions for life-threatening conditions, for example — may face PMA requirements.
Why Classification Is the Foundational Strategic Decision
Healthcare AI developers sometimes approach classification as a compliance checkbox. That framing is backwards. Classification is the strategic foundation around which your entire product development, validation, go-to-market, and post-market management strategy is built.
If your product requires FDA clearance or approval, that requirement shapes your development timeline, your clinical validation study design, your data practices, your labeling, your software change management (see our companion post on Predetermined Change Control Plans), and your quality system obligations. Discovering late in development that your product requires a 510(k) — after you have already built and tested it without the documentation FDA requires — is recoverable but expensive.
If your product qualifies as non-device CDS, that determination is not permanent. The exemption applies to the product as it exists when you make the determination. If you add features that cause the product to fail any of the four factors — integrating with imaging, removing the independent review display, repositioning toward patients — the exemption may no longer apply.
Start with a rigorous classification analysis, documented in writing, with the input of experienced regulatory counsel. Revisit the analysis whenever your intended use, technical architecture, or clinical workflow changes. And build your development and compliance program around the classification determination, not around the hope that the question will resolve itself.
This post is for general informational purposes only and does not constitute legal advice. Reading this post does not create an attorney-client relationship. If you have questions about your specific situation, consult a qualified attorney.