Confidential Computing Makes AI Inference Usable For Sensitive UK Workflows

The Sovereign Cloud

14 July 2026 | By Ashley Marshall

The interesting shift is not that every sensitive AI workload is moving on premises. It is that confidential computing is making cloud inference easier to justify when the data matters.

The middle ground is finally practical

For UK teams working with sensitive data, the AI inference choice has often been framed too crudely. Either send prompts to a public SaaS model and hope the contracts, settings and controls are enough, or retreat into a fully private deployment that is expensive, slow to change and difficult to operate well. Confidential computing gives leaders a more useful third option. It does not make every risk vanish, but it can materially reduce the trust you have to place in the cloud operator, the platform administrator and the wider hosting environment when a model is processing live data.

The point is not that confidential computing is new. Trusted execution environments, secure enclaves and hardware rooted attestation have existed for years. What has changed is the fit with inference. Inference is narrower than training, easier to govern and closer to the business workflow. A support case, a claims note, a procurement file or a clinical administration summary may only need to pass through a model for seconds. If that processing happens inside an attested environment, with encryption for data in use and a clear record of what code was allowed to run, the risk conversation becomes more concrete.

This matters because UK organisations are not short of demand for AI. They are short of deployment patterns that survive legal, security and operational review. The NCSC cloud security guidance already frames cloud selection around matching controls to the data and service being protected. Confidential computing sits neatly in that logic. It is not a slogan about sovereignty. It is a deployable control that can support a sensible assurance case when the data is valuable, the workflow is repeatable and the organisation cannot justify a full private AI estate.

Why inference is the right starting point

Most data sensitive organisations should start the confidential computing discussion at inference rather than training. Training and fine tuning create broader governance questions: where the corpus came from, what personal data it contains, whether outputs can leak training examples and how model weights are controlled over time. Inference is still sensitive, but it is usually easier to define. A user submits a prompt. The system retrieves approved context. A model produces an answer. Logs, retention and access can be specified around a known business process.

Microsoft describes confidential AI as protecting data and models across the AI lifecycle, including while they are in use, using trusted execution environments and attestation. Its Confidential AI guidance gives examples such as fraud detection across banks and assisted diagnostics where data owners want the benefit of AI without exposing raw records to other parties. Those examples are useful because they are not abstract. They are exactly the kind of collaboration problem UK boards recognise: valuable data, constrained permissions, multiple parties and a need to prove what happened.

What this means in practice is that an organisation can identify a small number of high value inference workflows and apply stronger controls there first. A law firm might use confidential inference for matter summaries that include privileged client material. A manufacturer might use it for supplier risk analysis involving contract terms and pricing. A health or care organisation might start with administrative triage rather than diagnostic decision making. The control question becomes specific: can we prove the approved container image, model endpoint and policy were used for this workflow, and can we prevent administrators outside that boundary from reading the payload while it is processed?

That is a better procurement conversation than asking whether a service is simply safe or unsafe. It allows security, legal and operations teams to separate workloads. Low sensitivity AI can use standard managed services. Highly sensitive inference can sit behind confidential compute, stricter logging and tighter retention. Workloads that still cannot tolerate cloud processing can remain on premises. The result is not ideological purity. It is tiering.

UK governance already points in this direction

The UK regulatory and security position does not require organisations to avoid cloud AI altogether. It does require them to understand the processing, manage risks and keep appropriate controls in place. The ICO guidance on AI and data protection is clear that AI systems using personal data must be assessed across familiar data protection principles such as fairness, transparency, accuracy, security and accountability. It also highlights the need to think through automated decision making, bias mitigation and the AI lifecycle. Confidential computing helps with some of those duties, especially security and accountability, but it does not replace the work of defining lawful basis, minimising data or explaining outcomes.

