There is an AI product in your roadmap that helps make a clinical decision, and the team is treating it like any other software launch: build it, test it, ship it, iterate. What the plan does not reckon with is that if the software's intended use makes it a medical device, it falls under FDA oversight, with classification, validation, and change-control requirements that reshape how it is built and how it can be updated. The "ship and iterate" plan assumes a regulatory freedom the product may not have.
This is more than a compliance footnote. It is the difference between shipping software and shipping a regulated medical device.
Shipping AI as Software as a Medical Device is not a normal software launch with paperwork added. It is a regulated product where intended use determines whether and how FDA oversight applies, where validation and evidence are required before market, and where the model's ability to change is constrained by change-control expectations. The regulatory pathway shapes the architecture, the evidence, and the update model from the start.
However, many teams build the AI first and confront the regulatory reality late, when classification, validation, and change control have to be retrofitted onto a product not designed for them.
If you are a product or technology leader building clinical AI, the intent of this article is:
- Define what makes AI a medical device and what FDA oversight requires
- Walk through classification, validation, and change control
- Lay out the controls a regulated AI product needs
To do that, let's start with the basics.
Why Most Healthcare AI Projects Fail
The four infrastructure failure modes that determine whether a promising clinical AI pilot becomes a production system.
What Is SaMD Under the FDA? The Basic Definition
At a high level, Software as a Medical Device (SaMD) is software whose intended use is medical, diagnosis, treatment, or clinical decision-making, which can bring it under FDA oversight, requiring classification by risk, validation and evidence before market, and change control over modifications.
To compare:
If shipping ordinary software is opening a restaurant, shipping SaMD is opening one that serves a regulated medical function, with inspections, certifications, and rules on what you can change without re-certifying. The food is software; the regulation is the difference.
Why Is Treating AI as a Medical Device Necessary?
Issues that treating AI as a medical device addresses or resolves:
- Determining whether FDA oversight applies based on intended use
- Meeting validation and evidence requirements before market
- Managing model change under change-control expectations
Resolved Issues by a Regulated Approach
- Clarifies the regulatory pathway from intended use
- Builds the validation and evidence the FDA requires
- Designs an update model compatible with change control
Core Components of Shipping SaMD
- Intended use that determines classification and oversight
- Risk-based classification
- Validation and clinical evidence before market
- Change control over model modifications
- Quality and documentation systems
Modern SaMD Considerations
- Intended-use and classification analysis
- Validation against the intended use
- Predetermined change control for adaptive models
- Quality management systems
- Post-market surveillance
These are the realities of regulated AI; the discipline is designing for them from the start, not retrofitting.
Other Core Issues They Will Solve
- Provide a defensible regulatory position
- Enable lawful marketing of clinical AI
- Manage the tension between model updates and re-certification
Importance of Getting SaMD Right in 2026
Treating clinical AI as a regulated device matters more as AI enters clinical decisions. Four reasons explain why it matters now.
1. Intended use determines oversight.
Whether software is a medical device turns on its intended use. Misjudging this is a serious regulatory error with market consequences.
2. Validation is required before market.
Unlike ordinary software, SaMD requires validation and evidence before it can be marketed. "Ship and iterate" does not apply.
3. Change control constrains model updates.
A regulated model cannot be freely updated; modifications fall under change control. AI's iterative nature collides with this unless designed for.
4. Retrofitting regulation is costly.
Confronting classification, validation, and change control after building is expensive and risky. Designing for them is far cheaper.
Traditional vs. Regulated AI Shipping
- Ship and iterate vs. validate before market
- Software launch vs. regulated device with oversight
- Free model updates vs. change-controlled modifications
- Regulation as afterthought vs. designed in from intended use
In summary: Shipping AI as a medical device is a regulated process shaped by intended use, validation, and change control, designed in from the start.
Details About the Core Components of Shipping SaMD: What Are You Designing?
Let's go through each element.
1. Intended Use Layer
What determines oversight.
Intended use decisions:
- Define the intended medical use precisely
- Determine whether it makes the software a device
- Recognize that intended use drives classification
2. Classification Layer
The risk-based category.
Classification decisions:
- Risk-based classification per the intended use
- Requirements scaling with risk
- The pathway determined by classification
3. Validation Layer
The evidence required.
Validation decisions:
- Validation against the intended use
- Clinical evidence before market
- Documentation of validation
4. Change Control Layer
How modifications are managed.
Change control decisions:
- Modifications under change control
- Predetermined change control for adaptive models where applicable
- The update model designed for the constraint
5. Quality System Layer
How quality is assured.
Quality decisions:
- A quality management system
- Documentation throughout
- Post-market surveillance
Benefits Gained from a Regulated Approach
- A defensible regulatory position from intended use
- Validation and evidence built in, not retrofitted
- An update model compatible with change control
How It All Works Together
You define the AI's intended medical use precisely, because that determines whether it is a medical device and how it is classified by risk. The classification sets the regulatory pathway and the requirements, which scale with risk. You build the validation and clinical evidence the pathway requires before market, rather than shipping and iterating. Because a regulated model's modifications fall under change control, you design the update model for that constraint, using predetermined change-control approaches for adaptive models where applicable. A quality management system and documentation support the whole, with post-market surveillance after launch. The regulatory pathway shapes the architecture, evidence, and update model from the start, rather than being retrofitted late.
Common Misconception
Clinical AI can be shipped like other software and made compliant afterward.
If the intended use makes the AI a medical device, it is subject to FDA oversight, validation, and change control that shape how it is built and updated, not paperwork added after. Shipping like ordinary software and adding compliance later means retrofitting regulation onto a product not designed for it, which is costly and risky.
Key Takeaway: Intended use, not engineering preference, determines whether AI is a regulated device. If it is, the regulatory pathway shapes the build from the start.
Real-World SaMD Shipping in Action
Let's take a look at how a regulated approach operates with a real-world example.
We worked with a team building clinical AI without reckoning with SaMD, with these constraints:
- Determine whether FDA oversight applied
- Build the required validation and evidence
- Design an update model compatible with change control
Step 1: Define Intended Use
Establish the regulatory basis.
- Intended medical use defined precisely
- Whether it makes the software a device determined
- Classification implications understood
Step 2: Classify by Risk
Determine the pathway.
- Risk-based classification
- Requirements scaling with risk
- Regulatory pathway set
Step 3: Build Validation and Evidence
Meet pre-market requirements.
- Validation against the intended use
- Clinical evidence before market
- Validation documented
Step 4: Design for Change Control
Reconcile updates with regulation.
- Modifications under change control
- Predetermined change control where applicable
- Update model designed for the constraint
Step 5: Establish Quality and Surveillance
Support the whole.
- Quality management system
- Documentation throughout
- Post-market surveillance
Where It Works Well
- Intended use defined and classification determined early
- Validation and evidence built in before market
- An update model designed for change control
Where It Does Not Work Well
- Shipping clinical AI like ordinary software
- Confronting validation and classification late
- An iterative update model incompatible with change control
Key Takeaway: The clinical AI that ships lawfully is the one designed from intended use through validation and change control, not the one built as ordinary software with regulation retrofitted.
Common Pitfalls
i) Treating it as ordinary software
If intended use makes the AI a device, FDA oversight applies and shapes the build. Treating it as ordinary software invites a costly retrofit.
- Define intended use early
- Determine if it is a device
- Design for the pathway
ii) Misjudging intended use
Intended use determines oversight, and misjudging it is a serious regulatory error. Analyze it carefully and precisely.
iii) Skipping pre-market validation
SaMD requires validation and evidence before market. "Ship and iterate" does not apply and can be unlawful.
iv) Ignoring change control
A regulated model's updates fall under change control. An iterative update model not designed for this collides with the regulation.
Takeaway from these lessons: Most SaMD trouble traces to treating clinical AI as ordinary software and confronting regulation late, not to the regulation itself. Define intended use, classify, validate, and design for change control from the start.
SaMD Best Practices: What High-Performing Teams Do Differently
1. Start from intended use
Define the intended medical use precisely, because it determines whether the AI is a device and how it is classified. Everything follows from this.
2. Classify by risk early
Determine the classification and pathway before building, so requirements shape the product rather than surprising it.
3. Build validation and evidence in
Plan for the validation and clinical evidence the pathway requires before market, not as an afterthought.
4. Design the update model for change control
Reconcile AI's iterative nature with change-control expectations, using predetermined change control for adaptive models where applicable.
5. Establish a quality system and surveillance
Support the product with a quality management system, documentation, and post-market surveillance from the start.
Logiciel's value add is helping teams analyze intended use and classification, build the required validation and evidence, and design an update model compatible with change control, so clinical AI ships as a lawful, regulated device rather than facing a costly retrofit.
Takeaway for High-Performing Teams: Focus on intended use, classification, validation, and change control from the start. Whether AI is a regulated device turns on intended use, and if it is, the regulatory pathway shapes the build, not the other way around.
Signals You Are Shipping SaMD Correctly
How do you know the approach is sound? Not in the software's quality alone, but in the regulatory footing. Below are the signals that distinguish a regulated approach from an ordinary-software one.
Intended use is defined. The team can state the intended medical use precisely and whether it makes the software a device.
Classification is determined. The team knows the risk classification and regulatory pathway, established early.
Validation is built in. The team has planned and produced the validation and evidence the pathway requires before market.
The update model fits change control. The team can update the model in a way compatible with change-control expectations.
Quality and surveillance exist. The team has a quality management system, documentation, and post-market surveillance.
Adjacent Capabilities and Connected Work
This work does not exist in isolation. Shipping SaMD depends on, and feeds into, several adjacent capabilities. Building one without thinking about the others is the most common scoping mistake.
In most organizations, SaMD shares infrastructure with the AI development and MLOps process, the clinical validation function, and the regulatory and quality program. It shares capacity with product, applied ML, regulatory affairs, and quality. And it shares leadership attention with whatever the next clinical-product initiative is on the roadmap. Naming these adjacencies upfront helps the program scope realistically and helps leadership see the work as a portfolio rather than a one-off project.
The most common mistake in adjacent-capability scoping is treating each adjacency as someone else's problem. The MLOps that must support change-controlled updates is your problem. The clinical evidence is your problem to plan. The quality system is your problem. Pretending otherwise pushes work to teams that did not plan for it, and the work returns to you later as a regulatory blocker. Own the adjacencies you depend on; partner with the teams that own them; share the timeline.
Conclusion
Shipping AI as Software as a Medical Device is a regulated process shaped by intended use, validation, and change control, not an ordinary software launch with compliance added. The discipline that delivers it is the same discipline behind any regulated product: understand the pathway from intended use, build the evidence, and design for the constraints from the start.
Key Takeaways:
- Intended use determines whether AI is a regulated medical device
- SaMD requires validation and evidence before market
- Design the update model for change control from the start
Shipping SaMD well requires intended-use, validation, and change-control discipline. When done correctly, it produces:
- A defensible regulatory position from intended use
- Validation and evidence built in, not retrofitted
- An update model compatible with change control
- A lawful path to market for clinical AI
Healthcare AI That Stays Accurate as Data Changes
Why clinical AI accuracy degrades when code sets update, how ontology mapping breaks across EHR vendors, and the canonical data layer.
What Logiciel Does Here
If you are building clinical AI, define its intended use, determine whether it is a medical device, and design validation and change control into the product before you build for market.
Learn More Here:
- AI Governance in Healthcare: From FDA to Internal Risk Controls
- EU AI Act Compliance for Healthcare Software: A Practitioner Guide
- AI Model Reliability in Clinical Decision Support
At Logiciel Solutions, we work with product and technology leaders on SaMD strategy, validation, and change-control design. Our reference patterns come from regulated clinical AI products.
Explore what it takes to ship AI as Software as a Medical Device.
Frequently Asked Questions
What is Software as a Medical Device (SaMD)?
Software whose intended use is medical, such as diagnosis, treatment, or clinical decision-making, which can bring it under FDA oversight. That oversight requires risk-based classification, validation and evidence before market, and change control over modifications.
How do I know if my AI is a medical device?
It turns on the intended use. If the software's intended use is to inform or make a clinical decision, diagnosis, or treatment, it may be a medical device subject to FDA oversight. Intended use, not engineering preference, determines this, and misjudging it is a serious regulatory error.
Can we ship clinical AI and iterate like normal software?
Not if it is a medical device. SaMD requires validation and evidence before market, and modifications fall under change control. The "ship and iterate" model does not apply and can be unlawful; the regulatory pathway shapes how the product is built and updated.
How does change control affect AI updates?
A regulated model cannot be freely updated; modifications are subject to change control. For adaptive models, predetermined change-control approaches can define permitted changes in advance. The update model must be designed for this constraint rather than assuming free iteration.
What is the biggest mistake in shipping clinical AI?
Treating it as ordinary software and confronting classification, validation, and change control late. If intended use makes it a device, the regulatory pathway shapes the build, and retrofitting regulation onto a product not designed for it is costly and risky. Start from intended use.
