FDA Regulation of AI Medical Devices: Pathways, PCCPs, and Oversight

If you are building clinical software that uses machine learning, one of the first planning questions is whether it counts as a regulated product, and if so, what that means for your timeline, your evidence, and your ability to update the model later. FDA AI medical device regulation is where those questions get answered, and the answers shape product decisions long before anyone writes a submission.

Getting this wrong is expensive in both directions. Teams that assume their tool is "just software" can find late in development that its intended use makes it a medical device, forcing a redesign or a delayed launch. Teams that over-assume regulation can spend months on documentation for a tool that would have fallen outside device rules entirely. And because AI models can change after release, the update strategy needs to be decided at the start, not after the first retraining run.

This explainer covers how the FDA approaches software that learns, what counts as an AI medical device, the main market pathways (510(k), De Novo, and premarket approval) and what a submission contains, the difference between locked and adaptive algorithms, how a predetermined change control plan works, why this matters now for builders and health systems, and the open questions the framework has not yet settled. It is educational, not legal advice; regulatory specialists should confirm decisions for any specific product.

A Regulator Built for Static Products, Meeting Software That Learns

The FDA was designed to answer one question about a medical device: does this specific, fixed thing work safely? A stent has a diameter. A pacemaker has a firmware version. Once cleared, the device stays the device — any meaningful change requires going back through review. That model works fine for hardware and even for conventional software, because conventional software doesn't change its own behavior after it ships.

AI models complicate that premise in two ways. First, even a "locked" model is a statistical object trained on a particular dataset, and its behavior on data unlike its training set is genuinely hard to predict in the way a mechanical device's behavior is not. Second, some AI systems are built to keep learning from new data after deployment — which means the thing the FDA cleared on day one is not necessarily the thing running in a hospital on day 400.

The FDA has spent the better part of a decade building a framework to handle this, and by mid-2026 that framework — while still evolving — has real structure to it. This piece walks through how AI medical devices actually get to market in the US, what the agency does and doesn't require, and where the open questions still sit.

What Counts as an "AI Medical Device" in the First Place

Not every piece of AI touching healthcare needs FDA clearance. The trigger is whether the software meets the legal definition of a medical device — broadly, whether it's intended to diagnose, treat, cure, mitigate, or prevent disease, or to affect the structure or function of the body.

The relevant category is Software as a Medical Device (SaMD): software intended for a medical purpose that isn't just running on or controlling a piece of hardware. An algorithm that flags a suspicious mass on a chest X-ray is SaMD. A wellness app that tracks your step count is not, even though both involve software analyzing personal health signals.

Within SaMD, AI-based products generally fall into one of these buckets:

• Computer-aided detection/diagnosis (CAD/CADe/CADx) — flags or characterizes findings in medical images, such as a mammography algorithm marking a region of interest, the same pattern-recognition work behind most AI medical imaging tools.
• Clinical decision support (CDS) — synthesizes patient data to suggest a diagnosis, risk score, or treatment option, generally intended to inform rather than replace a clinician's judgment.
• Monitoring and triage tools — continuously analyze streams of data (ECG waveforms, vital signs, imaging queues) to flag abnormalities or prioritize cases, the same underlying approach used in AI remote patient monitoring.
• Autonomous diagnostic systems — render a diagnostic result without a clinician reviewing the underlying image or data, a much smaller and more tightly scrutinized category.

The distinction between the first three and the last one matters enormously for how much scrutiny a product gets, because "human stays in the loop" versus "software makes the call" changes the risk calculus the agency applies.

The Pathways: How AI Devices Actually Get Cleared

Most AI medical devices reach the US market through one of three regulatory pathways, and almost none of them go through the full Premarket Approval (PMA) process that headline-grabbing implantable devices require.

The 510(k) route dominates because AI products often function similarly enough to prior cleared software (or to prior manual clinical workflows) that a predicate can be found. This has drawn sustained criticism: comparing a new AI algorithm to an older, sometimes far less sophisticated predicate can understate how much the underlying technology has actually changed, and 510(k) clearance does not require the kind of prospective clinical trial that a PMA does.

