Guide to Sovereign AI: The Inference Risk Your Cloud Governance Missed

Introduction

Cloud, cloud, and cloud . . .

On-Premise Private Cloud > Private Cloud > Public Cloud > Hybrid Cloud > Hybrid Multi-Cloud

The progression from on-prem to Public Cloud was economics and agility. Those who were pragmatic when Hybrid Cloud when facing the realities of data sensitivity and gravity. Eventually most enterprises of scale end up with Hybrid Multi-cloud not by design but by acquisition, shadow IT, or best-of-breed services selection such as SaaS, then finding themselves retrofitting governance and addressing the incurred cybersecurity challenges.

Jurisdictional and Data Privacy laws almost a decade old have become a priority to address of late given changes in geo-politics. Through jurisdictional law, nations can exert access to you workloads and data regardless of where they are physically located and includes geographies they traverse. Data Privacy law states that foreign authorities require an international to access a nation’s data. Jurisdictional law can conflict with Data Privacy as seen with the US CLOUD Act and EU GDPR.

Overview of Sovereign

Sovereign Cloud is a compliance and jurisdictional overlay to your cloud infrastructure to address this legal exposure. The three core pillars of Sovereign Cloud are:

· Data residency. Data must physically stay within a defined jurisdiction.

· Operational sovereignty. Personnel with access must be citizens/vetted nationals.

· Regulatory compliance. GDPR, NIS2, DORA, FedRAMP, ITAR, or sector-specific mandates.

Sovereign AI extends the jurisdictional logic beyond where data lives to who controls the intelligence derived from it. Three points that get missed are:

· Inference Risk. An organization can have perfectly compliant data residency and then deploy a SaaS AI tool that sends prompts containing that data to an API endpoint in a foreign data center. The prompt content is often more operationally sensitive than the stored data (it reveals what questions are being asked, by whom, about what). This is a sovereignty breach that bypasses most existing cloud governance frameworks because it looks like an API call, not a data transfer.

· “Model weights” as geopolitical assets. Model weights are “the math” that makes AI smart. Just like oil or gold, countries now see the ability to build and control AI as a source of national power.

· Supply chain risk. Sovereign AI requires sovereign infrastructure which means knowing and demonstrating the chain-of-custody for every component in the supply chain.

Trusted Cloud instead of Sovereign Cloud

Sovereign Cloud is about jurisdiction; Trusted Cloud is about verifiable assurance. The designation of trusted has its heritage from trusted compute base (TCB.) TCB is the totality of all hardware, firmware, and software components within a computer system that are critical to its security. It enforces security policies, such as access control, ensuring system integrity. To be a Trusted System every layer you add must itself be trusted. But you reach the point of diminishing returns once you move beyond on-premise private cloud where your ability to verify diminishes and becomes a risk to be managed.

With that said, the only Trusted Cloud is an on-premise private cloud. This does not imply you should only deploy on-premise private cloud. It establishes where you’re root of trust exists. To preserve its sanctity moving right towards multi-cloud requires tight control in use, consumption, and classification of other cloud services. Tight control begins with key management.

Key Management: Bring Your Own Key (BYOK) means the customer manages keys but the hyperscaler/service provider (SP) Hardware Security Modules (HSM) performs encryption. The SP could theoretically be compelled to use the key. Hold Your Own Key (HYOK) means the key never enters the SP’s infrastructure at all; they encrypt against a customer-held key that they never see. HYOK is the meaningful trust boundary; BYOK is a marketing claim more than a security one. Most enterprise procurement teams don’t ask which they are getting.

Buyer Beware

“Trusted Cloud” is increasingly devolving into a formal certification, not a posture. The EU’s EUCS (European Union Cybersecurity Certification Scheme for Cloud Services) under ENISA defines three assurance levels — Basic, Substantial, and High — with High explicitly requiring that providers not be subject to non-EU law that conflicts with EU data protection obligations. That is a direct structural barrier to the major US hyperscalers achieving the top tier without a legally separate EU entity. Expect this to drive M&A and joint venture activity in the European cloud market through 2026–2028.

Trust in LLMs

The genie is out of the bottle with the largest AI provider’s having LLM’s in the trillions of parameters. Is some of your enterprise data already in their corpus? Who knows. But we can do better in protecting our data from potentially unauthorized ingestion going forward.

But building a trusted LLM on top of an existing foundation model is a multi-layer engineering and governance challenge. We will go into this in my next installment.

For what it’s worth

– Joe