--- title: "NHS AI Sovereignty Is Really a Version-Control Problem" slug: "uk-nhs-foreign-controlled-ai-hospitals-sovereignty-risk" author: "Jaione Amigot" date: "2026-09-15 09:00:00" category: "Premium" topics: "NHS AI, AI sovereignty, MHRA, AI as a medical device, clinical AI governance, self-hosted AI, version control" summary: "On 10 September 2026 the MHRA's National Commission warned that medical AI built on foundation models owned outside the UK creates a sovereignty risk, and recommended version control recorded in the patient record." banner: "" thumbnail: "" linkedin: | The UK's own advisory commission on AI in healthcare reported on 10 September 2026, and one paragraph deserves more attention than it got. It warns that a growing number of AI medical products depend on a small number of external foundation-model providers, and that this "creates a sovereignty risk when those models are owned outside the UK." The Commission's answer to the hardest question in the field — how do you approve a system that changes after you approve it — is a set of three mechanisms: change control plans defined by boundaries rather than prespecified changes, staged authorisations, and traceability. The third one is the interesting one. Recommendation 20 asks that AI-enabled devices carry version control recorded in the patient record, so a clinician can audit which version informed which outcome. That recommendation quietly settles an architecture question. You cannot record the version of a model you do not control. A hosted endpoint can change behaviour under the same name, without a design change and without notice — which is exactly what the MHRA observed in its own AI Airlock sandbox. → Sovereignty here is not mainly about where data sits. NHS England's own FDP terms already keep processing in the UK → It is about whether the thing you validated is the thing running today → Pinning a version, inspecting it, and re-validating it requires the ability to freeze it → That is a deployment property, not a contract clause With ibl.ai you own all the code and the data — self-hosted inside your own perimeter, model-agnostic across any LLM, usage-based with no per-seat pricing, deployable anywhere from your own cloud to a fully air-gapped network. #iblai #AgenticAI #EnterpriseAI #NHS #HealthcareAI #AIRegulation --- ## The Short Answer **On 10 September 2026 the MHRA's National Commission into the Regulation of AI in Healthcare warned that AI products built on a few external foundation models create "a sovereignty risk when those models are owned outside the UK," and recommended version control recorded in the patient record. You cannot pin a version you do not host. With ibl.ai you own all the code and the data, so the model in production is one you can freeze, inspect and re-validate.** The sovereignty question in NHS AI is usually argued as a data-residency question. The Commission's recommendations point somewhere more specific. ## What is actually deployed in NHS hospitals, and is it "foreign-controlled AI"? The concrete deployment is the NHS Federated Data Platform, and the popular description of it needs two corrections. A consortium led by Palantir Technologies UK Limited [was awarded the contract in November 2023](https://www.england.nhs.uk/digitaltechnology/nhs-federated-data-platform/security-privacy/contract-explainer/). NHS England describes it as running over a seven-year period, of which "only a three year term is committed, which can be extended by two years and then two further one year periods." As of the end of May 2026, [**139 NHS trusts are live** on the platform, 170 have signed up, and 35 integrated care boards are live](https://www.england.nhs.uk/digitaltechnology/nhs-federated-data-platform/impact/fdp-uptake-and-benefits/). The first correction concerns control of the data. NHS England's published terms state that "all data is stored, processed and accessed within the UK," that Palantir acts as a processor that "only processes NHS data as directed by an NHS user," and that it cannot use NHS data "to develop or derive new Supplier products (for example by training an AI model on NHS data)." Those are meaningful commitments, and a post that describes the FDP as a foreign company helping itself to NHS records is describing something the contract forbids. The second correction matters more. The FDP is data infrastructure, not a regulated clinical AI system. The question of what happens when an AI model informs a care decision is governed separately, by the MHRA, and that is where the harder problem sits. ## Which UK advisers warned about AI sovereignty in the NHS, and what did they actually say? Two bodies, saying different things, five months apart. In May 2026, Professor David Strain, chair of the BMA's board of science, [published a warning about NHS data sovereignty](https://www.bma.org.uk/news-and-opinion/blog-ai-private-platforms-and-the-risk-to-nhs-data-sovereignty) arguing that if the platforms that structure NHS data are controlled externally, the NHS "could gradually move from being the owner of one of the world's most valuable health datasets to being a data provider to platforms it does not control." The BMA is the doctors' professional association, not a government adviser. The government's own adviser said something sharper. The National Commission into the Regulation of AI in Healthcare was established by the MHRA in September 2025 as an independent advisory body, and [published 44 recommendations on 10 September 2026](https://www.gov.uk/government/publications/national-commission-into-the-regulation-of-ai-in-healthcare-recommendations-for-a-future-regulatory-framework) after consulting **more than 12,000 people**. Its warning is not about data residency at all. It is about model dependency: > "An additional consideration is that increasing numbers of AI products built on general-purpose foundation models may rely on a small number of external providers. This challenges resilience and creates a sovereignty risk when those models are owned outside the UK." The Commission's response is Recommendation 8: manufacturers should be expected to report a dependency on a general-purpose model, its risks and mitigations "including continuity plans," both at regulatory submission and at procurement. That is a different threat model from the one the UK procurement debate has been running. It is not that a supplier sees your data. It is that the thing your clinical service depends on is produced elsewhere and can move. ## How does a regulator approve an AI system that can change itself after approval? The Commission's report is candid that the existing framework does not. The report states that as more adaptive AI devices are developed, "it will become more difficult and impractical to identify and assure changes during the pre-market stage within the current framework." The existing mechanism is the Predetermined Change Control Plan, agreed with international partners, which lets a manufacturer and regulator pre-agree changes that can then be made after authorisation without a new submission. The Commission's finding is that PCCPs were designed for a different kind of software: manufacturers were expected "to fully describe and define specific, planned changes," which "does not clearly accommodate more adaptive technologies." So Recommendation 6 proposes inverting it — defining **boundaries and guardrails** for the allowable scope of change "rather than requiring specific, planned changes." Recommendation 14 adds staged authorisations, described in the government's announcement as ["L-plates" for learner drivers](https://www.gov.uk/government/news/independent-commission-led-by-nhs-doctors-sets-out-blueprint-to-accelerate-safe-ai-adoption-in-healthcare), where a device is deployed in a tightly controlled scope and expanded on evidence. The MHRA had already seen why this is necessary. Reporting on [AI Airlock Phase 2 on 9 June 2026](https://medregs.blog.gov.uk/2026/06/09/advancing-ai-regulation-in-healthcare-insights-from-ai-airlock-phase-2/) — seven technologies selected from 51 applicants in [its regulatory sandbox for AI as a medical device](https://www.gov.uk/government/collections/ai-airlock-the-regulatory-sandbox-for-aiamd) — the agency observed that "for generative AI and large language model-based systems, device behaviour can shift significantly without explicit design changes." ## Why is version control the part of NHS AI sovereignty that deployment architecture decides? Because of Recommendation 20, which is the least-quoted and most operationally demanding item in the report. It asks the MHRA to introduce mechanisms to identify AI-enabled devices once deployed, "including appropriate version control, to provide clear traceability throughout a device's lifecycle," with traceability information "including version, is routinely recorded as part of the patient record." The clinical purpose is auditability: when an outcome goes wrong, a provider should be able to identify which device, at which version, informed that pathway. Read that requirement next to the MHRA's own observation that LLM-based behaviour shifts without a design change, and a deployment constraint falls out of it that the Commission does not spell out. Recording a version is only meaningful if the version is stable and knowable. A model served from a vendor endpoint can be updated under an unchanged name, on the vendor's schedule, without a notice period a hospital controls — and no field in the patient record fixes that. Sovereignty, at this point in the argument, stops being about jurisdiction and becomes a property of where the weights run. This is the layer beneath the [IP-ownership gap in UK sovereign AI procurement](/blog/uk-sovereign-ai-procurement-ip-ownership): a contract can assign rights, but only a deployment can freeze a version. ## What should an NHS trust CIO require before an AI system touches a clinical pathway? Four things, each of which is a deployment property rather than a contractual assurance. - **A pinned model version**, held until the trust chooses to move, so the system validated in October is the system running in March. - **A re-validation path** that runs before a version change reaches patients, not after — the practical form of the Commission's boundary-based change control. - **Declared dependencies**, per Recommendation 8, including what the fallback is if an upstream provider changes terms, pricing or availability. - **Inspectable behaviour**: access to the code and configuration that sit between the clinician and the model, so guardrails can be read rather than taken on trust. A trust that cannot hold a version cannot satisfy the traceability the Commission is asking for, however good its governance paperwork is. The [broader governance frame for health systems](/blog/ai-governance-for-healthcare-systems) sets out where this sits alongside audit and residency obligations. ## How does ibl.ai let a health system pin and inspect the exact model in production? With ibl.ai you own all the code and the data. The platform runs inside the trust's own perimeter with full source code under a perpetual licence, so the model weights, the serving stack and the guardrail configuration are artefacts the institution holds rather than services it calls. A version stays where it is until the trust decides otherwise, which is what makes recorded version control truthful. It is model-agnostic across any LLM, so a dependency on a single external provider is a choice rather than an architecture. It is usage-based with no per-seat pricing, so cost tracks clinical workload instead of headcount. And it can deploy anywhere: private cloud, on-premise, or a fully air-gapped network, which is [the endpoint most HIPAA- and UK-regulated clinical estates converge on](/blog/air-gapped-clinical-ai-platform). 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY. *Related reading: [UK sovereign AI: real procurement, but the IP still leaves](/blog/uk-sovereign-ai-procurement-ip-ownership) — the contractual half of the same question; [air-gapped clinical AI platform](/blog/air-gapped-clinical-ai-platform) — what the network boundary does and does not buy a regulated health system; and [AI governance for healthcare systems](/blog/ai-governance-for-healthcare-systems) — the audit and residency obligations this sits inside.* *Sources: the sovereignty-risk passage, Recommendations 6, 8, 14 and 20, and the PCCP and adaptive-AI findings from the [National Commission's full report](https://assets.publishing.service.gov.uk/media/6aa2662962ec7fe7bedf52b9/Full_National_Commission_Report_-_Publication__1_.pdf) and its [publication page](https://www.gov.uk/government/publications/national-commission-into-the-regulation-of-ai-in-healthcare-recommendations-for-a-future-regulatory-framework); the 10 September 2026 date, the chair, the 12,000 consulted and the "L-plates" framing from [the GOV.UK announcement](https://www.gov.uk/government/news/independent-commission-led-by-nhs-doctors-sets-out-blueprint-to-accelerate-safe-ai-adoption-in-healthcare); the behaviour-shift observation and Phase 2 cohort from [the MHRA's AI Airlock Phase 2 blog](https://medregs.blog.gov.uk/2026/06/09/advancing-ai-regulation-in-healthcare-insights-from-ai-airlock-phase-2/) and [the AI Airlock collection](https://www.gov.uk/government/collections/ai-airlock-the-regulatory-sandbox-for-aiamd); the FDP supplier, term and data terms from [NHS England's contract explainer](https://www.england.nhs.uk/digitaltechnology/nhs-federated-data-platform/security-privacy/contract-explainer/) and the uptake figures from [NHS England's FDP uptake page](https://www.england.nhs.uk/digitaltechnology/nhs-federated-data-platform/impact/fdp-uptake-and-benefits/); the BMA position from [Professor David Strain's May 2026 blog](https://www.bma.org.uk/news-and-opinion/blog-ai-private-platforms-and-the-risk-to-nhs-data-sovereignty).* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.