De Novo classification exists partly to address that gap — it lets the FDA establish a new device category (with its own risk controls) for something genuinely novel, which can then itself become a predicate for future 510(k) submissions in the same space.

What a Submission Actually Contains

Regardless of pathway, an AI/ML device submission generally needs to show:

1. Intended use and indications for use — precisely what clinical question the software answers and for whom (e.g., "detects diabetic retinopathy in adults with diabetes from retinal fundus photographs").
2. Algorithm description — architecture, training methodology, and the general nature of the training data (though not necessarily the training data itself).
3. Performance data — sensitivity, specificity, and other accuracy metrics, typically validated on a dataset independent from training data.
4. Bias and generalizability analysis — increasingly expected evidence that the model performs consistently across relevant demographic subgroups, not just in aggregate.
5. Human factors and labeling — how the output is presented to the clinician, what warnings accompany it, and how misuse is guarded against.

A submission that shows strong aggregate accuracy but skips subgroup performance, or that doesn't clearly define the intended patient population, is a common reason for delay.

Timelines vary widely depending on device risk and how much clinical evidence is required. A 510(k) for a well-precedented CAD tool with a clean predicate might move through review in a matter of months. A De Novo submission for a genuinely new category of software, or a device that requires a prospective clinical study to establish performance, can take considerably longer — and the clinical study itself, run before the submission is even filed, often dwarfs the agency review time, since designing and running AI-focused clinical trials well is its own multi-year undertaking. Manufacturers that underestimate this front-loaded work are the ones most likely to see their launch timeline slip.

Locked Algorithms vs. Adaptive Algorithms

This is the distinction that actually drives most of the regulatory novelty around AI, and it's worth spelling out plainly.

A locked algorithm produces the same output every time given the same input — its parameters are fixed at the time of clearance. It might have been built using machine learning, but once trained and validated, it doesn't change on its own. The vast majority of FDA-cleared AI medical devices to date are locked in this sense. If the manufacturer wants to retrain the model on new data or adjust its behavior, that's treated as a modification requiring a new or supplemental submission, the same way changing a device's materials would.

An adaptive algorithm, by contrast, is designed to update its behavior based on new data it encounters after deployment — the kind of continuous learning that AI research often aspires to. This is where the regulatory model runs into a real conceptual problem: how do you certify the safety of something whose behavior is, by design, not fixed at certification time?

The Predetermined Change Control Plan (PCCP)

The FDA's answer to the adaptive-algorithm problem is a mechanism called the Predetermined Change Control Plan. Instead of forcing a manufacturer back through full review every time they want to update a model, a PCCP lets the manufacturer specify, at the time of initial submission, exactly what kinds of future changes they intend to make, how those changes will be validated, and what the boundaries of acceptable modification are.

A PCCP generally has to define:

• The specific, planned modifications — for example, retraining on an expanded dataset to improve performance on an underrepresented subgroup, not an open-ended "the model will keep learning."
• The modification protocol — the exact methods used to develop, validate, and implement each change, including data management and retraining procedures.
• The impact assessment — an analysis of the benefits and risks of the planned changes, and how the manufacturer will confirm the modified device stays within its cleared indications for use.

If the FDA accepts a PCCP as part of the original clearance, subsequent updates that fall within its defined scope don't require a brand-new submission. Updates that fall outside the plan's scope still do. This is a meaningful shift in regulatory philosophy — from certifying a fixed artifact to certifying a bounded process for change — but it's still early. Uptake has been gradual, and manufacturers have to be genuinely disciplined about scoping their PCCPs narrowly enough that the FDA will accept them, which somewhat limits how much true adaptiveness a cleared PCCP realistically covers in practice.

Benefits of the FDA's AI Device Framework

The framework is often discussed as an obstacle, but for teams that plan around it, it provides real structure. These are the benefits it offers builders, buyers, and patients.

