If you build AI-enabled clinical software, sooner or later you hit the question: does FDA regulate this as a medical device? This is the most common question I hear when talking to prospective clients. It arrives phrased a hundred different ways: Is our skin health test a general wellness product or an FDA-regulated medical device? Is our AI remote patient monitoring system a Class II medical device or a non-device CDS tool? Can we avoid device classification through how we scope and market our platform? We specialize in AI-enabled software as a medical device (SaMD). Our team has worked on more than 70 FDA submissions involving AI-enabled software. So this article focuses on the version of the question that AI product teams actually face. It covers how the legal definition works, why the call is harder than it looks, and what the answer means for your business either way.
Getting it wrong is costly in both directions. Treat a non-device like a device and you burn a year and a budget you didn't need to spend. Treat a device like a non-device and you risk FDA enforcement, blocked hospital sales, and painful surprises during fundraising or acquisition diligence.
The Federal Food, Drug, and Cosmetic Act defines a device by what it is ** intended** to do: software intended for use in the
Notice what's missing: nothing about algorithms, models, or platforms. The same technology, whether a mobile app, a cloud service, an LLM, or a computer-vision model, may or may not be a device depending on its intended use. And your intended use is set by your objective intent. FDA reads that intent from your labeling claims, ads, sales conversations, and written statements. You cannot avoid device regulation by saying "not intended for medical use" while your marketing says otherwise.
When you decide how to position your product you are choosing an intended use and, if it is a device, the indications for use: which disease or condition, which patients, which users, and which clinical setting. Those choices, not your model architecture, decide whether you have a device, which classification applies, and how much evidence FDA will expect. Claims drive everything downstream. So we tell clients: first decide the claims you need to win in your market, then work out the regulatory consequences—not the other way around.
For a high-profile example, look at ChatGPT Health. By carefully limiting its claims—being deliberate about what they state its purpose is—OpenAI has kept it on the general wellness side of the boundary and avoided the need for a regulatory submission (I think the current political environment is likely a factor as well). It is a live demonstration that claims, not capability, draw the line. FDA regulates medical device software that is “intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease”. This is simple enough, but in the 21st Century Cures Act, Congress removed five categories of software functions from the device definition. In short (see the Appendix for the full statutory definitions), a software function is carved out when it is intended:
Two things to know. First, the carve-outs are judged function by function, not product by product; one product can hold device and non-device functions side by side. Second, they are narrow, and for AI-enabled products narrower than most teams hope. In particular, the CDS carve-out—the one every AI company wants—is not available to functions that acquire, process, or analyze medical images or signals, which covers most medical AI.
If the definition and the carve-outs sound almost mechanical, why do so many teams get stuck here? Because the statute's words are short and load-bearing—intended, unrelated, analyze, independently review—and real products refuse to sit still. Here are a few real-world examples to highlight how complex it gets: "At what point does AI involvement—e.g., an AI agent generating or modifying exercise regimens—trigger medical device classification?"
A therapist assembling exercise plans with software tools is one thing. An AI generating the plan for a patient with a musculoskeletal condition starts to look like treatment. The answer changed based on which humans stayed in the loop, what the marketing claimed, and whether the plans addressed a diagnosed condition. In this case, even the company and FDA read the same product differently: one saw an exempt measuring device, the other suggested a Class II product code. And when a roadmap adds a little more autonomy each quarter, there is no obvious moment when the answer flips.
A mental-health platform asked whether adding AI auto-risk detection—monitoring user text for risk of self-harm or harm to others—would make their app a medical device requiring FDA clearance. A feature added for user safety is arguably detection of a condition. The product decision that felt safest was the one that most threatened their non-device status. And it was not hypothetical: another country's regulator had already treated the same feature as a diagnostic device, forcing the company to pull it from that market. Whether FDA would read it the same way was an open question.
This highlights how infuriating the regulatory definitions can be sometimes and how trying to follow the regulations can conflict with making your device safer.
The FD&C Act expressly allows FDA to exercise enforcement discretion. In several guidance, FDA lists software functions that meet the device definition but that it does not intend to regulate. This adds a whole layer to the analysis: your function can be a device under the law and still sit outside FDA's active attention. But enforcement discretion is policy, not law. It can narrow or vanish with a guidance update, and it gives you none of the legal standing a carve-out does. Furthermore, even in some places where congress made a carveout, FDA is allowed to override it if patients start getting hurt (and after appropriate public commentary periods).
The founder of an LLM-based clinical platform asked how to scope a brain-MRI analysis feature so it wouldn't cause the whole platform to be classified as a medical device. That is really an architecture question. With deliberate boundaries, the regulated function can be contained. Without them, one feature's device status spreads to the positioning, and the validation burden, of the whole platform. Here the imaging feature's output fed an LLM assistant that doctors chat with, so the two functions were not naturally separate. Every chat answer that cited the imaging numbers pulled the assistant closer to the device boundary.
A radiology group asked whether they needed FDA clearance for a PACS they only use internally and never market or sell. Internal use, research use, and free distribution change the commercial picture and the enforcement picture, but less than most teams assume. Disclaimers do less work than founders hope. Part of the difficulty is that "we don't sell it" answers only one of several questions. Clinical-trial use, reimbursement, hospital security reviews, and the first outside customer each run on different rules, and any one of them can change the analysis overnight.
"Do our AI worklist-prioritization algorithms now require FDA clearance under the updated CDS guidance, after previously being advised they didn't?"
They had done the analysis, gotten advice, and shipped. Then FDA's guidance evolved. And it isn't just guidance: the statutory definition itself has shifted over time. Congress rewrote the software carve-outs in the 2016 Cures Act, and FDA has re-drawn the lines around whole product categories over the years—PACS software, for example, is regulated differently today than it once was. A determination that was right five years ago may be wrong today, in either direction. By the time the question resurfaced here, nine algorithms were already live inside customer workflows. Re-asking the device question about a product your customers depend on is a much harder problem than asking it before launch.
The pattern across all of these: the call is made function by function, it is driven by claims and intended use, and it drifts over time as your roadmap ships, FDA's policies evolve, and the law itself gets amended.
This is also why who you ask matters. The statutes, the guidance, and the precedent set by cleared devices are all public, and a careful team can study them. What you cannot look up is how FDA is applying them right now. That understanding comes from recent interactions with the agency: pre-sub meetings, deficiency letters, audits, and conversations with reviewers. When you work with a team like Innolitics, you get both layers—the detailed reading of the rules and precedent, and a current sense of the agency's posture. For new technology like generative AI, where the written guidance trails the products by years, that second layer is often the one that decides the call.
Every month, someone shares a version of this frustration with us, and it is a fair one:
"How do so many US mental health apps deploy auto-risk detection without FDA certification—and without penalty?"
Another client asked why similar competitor products carry such different regulatory statuses—one CE-marked, another labeled research-use-only with no clearance—and what path was actually required for them.
Several things are usually going on at once. Some competitors carefully scoped their claims to stay inside a carve-out; the product looks similar, but the labeling is not. Some rely on enforcement discretion. Some hold a CE mark, which covers Europe and says nothing about FDA. And some are simply non-compliant, betting that FDA won't get to them—the agency enforces slowly, and mostly in response to adverse events and complaints. That bet sometimes works for years. It also sometimes ends with a warning letter, a forced un-launch, or a diligence finding that kills a deal.
Two honest observations from our side of these calls:
Risk tolerance is a business decision, and it changes with stage and revenue. A pre-revenue startup testing demand may reasonably accept regulatory ambiguity that would be reckless for a company with real revenue, hospital contracts, or an acquisition on the horizon. Hospital procurement teams, investors, and acquirers will force the device-status question even when FDA hasn't. The right time to buy certainty is usually just before the stakes rise, not after.
Starting as a non-device can be a good strategy—when it's deliberate. We often help clients launch a wellness or workflow product with carefully scoped claims, build revenue and data, and then add device claims through a clearance later. Clients ask whether they can keep selling a general wellness consumer version while pursuing FDA clearance for a clinical version of the same technology (yes, with care), and whether adding regulated features later means starting the FDA process over (no—the clearance covers the device functions you add, and good records from the wellness phase make it much cheaper). Others ask about soft-launching to design partners under "research use only" labeling while FDA review is ongoing. RUO labeling is legitimate for genuine research use, but it will not protect you if your "research" sites are really using the product in patient care. Hospitals and FDA both see through that.
What separates the deliberate version of this strategy from the risky one: written claims guardrails your marketing team actually follows, an architecture that keeps the future device function separable, and development records that can later support a Design History File.
Device status sets off a chain of consequences worth understanding early:
But device status is not only a burden, and smart founders increasingly see that. What do you gain from clearance? Reimbursement eligibility, clinician trust, clinical validation, and protection if FDA later tightens its approach to today's "wellness" products. We have even seen companies pursue a clearance they didn't strictly need, because clearance itself is a marketing tool. It unlocks claims unregulated competitors cannot legally make, shortens hospital procurement, and builds a moat that survives FDA policy shifts.
A "not a device" conclusion is not the end of the work. It is a position you have to defend and maintain:
One more pattern worth knowing: your customers may hold you to a device-grade bar even when FDA doesn't. Hospital buyers formed their expectations under older rules—PACS software, for example, used to be regulated differently than it is today—so vendors sometimes get pushed toward device-level rigor by their customers rather than by the agency. An ISO 13485 certification can reassure those customers without a regulatory submission, and it positions you well if you later decide to pursue a clearance.
AI-enabled SaMD is our specialty. It's the product category behind most of the 70+ FDA submissions our team has supported, and behind nearly every question quoted in this article. The subtlety in these decisions is exactly why working with experts pays for itself: the statutes are short, but the judgment lives in FDA's guidance, its databases of past clearances, and years of deficiency letters and pre-sub meetings. That experience matters most once real money is on the line. If you're starting to see meaningful revenue, selling into health systems, or raising institutional capital, an untested device-status position is a liability you can remove in weeks.
Medical Device Status Assessment. A fixed-scope engagement that answers this article's question for your specific product. We map your software into functions, apply the statutes, guidance, and FDA precedents to each, and deliver a written regulatory opinion. It includes our official recommendation, practical marketing and product guardrails, whether it's worth confirming the status with FDA, and the changes that should trigger reassessment. The report is written so you can share it with customers and investors for diligence. If the product turns out to be a device, the fees are credited toward the full regulatory strategy.
AI/ML Regulatory Strategy and Pre-Sub. If your product is a device, or you want it to become one, we develop the full strategy. Finding the best regulatory strategy means balancing budget, timeline, investor milestones, marketing claims, data availability, and predicate strength. We work from your business goals to a product definition, pathway, predicate and product-code analysis, clinical validation strategy, and, when warranted, an FDA pre-submission—with optional Breakthrough Device Designation, PCCP, and reimbursement-strategy add-ons.
If you're wrestling with the device-status question right now, reach out in the website chat. We're happy to give you a quick initial read. Hi, I'm David Giese, a Partner at Innolitics. I wrote this article based on my experiences talking to 100s of founders and engineering leaders. It is based on my experience across 40+ FDA submissions involving AI-enabled SaMD. I'd love to connect on LinkedIn**, where I post pragmatic tips about bringing AI-enabled medical software to market.**
For readers who want the primary source, here is the definition of a device from section 201(h) of the FD&C Act: An instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is: (A) recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them, (B) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or (C) intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes. The term "device" does not include software functions excluded pursuant to section 520(o).
And the five software carve-outs from section 520(o):
Section 520(o)
Key FDA guidance interpreting these provisions: