Data residency is a choice with a price. Here is the price.

Residency is the most common opening requirement in a first conversation and the one most often stated without a reason attached. "Our data has to stay in Canada" is sometimes a legal obligation, sometimes a contract term, sometimes a board preference, and sometimes an inherited assumption nobody has re-examined since 2018. Those four things have very different prices, so it is worth separating them before deciding anything.

What Canadian law actually requires

The operative federal private-sector privacy law is still PIPEDA, built on ten fair information principles and overseen by the Office of the Privacy Commissioner of Canada.¹ The important point for this discussion is what it does not say. The OPC's own published guidance is explicit: "PIPEDA does not prohibit organizations in Canada from transferring personal information to an organization in another jurisdiction for processing."²

What PIPEDA does instead is attach accountability to the data rather than to the border. The same guidance says "An organization is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing," and that organizations should advise customers "that their personal information may be sent to another jurisdiction for processing and that while the information is in another jurisdiction it may be accessed by the courts, law enforcement and national security authorities."²

Read plainly, that is a transparency and accountability obligation, not a geography rule. You may transfer. You must remain answerable, and you must tell people.

Quebec is the real constraint

The closest thing in Canadian private-sector law to a residency-style obligation is Quebec's Law 25. It came into force in three stages, not one: first provisions in September 2022, the majority in September 2023, and data portability on 22 September 2024. Before communicating personal information outside Quebec, an organization must carry out a privacy impact assessment. Administrative monetary penalties can reach 2% of worldwide turnover or $10 million.³

Higher penal figures circulate widely in law-firm summaries. This article cites only the administrative penalty the regulator itself publishes, because that is what could be read directly from the source.

Federal AI legislation, as it actually stands

Bill C-27, which contained the Artificial Intelligence and Data Act and a replacement for PIPEDA's private-sector rules, was never voted down. It died on the Order Paper at committee stage when Parliament was prorogued on 6 January 2025.⁴ The live bill is C-36, introduced 15 June 2026, which would enact the Protecting Privacy and Consumer Data Act and amend PIPEDA. When checked on 20 September 2026 its status was second reading in the House of Commons.⁵

The government describes the proposed act as "the most significant change to Canada's private-sector privacy law in over 25 years," creating a new Digital Safety and Data Protection Commission, providing administrative monetary penalties up to $10 million or 3% of global revenue, whichever is greater, and fines up to $25 million or 5% of global revenue, and increasing transparency around automated decision systems including those powered by AI.⁶ Every verb in that sentence is conditional on purpose. It is a bill, not a law. PIPEDA remains in force.

Alongside it sits a national AI strategy announced on 4 June 2026, with priorities including public trust and Canadian sovereignty, committing the government to modernize privacy and online safety laws.⁷ A strategy, not a statute.

If you are federally regulated in financial services, one more date matters. OSFI Guideline E-23 on model risk management was published on 11 September 2025 and takes effect on 1 May 2027. It covers traditional actuarial models as well as AI and machine learning, and says that "the extensive use of advanced AI/ML techniques should have correspondingly mature governance and oversight."⁸ It is not in force today. It is close enough that designing for it now is cheaper than retrofitting.

Residency is not immunity

The strongest argument for keeping data in Canada is usually stated as protection from foreign legal process. It is worth being accurate in both directions here, because the loudest claims on each side are wrong.

The United States CLOUD Act, enacted in March 2018, lets US authorities compel a provider subject to US jurisdiction to produce data in its possession, custody or control regardless of where that data is stored, and allows executive agreements with qualifying foreign governments.⁹ Storing data in a Canadian region does not by itself place it beyond that reach, because the reach follows the provider's jurisdiction, not the disk.

The other half, from the provider's own published position: the Act "applies to any service provider with operations in the U.S., not just companies with U.S. headquarters"; it "Does not give the U.S. government or any government unfettered or automatic access to data"; the provider says it "will use every reasonable effort to redirect law enforcement to the customer and will notify the customer if legally permitted"; and it states it "has not disclosed any enterprise or government content data stored outside the U.S. to the U.S. government since we started reporting the statistic in 2020."¹⁰

Both halves belong in the same paragraph. Residency does not remove the exposure, and the exposure is narrower than the marketing on either side suggests. The honest mitigation to point at is not geography. It is keys: encryption with customer-managed keys under your own control changes what a compelled production can actually yield, which is why key custody is a posture-tier decision here rather than a footnote.

What Ottawa means by sovereign

Canada is spending real money on sovereign compute, and the way the government defines the word is more useful to a buyer than the dollar figures. Its infrastructure programme requires a "Canadian-located, Canadian-governed system that ensures data residency, operational control, and decision-making authority and agency remain in Canada."¹¹

