Microsoft sovereign AI: what Japan can use now, what waits

In manufacturing, healthcare and government systems, organizations often want to give sensitive data to generative AI but can’t let it leave the country or pass into another company’s control.

On October 19, the Azure Blog published “Designing for sovereign AI: A shared foundation from edge to cloud.” The author is Alistair Speirs, General Manager for global infrastructure. Built around a partnership with Intel, it describes how to design the foundation for “sovereign AI.” It reads less as a product launch than as a framing of ideas; the concrete updates came the next day, on the 20th, on the Official Microsoft Blog. Using both posts, this article separates the pieces companies in Japan can use today from the features they will have to wait for.

From where data lives to control per workload#

The blog says the debate over digital sovereignty has widened. Beyond where data is stored and processed, it now covers where workloads run, who can access and operate the systems, and whether they can keep running safely when requirements change.

Its position is that how much control you need depends on the workload. The factors it lists include data sensitivity and regulation, as well as latency, connectivity, operational access and resilience. As a result, it expects organizations to mix the public cloud, customer-managed environments and trusted partner environments workload by workload. The October 20 announcement took the same position: sovereignty starts from the workload.

The blog closes with three questions for executives.

1. What must stay under our control (data, infrastructure, administrative access, software operations, connectivity)?
2. Can we verify that this control is working (encryption, isolation, identity and access control, policy enforcement, attestation, operational transparency)?
3. Can we adapt without rebuilding when requirements change (adopting new models, moving processing closer to the data, changing where things run)?

The third question seems easy to overlook. A workload that runs connected today may need to move to a disconnected environment if regulations or connectivity conditions change. The blog calls for a design that avoids rebuilding the management and security setup each time that happens.

Verifying trust with confidential VMs and attestation#

For the second question, the blog names specific mechanisms. Supported Azure confidential VM configurations can use Intel TDX (Trust Domain Extensions) on Xeon. TDX isolates workloads in use from the host and the hypervisor. Hardware-based attestation, it explains, gives organizations evidence to check an environment’s security properties against their own requirements. An Intel executive said this lets organizations move from trusting an environment to verifying it.

Microsoft Learn explains how confidential VMs work. If a setting required for isolation is missing, Azure Attestation won’t attest to boot health and the VM won’t start. You can choose whether the platform or the customer manages the encryption keys. The Learn page also uses AMD SEV-SNP as an example, so confidential VMs are not built only on Intel products.

On October 20, two updates in this area became generally available. One is confidential VMs on Azure Local, which protect data in use in your own facilities too. The other is external key management for Azure Managed HSM, which lets you keep root encryption keys on hardware run by you or a trusted third party.

The blog argues that the strength of protection should match each workload’s risk. The idea is to apply isolation, encryption, attestation and operational controls where they have an effect, and to keep the whole thing operable.

Pieces that run in your own environment, and their status#

The pieces for running AI close to the data are grouped as “Sovereign Private Cloud,” built on Azure Local. According to the October 20 announcement and each product’s documentation, the status is as follows.

Component	What it is	Status
Azure Local	The Azure platform running on hardware you own. In disconnected operations, the portal, Resource Manager, RBAC, Key Vault, Azure Policy and more run locally	Available. Switching between connected and disconnected is entering public preview
Foundry Local (on Azure Local)	Runs AI model inference on Arc-enabled Kubernetes. OpenAI-compatible REST API, CPU and GPU, supports disconnected environments	Preview. General availability planned at Ignite for both connected and disconnected
GitHub Enterprise Local	Runs GitHub Enterprise Server as a virtual appliance on Azure Local	Preview. General availability planned at Ignite
Microsoft 365 Local	Runs Exchange Server, SharePoint Server and Skype for Business Server on Azure Local	Available. Integration with Foundry Local is in preview for approved customers

Separately from this table, the same announcement introduced a “Sovereign Control Panel” as a feature on Microsoft’s cloud side (Sovereign Public Cloud), not in your own environment. It shows sovereignty posture, risk and ease of migration in one place in the Azure portal, and is set to enter public preview at Ignite.

