ibl.ai Agentic AI Blog

Insights on building and deploying agentic AI systems. Our blog covers AI agent architectures, LLM infrastructure, MCP servers, enterprise deployment strategies, and real-world implementation guides. Whether you are a developer building AI agents, a CTO evaluating agentic platforms, or a technical leader driving AI adoption, you will find practical guidance here.

Topics We Cover

Featured Research and Reports

We analyze key research from leading institutions and labs including Google DeepMind, Anthropic, OpenAI, Meta AI, McKinsey, and the World Economic Forum. Our content includes detailed analysis of reports on AI agents, foundation models, and enterprise AI strategy.

For Technical Leaders

CTOs, engineering leads, and AI architects turn to our blog for guidance on agent orchestration, model evaluation, infrastructure planning, and building production-ready AI systems. We provide frameworks for responsible AI deployment that balance capability with safety and reliability.

Back to Blog

NHS AI Sovereignty Is Really a Version-Control Problem

Jaione AmigotSeptember 15, 2026
Premium

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.

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. 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.

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 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 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, 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 β€” seven technologies selected from 51 applicants in its regulatory sandbox for AI as a medical device β€” 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: 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 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.

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 β€” the contractual half of the same question; air-gapped clinical AI platform β€” what the network boundary does and does not buy a regulated health system; and 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 and its publication page; the 10 September 2026 date, the chair, the 12,000 consulted and the "L-plates" framing from the GOV.UK announcement; the behaviour-shift observation and Phase 2 cohort from the MHRA's AI Airlock Phase 2 blog and the AI Airlock collection; the FDP supplier, term and data terms from NHS England's contract explainer and the uptake figures from NHS England's FDP uptake page; the BMA position from Professor David Strain's May 2026 blog.

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.

Related Articles

Sovereign or Supervised: Government AI Architecture

In one week of August 2026 the EU moved to restrict foreign cloud providers from sensitive public-sector workloads, and researchers documented autonomous AI agents breaching 85 Taiwanese government accounts. Read together, the two events make the same argument: for a government agency, where AI runs is a security architecture decision rather than a procurement preference.

Mikel AmigotAugust 17, 2026

Self-Hosted AI Agents for Healthcare: PHI Never Leaves

Self-hosted AI agents for healthcare are autonomous clinical and administrative agents that run entirely inside your HIPAA-covered environment β€” reading from and writing to your EHR through connectors, with PHI never leaving the boundary. The agents, the architecture, the cost math, and why owning the stack is the defensible posture.

Mikel AmigotJune 8, 2026

Self-Hosted AI for Universities: FERPA-Safe by Design

Self-hosted AI for universities means the runtime executes inside infrastructure the campus controls β€” FERPA-protected student records never leave the institution boundary. The deployment options, the workloads, the cost math, and why this becomes the default endpoint for any serious campus AI program.

Mikel AmigotJune 8, 2026

Onyx (Danswer) Alternative Enterprise: Self-Hosted AI With Compliance + Support

Onyx (formerly Danswer) is the open-source self-hosted enterprise-search starting point. ibl.ai is the enterprise-grade alternative: same self-hosted thesis, but with compliance posture for regulated industries, enterprise support, 160+ pre-built agents, multi-LLM routing, and family-owned-NY long-term partnership.

Jaione AmigotJune 1, 2026

See the ibl.ai AI Operating System in Action

Discover how leading universities and organizations are transforming education with the ibl.ai AI Operating System. Explore real-world implementations from Harvard, MIT, Stanford, and users from 400+ institutions worldwide.

View Case Studies
Work with our team

Pilots, deployment, and full ownership

Most enterprise engagements are one-time, not subscriptions. You integrate ibl.ai with your own data, deploy it on your own infrastructure, and the engineering hours scale with the work β€” so the price tracks the scope, not your headcount.

Start here

Pilot

from $15K

fixed scope Β· fixed timeline

A time-boxed proof of value on your real data β€” not a slide deck.

Best for: Teams that want to see ibl.ai working before committing.

  • Deployed on your infrastructure or our cloud
  • 1–2 production agents wired to a slice of your data
  • One integration (LMS / SIS / SSO / data source)
  • Weekly working sessions with our engineers
  • Pilot fee credits toward a full engagement
Scope a pilot
Most common

Integration & Deployment

$25K – $80K

one-time Β· not a subscription

Full deployment integrated with your data and systems. Engineering hours scale with scope.

Best for: Organizations rolling ibl.ai out across a department, campus, or business unit.

  • Platform deployed in your VPC, on-prem, or air-gapped
  • Integrated with your data + identity (SSO / SAML)
  • Multiple custom agents built to your workflows
  • Engineering hours proportional to scope
  • You own the data Β· run any LLM you choose
Plan a deployment
Full ownership

Codebase Transfer + Custom AI Engineering

Six figures

perpetual license Β· you own the stack

We transfer the full source code. You own and self-host the entire platform β€” outright.

Best for: Government, defense, and enterprises that require perpetual ownership and sovereignty.

  • Complete source-code transfer + perpetual license
  • Dedicated AI engineering team on your roadmap
  • Custom agents, models, and integrations to spec
  • Air-gapped capable Β· zero vendor lock-in
  • Family-owned, New York–based long-term partner
Talk about ownership
You own the code and data Run any LLM β€” Claude, GPT, Gemini, Llama Family-owned & operated from New York, NY