Does adding AI make our software a medical device?

You make software that doctors, device reps, or clinics use, and someone has proposed an AI feature. Before anyone starts building, one question belongs on the table: could this turn our product into a medical device in the FDA's eyes? This guide explains how the FDA decides, what changed in its January 2026 guidance, and how to settle the question while it is still a conversation rather than a redesign. It is written for small product teams in the United States. It is not legal or regulatory advice. Anything that matters should go past regulatory counsel before you commit.

The short answer

Adding AI does not, by itself, make software a medical device. The FDA cares about three things: what the software is meant to do, who uses it, and whether a clinician can check its work. Putting a machine learning model behind a feature does not change those questions, though it often changes the answers. The FDA's Clinical Decision Support guidance, revised January 6, 2026 and reissued with a minor correction on January 29, does not mention AI at all. The same four tests apply to a neural network and to a lookup table.

What "medical device" means for software

Federal law defines a device as anything meant to diagnose, cure, treat, lessen, or prevent disease. Software can meet that definition by itself. The industry calls this Software as a Medical Device, or SaMD. In 2016 the 21st Century Cures Act pulled five kinds of software out of the definition:

• Office and billing tools
• General wellness apps
• Electronic health records
• Software that only stores, moves, or displays data
• Certain clinical decision support

Most of the hard questions about AI features land in that last group.

Clinical decision support is software that helps someone, usually a clinician, make a call about a patient's care. The exemption covers only the clinician-facing kind, because a lot of useful software informs a clinician without acting like a medical instrument. The FDA's job is to draw that line, and the CDS guidance is where it draws it.

The four clinical decision support criteria, in plain English

One thing first: these tests only matter for software that has a medical purpose to begin with. A sales tool, a billing feature, or anything else that never touches a patient's care is ordinary software and never gets this far. For software that does have a medical purpose, the 21st Century Cures Act exempts clinical decision support from device regulation when it meets all four of these. Pass all four and the software is not a device. Miss any one and it is, whether or not AI is involved.

• 1. It does not read medical images or signals. If the feature interprets an x-ray, a heart tracing, a tissue slide, or the live stream of readings from a monitor or lab instrument, it fails here. A finished lab value or a single blood pressure reading does not count as a signal. A continuous feed does. AI that summarizes a note the clinician typed is fine. AI that looks at the scan is not.
• 2. It works from medical information. Lab results, patient history, clinical guidelines, published studies. The 2026 revision widened this to include relevant information from well-established sources, not only what would come up in a conversation between clinicians.
• 3. It is built for a healthcare professional. The exemption covers tools clinicians use. Software made for patients or family caregivers falls outside it and is judged under the FDA's other rules for health software.
• 4. The clinician can see how it reached its recommendation, and is not expected to lean on it as the main reason for a decision about a particular patient. This is the test AI features fail most often. A model that says "do X" with nothing the clinician can inspect gives them nothing to review.

The fourth test is where design matters most. Showing which inputs the model used, which sources it drew on, and why it answered the way it did is not just good practice. It is what keeps the feature exempt.

What changed in the FDA's January 2026 CDS guidance

The FDA replaced its 2022 guidance with a revised version on January 6, 2026. The law and the four tests did not change. The FDA's reading of them loosened in a few places and tightened in one.

• A single recommendation can now qualify. Under the 2022 version, software that gave one specific diagnosis or treatment was treated as a device, no exceptions. The 2026 version applies enforcement discretion when only one option is clinically appropriate and the other tests are met. The guidance does not say how to decide when only one option is appropriate.
• Urgent decisions moved from the third test to the fourth. Software whose recommendations call for an immediate response is still a device, on the reasoning that there is no time to check its work. The FDA's worry about automation bias, the habit of accepting whatever the machine says, now sits here too.
• Risk scores are no longer ruled out. The 2026 examples put software that estimates a patient's future risk of a heart attack or stroke, from weight, smoking history, blood pressure, and a lab result, under the same enforcement discretion, as something for a clinician to weigh. Software that predicts something imminent to drive an immediate decision, such as a heart attack or stroke in the next 24 hours or the chance a patient dies in the hospital based on live monitor readings, is still a device.
• Drafting clinical reports got a worked example. A tool that takes a radiologist's own findings and drafts a summary of those findings for the report, including a suggested diagnosis, can fall under enforcement discretion as long as a clinician reviews it, the tool does not look at the image itself, and its suggestions come from well-established sources.
• The FDA updated its General Wellness guidance the same day. That matters if your product involves wearables or readings taken from outside the body, because it widens what can be sold as a wellness product rather than a device.

What did not change: the guidance covers software for clinicians only. It says nothing new about patient-facing tools like symptom checkers or health chatbots. And although the FDA announced it as an AI update, it never explains how a generative AI feature would pass the fourth test. Until the FDA fills that gap, you and your counsel have to reason it through yourselves. The agency has said it plans to revise its broader policy on device software and mobile medical apps during fiscal 2026.

Worked examples from the kind of software we build

These are illustrations. What your feature is for, and what you claim about it, decide the real answer.