In the Learn overview, Microsoft 365 Local lists only the three server products. Teams and Microsoft 365 Copilot are not mentioned. The subscription editions of these three products are supported until at least 2035.

For AI processing, the blog points to speeding up CPU inference with Intel AMX on Xeon 6, and to Intel’s OpenVINO for model optimization. For GPUs, the April announcement cited support for high-performance GPU infrastructure. The same announcement said Azure Local can now scale to thousands of servers within a single sovereign boundary.

When Copilot in-country processing arrives in Japan, and the alternatives#

For anyone evaluating this in Japan, timing matters most. In November 2025, Microsoft announced that it would extend the option to process Microsoft 365 Copilot in-country to 15 countries. Japan was in the group slated for the end of 2025, along with Australia, the UK and India.

An update dated April 3, 2026 on the same page revised the timing and scope. It states that what happens in-country is “inference,” the stage where the model processes the prompt and generates a response, and it added Copilot Studio, Power Platform and Dynamics 365 to the covered products. Australia, India, the UAE, the UK and the US are planned by the end of 2026, Canada in 2027 and Japan in 2028. If your internal policy requires Copilot inference to run in Japan, you likely can’t meet that requirement until the availability slated for 2028 (no month has been given).

On the same day, April 3, Microsoft announced a $10 billion investment in Japan from 2026 to 2029. The plan is for Sakura Internet and SoftBank to offer GPU compute through Azure, with data kept in Japan (Sakura Internet is still exploring whether to offer it). The announcement also says GitHub Enterprise Cloud now supports choosing Japan as its data residency location.

Among the October 20 announcements, Data Guardian is for EU and EFTA customers, and Japan is not listed. It is a mechanism in which a trusted EU partner oversees remote access by Microsoft engineers to in-scope production systems. Production Touch Ledger, which records that access and the actions taken in a tamper-evident form, will also roll out in stages in the EU and EFTA. The independently operated national clouds named were likewise France’s Bleu Cloud and Germany’s Delos Cloud.

If you want AI to process sensitive data in Japan before 2028, the likely option is to run models in your own environment, as Foundry Local does. Note, however, that this does not run Microsoft 365 Copilot itself on-premises.

Conditions for disconnected operations, and the dependencies that remain#

Disconnected operations for Azure Local are not available to anyone who simply signs up. Learn lists these conditions.

• An eligible agreement is required; the Microsoft Online Subscription Program (MOSA) is not eligible
• A Standard or higher support plan, or a partner that has one
• A reason you can’t connect (connectivity problems or regulation)
• Staff who can operate it, or a partner that operates it for you
• Azure Local “Premier Solutions” hardware and a dedicated management cluster

Because the management stack runs locally, the minimum hardware is larger than for connected deployments. You apply through a form, and the result, such as approval or rejection, arrives within 10 business days.

Nor do dependencies go away. Speaking to Network World, Gartner’s Ashish Banerjee said he would “not call it complete control.” His point is that you need to check whether Microsoft stays involved in identity, software updates, management and support. The article also relays his view that not every Azure service is necessarily available at the same time in disconnected environments, that dedicated facilities or staff may be needed, and that some of the elasticity and scale benefits may be lost. In his opinion, maximum sovereignty should be reserved for workloads that justify the added complexity. Pareekh Jain of EIIRTrend said Microsoft remains subject to US law, sanctions and export controls.

KuppingerCole likewise assesses that the legal basis for lawful access under the US CLOUD Act remains. Because Microsoft’s licensing determines whether the technology can be used, it adds, the risk of losing access for legal or political reasons also remains.

The blog’s three questions don’t address how to handle this dependence. If you use the three questions for internal planning, it seems worth adding a column for “where dependence on Microsoft remains” to the table where you decide, workload by workload, what to keep under your control. That table can then help you sort out whether to wait until 2028 for Copilot in-country processing or move some processing into your own environment.