Why Confidential Computing Is the Missing Middle Ground Between Cloud AI and On-Prem AI

The Sovereign Cloud

20 April 2026 | By Ashley Marshall

Most UK organisations think they have two choices for AI: hand their data to a hyperscaler and hope for the best, or spend seven figures building on-premises infrastructure they cannot afford to staff. Confidential computing breaks that binary - and it is now production-ready.

The False Binary That Is Holding UK Businesses Back

Ask most UK IT directors or Chief Information Security Officers about deploying AI on sensitive data, and you will hear a variation of the same dilemma. The public cloud is fast, scalable, and packed with AI tooling - but it means sending patient records, financial data, or proprietary business information through infrastructure owned and operated by American hyperscalers, subject to US law, and technically accessible to cloud provider employees. On-premises feels safer, but building out the GPU capacity required for serious AI workloads costs millions in capital expenditure, requires specialist staff that are genuinely hard to hire, and locks you into hardware that will be obsolete within three to four years.

For regulated industries - NHS trusts, financial services firms, legal practices, defence contractors - this feels less like a business decision and more like a compliance trap. UK GDPR requires organisations to ensure appropriate technical safeguards for personal data. The FCA expects firms to maintain data residency controls. The Cabinet Office's Cloud First policy pushes towards public cloud adoption. These mandates are not always pointing in the same direction.

What most of those conversations are missing is a third option that has quietly moved from research project to production reality over the past two years. Confidential computing does not ask you to choose between cloud economics and data control. It offers both at once - by encrypting data not just at rest and in transit (which most organisations already do), but during the actual computation itself. Your data is never exposed in plain text to the cloud provider's infrastructure, the hypervisor, or any privileged operator - including the cloud vendor's own staff.

The numbers suggest this is not a niche concern. A 2025 survey by IDC Research of 600 IT leaders found that 75% are already adopting confidential computing in some form - with 18% in full production deployment and 57% actively testing it. That is a technology crossing the chasm from early adopter to mainstream in real time. Gartner has gone further, naming confidential computing in its Top 10 Strategic Technology Trends for 2026 and predicting that 75% of workloads running in untrusted infrastructure will be secured by it by 2029. For UK businesses still treating this as a future consideration, the ground has already shifted.

The practical question is not whether to take confidential computing seriously - it is how quickly to assess where it fits in your AI architecture, and which workloads to start with.

How Confidential Computing Actually Works

The core concept is straightforward even if the underlying engineering is not. Conventional security controls protect data at rest (full disk encryption, database encryption) and data in transit (TLS, VPNs). What they cannot protect is data in use - the moment when data must be decrypted to be processed. That window of exposure is where a compromised hypervisor, a rogue cloud operator, a malicious process with elevated privileges, or a sophisticated attacker with physical access to memory could theoretically read your data in plain text.

Confidential computing closes that window by creating a Trusted Execution Environment (TEE) - a hardware-enforced, cryptographically isolated region within the processor itself. Code and data loaded into a TEE are encrypted by the CPU before they reach system memory. The cloud provider's hypervisor, the host operating system, and every other process on the physical server are excluded from that encrypted region by hardware, not just by software policy. A policy can be changed or circumvented. Hardware-enforced memory encryption is significantly harder to defeat.

The two dominant implementations in production cloud environments today are AMD Secure Encrypted Virtualisation with Secure Nested Paging (AMD SEV-SNP) and Intel Trust Domain Extensions (Intel TDX). Both were developed and commercially deployed between 2022 and 2023. A technical report published by Cyberus Technology in early 2026, drawing on interviews with professionals from more than 20 partner organisations, describes how both technologies allow standard virtual machines to run inside hardware-enforced encrypted memory regions - crucially, without requiring modifications to application code. This lift-and-shift compatibility is significant: it means organisations can move existing AI workloads into confidential compute environments without rewriting their applications.

The attestation mechanism is equally important and often overlooked. Each TEE generates a cryptographic proof - a unique signature that verifies the workload is running inside a genuine, unmodified confidential environment on real hardware. This remote attestation capability means that before any sensitive data is sent to a cloud workload, the system can verify cryptographically that the receiving environment is actually what it claims to be. It is hardware-rooted trust, not contractual trust.

For AI specifically, the most significant recent development is NVIDIA's Blackwell GPU architecture, which became the first GPU in the industry to support TEE-I/O - meaning the entire pipeline from CPU to GPU can be protected within a single confidential environment. NVIDIA states that Blackwell Confidential Computing delivers near-identical throughput performance compared to unencrypted modes, removing the performance penalty that was previously a significant objection. Organisations can now run large language model inference and training on public cloud GPUs with the same cryptographic data protections previously only possible with on-premises hardware.