A known route to market

The 510(k), De Novo, and PMA pathways give manufacturers a defined set of options, each with recognisable evidence expectations. A team that knows its device type, risk level, and likely predicate can estimate what evidence it needs and roughly how long preparation will take. That predictability makes it possible to plan funding, hiring, and clinical studies around a realistic timeline rather than an open question.

A path for updating models after clearance

Before the PCCP mechanism, any behaviour-affecting retraining meant returning for a new or supplemental submission. A plan accepted at clearance lets a manufacturer make specified, validated changes without starting again. For AI products, where performance often improves with more data, that turns model maintenance from a regulatory event into a governed engineering process.

Evidence that buyers can rely on

Clearance confirms that a device met a defined bar of safety and effectiveness for its stated indication, based on documented validation. For hospital procurement and clinical governance committees, that is a shared starting point. It doesn't replace local validation, but it means buyers are not evaluating every claim from scratch, and it gives them a documented intended use to compare against their own needs.

Pressure toward better validation practice

Expectations around independent test sets, subgroup performance, and clear labelling push teams toward habits that improve the product regardless of regulation. A model that has been checked across demographic groups and documented with a precise intended use is less likely to fail quietly in deployment. Teams that build these practices in early tend to find fewer surprises when the product reaches real patients.

Clearer accountability when things change

Because a cleared device has a defined intended use, algorithm description, and change plan, it is easier to tell whether an update stayed in scope and who is responsible for confirming that. For clinicians and health systems, that clarity matters when a tool's behaviour shifts and someone needs to explain why.

FDA-Regulated AI Medical Device Use Cases

Most AI devices on the US market fall into a few established categories. These are the areas where AI software most commonly reaches clearance, and where the framework described above is applied day to day.

Image analysis in radiology

The largest group of AI devices supports radiologists reading images: marking possible findings on mammograms, highlighting nodules on chest imaging, or measuring structures automatically. These are typically computer-aided detection or diagnosis tools with a clinician reviewing every output. Because many have predicates among earlier cleared software, the 510(k) pathway is the usual route, with submissions centred on performance against an independent image set.

Triage and worklist prioritisation

Some tools don't diagnose at all but reorder the queue, flagging studies that appear to show an urgent finding so they are read sooner. The clinical value is time: a critical case moves to the top of a busy list. Regulators look closely at how the notification is presented and at what happens when the tool misses a case, since clinicians might otherwise assume an unflagged study is normal.

Physiological signal monitoring

Algorithms that analyse ECG waveforms, vital signs, or other continuous signals to detect arrhythmias or deterioration are a well-established category. They often run in wearables, bedside monitors, or remote monitoring services. Submissions focus on detection performance across the conditions and patient groups named in the intended use, and on how alerts are presented so that clinicians can act on them without being overwhelmed.

Autonomous screening

A smaller group of devices returns a result without a clinician reviewing the underlying data, such as screening for a specific eye condition from retinal photographs in a primary care setting. The aim is to extend screening to places where specialists aren't available. Because the software makes the call itself, these devices face closer scrutiny of their evidence, including performance in the setting where they will actually be used.

Clinical decision support with risk scores

Software that combines patient data into a risk score or suggested next step sits near an important boundary. Some decision support falls outside device regulation when a clinician can independently review the basis for the recommendation; other tools, especially those that are time-critical or opaque, are regulated as devices. Teams building in this area need an early, careful reading of the intended use to know which side they fall on.

Why This Matters Right Now for Builders and Health Systems

Interest in AI-enabled clinical tools has moved well past pilot projects into production purchasing decisions at hospitals, radiology groups, and primary care networks, where integrating a new tool with existing EHR systems via FHIR is often as much of a deployment hurdle as clearance itself. That shift changes who needs to understand this framework and why.