The UK government has also moved from general AI concern to concrete security expectations. The AI Cyber Security Code of Practice sets out 13 principles across the AI lifecycle, including secure design, secure development, secure deployment, secure maintenance and secure end of life. It says the government intervened because AI supply chain stakeholders need clarity on baseline security requirements. That is important for confidential inference because the model host, cloud provider, application vendor and data controller may all be different parties.

The NCSC's Guidelines for Secure AI System Development add another practical anchor. They are aimed at providers of AI systems, including those built on tools and services supplied by others, and emphasise systems that function as intended, remain available and avoid revealing sensitive data to unauthorised parties. Confidential computing speaks directly to the last of those outcomes. It gives teams a technical way to restrict exposure during processing, and it gives assurance teams something testable: an attestation report, an enclave policy, a deployment boundary and a set of logs.

What this means in practice is that a confidential inference project should produce evidence, not just architecture diagrams. The DPIA should say why data is needed, what is stripped before inference and what is retained afterwards. The security review should record the chosen enclave or confidential VM pattern. The supplier assessment should state who can administer the service and who cannot inspect data in use. The operating procedure should define how attestation failures, model changes and emergency access are handled. That is the level at which this stops being a buzzword and starts becoming governance.

The technology has caught up with the workload

For years, the obvious objection to confidential computing was performance and practicality. Secure enclaves sounded useful, but AI workloads needed accelerators, memory bandwidth and a deployment model that ordinary platform teams could operate. That objection is weaker than it used to be. Microsoft says Azure confidential GPU VMs use AMD SEV-SNP and NVIDIA H100 Tensor Core GPUs, with a trusted execution environment spanning the CPU confidential VM and attached GPU. In plain English, that means the protected boundary can include the accelerator used for inference, not just a small CPU enclave beside it.

NVIDIA says Azure was the first cloud provider to offer confidential computing with NVIDIA H100 GPUs, and that Azure NCC H100 v5 VMs are designed for inference, fine tuning and training of small to medium sized models such as Whisper, Stable Diffusion variants and language models including Llama 2. Its September 2024 announcement also states that H100 GPUs keep data encrypted while it is being processed. The technical blog goes further, explaining that the H100 uses a hardware based trusted execution environment, an on die hardware root of trust and a cryptographically signed attestation report that users can check before proceeding.

Those details matter for UK buyers because they change what is feasible. Confidential inference no longer has to mean tiny workloads running in a specialist enclave with awkward integration. A team can now discuss confidential containers, confidential VMs, GPU backed inference, remote attestation, policy controlled deployment and normal cloud operations in the same meeting. That does not mean every vendor implementation is mature or every region has the capacity you want. It does mean the pattern is moving from research paper to procurement option.

The practical buying question is therefore specific. Can the service show the exact hardware, region, VM family, model serving stack and attestation process? Can it support your latency target? Can it integrate with identity, key management, logging and incident response? Can you decide whether prompts and outputs are retained, and can the vendor prove that administrator access is constrained? If those answers are missing, the word confidential is doing too much work. If they are present, the organisation has a credible middle path between unmanaged SaaS and building everything itself.

The counterargument is right, but incomplete

The strongest counterargument is that confidential computing can become security theatre if leaders treat it as a substitute for good AI governance. That warning is fair. A secure enclave will not tell you whether a prompt contains too much personal data. It will not make a hallucinated answer accurate. It will not solve bias, legal basis, model suitability, access management, user training or supplier lock in. It will not prove that your retrieval corpus is correct or that a generated recommendation should be used in a regulated decision. In some cases it may also add cost, operational complexity and vendor constraint.

That is why the right claim is modest. Confidential computing is not the whole AI control framework. It is a strong control for a particular risk: exposure of data and code while computation is happening. That risk is real. The Cyber Security Breaches Survey 2025 reported that 43 percent of UK businesses and 30 percent of charities identified a cyber breach or attack in the previous 12 months, equivalent to about 612,000 businesses and 61,000 charities. The same survey found only 14 percent of businesses reviewed risks posed by immediate suppliers, and only 7 percent looked at the wider supply chain. AI inference platforms are part of that supplier risk story.