The UK Regulatory Context That Makes This Urgent

Data sovereignty is not an abstract concern for UK organisations in 2026. It is a live compliance question with real enforcement risk attached. The combination of UK GDPR, sector-specific regulation, and geopolitical uncertainty around US cloud providers has created genuine pressure on how organisations approach AI deployment decisions.

The UK GDPR retains the core requirements of the EU regulation: data must be processed with appropriate technical safeguards, transfers to third countries must meet adequacy or transfer mechanism requirements, and organisations must be able to demonstrate - not just assert - that these safeguards exist. For AI workloads that process personal data, the question of whether that data is ever decrypted inside a cloud provider's infrastructure is a legitimate legal question, not just a technical one. The UK-US data bridge provides a framework for transfers, but it does not remove the need for technical controls around data exposure during processing.

The NIS2 Directive, being transposed into UK law through the Cyber Security and Resilience Bill, introduces stricter security requirements for operators of essential services and digital infrastructure providers. NHS trusts, energy companies, financial market infrastructure providers, and public sector bodies processing critical data will face more prescriptive obligations around securing sensitive workloads. Confidential computing is increasingly referenced in regulatory and standards guidance as a mechanism for meeting those obligations.

Gartner's February 2026 forecast is striking in this context: sovereign cloud IaaS spending will shift 20% of current workloads from global to local or sovereign cloud providers this year, with government as the primary driver. Afshin Attari, Senior Director of Public Sector at Exponential-e, writing in Open Access Government in April 2026, notes that the NHS is under pressure to connect disparate datasets for integrated care and AI-enabled decision making - but data sovereignty requirements are creating real friction in how that can be done. Confidential computing offers a path that does not require choosing between clinical AI capability and data governance compliance.

For financial services firms regulated by the FCA, the situation is similar. Banks and insurers processing customer financial data through AI models need to be able to demonstrate that sensitive data is not accessible to the cloud provider's staff or systems. The FCA's operational resilience framework and its expectations around third-party risk management create a compliance environment where the technical architecture of AI workloads matters - not just the contractual terms with cloud vendors. Confidential computing provides technical, auditable, hardware-rooted assurance that contractual controls alone cannot replicate.

What This Means in Practice: Real Scenarios for UK Organisations

The theory is compelling. The practical application is where most UK technology leaders need help translating it. Here are three scenarios that illustrate where confidential computing genuinely changes what is possible.

NHS and healthcare AI: An NHS Trust wants to use a large language model to assist clinicians with discharge summaries and clinical coding. The model needs access to patient identifiable information, which under UK GDPR cannot simply be handed to a commercial cloud provider without appropriate safeguards. Building the GPU infrastructure on-premises to run a capable model costs well over a million pounds in hardware alone, plus ongoing staffing. With confidential computing on Azure or Google Cloud, the trust can deploy the model on cloud GPU capacity where patient data is encrypted inside a TEE throughout processing. The cloud provider cannot see the data. The trust can provide attestation evidence to the ICO or the Care Quality Commission that appropriate technical controls exist. The economics shift from CapEx to OpEx, and the clinical AI capability becomes accessible without the data governance compromise.

Financial services and proprietary models: A UK investment manager wants to run AI inference over client portfolio data and proprietary trading signals. The concern is not just regulatory - it is competitive. Sending proprietary strategies through cloud infrastructure that could, theoretically, be accessed by a provider employee or compelled by foreign government order is a real business risk. Confidential computing allows the firm to use cloud scalability for inference while maintaining cryptographic control over both the model weights and the input data. Even if the cloud provider received a legal demand for the data, they could not decrypt it - they simply do not hold the keys.

Legal and professional services: A large law firm processing privileged client communications through an AI document review tool faces a similar problem. Legal professional privilege is not just a regulatory requirement - it is a foundational principle that, once compromised, cannot be remediated. Confidential computing allows the firm to use cloud AI tooling without exposing privileged material to the cloud vendor's infrastructure, staff, or legal jurisdiction.

In all three cases, the key practical shift is this: confidential computing does not require the organisation to build and operate its own AI infrastructure. It requires selecting the right cloud deployment configuration and verifying, through hardware attestation, that the technical controls are in place. That is a fundamentally different cost and complexity profile than full on-premises AI deployment - and a fundamentally different data protection profile than standard public cloud AI deployment.

The Counterargument: Is Confidential Computing Actually Mature Enough?

Honest answer: it depends on your workload, your cloud provider, and your tolerance for some rough edges in the tooling. The technology has moved from research to production faster than most people realise, but it would be misleading to suggest it is uniformly smooth to deploy.

