The FDA regulates an AI medical device as a medical device that includes one or more AI-enabled device software functions. The agency says plainly that it does not regulate AI as such: it regulates devices, and software counts as a device when it is intended for the diagnosis, cure, mitigation, treatment or prevention of disease. Software that analyses a medical image for one of those purposes stays a device even under the clinical decision support exclusions. From then on, every meaningful model change can be a regulatory event. That is why validation evidence, a change plan and post-market monitoring are best designed into the product from the start rather than assembled just before submission.
For the clinical picture first, see the overview of computer vision in healthcare and what must exist before clinical reliance.
When AI software becomes an AI medical device under FDA rules
The legal test is Section 201(h) of the Federal Food, Drug, and Cosmetic Act: AI is a medical device, and subject to FDA regulation, if it is intended for use in diagnosing, curing, mitigating, treating or preventing disease. The definition of a device includes software, apart from certain software functions excluded under section 520(o) of the Act. The FDA’s draft lifecycle guidance calls an AI-enabled device one that includes one or more AI-enabled device software functions. A model, in that guidance, is a mathematical construct that produces an inference or prediction from new input data.
Medical software comes in two kinds. The International Medical Device Regulators Forum (IMDRF) defines Software as a Medical Device (SaMD) as software intended for one or more medical purposes that performs them without being part of a hardware medical device. Software in a Medical Device (SiMD) is part of, or drives, a physical device and is needed for that device’s medical function. AI software running in the cloud that measures tumours on medical images is SaMD.
Intended use decides whether software is a device at all, and the IMDRF defines it as the manufacturer’s objective intent as reflected in its specifications, instructions and information. Sales and marketing materials can count as that information. In practice this means a product page or a sales deck that promises “detects fractures” can move software into device territory, whatever the engineering team meant to build.
The first check: is this part of the pipeline a device at all?
Regulation is often less constraining than teams assume. Many parts of a life-sciences pipeline sit outside the regulated portion, so the first job is to check whether a given AI function actually falls under the requirements. The FDA’s clinical decision support guidance, finalised in January 2026, says that not all decision support software used in healthcare is a device. To be excluded, a software function has to meet all four of the statutory criteria.
Functions that enhance images, take measurements, identify normal or abnormal structures, or work inside computer-aided detection (CADe) or computer-aided diagnosis (CADx) systems fail the first criterion and stay devices. The same applies to ECG waveform analysis and to software that analyses NGS sequence data to identify variants. That last point touches the pipeline described in AI in clinical genetics and the variant-interpretation pipeline. A diagnostic CV tool such as aneurysm detection with computer vision, or the volumetric work in brain analysis with 3D computer vision when used for diagnosis, falls on the device side under that test.
Computer vision that measures endpoints inside a study, as in computer vision advancing modern clinical trials, raises the same question first: does the software carry a marketed diagnostic claim?
How many AI-enabled medical devices has the FDA authorised, and which clinical areas (radiology, ophthalmology, dermatology) make up most of the list?
The FDA states that it has authorised over 1,600 AI-enabled medical devices for marketing in the United States as of September 2026. Published counts differ by snapshot date and source:
| Snapshot | Count | Source |
|---|---|---|
| FDA list, as of September 2026 | over 1,600 authorised | FDA hub page |
| FDA registry through 31 December 2025 (downloaded March 2026) | 1,430 devices | JMIR registry analysis |
| Cutoff 5 December 2025 | 1,357 cleared or approved | PLOS Digital Health evidence census |
| FDA database, July 2025 | over 1,250 (up from 950 in August 2024) | Bipartisan Policy Center |
| FDA list to 27 September 2024 | 1,016 authorisations, 736 unique devices | npj Digital Medicine taxonomy |
| 1995 to 2023 | 692 devices | npj Digital Medicine scoping review |
The PLOS Digital Health census found that radiology accounts for 78% of cleared devices (1,059 of 1,357), with cardiovascular and neurology devices among the other specialties it reported. The JMIR study stratified all 1,430 devices by FDA advisory panel across four eras from 1995 to 2025. None of the supplied sources gives a clean share for ophthalmology or dermatology, so we will not put a number on either.
The sources cited here give no ranking of companies; they name individual cases, such as O.N. Diagnostics’ VirtuOst VFA in the enforcement section below.
Which computer vision tasks do FDA-authorised AI devices actually perform?
In the npj Digital Medicine taxonomy of 736 unique devices, 84.4% used images as the core input to the AI, 14.5% used signals, 0.7% used ‘omics data and 0.4% used tabular EHR data. The same study classified 85.6% of devices as analysis, 11.3% as generation and 3.1% as both. On the analysis side, it identified six subclasses: triage, quantification and feature localisation, detection, diagnosis, combined detection and diagnosis, and prediction.
Triage devices output a binary prediction that flags an exam for prioritised review by a clinician. Quantification devices calculate a quantitative metric or locate structural features, often by segmenting a structure and then measuring its volume. Detection devices (CADe) highlight suspicious regions such as lung nodules on CT. Diagnosis devices (CADx) output a likelihood score without localising anything. Radiomics-style feature extraction computes quantitative metrics, so it sits nearest quantification. The taxonomy does not treat it as a class of its own.
On the generation side, 84 devices perform image enhancement such as denoising and AI-based reconstruction. LLM-based generative models were not yet represented in the 2024 data. How these systems work internally, and where validation decides whether they hold, is covered in how computer-aided diagnosis software works.
What submission evidence does each CV task need for an FDA review?
The draft lifecycle guidance treats the model as part of the device’s mechanism of action, so the way data was collected, processed, annotated, stored and used is central to the FDA’s review. The model description should be detailed enough for a competent AI practitioner to produce an equivalent model. It covers inputs and outputs, architecture, features, loss functions and training method, hyperparameters and convergence curves.
Approval-grade evidence is a first-class engineering output. It is evidence a non-engineer can read and sign against. Here is how each CV task turns into submission content:
| CV task | Typical device class (npj taxonomy) | What the submission needs to show |
|---|---|---|
| Image classification (score or category) | Diagnosis or triage | AUROC, sensitivity and specificity, PPV and NPV with confidence intervals, and performance at each operating point |
| Detection (regions or boxes) | Detection (CADe) | The same clinical metrics, with reference-standard criteria and reader blinding stated |
| Segmentation and measurement | Quantification and feature localisation | Validation on independent data, plus robustness to foreseeable changes in inputs and use conditions |
| Image enhancement or reconstruction | Generation | Validation on independent datasets, as for every model |
Three requirements apply to every row. First, test data should be independent of the training data (for example, drawn from entirely different clinical sites) and kept away from the model developers. Leakage between the two leaves the device’s true performance uncertain. Second, the software version history has to record the model version that was tested and any difference from the released version, so the FDA can confirm the model was not adjusted after the fact in light of the test data. Third, discrimination on its own is not enough: a model can score well on discrimination and still produce poorly calibrated probabilities in new settings, so calibration slope and intercept should be assessed too.
Foundation-model output needs the same care: the article on MedSAM and why prompted masks are not validation evidence explains why a good-looking mask is not a validated measurement. For the wider training pipeline behind these devices, see deep learning in medical computer vision.
What does FDA guidance on AI-enabled device software functions require today?
The FDA’s final guidance on predetermined change control plans (PCCPs) for AI-enabled devices addresses model updates directly. It was drafted in April 2023 and finalised in December 2024, after PCCPs for devices generally became statutorily permitted in December 2022. The guidance applies to AI-enabled devices reviewed through the 510(k), De Novo and PMA pathways. A PCCP has three parts: a description of the planned modifications, the methodology for developing, validating and implementing them, and an assessment of their impact. The FDA reviews the plan as part of the marketing submission, so modifications described in an authorised PCCP can then be made without a further submission for each one. According to the Bipartisan Policy Center, the FDA has indicated that each change must stay within the device’s intended use and indications for use, and maintain or improve safety and effectiveness.
Few devices use PCCPs so far. A JAMA Network Open research letter found that 43 of 794 AI-enabled devices authorised from 2023 to 2025 (5.4%) had authorised PCCPs, rising to 9.7% of devices authorised in the fourth quarter of 2025.
The broader document is the FDA’s draft guidance on lifecycle management and marketing submissions for AI-enabled device software functions. It is explicitly nonbinding, and sponsors can use an alternative approach that satisfies the statutes and regulations. It asks for a device description that states AI is used, describes the inputs and outputs, and lists compatible input devices and acquisition protocols. It says reliance on a single data collection site is generally not appropriate, and that at least three geographically diverse US clinical sites or health systems may be appropriate for clinical validation. It also notes that AI-enabled devices may need a higher proportion of US data in validation.
Several other requirements surround it. According to the Bipartisan Policy Center, the FDA’s 2025 guidance sets labelling expectations: a plain statement that the device uses AI, details of inputs and outputs, performance measures, known sources of bias, and, where a PCCP exists, how performance is monitored and updates happen. The FDA’s 2025 premarket cybersecurity guidance requires a Software Bill of Materials (SBOM). A new unique device identifier is required for each new version or model of a device subject to UDI requirements. The Quality Management System Regulation took effect on 2 February 2026 and incorporates ISO 13485:2016 by reference. The FDA’s 2021 AI/ML SaMD Action Plan committed the agency to PCCP guidance, good machine learning practice, transparency to users, better algorithm evaluation methods and real-world performance monitoring pilots.
Which pathway: 510(k), De Novo or PMA?
| Pathway | Applies to | Evidence it expects | Performance monitoring plan |
|---|---|---|---|
| 510(k) | Most Class I and II devices with a predicate | Substantial equivalence to an existing device, without independent prospective clinical trial data | Generally not required, unless it is a special control for the device type |
| De Novo | Novel devices with no predicate | An independent demonstration of safety and effectiveness | May be needed, and may become a special control for the device type |
| PMA | Class III, high-risk devices | Reasonable evidence that probable benefits outweigh probable risks, with a public SSED | May be a condition of approval |
The 510(k) pathway dominates. Lee et al. (JAMA Health Forum, 2025) describe nearly all AI-enabled devices as cleared through it. In the 692-device scoping review, 99.7% of devices were Class II and only two were Class III. An AI-enabled device can even be found substantially equivalent to a non-AI device with the same intended use, provided it raises no different questions of safety and effectiveness. Ongoing post-market monitoring requirements are more common for De Novo and PMA devices than for 510(k) devices.
Why is every model change a regulatory event for an AI medical device?
The rule is 21 CFR 807.81(a)(3): a new 510(k) is required when a device is changed in a way that could significantly affect its safety or effectiveness. Bug fixes, patches and tweaks all count as design changes under the quality system regulation, whatever they are called. The FDA expects manufacturers to make a risk-based assessment of each change, positive or negative. A change made to improve clinical outcomes is likely to need a new 510(k) precisely because it is intended to affect effectiveness. Even a complete rewrite of a core algorithm with the same performance claims may be significant enough to need one. Verification and validation are required whether or not a submission is needed.
A retrained CV model counts as a potential regulatory change. Unless an authorised PCCP covers that change, the default assumption should be that it needs a documented 807.81 assessment, and possibly a submission.
Locked models, adaptive models and the PCCP compromise
A Frontiers in Digital Health review describes the trade-off. Locked models offer clearer reproducibility and are easier for regulators to interpret, while adaptive models may cope better with dataset shift. A PCCP is a pragmatic compromise that allows limited change under validation expectations set in advance. Locking does not stop drift, though: even a locked model can diverge as populations and uses change. The draft lifecycle guidance names the causes, including data drift between development and deployment inputs, changes in patient populations and changes in disease patterns. For a concrete case, fine-tuning SAM for medical segmentation under FDA change control shows what a locked baseline and its change evidence look like for a foundation model.
Each model change, such as a retrained candidate, should be supported by performance testing on representative, independent data. A/B testing statistics for clinical CV models covers how to design that comparison so it holds up in review.
Post-market surveillance in practice
Under the draft guidance, a performance monitoring plan covers several things: how changes in model performance are detected and assessed; causes such as shifts in demographics or prevalence, shifts in input data and corruption in the data pipeline; monitoring in the deployment environment; and a plan for deploying corrective updates in good time. The Frontiers review adds that a practical plan specifies what is monitored, how often, in whom, and what happens when a signal crosses a predefined threshold. It also recommends intensified monitoring after meaningful updates or during phased canary deployments. Subgroup monitoring should be in the plan from the start, with a defined response such as recalibration, constrained retraining or rollback.
Monitoring that the FDA itself carries out is limited. The MAUDE adverse-event database suffers from underreporting and inconsistent data quality, and the agency has limited ways to track real-world performance and model drift. For a deployed CV device, the manufacturer should itself proactively monitor, identify and address performance changes.
How do FDA-authorised AI devices show they work across sites and populations, and what have reviews found?
The FDA expects validation data that represents the intended-use population. It lists subgroups for analysis: sex, age, race, ethnicity, disease variables, clinical site and acquisition equipment (down to camera brand), and recommends multiple data collection sites. The draft guidance gives a dermatology-shaped warning: a model can learn confounders such as a ruler that appears in clinical images of melanoma, and produce predictions that look accurate but rest on irrelevant features. Models can also over-learn features specific to a scanner or a site. The Frontiers review argues that external validation should cover technical and workflow variability, not only geographic separation.
Published audits find large gaps in public reporting:
- A scoping review of 692 devices (npj Digital Medicine, 2024) found that 46.1% of summaries gave detailed performance results, 62.8% gave no sample size, only 3.6% reported race or ethnicity, and only 9.0% contained a prospective post-market surveillance study.
- The PLOS Digital Health census of 1,357 devices found that 2.5% were linked to registered prospective trials and only 0.2% (three devices) had been evaluated on patient-centred outcomes such as mortality or readmissions. Of the registered trials, 73.5% enrolled fewer than 500 participants.
- An analysis of 950 devices by Lee et al., cited in that census, associated 6% with recall events, nearly half of them within a year of clearance. Lee et al. (JAMA Health Forum, 2025) examined whether a lack of reported clinical validation was associated with these recalls.
- Windecker et al. (JAMA Network Open, 2025) assessed generalisability-relevant features of all devices listed by 31 August 2024, including the design of clinical performance studies and subgroup reporting.
These figures come from public registries and may undercount validation studies that manufacturers ran but did not publish. What they do show is that the public evidence base is incomplete. In the 692-device review, most summaries gave no information on the race or ethnicity of intended subjects. Showing benefit rather than accuracy calls for outcome methods such as causal trees for treatment effects, because evaluation should extend to clinical benefit when outputs drive referral or treatment.
What do FDA warning letters about AI-enabled devices show?
A recent case is the warning letter the FDA issued to O.N. Diagnostics on 1 September 2026, after a March 2026 inspection, about its VirtuOst VFA software for vertebral fracture assessment. The FDA found three changes, each of which on its own required a new premarket notification under 21 CFR 807.81(a)(3)(i):
- A new machine learning model for vertebral landmarking. The FDA wrote that a model trained on different data, with a different architecture or a different objective, may perform differently across populations, imaging equipment and clinical settings.
- A move from a desktop application to a web-based architecture, which the company acknowledged had expanded its cyberattack surface.
- A platform migration that required re-verification of the entire codebase. The FDA noted it had not reviewed the device’s SBOM or the third-party components affected.
The FDA found the new model by reading the company’s software version control log and its 3.0.0 release notes. The letter also cited inadequate procedures for medical device reporting and corrective action.
This is one letter, so it shows how the FDA reasoned in one case, not a general rate of failures. The reading is also contested. Hyman Phelps’ FDA Law Blog argues that the letter conflates the need for validation with the need for a new 510(k), a standard that the FDA’s own software-change guidance does not set. A careful sponsor should still plan as if the broader reading applies, because the FDA is the one applying it. The practical lesson, as MDDI summarised it, is that the regulatory assessment of software updates belongs in the formal quality system and change process, not in an informal decision at release time.
What integration patterns connect CV inference to PACS, EHR and clinical workflow?
The integration is part of the device description. The draft guidance asks submissions to describe the expected clinical workflow, the use environment and how users interact with the device. That includes whether inputs arrive manually or automatically, and which input devices and acquisition protocols are compatible. Submissions should also show the user interface: what information reaches the user, when, and how it is presented.
Imaging devices usually take studies from PACS as DICOM objects and return results to the reading workflow, often as secondary-capture images or structured reports. Triage devices are a workflow pattern in their own right: the output is a notification that flags a study for prioritised review by a clinician. The Frontiers review says traceability should cover the software version, configuration, model lineage and deployment-environment dependencies. Pipeline corruption (missing values, duplicate records, data type mismatches) is a monitoring target, and the O.N. Diagnostics letter treated a change of hosting architecture as a regulated change. Institutions without PACS and EHR interoperability may face significant engineering costs to support monitoring.
We would treat the DICOM listener, preprocessing, inference service and results writer as one versioned, validated unit. The model alone is not the unit, because a change in any of them can change what the clinician sees. The production side of these pipelines is covered in AI computer vision in biomedical applications.
What is hard to rebuild when validation evidence is added just before submission?
Some of the evidence the FDA asks for has to be produced during development itself. Examples are sequestered test sets from independent sites, a record of exactly which model version was tested, subgroup labels collected at acquisition, and a monitoring plan tied to predefined tolerances. The Frontiers review makes the same point for developers: design with lifecycle governance in mind, including traceability, update documentation and monitoring. The FDA encourages early engagement through the Q-Submission Program when validation methods are novel. We do not have a sourced figure for how much time this saves, so we will not give one. The mechanism is that evidence a team cannot reconstruct has to be regenerated, and regenerating it means new data collection.
Who can build the validation evidence for an AI medical device?
TechnoLynx produces validation evidence as engineering outputs a regulatory owner can read and sign against. The scope is engineering. It is validation evidence, not regulatory clearance, policy advice or certification. TechnoLynx delivers this through its AI engineering for life sciences and healthcare work.
For teams shipping CV models, which changes count remains unsettled. The draft lifecycle guidance is still draft. PCCP uptake was below one device in ten in late 2025. Hyman Phelps argues a warning letter has read 807.81 more broadly than the FDA’s own guidance. Until that settles, the best protection is a version history the team could hand to an inspector today.