For a startup building a diagnostic or triage tool, the regulatory pathway is not a compliance afterthought bolted on before launch — it shapes the product from the earliest design decisions. Choosing to build a locked model versus pursuing a PCCP for a more adaptive system changes the validation dataset you need, the clinical study design, and the timeline to market by potentially a year or more. Teams that treat regulatory strategy as something to figure out after the model works well in a notebook consistently find themselves re-architecting late in development.

For health systems and clinical buyers, FDA clearance is a floor, not a ceiling. Clearance confirms a device met a bar of safety and effectiveness for its stated indication — it does not confirm the device performs well on your specific patient population, your specific imaging equipment, or your specific workflow. A model validated primarily on one demographic or one type of scanner can underperform when deployed elsewhere — one reason approaches like federated learning, which trains across multiple hospitals' data without centralizing it, are gaining attention — and clearance paperwork alone won't tell a purchasing committee that.

For clinicians, the locked-vs-adaptive distinction matters practically: a locked tool behaves predictably over time (its failure modes today are its failure modes next year, for better or worse), while a tool operating under a PCCP might genuinely improve — or, if something goes wrong in the update process, degrade — without an obvious external signal that anything changed.

There's also a procurement dimension that's easy to overlook. A hospital IT and clinical governance committee evaluating two competing products — one locked, one operating under an approved PCCP — is effectively evaluating two different kinds of ongoing risk exposure, not just two accuracy numbers on a spec sheet. Contracts, monitoring plans, and internal validation cadences increasingly need to account for that difference explicitly rather than treating "FDA cleared" as a single uniform label.

Common FDA AI Device Planning Mistakes

Most regulatory delays for AI products come from decisions made long before a submission is drafted. These are the mistakes that show up most often.

Writing the intended use last

Teams often build the model first and describe its intended use afterwards, as a summary of what it happens to do. But the intended use determines whether the software is a device, which pathway applies, and what evidence is required. Drafting it late can reveal that the validation data doesn't match the claimed population or setting, forcing new studies. Write a precise intended use early and revise it deliberately as the product evolves.

Validating only on aggregate accuracy

A strong overall sensitivity and specificity can hide weak performance in a subgroup, a type of scanner, or a care setting. Reviewers increasingly expect subgroup analysis, and submissions without it are a common cause of questions and delay. Plan the validation dataset to cover the populations and equipment named in the intended use, and report results for each.

Retraining without a change strategy

Engineers naturally want to retrain a model as more data arrives. For a locked device, a behaviour-affecting retrain usually means a new or supplemental submission. Teams that discover this after launch either freeze an improving model or face an unplanned regulatory cycle. Decide at the start whether the product will stay locked or operate under a PCCP, and design the data and validation pipeline accordingly.

Scoping a PCCP too broadly

A change control plan that describes open-ended learning is unlikely to be accepted. Plans need specific modifications, a defined protocol for validating each one, and clear boundaries. Teams that aim for maximum flexibility can end up with no accepted plan at all. A narrow, well-defined plan that is actually accepted is worth more than an ambitious one that isn't.

Treating clearance as proof of local performance

On the buyer side, assuming a cleared tool will perform equally well on every patient population, scanner, and workflow leads to disappointment or worse. Clearance reflects performance on the manufacturer's validation data for a stated use. Health systems that skip local validation and ongoing monitoring may not notice when a tool underperforms in their setting.

FDA AI Device Best Practices

These practices help builders and health systems work with the framework rather than against it. They are general orientation; specific products need advice from regulatory specialists.