The Cyberus Technology report published in 2026 identifies three specific challenge areas for organisations deploying confidential computing at scale. First, operating system dependencies: kernel support for AMD SEV-SNP and Intel TDX is still maturing across Linux distributions. Organisations running older kernel versions or less common distributions may encounter compatibility issues that require engineering effort to resolve. Second, VM lifecycle management: the tooling for managing the full lifecycle of confidential VMs - provisioning, patching, attestation verification, key management - is more complex than standard VM management. Third, performance overhead: while the overhead has reduced dramatically with recent hardware, some workloads still see measurable performance differences, particularly during the attestation verification process.

These are real constraints, but they are primarily relevant to organisations attempting to build bespoke confidential computing infrastructure from scratch. The major hyperscalers - Microsoft Azure, Google Cloud, and Amazon Web Services - have invested heavily in making confidential computing accessible through managed services that abstract much of this complexity. Azure's confidential VMs with NVIDIA H100 Tensor Core GPUs allow organisations to redeploy existing CUDA models into a confidential GPU environment without rewriting application code, according to Microsoft. Google's Confidential Computing offering provides similar capabilities with AMD SEV-SNP-based instances. AWS Nitro Enclaves have been in production use for several years.

The IDC data puts context on the maturity question: 18% of the organisations surveyed are already running confidential computing in full production. These are not research projects or proof-of-concept deployments - they are live workloads. The common thread across most of the counterarguments is that they reflect the complexity of self-managed deployment rather than managed cloud services. For UK organisations without a dedicated confidential computing engineering team, the practical path is to use the managed services the hyperscalers already provide, rather than attempting to deploy TEE infrastructure independently.

Mark Bower, Chief Strategy Officer at Anjuna Security and co-chair of the Cloud Security Alliance's Confidential Computing Working Group, puts the maturity question simply: "When we describe confidential computing and people actually understand it, the question is almost always the same: Why wouldn't we use this?" The hesitation is usually not about the technology itself - it is about unfamiliarity and the assumption that complexity is higher than it actually is when using managed services.

How UK Leaders Should Approach This Now

The strategic window for acting on confidential computing is not in three years when the technology is universally adopted - it is now, when early movers can build both technical capability and competitive differentiation before the market normalises around it. Here is a practical framework for UK technology and business leaders.

Start with a workload audit, not a technology pilot. The first question is not 'how do we deploy confidential computing' - it is 'which of our AI use cases are currently blocked, limited, or carrying unacceptable risk because of data exposure concerns?' For most organisations, there will be a set of high-value AI applications that have been parked because of compliance, data governance, or competitive sensitivity concerns. Those are the workloads to evaluate first. Confidential computing is not a universal replacement for everything running in cloud - it is a targeted solution for the specific problem of sensitive data in AI workloads.

Evaluate the managed service options before scoping custom infrastructure. Azure Confidential Computing, Google Confidential Computing, and AWS Nitro Enclaves all provide production-grade confidential compute options through familiar cloud interfaces. For most UK organisations, the right starting point is an evaluation of these managed services against specific workload requirements - not an architecture project to build bespoke TEE infrastructure. The lift-and-shift compatibility of AMD SEV-SNP and Intel TDX means that many existing cloud AI deployments can be moved into confidential compute configurations with limited application changes.

Engage legal, compliance, and information governance early. Confidential computing's value proposition is partly technical and partly legal. The hardware attestation capability - the cryptographic proof that data is processing inside a genuine TEE - is evidence of technical control that can be presented to regulators, auditors, and data subjects. Getting legal and compliance teams to understand what attestation reports demonstrate, and how they can be incorporated into data protection impact assessments and regulatory submissions, is as important as the technical deployment work.

Watch the NVIDIA Blackwell rollout closely. The extension of confidential computing to GPU workloads is the development that makes this relevant to most AI deployments. The NVIDIA H100 with Azure confidential VMs is already available; the Blackwell architecture with full TEE-I/O capability represents the next generation. As GPU-based confidential computing becomes more widely available, the performance and cost objections that previously limited adoption are increasingly resolved.

Build internal knowledge now. The organisations that will extract the most value from confidential computing over the next three years are those that build genuine internal understanding of TEEs, attestation, and key management today. This is not a large team requirement - it is one or two engineers or architects who understand the technology well enough to evaluate vendor claims, select the right managed services, and explain the security model to regulators and board-level stakeholders. The Cloud Security Alliance's Confidential Computing Working Group publishes practical guidance that is a good starting point.

Frequently Asked Questions

What is the difference between confidential computing and standard cloud encryption?

Standard cloud encryption protects data at rest (stored on disk) and in transit (moving across a network). It does not protect data while it is being actively processed - at that point, data must be decrypted and is theoretically accessible to anyone with access to system memory, including a compromised hypervisor or the cloud provider's privileged staff. Confidential computing encrypts data in use by processing it inside a hardware-enforced Trusted Execution Environment (TEE). The cloud provider's own infrastructure cannot read the data, even during computation.

