Your Data Is in Canada Central. That Still Isn't Sovereignty.

Ask your cloud team where the AI project's data lives and you will usually get a confident answer: Canada Central, sometimes Canada East. Region pinned. Residency satisfied. Question closed.

It isn't closed. Residency answers where the bytes sit. Sovereignty answers who can compel access to them. Those are two different questions with two different owners, and most teams only ever answer the first one.

// THE GAP

Here is the text that makes this concrete. The CLOUD Act added 18 U.S.C. § 2713 to the Stored Communications Act in 2018:

A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.

Read the two clauses that matter. "Regardless of whether… located within or outside of the United States" kills the geography argument outright. Picking Canada Central does not put data beyond the reach of a valid US order served on a US-headquartered provider. Microsoft's own support channels say this plainly: because Microsoft is a US-headquartered company, the CLOUD Act may require it to respond to legally binding US requests even when the data sits in a Canadian Azure datacentre.

But read the other clause too, because that one is the lever: "within such provider's possession, custody, or control." No possession, custody, or control, no disclosure obligation. That is not a loophole. It is an architecture requirement, and it is the only part of this problem your engineering team can actually change.

What Microsoft actually committed to for Canada

On December 9, 2025, Microsoft announced $19B CAD in Canadian investment across 2023–2027, including more than $7.5B CAD over two years, with new capacity coming online in the second half of 2026. Bundled with it: a five-point plan for Canadian digital sovereignty. Ottawa threat-intelligence hub. In-country Copilot processing. Azure Local expansion. Confidential computing. External key management in Azure Key Vault. A commitment to defend service continuity for government customers, including litigation.

And this contractual pledge, which got quoted everywhere:

…challenge any government demand for Canadian government or commercial customer data where we have a legal basis for doing so.

Take that commitment seriously and read it literally, because both halves are load-bearing. Microsoft will litigate. Microsoft will also comply when a demand is lawful, because that is what § 2713 requires of it. A promise to fight orders that are contestable is not a promise that no order will ever be honoured. It is a good-faith commitment operating inside a legal constraint the vendor does not control.

Nobody is being deceptive here. The vendor is telling you exactly where its authority ends. The failure mode is on the buyer's side: reading "sovereignty plan" in a headline and filing the risk as closed.

Microsoft Sovereign Cloud is real — and mostly not aimed at you

The natural next move is "then we buy Sovereign Cloud." Read the product documentation before you budget for it. Microsoft's own overview, updated July 15, 2026, is precise:

Microsoft Sovereign Cloud is available across European datacenter regions for European customers… Although the foundation targets European datacenter regions, technical capabilities to enforce data sovereignty are available worldwide.

That sentence is the whole planning answer for a Québec organization. The deployment model — Sovereign Public Cloud with Data Guardian, External Key Management, tamper-evident access logs — is Europe-first. The technical controls are available to you today. There is no "Canada Data Boundary" SKU to purchase. What exists for you is a set of Azure primitives you have to assemble and prove, which is exactly the kind of work that gets deferred because it has no purchase order attached to it.

Microsoft did ship one useful accelerator with the Canadian announcement: SAIL, the Sovereign AI Landing Zone, open-sourced at github.com/Azure/SAIL. Bicep templates for Microsoft Foundry, Azure Machine Learning, and Azure Databricks, with the residency requirement stated as data at rest and in transit staying inside Canadian regions, and models restricted to those directly sold by Azure. Read its abuse-monitoring note as well: prompts and completions can be retained for 30 days, and that retention is disableable. That is the level of detail this problem actually lives at.

What Law 25 asks — and what the CAI will ask you for

Québec's regulator is not going to audit your sovereignty narrative. It is going to audit your paperwork, and the paperwork has a specific shape.

Under the Act respecting the protection of personal information in the private sector (CQLR c. P-39.1, as amended by Law 25):

Section 3.3 — a privacy impact assessment is required for processing that presents elevated privacy risk. An AI system profiling individuals generally qualifies.
Section 17 — before communicating personal information outside Québec you must conduct an assessment, conclude the information will receive adequate protection given the destination's legal regime, and put a written agreement in place reflecting that assessment. "Communication" includes calling an inference endpoint outside the province, even when the result comes back and is stored locally.
Section 12.1 — individuals must be informed when a decision is made exclusively by automated processing, and be able to submit observations to a human.

Exposure runs to administrative monetary penalties of up to $10M or 2% of worldwide turnover, and penal fines up to $25M or 4%, whichever is greater — in force since September 22, 2023.

Notice what section 17 is really asking. Not "is your data sovereign." It asks whether you assessed the destination's legal regime and documented the conclusion. An organization that wrote down "US provider, CLOUD Act applies, here are the compensating controls, here is the signed agreement" is in a defensible position. An organization that wrote down "data is in Canada" has not answered the question that was asked.

The four controls that actually move the risk

Back to possession, custody, or control. Four things change your exposure. Everything else is documentation.

Hold the keys outside the provider's control. Customer-managed keys in Key Vault are the floor; external key management and client-side encryption with keys held outside Azure are the real answer. Ciphertext without keys is a much weaker disclosure target.
Confidential computing for data in use. Hardware-based trusted execution environments close the gap where memory is readable. Microsoft's own documentation frames this as reducing risk "including from cloud operators."
Region enforcement as code, not as a deployment habit. Assign the built-in Allowed locations deny policy (e56962a6-4747-49cd-b67b-bf8b01975c4c) at the management-group scope. A pinned region that any engineer can override in a portal blade is a preference, not a control.
An audit trail that survives a question asked eighteen months later. Who queried what, which model, which data, under whose identity. Without it you cannot complete a section 17 assessment honestly.

# infra/landing-zone: residency as a deny guardrail, inherited by every subscription
resource "azurerm_management_group_policy_assignment" "allowed_locations" {
  name                 = "entz-allowed-locations"
  management_group_id  = azurerm_management_group.entz_root.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c"

  parameters = jsonencode({
    listOfAllowedLocations = { value = ["canadacentral", "canadaeast"] }
  })
}

Six lines of Terraform. It is not sophisticated. It is just committed, reviewed, and inherited — which is the entire difference between a control and an intention.

The honest position

You cannot buy your way out of the CLOUD Act while running on a US hyperscaler. Anyone selling you that is selling something they don't have. What you can do is narrow the surface to ciphertext you control the keys to, enforce residency as policy instead of convention, and document the assessment Law 25 actually requires. That combination is defensible to a regulator, to a board, and to a customer's security questionnaire.

The organizations that get hurt in 2026 will not be the ones that chose Azure. They will be the ones that mistook a region dropdown for a jurisdictional answer, and never wrote the assessment down.

Speed without rigor isn't velocity. It's technical and regulatory debt.

Where does your data actually go? Start with a free scan — under 24h, no commitment. We map your data paths, key custody, and residency guardrails, and tell you which of the four controls above you are missing.