Introduction 🔗

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 answer turns on your intended use, not your technology 🔗

The Federal Food, Drug, and Cosmetic Act defines a device by what it is intended to do: software intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease.

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.

The five carve-outs, briefly 🔗

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:

1. for administrative support of a healthcare facility (scheduling, billing, claims, analytics);
2. for general wellness: maintaining a healthy lifestyle, unrelated to any disease or condition;
3. to serve as electronic patient records, without interpreting or analyzing them;
4. to transfer, store, convert, or display device data without analyzing it (MDDS);
5. as certain clinical decision support (CDS) for healthcare professionals, where the clinician can independently review the basis for the recommendations rather than rely on them.

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.

Why this is such a hard question 🔗

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:

AI-Assistance vs Generation 🔗

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.

The safety feature that creates device risk 🔗

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 law FDA sometimes chooses not to enforce 🔗

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 platform with one clinical feature 🔗

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.

"But we don't sell it" 🔗

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.

The ground moves 🔗

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.

Conclusion 🔗

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.

"But our competitors just shipped it" 🔗

Every month, someone shares a version of this frustration with us, and it is a fair one:

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.

If it is a medical device 🔗

Device status sets off a chain of consequences worth understanding early:

• A pathway. For most AI-enabled SaMD, the realistic outcomes are 510(k)-exempt status, a 510(k) (if a good predicate exists), or a De Novo. Which one applies drives your timeline and evidence burden more than any other single factor.
• Evidence. Performance testing against a reference standard and, depending on claims, clinical evidence. Plus software documentation, cybersecurity documentation, and human factors work.
• A quality system. Design controls and a QMS. You don't need the full system at submission time, but you do before you market, and it is far cheaper to phase in early than to retrofit.
• Claims discipline. Your marketing must match your cleared indications for use. No more, no less.

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.

If it isn't a medical device (yet) 🔗

A "not a device" conclusion is not the end of the work. It is a position you have to defend and maintain:

• Write it down. Document the decision: the facts, the functions you analyzed, the carve-outs you relied on, and the assumptions. Hospital customers, investors, and acquirers will ask. A verbal rationale does not survive diligence.
• Set claims guardrails. Your non-device status lives or dies by what marketing and sales say. Give them a concrete list of claims they can and cannot make.
• Define reassessment triggers. New features (especially AI features that analyze data), new claims, new user groups, and new FDA guidance should each trigger a re-check. As one client asked after concluding they were outside FDA's scope: "If our software isn't a medical device, do we need to notify FDA proactively, and what marketing claims or features could trigger enforcement?" (You don't notify FDA, but you should know your triggers.)
• Consider a lightweight QMS anyway. If you're borderline—especially near the CDS line—running a light quality system shows due diligence. If FDA ever comes knocking, you can show that you took the question seriously and built your software professionally. We help teams set this up in a low-risk, low-overhead way that doesn't slow product work.
• Consider confirming with FDA. For close calls, a pre-submission can get FDA's read. Often, though, a well-documented internal justification is the right level of investment. Which you choose is a judgment call about how much certainty your business needs.

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.

How Innolitics can help 🔗

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.

About the Author 🔗

Appendix: The statutory definitions 🔗

For readers who want the primary source, here is the definition of a device from section 201(h) of the FD&C Act:

And the five software carve-outs from section 520(o):

Key FDA guidance interpreting these provisions:

• Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act
• General Wellness: Policy for Low Risk Devices
• Clinical Decision Support Software
• Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices
• Multiple Function Device Products: Policy and Considerations
• Policy for Device Software Functions and Mobile Medical Applications