NHS £10bn AI rollout forces every trust to answer where patient data sits
DCB0160 puts the liability on the deploying trust, and only on premise deployment answers where the record actually processes.
DCB0129 and DCB0160 make the trust, not the vendor, accountable for where identifiable records go. When triage or ambient scribe workloads run in a US frontier vendor's cloud, that record has left the NHS boundary. On premise SIOS runs those same workloads inside the trust firewall with every action signed and offline verifiable.
What NHS England actually announced on 4 July 2026
On 4 July 2026 NHS England confirmed £10bn over three years for technology, digital and data systems, with AI triage in the NHS App, ambient voice technology in clinical consultations and Microsoft Copilot on the desks of more than 500,000 NHS staff as the headline programmes. The AI triage rollout begins with 200,000 patients within 12 months and extends to every NHS App user by April 2028.
The announcement is not the compliance question. The compliance question is where identifiable patient data actually processes when a clinician dictates an ambient scribe note, when a citizen taps triage, or when Copilot summarises a case file inside a trust's Microsoft 365 tenant.
Why DCB0129 and DCB0160 do not go away
DCB0129 places clinical risk management on the manufacturer of any health IT system. DCB0160 places clinical risk management on the organisation that deploys and operates it. Both are information standards published under section 250 of the Health and Social Care Act 2012, and compliance is mandatory for NHS bodies. Each requires a written clinical safety case, a hazard log and a named Clinical Safety Officer signing off deployment.
On 29 June 2026 NHS England opened a public consultation on both standards, running until 11 September 2026, to bring in AI specific expectations around model behaviour, drift and interpretability. The consultation does not weaken the existing standards. It sharpens them. A trust that switches on AI without a valid DCB0160 safety case is not compliant on the day the rollout goes live, whatever the vendor's marketing says.
The question your ICB will be asked
Every acute trust and every Integrated Care Board buying into the £10bn programme has one procurement question a Caldicott Guardian and a Data Protection Officer cannot dodge. Where does an identifiable patient record physically process during triage inference, and where do the transcripts of an ambient scribe conversation actually land.
If the answer is a US frontier vendor endpoint, the trust has crossed an NHS boundary without a documented lawful basis for that transfer. The Data Protection Impact Assessment cannot say the vendor is certified and stop there. A UK international data transfer risk assessment is required in every case, and it has to survive a subject access request from a named patient five years after the visit.
What on premise deployment actually changes
The alternative is not a rejection of AI. It is a rejection of the extraction step. When triage, ambient scribe and admin workloads run on hardware the trust owns, on premise or in a physically air gapped ward server, no record leaves the boundary at any point in the pipeline. The inference happens where the record already lives, and no telemetry containing patient content ever leaves.
The Open Audit Record built into SIOS signs every consequential action the system takes, from a triage inference to an ambient scribe transcript, into a post-quantum tamper-evident ledger. A Caldicott Guardian, an ICO inspector or a coroner's officer can verify that ledger offline, in a browser, with no network and no trust in the vendor. That is what the DCB0160 safety case has always asked for and rarely been given.
| DCB0160 requirement | On premise SIOS deployment property |
|---|---|
| Clinical safety case with a named Clinical Safety Officer | Deterministic model versions pinned to signed hashes so the case survives review |
| Hazard log covering all reasonably foreseeable clinical risks | Every model call and clinician correction signed into the Open Audit Record |
| Post market surveillance of the deployed system | Local telemetry replayable against the ledger without vendor access |
| Written incident procedure with named routes and rollback | Rollback to a previous signed model version in one operator action |
What ten years of NHS procurement teaches us
NHS trusts have been asked to trust vendor claims about data residency before. The record is not good. UK cloud regions have proved to be logically UK tagged but physically routed through global infrastructure, with support engineers in jurisdictions outside the Schrems II perimeter and subprocessor lists that change on the vendor's schedule, not the trust's.
A trust that wants to defend its DCB0160 safety case in five years cannot depend on those claims. It needs a deployment where the boundary is physical, the audit is cryptographic and the escape hatch is a plug the estates team can pull. Anything softer than that is a hostage to whatever the next commercial dispute or geopolitical event does to the vendor's cloud region.
How we build for this
MICKAI runs as a Sovereign Intelligence Operating System on hardware the trust owns. Triage, ambient scribe and clinical admin workloads run in dedicated studios inside that boundary. 63 studios sit on one operating system, 10 production ready at launch and 53 in development. Every one of them writes to the same Open Audit Record.
For a trust reading this in the middle of a summer procurement cycle, the practical answer is to name the boundary in the tender and to make offline audit a scored requirement. Anything less puts the DCB0160 signature at personal risk of the clinical safety officer who signs it.
Does DCB0160 apply to a US vendor's SaaS product used by an NHS trust?
Yes. DCB0160 sits on the deploying organisation regardless of where the software runs. If the trust cannot produce a valid safety case for the deployed system, the trust is out of compliance whatever the vendor promises in its own paperwork.
What does no data egress mean in an NHS deployment?
It means no patient identifiable data, no derived embeddings and no telemetry containing patient content leaves the trust firewall at any point in the pipeline. That includes model calls, logs, error reports and update checks. The deployment is auditable to that standard by an offline replay against the signed ledger.
Can ambient voice technology be deployed on premise without losing quality?
Yes. Modern speech models fit inside a single air cooled workstation and produce clinical grade transcripts against domain vocabulary. The trade off is not quality. It is capital versus operating cost, and the DCB0160 exposure that a cloud endpoint carries over the life of the deployment.
How does the Open Audit Record help a Caldicott Guardian?
The Open Audit Record signs every consequential action into a post-quantum tamper-evident ledger. A Caldicott Guardian can verify the ledger offline in a browser, with no network and no trust in the vendor, which means a subject access request can be answered end to end from the trust's own systems.
How can an NHS trust deploy AI triage and ambient scribe without breaching DCB0129 and DCB0160?
The trust must be able to write a DCB0160 safety case that names where identifiable data processes, and that safety case has to survive an ICO or Caldicott review five years later. The only architecture that answers that cleanly is on premise, with signed audit and offline verification, on hardware the trust owns.
What is MICKAI?
MICKAI is a Sovereign Intelligence Operating System built in Britain that runs on hardware the customer owns, on premise and air gapped, with no data egress. Every consequential action is signed into the Open Audit Record, a post-quantum tamper-evident ledger any outside party can verify offline. 63 studios sit on the operating system, 10 production ready at launch and 53 in development, backed by 104 filed UK patent applications across 2,340 claims.