Cloud and AI sovereignty: understanding Microsoft’s strategy from public cloud to the edge

When discussing digital sovereignty, data location is often one of the first issues to arise. For an organization, however, control over its systems depends on many other decisions: who can administer them, how information is protected during processing, which technology dependencies remain, and how operations continue when conditions change.

Artificial intelligence broadens this scope further. Alongside data, organizations must consider models, inference processes, indexes, development tools, and agents capable of interacting with business systems.

Microsoft’s recent announcements outline an approach that connects these elements across public cloud, infrastructure controlled by the customer, and solutions operated by partners. The common framework is Microsoft Sovereign Cloud, organized around the requirements of individual workloads. Advancing digital sovereignty with greater control and choice.

The principle I would start from is this:

A sovereignty strategy becomes concrete when control requirements are translated into architectures, operational responsibilities, and verifiable evidence.

Control requirements first, platform second

When assessing a sovereign architecture, a useful starting point is the business process itself.

Which information must remain within defined boundaries? Who can access the environment? Which administrative activities require oversight? How long can a connectivity outage last? How are infrastructure, applications, and models updated? Which components must be replaceable?

The answers can differ even within the same organization.

A service facing the public may place considerable value on elasticity. An industrial application may require processing close to the equipment. An AI assistant working with sensitive documents may have specific requirements around inference, access, and source management.

Microsoft’s approach therefore connects sovereignty to workload placement, extending the assessment across the entire technology stack: infrastructure, security, data, and AI. Designing for sovereign AI: A shared foundation from edge to cloud.

From an architectural perspective, this calls for a clear sequence: define the organization’s control model, then assess where workloads should run within it.

A continuum of control

Microsoft structures its approach around three complementary components.

Component	Role in the architecture
Sovereign Public Cloud	Adds controls and transparency for workloads running in the Azure public cloud.
Sovereign Private Cloud	Brings cloud capabilities into environments managed by the customer, including disconnected deployments.
Sovereign Partner Ecosystem	Provides local expertise, specialized services, and environments with independent operating models.

All three components can coexist within the same application estate, depending on the requirements of each service. Microsoft Sovereign Cloud: a continuum of control.

In my view, the value of this approach depends on the ability to maintain consistent governance and operations as the execution environment changes. That consistency must be assessed alongside the actual differences between environments: available services, customer responsibilities, and management procedures.

Sovereign Public Cloud: making control visible

In public cloud, a significant part of the challenge is demonstrating that the intended controls are actually in place.

Sovereign Control Panel provides a unified view in the Azure portal, organized around three activities: understanding the current posture, applying controls, and addressing deviations.

The platform combines Azure Policy assessments with inspection of resource configurations. The aim is to gather evidence across residency, confidentiality, operations, and continuity, making it easier to identify areas that need attention. Sovereign Control Panel.

The public preview is planned for Microsoft Ignite. The announced scope also includes assessments of dependencies and portability readiness: useful input when planning a potential move to another environment, which will still require work on the application architecture. What is new in Sovereign Public Cloud.

For those managing the platform, the practical implication is significant: control can become part of routine operations, with responsibilities, regular reviews, and configuration changes.

Administrative access and traceability

Data Guardian adds regional oversight to operational access. In its October update, Microsoft describes a phased rollout across the EU and EFTA, with oversight by European residents through a trusted EU partner, covering remote engineer access within the defined scope.

Production Touch Ledger provides records of those access events and the actions performed, with evidence that allows tampering to be detected. Operational controls in Sovereign Public Cloud.

The model therefore brings together authorization, oversight, and traceability. Assessing its effectiveness in a particular environment requires checking which systems and operations are covered, and how the evidence can support audit processes.

External key custody

With External Key Management for Azure Key Vault Managed HSM, which is generally available, the key protecting the data encryption keys can remain in an HSM outside Microsoft infrastructure, operated by the customer or a party of its choice.

The technical detail matters. The external key, the Key Encryption Key, remains in the HSM; authorized operations allow the Azure service to obtain the Data Encryption Key needed to process the data. The service therefore continues to perform encryption and decryption.

The control concerns external key custody and protection of data at rest in compatible services. The proxy, HSM, and connections also become components of overall availability, with operational responsibilities falling to the customer or its provider. Managed HSM External Key Management.

The choice should therefore address a specific custody requirement, supported by a design for availability, monitoring, and recovery.

Applying controls through the landing zone

The Sovereign Landing Zone allows these decisions to be incorporated into the governance structure. Microsoft describes it as an architectural variant that can also be adopted incrementally on top of an existing landing zone, with Bicep and Terraform implementations. Sovereign Landing Zone: implementation options.

The update also introduces a Local management group to include Azure Local in the governance design. For collaborative analytics, Azure Confidential Clean Rooms, in limited preview, applies confidential computing to approved processing of sensitive data from multiple participants. Sovereign Public Cloud updates.

Sovereign Private Cloud: bringing the operating model into the customer’s environment

Azure Local provides the foundation for Sovereign Private Cloud: infrastructure running in an environment controlled by the customer, hosting supported workloads and services.

Here, it is essential to distinguish where workloads execute from where management functions reside.

With connected operations, applications and data can remain local while Azure provides management, governance, and lifecycle capabilities. The platform tolerates temporary connectivity outages, although some functions depend on cloud services. Connected operations for Azure Local.

Data flows also require attention. The documentation distinguishes application data from management data stored in the cloud, such as resource names, usage, and billing information. Optional services, such as backup, can introduce additional transfers.

With disconnected operations, the control plane moves into the customer’s environment. Management, identity, monitoring, and maintenance must use supported local configurations and procedures, including offline processes for updates and onboarding.

