On July 21, Microsoft and Mistral announced a significant expansion of their partnership: a multibillion-dollar commitment to Europe-based GPU capacity built on NVIDIA Vera Rubin systems, Mistral Medium 3.5 and OCR 4 landing in Microsoft Foundry, and — the line that matters most for this site — a common deployment model spanning Azure's public cloud, customer-controlled Azure Local, and fully disconnected environments.
The generalist press covered the money and the geopolitics. Almost nobody has covered the "how". So let's do that: what does it actually take to run a frontier model like Mistral Medium 3.5 on an Azure Local instance with no connection to the public cloud?
What was actually announced
Three layers, per the official announcement:
- Infrastructure: Microsoft will leverage Mistral's expanded Europe-based GPU capacity — thousands of NVIDIA Vera Rubin GPUs — to increase AI compute availability in Europe, in line with the European Digital Commitments.
- Models: Mistral Medium 3.5 (open-weight) and OCR 4 are now available in Microsoft Foundry; Medium 3.5 also lands in Copilot Studio.
- Deployment: a spectrum of operating environments — cloud, cloud-connected Azure Local, and Azure Local deployments that "can operate independently of external connectivity for highly sensitive, constrained or mission-critical environments."
The bridge between the model layer and the disconnected layer is Microsoft Foundry plus Foundry Local, which extends the Foundry development and runtime experience to Azure Local, so the same models, tools, APIs and workflows work regardless of where the application ultimately runs.
"Fully disconnected" is not a checkbox
This is where most coverage stops and the real architecture begins. Azure Local's disconnected operations is not a mode you toggle on. It's a distinct product experience: a local control plane — Azure portal, ARM, CLI, RBAC — running as a virtual appliance on a dedicated management cluster inside your own datacenter, with no dependency on Azure Public.
The supported service surface is deliberately narrow: Azure Local VMs, Arc-enabled servers, AKS enabled by Arc (preview), Azure Container Registry, Key Vault, Policy, and system-assigned managed identity. Everything else you take for granted in public Azure — you plan around it.
And you don't just buy it. Per the eligibility criteria, you need an eligible Microsoft agreement (MOSA doesn't qualify), an active support plan (Standard or higher), a documented business need to operate disconnected, staff or a partner who can run it, and your own validated hardware — Premier Solutions from the Azure Local catalog, plus the dedicated management cluster on top of your workload capacity.
What it takes, end to end
Mapping the announcement onto the documented deployment flow, a realistic path to Mistral-on-disconnected looks like this:
- Qualify. Pre-qualification with your account team, approval in up to 10 business days. This is a procurement conversation before it's a technical one.
- Plan the foundations. Network, identity (no Entra ID in the sky to lean on), and customer-run PKI for every endpoint. This is where disconnected projects are won or lost.
- Size for inference, not just infrastructure. The control-plane appliance already raises the minimum hardware bar. A frontier-class model adds GPU capacity on top — on validated Azure Local solutions with GPUs, sized for your latency and concurrency targets, not for a demo.
- Deploy the platform. Management cluster, disconnected appliance, registration — then the workload clusters (VMs or AKS enabled by Arc) that will serve the model.
- Operate offline. Model updates, OS updates, container images through Azure Container Registry — everything moves through a controlled import process. The 2607 release helps here: update packages are now downloadable directly from the Azure portal, explicitly aimed at limited-connectivity scenarios.
What the press release doesn't answer
Being honest about the gaps — because "tested, not paraphrased" is the promise of this site:
- Model delivery to disconnected environments. The announcement confirms Medium 3.5 is open-weight and that disconnected deployment is part of the common operating model. What's not yet documented publicly is the exact mechanism: how model weights, updates and licensing flow into an environment with no Azure connection. I expect this to run through Foundry Local's catalog and the disconnected import path — verifying that is the first thing on my lab list.
- GPU sizing. No published guidance yet on the hardware envelope Medium 3.5 needs on Azure Local — a number that decides whether this is feasible for a mid-size regulated org or only for governments.
- The service-surface delta. Foundry in public Azure is a rich platform; Foundry Local on a disconnected instance will necessarily be a subset. How big that delta is determines how much application redesign the "one deployment experience" claim really saves you.
Who should care
If your workloads answer to NIS2, DORA, or national baselines like the Dutch BIO — or you operate critical infrastructure, defense-adjacent estates, or sites where connectivity itself is the risk — this is the first credible story of frontier AI that stays entirely inside your boundary: European model, your hardware, your control plane, your PKI, no path home to a hyperscaler. That combination did not exist a month ago.
It's also, quietly, another argument in the VMware-exit conversation: the platform you'd migrate to for sovereignty reasons now has a native answer for on-prem AI, which VMware-era stacks never had.
Frontier AI inside your own boundary is no longer a slideware claim — but between the press release and production sits an architecture: eligibility, dedicated management cluster, identity, PKI, GPU sizing, and an offline supply chain for model weights.
I'm building the lab plan for exactly that path. If you want the results — what worked, what broke, and what Microsoft's docs don't tell you yet — subscribe to Sovereign Cloud Watch or find me on LinkedIn.