Why local-first clinical AI
Local-first clinical AI addresses unreliable connectivity, limited computing resources and the need to keep health data under local control. The research below motivates experiments with locally hosted open models, deployment-specific clinical context and independent evaluation. Findings are qualified by their study setting; local hosting and clinical reliability need verification for each deployment.
Sources, exact figures, and confidence notes are collected in the project's research file: Background & evidence (research).
Where most primary care actually happens
The setting, not the algorithm, is what makes this hard.
- Power. Close to 1 billion people in low- and lower-middle-income countries are served by health facilities with unreliable electricity or none at all; in sub-Saharan Africa only about 40% of facilities have reliable electricity (WHO, 2023).
- Connectivity. 78% of people in low-income countries are offline, and in rural areas only about 1 in 6 use the internet (ITU, Facts and Figures 2024). An always-online, cloud-only design cannot reach them.
- People. WHO projects a shortfall of roughly 11 million health workers by 2030, concentrated in low- and lower-middle-income countries (WHO health workforce). (The exact figure has moved across WHO documents; treat it as an order of magnitude.)
- The consensus fix. A 2026 scoping review of clinical-AI deployment in these settings found fragile infrastructure, hardware limits, and fragmented records to be the dominant barriers, and recommended offline-capable AI with local data caching (Al-Ganad et al., Frontiers in Digital Health, 2026).
Why high-income-trained AI underperforms here
- WHO's own guidance warns that AI "systems trained primarily on data collected from individuals in high-income countries may not perform well for individuals in low- and middle-income settings" (WHO, Ethics and governance of AI for health, 2021).
- That is borne out in practice: a 2025 review reports LLMs make up to three times more errors on information about low-income countries, and accuracy can fall sharply in lower-resourced languages — while over 87% of healthcare-LLM research is led by high-income-country institutions (Chen et al., Lancet Regional Health – Western Pacific, 2025). (Some underlying figures are single-source within that review.)
The AI is least reliable exactly where it is needed most — which is the case for contextualizing it to each deployment rather than shipping one global model.
Why patient data should stay local
- WHO cautions that data disclosed to a model provider "can usually not be retrieved as future iterations of the model may be trained on this data" (WHO, Guidance on large multi-modal models, 2024).
- A review of 464 healthcare-LLM studies found six distinct privacy risks from external/cloud models, that 38% reported no patient-data protection at all, and recommended that "priority should be given to deploying the LLM locally" (Zhong et al., JMIR, 2025).
- The governance literature points the same way: the Health Data Governance Principles call for keeping data "close to their point of generation," and at WHO's 2026 digital-health debate, low- and middle-income countries argued health data should be "a national asset under local control" (Health Data Governance Principles; Health Policy Watch, 2026).
Local processing supports this guidance, but privacy is deployment-specific. Review configured providers, evaluation services and publication/redaction before sharing evidence.
Why small, right-sized open models — with a strong judge
- Small can run offline. A 3.8-billion-parameter open model runs fully offline on a phone at roughly the quality of a previous-generation cloud model (Microsoft Research, Phi-3 technical report, 2024).
- Open is closing the gap. On 1,933 real radiology cases, the leading closed model scored 79.6% and the best open model 73.2% — the authors concluded "open-source LLMs are quickly closing the gap to proprietary LLMs" (Kim et al., npj Digital Medicine, 2025). Open medical models such as MedGemma are explicitly built to run locally or offline (Sellergren et al., 2025; its top score uses extra test-time computation).
- Right-size the model to the job. Matching model size to task difficulty — small models for routine work, escalating only when needed — captures most of the quality at a fraction of the cost (survey: Moslem & Kelleher, 2026; direction is robust, exact savings are setup-dependent).
- But a small model can't check itself. In a 2026 study, AI self-verification wrongly accepted incorrect medical answers more than 60% of the time, and smaller models were no better — the authors warn it "cannot serve as a universal safety layer" (Jin et al., 2026, a recent preprint). This supports evaluating answers against independent evidence and human review, with separately configured model evaluators where appropriate.
This motivates experiments with right-sized open models, record-grounded answers and independent review. It does not establish correctness or safety for a particular model team.
Why guideline-concordant and testable
WHO's SMART Guidelines exist to turn paper recommendations into a standards-based, computable form so digital systems deliver guideline-concordant care faithfully and faster — organized as a ladder of knowledge layers from L1 narrative through machine-readable and executable forms (WHO SMART Guidelines; WHO, 2021). The first such guidelines covered antenatal care, family planning, STIs, and HIV — HIV being one concrete example of a computable WHO guideline, not the limit of what a validation harness covers.
Software that delivers clinical guidance should be standards-based, verifiable, and testable. Harness experiments can evaluate claim support against captured source evidence using the selected adapter, scenarios and evaluation methods. WHO's AI guidance reinforces the bar, warning that large models carry "documented risks of producing false, inaccurate, biased, or incomplete statements" and can encourage "automation bias" where errors go unnoticed (WHO, 2024).
The through-line
| The reality | The project's answer |
|---|---|
| Care runs offline, on modest hardware | Configurable locally hosted open models; disconnected operation depends on the selected services and hardware |
| High-income-trained AI underperforms for these patients | Application-supplied clinical context and evaluation on the intended records, terminology and population |
| Sending data to clouds is a privacy and sovereignty risk | Prefer local processing; verify configured providers and disclosure boundaries |
| Models hallucinate; small models can't self-verify | Evaluate claim support against recorded evidence with independent review |
| Clinical software should be guideline-concordant and testable | Configured experiments that capture responses, available evidence and review findings |
The research supports local processing, context appropriate to the deployment, and independent evaluation against recorded evidence as priorities for clinical AI experiments.