• AI search and drafting inside a sales or ordering platform. Reps find the right product, draft follow-up emails, pull the current document. Office work. Nothing here diagnoses or treats anyone.
• AI that flags incomplete records in a surgical registry. Data cleanup. Not a device. But the moment the same registry starts predicting how a particular patient will do, in order to guide their treatment, the fourth test comes into play. A registry that estimates a patient's risk in the 90 days after surgery, from published evidence, for planning, is the kind of thing the guidance now tolerates. One that predicts a patient is about to get worse in the hospital, so staff can step in, is a device.
• A 3D app that shows off a device to reps and surgeons. Education and sales. Not a device, as long as it shows the product rather than building a model of a specific patient's anatomy to plan their operation.
• A clinical calculator. It depends. A calculator built on a published, widely accepted formula, where the clinician can see the inputs and the math, can qualify for the exemption. One that pulls readings from a monitor, or tells the clinician to act right now, does not. The FDA has treated some calculators as devices, so do not assume.
• A chatbot that answers clinician questions from your product's instructions and guidelines. The strongest case rests on the second and fourth tests: it draws on accepted sources and shows them, so the clinician can check. The weakest case is advice about a specific patient with nothing on screen to back it up. The guidance says nothing about generative AI, so this one needs counsel.
• A symptom checker or coaching tool for patients. Outside the exemption entirely. It is judged under the FDA's other software and wellness rules, and the answer can go either way.

Do you want to be a device?

Being a device is not a failure. For some products it is the point. Decide which path you want before you design the feature, because the two paths pull the design in opposite directions.

• Reasons to pursue device status on purpose. The value of the feature is in making the call, not supporting it: reading the image, scoring the risk, flagging the patient who is about to get worse. A clearance lets you say so in your marketing, which exempt software cannot. It is a barrier your competitors have to clear too. And in a raise or a sale, a clearance is an asset, where a surprise classification is a liability.
• Reasons to stay exempt. The feature supports a clinician's judgment rather than replacing it. You need to ship in months, not years. The budget does not stretch to a quality system and a submission. Or the feature is a small part of a larger product and does not justify pulling the whole product into regulation.
• What you cannot do is drift between the two. It happens more often than you would think: a team builds a feature that stays carefully on the exempt side, then the marketing copy or a sales rep starts describing it as something that detects disease, and now the company is selling a device it never cleared. Whichever path you pick, make sure your claims stay on it.

If you choose the device path, the next section is your plan. If you choose to stay exempt, the section after it is how to hold that line.

If it is a device: 510(k), QMSR, and what changes

Whether you chose this path or the tests put you on it, you are in company: the FDA's own list of AI-enabled devices passed 1,500 in 2026. What the path changes is your plan, your timeline, and your budget.

• Review before you can sell. Most software devices are Class II, the middle risk tier, and go through a 510(k), where you show your product is as safe and effective as one already on the market, or De Novo, the route for products with nothing comparable to point to. Either way, expect performance testing and a documented record of how the software was designed and checked.
• A quality management system. The FDA's Quality Management System Regulation, which follows the international standard ISO 13485, took effect February 2, 2026. Documented design steps, risk management, and controlled changes become part of how you build.
• Cybersecurity. If the software can connect to the internet, your submission must include a security plan and a software bill of materials, a list of every component and library you ship.
• A plan for updating the model. The FDA's Predetermined Change Control Plan guidance, first finalized in December 2024, lets you get approval in advance for certain kinds of model updates, so retraining does not mean a new submission every time.

How to decide early, and how to stay exempt if that is your choice

• Write down what the feature is for, in one sentence. Who uses it, with what information, to make what decision. If you cannot write that sentence, you cannot judge the feature. The FDA calls this the intended use, and everything else hangs on it.
• Check that sentence against the four tests. Honestly. The first test you find yourself arguing about is the one to take to counsel.
• If you want to stay exempt, design for the fourth test. Show the inputs, show the sources, show the reasoning, and keep the clinician in charge. Treat the explanation as a feature, not an afterthought. If you want to be a device, design for the submission instead: validation data, documented design, and a clinical claim you can back.
• Watch what you claim. Your website, your sales deck, and your reps are all evidence of what the feature is for. "Detects sepsis early" is a device claim even if the code only sorts a list.
• Write the decision down. One page: what the feature is for, how it fares on the four tests, and the date. When the FDA, a buyer, or an investor asks, you have an answer ready.
• Revisit it when the feature changes. A new input, a new type of user, or a new claim can change the answer. Acquirers in particular will ask when you last looked.

How Skye Road handles this

We are engineers, not regulatory counsel, and we do not give regulatory or legal advice. What we do is raise the question at the start of any feature that touches clinical decisions, write the one-sentence purpose with you, design so the reasoning behind any recommendation is visible to the person using it, and bring in your counsel before the build locks you in. Our healthcare work and case studies show what that looks like in practice. If the feature also touches patient data, our guide to HIPAA and AI covers what to expect from an AI vendor, and our security page covers how we handle it.

The bottom line

The FDA does not regulate AI as such. It regulates what software is for. Decide what your feature does, who relies on it, and whether they can see why it said what it said. Answer those three questions honestly and the regulatory question mostly answers itself. Then choose which side of the line you want to be on, and build for it. Put the questions off and they get answered for you, later and at a higher price.