Three tests, and location is only the first. An organization that stores in Canada but cannot see its own configuration, cannot change its own policy and cannot leave its vendor has satisfied one of the three. That is a more demanding and more useful standard than a region setting, and it is the standard I would encourage any buyer to apply to a vendor claiming sovereignty.

On the money, one caution: the 2024 strategy committed $2 billion over five years across three streams, and Budget 2025 proposed $925.6 million over five years for large-scale sovereign public AI infrastructure, of which $800 million came from funds previously provisioned.¹¹ Those figures overlap. Do not add them together, as a good deal of commentary has.

Two different residencies

Here is the distinction that most residency conversations skip, and it is the one that actually determines what you can use.

Storage residency is where your documents, indexes, user records and logs sit at rest. It is a per-deployment choice, it is easy to verify, and it is what most people mean when they say their data stays in Canada.

Inference residency is where a prompt is processed when a model answers it. It is a separate setting, it is invisible from the storage configuration, and by default across this industry it is not pinned at all. Managed model services commonly route requests across regions for capacity, and at least one provider documents the case plainly: prompts and responses are processed within the customer-specified geography "unless you are using a Global or DataZone deployment type," in which case they "may be processed in any geography where the relevant model sold by Azure is deployed."¹² The same kind of distinction exists at the other providers.

So a deployment with data at rest in Canada, under a default profile, has inference wherever the provider routes it. That is not a scandal and it is not a secret, but it is very often not what the buyer believes they bought. Ask any vendor for the two settings separately, and ask which one their residency claim refers to.

What pinning actually costs

Our model catalogue is generated by script from the provider's live catalogue and classified by where inference actually runs. Nobody types model names into copy here: a hand-maintained list goes stale within weeks, and a stale list in a compliance conversation is worse than no list.

At the 5 September 2026 generation the catalogue held 104 active models from 18 labs. From the point of view of a Canadian deployment: 13 process in-region in Canada, 1 is routed within Canada only, 18 are reachable but processed outside Canada, and 72 are served from United States and global regions.

The thirteen are the whole story. The in-Canada generation set is previous-generation: Claude 3 Sonnet and Haiku, Llama 3 8B and 70B, Mistral Large 24.02, Mixtral 8x7B, and Mistral 7B. Every current frontier model routes outside Canada.

That is the price, stated as plainly as I know how. Pinning a deployment to Canada is a genuinely enforced control, and it costs you the models most people mean when they say AI. For classification, extraction, routine summarization and a good deal of internal drafting, a previous-generation model is adequate and the trade is easy. For the reasoning-heavy work that made somebody excited about this in the first place, it is not.

Refused in words, not rerouted

There is a second design decision hiding behind the residency toggle, and it matters more than the toggle itself: what should happen when someone selects a model that has no compliant route.

The convenient behaviour is to route the request to the nearest available region and return the answer. The user is happy, the product looks capable, and the control you sold has quietly not applied. The correct behaviour is to refuse the request with a reason, and to say which models are available instead.

This is enforced rather than promised: with a residency pin in place, inference outside the configured endpoint regions is denied by cloud identity policy, so a code path that tried to reroute would fail rather than succeed quietly. If you only test one thing about a vendor's residency control, test this one. Ask them to pin a deployment and then ask for a model that cannot comply, and watch what comes back.

Deciding per workload

The mistake is deciding residency once, for the whole organization, at the sensitivity of the most sensitive thing anyone might ever do. That buys a previous-generation model set for the entire company because of one workload. Decide per workload instead.

These are starting positions for a conversation with your counsel, not determinations. The column that matters in a review is the last one: a residency decision with no stated cost has not been made, it has been assumed.

Two observations from doing this with real organizations. First, the set of workloads that genuinely require a Canadian inference pin is usually much smaller than the opening statement implies, and finding that out takes about an hour. Second, the transparency obligation the OPC describes is easier to meet than people expect, and meeting it explicitly is often what unblocks the workloads that do not need a pin.

The honest summary

Data residency is configurable, pinned to your region when you need it. That sentence is true and it is incomplete without the next one: pinning costs you the current frontier models, because at the last generation of our catalogue not one of them published a route inside Canada.

Anyone selling you residency as a free checkbox is selling you a setting they have not measured. Anyone telling you residency makes your data untouchable by foreign process is overstating it in the other direction. The defensible position is narrower than both: decide per workload, write down what each decision costs, keep the keys, and insist that a request with no compliant route is refused in words rather than quietly sent somewhere else.

There is a fuller treatment of the account-ownership argument in why your models run inside your cloud, and the product-side detail lives on data residency and posture tiers.

Sources