Which cloud providers offer confidential computing for AI workloads in the UK?

All three major hyperscalers offer confidential computing options. Microsoft Azure provides confidential VMs using AMD SEV-SNP and Intel TDX, and has introduced confidential GPU computing with NVIDIA H100 Tensor Core GPUs. Google Cloud offers Confidential VMs and Confidential GKE (Kubernetes) nodes based on AMD SEV-SNP. AWS provides Nitro Enclaves, which isolate sensitive workloads using a separate microVM with no persistent storage, no interactive access, and no external networking. All three have UK data centre regions, though you should verify the specific confidential compute instance types available in UK regions before scoping a deployment.

Does confidential computing satisfy UK GDPR requirements for AI processing of personal data?

Confidential computing significantly strengthens the technical safeguard position under UK GDPR by ensuring personal data is never exposed in plain text to the cloud provider's infrastructure. However, it is not a standalone compliance solution - it needs to be evaluated as part of a broader data protection framework including data minimisation, purpose limitation, retention controls, and documented impact assessments. The ICO's guidance on technical safeguards and its AI and data protection guidance are the relevant starting points. Confidential computing's attestation capability provides auditable evidence of technical controls that can be included in Data Protection Impact Assessments.

How does hardware attestation work, and why does it matter?

Hardware attestation is the mechanism by which a TEE proves, cryptographically, that it is a genuine hardware-enforced confidential environment running unmodified code. When a workload is loaded into a TEE, the CPU generates a signed measurement of the workload and the TEE configuration. Before sensitive data is sent to that workload, an external party (your own system, a regulator, or a third party) can request this attestation report and verify the signature against the chip manufacturer's root certificate. This provides a verifiable, hardware-rooted proof that data will be processed inside a genuine confidential environment - something contractual terms with a cloud provider cannot replicate.

Is confidential computing significantly slower than standard cloud computing?

The performance overhead depends on the workload and the hardware generation. Early implementations carried meaningful performance penalties, which was a legitimate objection. More recent hardware - particularly AMD SEV-SNP and Intel TDX for CPU workloads, and NVIDIA Blackwell for GPU workloads - has reduced this overhead substantially. NVIDIA specifically states that Blackwell Confidential Computing delivers near-identical throughput performance compared to unencrypted modes. For most AI inference workloads, the performance difference is not significant enough to change the business case. Latency-sensitive applications and high-throughput training runs on older hardware generations are where you are more likely to see measurable differences worth benchmarking.

Can we use confidential computing with open-source AI models like Llama or Mistral?

Yes. Because AMD SEV-SNP and Intel TDX enable lift-and-shift deployment - running standard virtual machines inside encrypted memory regions without application code changes - any model that can run in a standard cloud VM or container can in principle run inside a confidential VM. This includes open-source models deployed with inference frameworks like vLLM, Ollama, or Hugging Face Text Generation Inference. The practical steps involve selecting a confidential VM instance type from your chosen cloud provider, verifying the attestation setup, and confirming your orchestration tooling is compatible. Most mainstream Kubernetes and container orchestration tools have confidential computing support either natively or through add-ons.

What is the difference between confidential computing and a sovereign cloud?

Sovereign cloud refers to cloud infrastructure operated under the laws and jurisdiction of a specific country - for example, cloud services hosted entirely in the UK and operated by a UK entity, ensuring data residency and jurisdictional control. Confidential computing is a technical data protection mechanism that can be applied regardless of where the cloud infrastructure is physically located. The two are complementary rather than competing approaches. A sovereign cloud deployment without confidential computing still exposes data during processing to the cloud operator. Confidential computing on a hyperscaler's UK region protects data during processing but does not change the jurisdictional status of the cloud provider. For the most sensitive workloads, combining both approaches - sovereign cloud hosting with confidential compute instances - provides the strongest posture.

How much does confidential computing cost compared to standard cloud AI deployment?

Confidential compute instances typically carry a small premium over equivalent standard instances - historically in the range of 5-15% depending on the provider, instance type, and workload. This is significantly lower than the total cost of building and operating equivalent on-premises GPU infrastructure, which for a production-grade AI deployment at scale typically runs to seven figures in capital expenditure plus ongoing operational and staffing costs. For organisations currently blocked from cloud AI deployment by data governance concerns, the economics strongly favour confidential cloud computing over on-premises alternatives. The relevant comparison is not confidential compute premium versus standard cloud - it is confidential cloud versus the full cost of on-premises AI infrastructure that can deliver equivalent capability.