Category: evidence-appraisals. Clinical-use disclaimer: this article is an evidence appraisal for procurement and governance review, not clinical guidance for patient care. FDA clearance or authorization is treated here as a regulatory fact, not as proof that the exact deployed system has been clinically validated in the setting where a hospital intends to use it.
The compact verdict is uncomfortable but not subtle: current peer-reviewed evidence does not adequately support broad clinical deployment claims for on-device AI medical devices when those claims rest mainly on FDA status, general model performance, or vendor assurances about local execution. On-device design can be operationally attractive. Lower latency, offline function, and reduced cloud dependence are real engineering advantages. They do not answer the validation question.
The strongest evidence base for this appraisal does not isolate on-device systems. That is part of the problem. Three large peer-reviewed studies examined 2,163 unique FDA-authorized or approved AI medical devices across pre-market validation, recalls, and public reporting transparency. In a Nature Medicine analysis of 521 FDA-authorized AI devices, 43% lacked published clinical validation data at the time of market authorization, only 22 devices, or 4%, had been tested through randomized controlled trials, and some devices relied on computer-generated images rather than real patient data [1].
That is the first distinction procurement teams need to preserve. A device can be FDA-authorized and still lack published clinical validation data at authorization. A model can run locally and still be untested as the exact locked model that clinicians will use. A vendor can say “validated” and mean technical verification, retrospective testing, internal benchmarking, or something much closer to clinical evidence. Those meanings cannot be allowed to collapse into one reassuring sentence.
The FDA Label Does Not Carry the Whole Clinical Burden
The Nature Medicine findings are load-bearing because they address the point at which many hospital reviews begin: market authorization. The study does not say that 43% of AI devices are unsafe. It says 43% lacked published clinical validation data at the time they were authorized. That narrower finding is already enough to change the procurement conversation, because many clinical users assume authorization implies visible evidence in human data.
The randomized-trial figure is even more clarifying. Only 22 of 521 devices had been tested through RCTs [1]. RCTs are not the only acceptable validation design for every AI medical device, and demanding one for every incremental imaging tool would be a blunt policy. But the scarcity matters because it shows how often deployment decisions must be made from thinner evidence: retrospective datasets, internal studies, limited external testing, or documentation that is not published in a form independent reviewers can inspect.
For on-device AI, this evidence cannot be read as an on-device-only statistic. The FDA public materials used in these studies do not provide a deployment-architecture tag that cleanly separates edge, embedded, mobile, workstation, and cloud systems. If a health system cannot stratify validation evidence by deployment architecture, it cannot easily tell whether the evidence presented for a cloud-hosted or larger reference model applies to the compressed model locked inside a local device.
The Recall Evidence Makes the Gap Safety-Relevant
A validation gap is not automatically a patient-safety event. The recall literature is useful because it moves the discussion closer to consequences. In a JAMA Health Forum study of 950 AI medical devices through November 2024, 60 devices, or 6.3%, were associated with 182 recall events. Of those recalls, 43% occurred within one year of authorization, and diagnostic or measurement errors accounted for 109 recalls, or 60% [2].
The same study found that devices lacking prospective or retrospective clinical validation had more recalls per device [2]. That finding should be handled precisely. It does not prove that inadequate validation caused each recall. It does show that weaker clinical validation and recall burden are associated in a direction no governance committee should find reassuring.
The company-level pattern also matters for purchasers. Publicly traded companies accounted for 53% of devices but more than 90% of recall events and 98.7% of recalled units in the study [2]. This does not mean large vendors are worse by default; larger distribution can expose more units when problems occur. It does mean that institutional risk is not confined to obscure startups. A familiar name and a polished integration plan do not substitute for evidence about the model, the population, the workflow, and the post-market controls.
Transparency Is Too Thin for Independent Risk Assessment
The third large study explains why hospital review so often becomes document archaeology. In an npj Digital Medicine analysis of 692 FDA approvals, only 46.1% provided detailed performance study results, and only 1.9% linked to a published scientific validation study [3]. The missing fields were not cosmetic. Only 3.6% reported race or ethnicity of testing populations, 81.6% provided no age data, 99.1% provided no socioeconomic data, and only 9.0% included a prospective post-market surveillance plan [3].
Those omissions land directly on the desk of the local reviewer. If age distributions are absent, a pediatric hospital, a geriatric service line, or a safety-net system cannot assess whether the testing population resembles its patients. If race, ethnicity, and socioeconomic data are missing, fairness assessment is reduced to general assurances. If a post-market surveillance plan is absent or vague, the hospital inherits the task of discovering performance degradation after the tool has already entered workflow.
This is where on-device deployment starts to matter more than its marketing suggests. A local model may reduce network dependency. It may keep inference closer to the source device. But if its operating characteristics are poorly reported, and if the post-market plan does not explain how local performance will be observed, the architecture can make weak transparency harder to live with rather than easier.
Compression Is Not Just an Implementation Detail
On-device AI usually has to live inside tighter constraints than a cloud model: memory, compute, battery, heat, storage, and update pathways. The usual engineering responses are familiar: quantization, pruning, knowledge distillation, low-rank factorization, and related compression techniques. A 2025 ACM Computing Surveys review describes the accuracy-parameter trade-offs introduced by these methods [4].
That point should change the validation unit. The clinically relevant object is not the impressive parent model in a slide deck. It is the exact model artifact deployed on the device, after compression, thresholding, calibration, software wrapping, local hardware constraints, and workflow integration. If the vendor validated a larger model, a cloud model, or a development build, the evidence may be informative, but it is not equivalent by default.
Compression can affect different error modes unevenly. A small average accuracy loss can be clinically tolerable in one use case and unacceptable in another if the lost performance concentrates in rare findings, poor-quality acquisitions, comorbid presentations, or patients underrepresented in development data. The public evidence base rarely gives purchasers enough detail to inspect those trade-offs at the level where clinical risk is actually borne.
The Best Direct On-Device Signal Raises the Bar, Not Lowers It
The most direct on-device benchmarking evidence cited here is not yet peer-reviewed, so it should be used as a signal rather than as settled evidence. In a 2026 arXiv preprint, Munim et al. reported that fine-tuned on-device LLMs using Qwen3.5-35B reached 87.9% diagnostic accuracy compared with 89.4% for cloud GPT-5.1, but only for models with at least 31 billion parameters; smaller models below that threshold produced off-topic or hallucinated errors [5].
The procurement lesson is not that on-device models are almost as good as cloud models. It is that parity, when observed, depends on model size, fine-tuning, task, benchmark, and deployment conditions. A vendor offering a smaller model, a different specialty, a different patient population, or a different compression approach has not inherited that result. They have inherited the obligation to show their own evidence.
This is also why “runs locally” is a weak clinical assurance. Local execution can improve availability in a disconnected environment and reduce reliance on a remote service. It does not verify that the model generalizes across scanners, acquisition protocols, technician technique, lighting conditions, device firmware, local prevalence, or patient mix.
Locked Local Models Can Be Harder to Watch
A locked algorithm is sometimes presented as a safety virtue: the model is not continuously changing, so the validated version remains stable. Stability helps only if the validated version was the deployed version and if someone can tell when the operating environment has drifted away from the validation environment.
The post-market evidence gap is therefore not an administrative afterthought. In the transparency study, only 9.0% of approvals included a prospective post-market surveillance plan [3]. For on-device tools, missing surveillance planning can be more consequential because local inference may generate fewer centralized telemetry signals than cloud services, updates may depend on device access or maintenance cycles, and performance monitoring may have to be deliberately engineered into the hospital workflow.
Generalization uncertainty is broader than demographic representativeness alone. A Paragon Health Institute analysis argues for Digital Similarity Analysis as a voluntary patient-specific safety tool and notes that equipment variation and technician technique can affect locked on-device model performance [6]. Direct post-market evidence of drift in locked on-device clinical AI remains sparse, so this should be treated as a credible risk mechanism rather than a quantified failure rate.
What the Evidence Can and Cannot Support
| Claim under review | What current evidence supports | Evidence judgment |
|---|---|---|
| FDA-authorized AI devices are clinically validated before market entry | A large peer-reviewed analysis found that 43% of 521 FDA-authorized AI devices lacked published clinical validation data at authorization, and only 4% had RCT evidence [1]. | Not supported as a broad claim |
| Weak validation is only a paperwork issue | A recall study found 182 recall events among 60 of 950 AI devices, with diagnostic or measurement errors accounting for 60% of recalls; devices lacking prospective or retrospective validation had more recalls per device [2]. | Safety-relevant concern |
| Public FDA materials let hospitals independently judge subgroup and monitoring risk | Reporting was frequently incomplete: 3.6% reported race or ethnicity, 81.6% provided no age data, 99.1% provided no socioeconomic data, and 9.0% included a prospective post-market surveillance plan [3]. | Insufficient transparency |
| A compressed on-device model can rely on validation of its larger ancestor | Compression methods introduce accuracy-parameter trade-offs that can change deployed-model behavior [4]. | Exact deployed model requires validation |
| On-device models can be assumed equivalent to cloud models | A preprint found near-parity only under specific model-size and fine-tuning conditions, while smaller models produced off-topic or hallucinated errors [5]. | Possible in specific cases, not generalizable |
| Post-market monitoring is less important for locked local algorithms | Public evidence shows sparse prospective surveillance planning, and equipment variation and technician technique may affect locked on-device performance [3][6]. | Monitoring remains necessary |
The inference boundary is important. The 43% validation-gap figure is not an on-device-only statistic. The recall findings are not an on-device-only recall rate. The FDA public lists do not provide a clean deployment-architecture tag that would let reviewers count edge and cloud devices separately inside these datasets. Any claim of a precise on-device validation-gap rate from these studies would overread them.
But that boundary does not rescue the deployment claim. It sharpens the procurement problem. If the regulatory and public evidence infrastructure cannot distinguish cloud from on-device deployment, and if compression can change model behavior, then the burden moves back to the vendor and the local governance process: show evidence for the exact locked on-device model, not for the product family, the cloud version, or the pre-compression model.
Evidence Verdict
| Domain | Verdict for on-device AI clinical deployment claims |
|---|---|
| Study design | Weak for broad claims when evidence is retrospective, unpublished, internally generated, or based on non-human or computer-generated data rather than prospective clinical testing. |
| External and prospective validation | Insufficiently visible across FDA-authorized AI devices; especially important when the deployed model differs from a larger or cloud-based ancestor. |
| Transparency | Often inadequate for independent institutional review, particularly for subgroup characteristics, study details, and linkage to published validation. |
| Post-market surveillance | A major gap. Local deployment does not remove the need to detect drift, workflow mismatch, device-environment changes, and subgroup performance problems. |
| On-device model-change risk | Material. Quantization, pruning, distillation, and related techniques can alter performance, so validation should attach to the exact compressed model running on the device. |
| Operational convenience | Real but secondary. Lower latency, offline availability, and reduced cloud dependence may justify interest, not clinical reliance without evidence. |
| Cloud-versus-local tradeoff | Architecture affects monitoring, updating, telemetry, and failure detection. It should be part of risk assessment, not treated as proof of safety. |
The current evidence base does not adequately support broad clinical deployment claims for on-device AI medical devices, especially when those claims rely on FDA clearance, compressed-model equivalence, or vague post-market monitoring assurances. The governance question to leave on the agenda is direct: before deployment, can the vendor show peer-reviewed validation of the exact locked on-device model, in the intended clinical setting, with a credible plan for monitoring performance after installation?
References
- Chouffani El Fassi et al., Nature Medicine, 2024
- Lee et al., JAMA Health Forum, 2025
- Muralidharan et al., npj Digital Medicine, 2024
- Wang et al., ACM Computing Surveys, 2025
- Munim et al., arXiv, 2026
- Generalization Uncertainty in AI-Enabled Medical Devices: A Safer Way Forward, Paragon Health Institute, 2026