The common misconception is that data sovereignty is mainly about geography. Location matters, especially for regulatory, contractual and political reasons, but geography alone does not answer who can access data, what administrators can see, what subprocessors are involved, how keys are controlled or whether the runtime can be verified. A UK region can still be poorly governed. A non UK service can still have strong technical controls but fail a particular policy requirement. Confidential computing helps shift the discussion from place to verifiable access and processing controls.

For boards, the implication is simple: do not buy confidential computing as a badge. Buy it as one layer in a defensible pattern. Pair it with data minimisation, approved use cases, red teaming where appropriate, retrieval controls, human review for consequential outputs, supplier due diligence and documented incident response. The teams that get value will be the ones that know which workflows justify the extra control and which do not.

How to decide where it belongs

A sensible confidential inference roadmap starts with classification, not technology selection. List the workflows where AI would create clear value but data sensitivity has slowed or blocked adoption. Then score each workflow against four questions. Does it process personal, privileged, commercially sensitive or regulated information? Is inference frequent enough that automation matters? Can the data be minimised before the model sees it? Would stronger proof about runtime isolation change the approval decision? If the answer to all four is yes, confidential computing deserves serious evaluation.

From there, build a small reference pattern. For example, an internal knowledge assistant for contract review might use UK hosted storage, a retrieval layer that filters documents by user permission, a confidential VM or confidential container for the inference service, customer managed keys, short log retention, attestation checks before requests are accepted and a review screen that keeps the human responsible for the final action. A health administration workflow might add stricter audit trails and a clearer separation between administrative support and clinical decision making. A financial services workflow might focus on fraud investigation, suspicious activity context or customer vulnerability notes, with stronger monitoring and retention controls.

Leaders should also decide what not to put in the enclave. Do not pass entire documents when extracted fields will do. Do not retain prompts because they might be useful one day. Do not use confidential inference to bypass a policy decision that says a particular category of data should not be processed by an external service at all. The control is most valuable when the surrounding workflow is disciplined.

The final test is operational. A proof of concept should measure latency, cost, failure modes, evidence quality and supportability. It should produce artefacts legal and security teams can inspect: DPIA notes, supplier answers, attestation evidence, architecture diagrams, access model, data retention settings and a rollback process. If that evidence makes the approval conversation faster and more specific, confidential computing is doing its job. If it only adds another box to a vendor slide, walk away.

Frequently Asked Questions

Is confidential computing the same as data sovereignty?

No. Data sovereignty is about jurisdiction, control, contractual terms and operational access. Confidential computing is a technical control that protects data in use inside a trusted execution environment and can support a sovereignty strategy.

Does confidential computing mean the cloud provider cannot see my prompts?

It can reduce exposure to cloud administrators and the hosting environment when correctly implemented, but you still need to check the exact service design, logging, key control, model endpoint and attestation process.

Is this only relevant for large language models?

No. It can apply to any AI inference workload where sensitive data is processed, including speech, vision, fraud detection, document extraction and specialist classification models.

Does it remove the need for a DPIA?

No. If personal data is involved and the processing is high risk, a DPIA may still be needed. Confidential computing can be part of the security and risk mitigation evidence inside that assessment.

Will confidential inference be slower or more expensive?

Sometimes. The right proof of concept should test latency, cost and operational complexity against the risk reduction. It is best used where the sensitivity of the workflow justifies the extra control.

Can this help with supplier risk?

Yes, if the supplier can provide evidence about runtime isolation, administrator access, subprocessors, key management and incident response. It does not replace supplier due diligence.

Should UK organisations require UK hosting as well?

Often yes, depending on the data, contract and policy position. But UK hosting alone is not enough. You still need to understand who can access data, how processing is controlled and what evidence is available.

Where should a business start?

Pick one sensitive but bounded inference workflow, minimise the data passed to the model, test a confidential deployment pattern and gather evidence that legal, security and operations teams can review.