AI and FDA Software as a Medical Device: What Applies

Whether AI software is a regulated medical device turns on intended use rather than on technology, and the clinical decision support boundary is narrower than many teams assume. This guide covers where the lines sit, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal or medical advice.

What determines device status?

Intended use, established by function and by what the manufacturer claims.

Factor	Effect
Diagnostic or treatment purpose	Generally a device
Clinician can independently review basis	May fall outside
Time-critical use without review	Generally a device
Administrative or workflow only	Generally outside
Marketing claims a clinical indication	Pulls into device territory
Patient-facing without clinician	Higher scrutiny

What is the clinical decision support boundary?

Software providing recommendations that a healthcare professional can independently review — because the basis is transparent, the inputs are identified, and the clinician is not relying primarily on the output — may fall outside device regulation.

The practical test is whether the clinician could reach the same conclusion from the underlying information. A system that surfaces relevant records and cites them supports independent review; one that outputs a score with no visible basis does not, whatever the intended positioning says.

What is a predetermined change control plan?

A mechanism allowing certain planned modifications to an AI-enabled device without a new submission, provided the modifications and the methods for implementing and validating them were described and authorised in advance.

That matters enormously for systems expected to improve. Without it, every meaningful model update is a regulatory event. With it, updates within the described envelope proceed on a defined process — which makes the plan one of the most consequential documents in the programme.

Why do marketing claims matter?

Because intended use is established partly by what the manufacturer says the product does.

A system positioned internally as workflow assistance but marketed as detecting a condition has claimed a clinical indication. That mismatch between engineering intent and commercial language is a recurring cause of regulatory problems, and it is entirely avoidable with a review step before claims are published.

What evidence do you need?

Intended use documentation, evidence supporting the independent-review position where relied on, validation records tied to specific model versions, change control plan documentation, and post-market performance monitoring results.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes transparency of basis and version control to the centre. A system that shows which records and findings drove a recommendation supports the independent-review position; one that does not forecloses it.

Version control matters because validation attaches to a version. A system that silently adopts provider model updates cannot state what was validated, which is a problem in any regulated context and an acute one here.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Assuming a workflow positioning removes device status when the output is relied on directly. Marketing a clinical indication for a non-device product. Updating models without a change control plan. And validating without tying the record to a version.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does this interact with other jurisdictions?

Other markets have their own device regimes with different classification and conformity routes, and the EU AI Act interacts with medical device legislation for AI components in regulated products.

A product intended for several markets should be designed against the strictest applicable set rather than certified serially, because retrofitting transparency or change control after a first approval is disruptive.

What should you do first?

Write down the intended use in one sentence and check it against what your marketing says. Mismatches there are the cheapest regulatory problem to find and the most expensive to discover later.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: the basis of each recommendation surfaced so independent clinical review is genuinely possible, validation tied to pinned model versions, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and GxP validation.