This model provides a subset of cloud capabilities and requires preparation: suitable hardware, appropriately sized capacity, a dedicated management cluster, skills, and operational processes. Disconnected operations for Azure Local.

The architectural question therefore becomes very concrete: which functions must remain available when connectivity to Azure is lost, and for how long?

Microsoft also announces that the transition from connected to disconnected environments is entering public preview. This capability should be incorporated into a planned process, with dependencies, steps, and validation defined before the need to use it arises. Sovereign Private Cloud: operational updates.

Sovereignty extends to application services and development

Operational autonomy also involves the services applications depend on.

SQL Server on Azure Local is already available for connected and disconnected deployments. DocumentDB and Blob Storage on Azure Local will enter public preview at Ignite, expanding the options for document data and object storage respectively.

Multitenant support has also been announced, initially for qualified opportunities, to separate resources, governance, and management across different tenants sharing the same infrastructure. Services and multitenancy in Sovereign Private Cloud.

The same principle extends to the development lifecycle.

GitHub Enterprise Local, with GA planned for Ignite, brings GitHub Enterprise Server to Azure Local as an appliance. Repositories, pipelines, and artifacts can be managed within the customer’s infrastructure, including through GitHub Actions with runners managed by the organization. Components such as artifact storage and GitHub Enterprise Server maintenance still need to be designed and planned. GitHub Enterprise Local.

For collaboration, Microsoft 365 Local includes Exchange Server, SharePoint Server, and Skype for Business Server on validated Azure Local architectures. Its scope covers these specific server products, with their associated hardware and deployment requirements. Microsoft 365 Local.

The architectural issue is the completeness of the chain: an application running locally may still depend on external repositories, identity services, libraries, collaboration services, or release processes. These relationships must be included in the assessment of operational autonomy.

Foundry Local: from inference to AI applications built on enterprise data

With Foundry Local on Azure Local, Microsoft brings model execution into the customer’s infrastructure. GA is announced for Ignite, including supported connected and disconnected operations. Advancing sovereign AI with Foundry Local and Azure Local.

The solution uses Kubernetes enabled by Azure Arc and provides model lifecycle management, CPU or GPU deployments, scaling across multiple nodes, and APIs compatible with OpenAI patterns. Models can come from the catalog or from supported sources provided by the organization.

This provides an operational foundation for deploying and managing inference endpoints close to applications. It also requires capacity suited to the models, Kubernetes management, endpoint protection, and procedures consistent with the chosen connectivity model. Foundry Local on Azure Local: architecture and capabilities.

For an organization, model selection therefore needs to reflect the realities of the service: response quality, processing times, concurrent users, available memory, and operational sustainability.

Connecting models to enterprise knowledge

Agentic Retrieval adds document ingestion, indexing, and information retrieval through multiple steps, with responses accompanied by citations.

The announcements also include agents and connectors to enterprise systems through Model Context Protocol (MCP), together with configurable guardrails for local AI workloads, in preview. Foundry Local: retrieval, agents, and controls.

The documentation describes a local pipeline covering ingestion, embedding, search, orchestration, and generation. AI workloads on Azure Local.

This is what makes the architecture particularly relevant to enterprise data: the model can use current information from the organization’s own sources.

The governance scope therefore also includes indexes, connector credentials, document permissions, conversations, and the actions agents are allowed to perform. Each component must respect the access model defined for the service.

Trust must extend to the hardware

Protecting data during processing adds another layer to the approach.

In supported configurations, confidential virtual machines introduce a hardware-based isolation boundary between the workload and the virtualization stack. Attestation makes it possible to verify properties of the environment before starting certain operations or releasing keys. Azure confidential VMs.

Confidential VMs are available on Azure Local. Security in Sovereign Private Cloud.

In its collaboration with Intel, Microsoft highlights technologies such as Intel TDX for isolation, Intel AMX to accelerate specific AI workloads on CPUs, and OpenVINO for model optimization and deployment. The hardware foundation for sovereign AI.

For those designing the environment, security and performance therefore become connected decisions. The model, runtime, and hardware configuration need to be assessed together, using measurements taken with the intended workload.

Turning the approach into an architectural decision

An example helps connect capabilities to requirements.

Consider an organization with three different services.

Workload	Main requirement	Direction to assess
Portal serving geographically distributed users	Elasticity, availability, and control over operational access	Azure with the applicable Sovereign Public Cloud controls.
Assistant for technical documentation at a manufacturing plant	Processing close to the data and fast responses	Azure Local and Foundry Local, with validation of pipeline dependencies.
Essential service in an isolated environment	Extended operation without public cloud access	A disconnected architecture with supported local management and application services.

These three decisions can coexist within the same operating model.

For each one, I would ask for concrete evidence that the requirement is met: an access review, a map of data flows, a performance measurement, or a test of operation without connectivity.

Portability also needs to be addressed at this level. Moving a workload involves data, identity, application services, automation, and operational procedures. The design must establish which components can be moved directly and which require adaptation.

Finally, greater local control means taking on specific responsibilities for capacity, updates, security, and recovery. The financial assessment must include these activities as well.

Designing for control over time

I see Microsoft’s strategy as an expansion of the options for applying different controls while maintaining a shared technology foundation.

For organizations, the most important task remains defining which decisions they must be able to make independently, which dependencies are acceptable, and which operating conditions they must be prepared to handle.

The announced capabilities become valuable when they are incorporated into that design: with assigned responsibilities, verifiable configurations, and tested procedures.

The quality of a sovereign architecture is measured by the organization’s ability to govern its workloads, continue operating, and adapt its choices as requirements change.