• Hold a regulatory scoping session before the architecture is fixed. Bring product, clinical, engineering, and regulatory people together to agree the intended use, likely device classification, candidate pathway, and possible predicates. Those answers shape the dataset, model design, and timeline, and changing them later is far more expensive than settling them before the first training run.
• Use pre-submission meetings. Discussing the intended use, evidence plan, and any PCCP with the agency before filing reduces the risk of surprises and helps scope what is actually required.
• Design the validation dataset alongside the model. Keep a test set independent of training data, cover the subgroups and equipment named in the intended use, and document how data was collected and labelled.
• Decide locked or PCCP at the start. Choose the update strategy as a product decision, then build the retraining, validation, and documentation pipeline that the chosen strategy requires.
• Treat labelling and human factors as part of the product. Test how clinicians read and act on the output, including what they assume when the tool does not flag something, and design warnings around those findings.
• Keep a traceable record of every model version. Store the training data description, validation results, and release notes for each version that reaches users. When a question arises about a change, whether from the agency, a customer, or an internal review, the answer should come from documentation rather than memory.
• Plan post-market monitoring before launch. Define the performance metrics to track in real deployments, how drift will be detected, and who reviews the results, rather than relying on complaints to reveal problems.
• For buyers, validate locally and contract for transparency. Test a cleared tool on your own patients and equipment before relying on it, and agree in the contract how updates, performance data, and changes under any PCCP will be communicated.

Real Limitations and Open Questions

None of this framework is settled science, and it's worth being direct about where the gaps sit.

• Post-market surveillance is thinner than pre-market review. Once a device is cleared, ongoing monitoring of real-world performance is largely left to the manufacturer's own reporting obligations rather than continuous independent oversight. Performance drift — where a model's accuracy degrades as the population or clinical practice it encounters shifts away from its training distribution — is a known risk that current mechanisms only partially address.
• Predicate-based clearance can obscure real technological change. Comparing a new deep learning model to an older, structurally different predicate device (sometimes one that isn't AI-based at all) can allow substantial jumps in underlying technology to clear a lower evidentiary bar than a De Novo or PMA review would demand.
• Bias evaluation standards are still maturing. Expectations around demonstrating subgroup performance have tightened, but there's no single, universally applied standard for what counts as sufficient demographic representation in a validation dataset, and enforcement is uneven across submission types.
• International divergence adds complexity. The EU's Medical Device Regulation and AI Act, the UK's MHRA framework, and FDA requirements are not aligned, which means a device cleared in the US may need separate evidence packages to launch elsewhere — a nontrivial cost for smaller manufacturers, and a pattern that shows up across global AI regulation well beyond medical devices.
• The PCCP mechanism itself is still young. It offers a real path toward safely regulating adaptive systems, but there isn't yet a long track record of how the FDA handles edge cases, disagreements over scope, or a manufacturer's PCCP-covered update turning out to have unintended effects.

What to Watch Next

A few threads are worth tracking if you're building or buying in this space:

1. Growth in PCCP-based clearances. As more manufacturers gain experience getting change control plans accepted, expect the proportion of adaptive (versus purely locked) cleared devices to rise gradually.
2. Real-world performance reporting requirements. Pressure is building — from clinicians, researchers, and within the agency itself — for more standardized, possibly public, post-market performance data rather than one-time clearance snapshots.
3. Generative AI in clinical workflows. Tools that summarize clinical notes, draft documentation, or synthesize patient histories using large language models — the same category of AI medical scribe products already in clinical use — sit in a genuinely ambiguous space: many function as administrative aids outside SaMD's scope, but as their outputs edge closer to clinical decision-making, expect sharper agency guidance on where the line falls.
4. Harmonization efforts across regulators. Ongoing international collaboration (through bodies like the International Medical Device Regulators Forum) aims to reduce duplicate evidence requirements across jurisdictions, though full harmonization remains distant.

FAQ

Does every AI healthcare app need FDA clearance?

No. Only software that meets the legal definition of a medical device — intended to diagnose, treat, prevent, or mitigate disease, or affect body structure or function — needs clearance. General wellness apps, administrative tools, and software that doesn't make or inform a clinical decision typically fall outside FDA's device jurisdiction. Some clinical decision support software is also excluded when a clinician can independently review the basis for its recommendations. Because the line depends on intended use and claims, the same algorithm can be regulated or unregulated depending on how it is marketed and what it tells users to do.

What's the difference between 510(k) and De Novo pathways?

A 510(k) requires showing your device is substantially equivalent to an already-cleared predicate device. De Novo is used when no valid predicate exists for a novel, low-to-moderate risk device; once granted, a De Novo classification can itself become a predicate for future submissions in that category. In practice, many AI products reach the market through 510(k) by citing an earlier cleared AI device with a similar intended use. Higher-risk devices go through premarket approval, which generally requires more extensive clinical evidence than either of the other two pathways.

Can an FDA-cleared AI model keep learning after it launches?

Only within limits it disclosed at clearance time. A "locked" model can't change its behavior without a new submission. An adaptive model can update within the bounds of a Predetermined Change Control Plan (PCCP) approved as part of its original clearance — changes outside that plan's defined scope still require new FDA review.

How does the FDA evaluate bias in AI medical devices?

Manufacturers are increasingly expected to report how a model performs across relevant demographic subgroups, not just in aggregate, and to describe the composition of their training and validation datasets. There isn't yet a single universal standard for what counts as adequate subgroup representation, so rigor varies by submission. Builders should plan for this early by recording dataset sources and demographics, holding out validation data from separate sites where possible, and reporting performance by subgroup. Retrofitting that evidence after training is far harder than collecting it while the dataset is assembled.

Is FDA clearance proof that an AI tool works well in my clinic?

Not entirely. Clearance confirms the device met a safety and effectiveness bar for its stated indication, typically validated on a specific dataset and patient population. Performance on your equipment, patient mix, or workflow can differ, which is why many health systems run their own local validation before full deployment. A sensible local check compares the tool's outputs against clinician judgment on a sample of your own cases, looks at results for the patient groups you serve, and continues monitoring after go-live, because scanners, protocols, and patient populations change over time.

What happens if a cleared AI device's performance degrades over time?

Post-market surveillance for this kind of "performance drift" currently relies heavily on manufacturer reporting rather than continuous independent monitoring, which is widely viewed as one of the framework's weaker points. If a manufacturer has a PCCP in place, planned retraining can help address drift within the plan's approved scope. Health systems should not rely on that alone and should keep monitoring the tool locally after go-live.

Are large language models used in clinical documentation regulated as medical devices?

It depends on function, not underlying technology. An LLM that drafts clinical notes or summarizes records for a clinician to review is generally treated as an administrative tool outside SaMD's scope; one that generates a diagnosis or treatment recommendation without meaningful clinician review moves much closer to being regulated as a medical device.

How long does the FDA process take for an AI medical device?

There is no single answer, because timing depends on the pathway, device risk, quality of the submission, and how many rounds of questions the agency raises. A 510(k) with a clear predicate is usually the quickest route, De Novo requests generally take longer, and premarket approval for high-risk devices is the most demanding. The preparation before submission, including validation studies, documentation, and quality system work, often takes longer than the review itself. Early pre-submission meetings with the FDA can reduce surprises and help scope the evidence needed.

Conclusion

The FDA's device framework was designed for products that stay the same after clearance, and AI models do not fit that assumption neatly. Even locked models can behave unpredictably on data unlike their training set, and adaptive models are designed to change. The framework that has developed in response classifies software by intended use, routes it through 510(k), De Novo, or premarket approval, and allows controlled updates through a predetermined change control plan.

For builders, the practical lessons are clear. Intended use, not the underlying technology, decides whether software is a device. The update strategy, locked or governed by a PCCP, needs to be designed alongside the model. Subgroup performance and dataset composition increasingly matter in submissions. And clearance shows a product met a bar for a stated use on a specific dataset, which is why health systems still validate locally.

Open questions remain around post-market monitoring of drift, standards for bias evaluation, and how generative models used near clinical decisions will be treated. Treat this guide as orientation and involve regulatory specialists early for any specific product. Teams building or evaluating AI-enabled clinical software can work through the regulatory strategy and technical validation together with Woyce Technologies. If you are planning the engineering side of a clinical AI product, start with our healthcare AI development team.