Two decisions wear the same word, and conflating them is how a residency commitment quietly becomes untrue.
Where your data sits at rest and where a request is processed are two different settings, and only one of them is free. This page gives you the catalogue numbers behind the second one, the exact set of models a Canadian pin leaves you, and the legal context in measured terms. Then you can decide per workload rather than per slogan.
Almost every residency conversation starts in the wrong place, because the phrase "our data stays in Canada" covers two facts that are configured separately and cost very different amounts. Storage region is a deployment parameter and is essentially free. Inference residency is a capability decision, and on today's catalogue it is expensive. A deployment storing in Canada with default routing has inference wherever the provider sends it, so this page prices both halves before you choose either.
The storage region is chosen when the deployment is built. Documents, the knowledge index, sessions and messages, usage and metering records, module stores and audit records are created there and stay there. This is the cheap half of the decision, and for many organizations it is the half their obligations actually turn on.
Inference routing is separate. By default a deployment uses global routing: the provider may run the request in any region with capacity, and the crossing is disclosed and recorded rather than assumed away. Pinning it is a real, enforced control at the Strict posture, and the price is the model list below.
These are not estimates. The model catalogue is produced by script from the provider's live list and classified by where inference actually runs from a Canadian deployment, then read by the site, the product and the agent index. Nobody retypes model names into copy here. Generated 5 September 2026.
Pin a deployment to Canada and generation is limited to a previous-generation set: Claude 3 Sonnet and Claude 3 Haiku, Llama 3 8B and 70B, Mistral Large 24.02, Mixtral 8x7B and Mistral 7B, plus one small model family routed within Canada only. Retrieval and reranking are well covered. Every current frontier model routes outside Canada. Exactly one cross-region routing profile scoped to Canada exists in the whole provider catalogue, measured August 2026, and the frontier vendors publish none. The second model plane, the one with an alternative request format, has no Canadian region at all.
Per-account entitlement varies, and a catalogue is a snapshot of a date. The figure that matters is the shape, not the decimal: the current generation is not available under a Canadian pin today, and no amount of configuration on our side changes that.
The dangerous version of this feature is the one that accepts your pin, then falls back to a compliant-looking route when a model is not available in region, and tells nobody. You would pass a review and fail the fact.
Three positions, chosen during discovery and recorded in the posture object that builds your infrastructure. There is no fourth position where you get current-generation models and a Canadian pin at the same time, and a vendor offering you one is describing a routing profile that does not exist.
| Question | Pinned | Flexible, with disclosure | Global |
|---|---|---|---|
| Storage at rest | ✓Your chosen region | ✓Your chosen region | ✓Your chosen region |
| Where inference runs | ✓In-country destinations only, enforced | △May cross regions; the crossing is disclosed and recorded | ✕Any region the provider has capacity in |
| Models available | ✕Previous-generation in-country set | ✓Whole catalogue | ✓Whole catalogue |
| If a model has no route | ✓Refused in words, with the reason | ✓Not applicable | ✓Not applicable |
| Posture it belongs to | △Strict | △Standard, recorded as a decision | △Baseline and Standard default |
| What your reviewer gets | ✓An enforced control plus the model list it costs | ✓A written disclosure of the crossing | △An accurate description, not a residency claim |
The middle column is not a weaker pin; it is a different, stated position: your data rests where you chose, and the processing of a request may cross a border, on the record.
Residency is usually treated as a single company-wide switch. It rarely needs to be. Most organizations have a small set of material that carries the obligation and a much larger set of work that does not, and the sensible arrangement is to route them differently and say so.
Not "our data": the specific material whose handling a regulator, a contract or a customer commitment actually constrains. In most organizations it is a fraction of what people want to ask questions about.
A pinned deployment for the constrained corpus, on the in-country models, which are adequate for a great deal of retrieval and summarisation work. Other work reaches the current frontier models with the crossing disclosed. The tradeoff is explicit per body of work, rather than averaged into a claim that fits neither.
The decision lands in the posture object that builds the infrastructure, surfaces on the in-product plan page, and appears in the export your compliance program consumes. Any override you asked for carries its written reason and shows as a standing exception, so a future reviewer reads the decision rather than reconstructing it.
Residency copy in this market leans on two opposite fictions: that Canadian law requires Canadian storage, and that Canadian storage puts data beyond foreign reach. Neither is right. Here is the sourced version, in measured terms.
The federal privacy regulator states plainly that the Act "does not prohibit organizations in Canada from transferring personal information to an organization in another jurisdiction for processing". What it does require travels with the data: 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 must advise people that their information may be sent to another jurisdiction and may be accessed there by courts, law enforcement and national security authorities.
Under Law 25, before communicating personal information outside Quebec an organization must carry out a privacy impact assessment. It is the closest thing in Canadian private-sector law to a residency-shaped obligation, and it is a process requirement rather than a prohibition. The province's administrative monetary penalties can reach 2% of worldwide turnover or $10 million.
The US CLOUD Act, enacted March 2018, lets US authorities compel a provider subject to US jurisdiction to produce data in its possession, custody or control regardless of where it is stored, and allows executive agreements with qualifying foreign governments. So storing in Canada does not by itself remove the exposure, and the Act is not a general-access door either. The mitigation worth discussing is key custody: customer-managed keys with rotation, available at the Strict posture.
We are engineers, not counsel, and nothing on this page is legal advice. What we can do is make the technical facts exact enough that your counsel can apply them: which region holds which store, which routing a request may take, who holds the keys, and what is written down when any of that changes. The rest is a conversation with your own advisors.
No, and we will not write that sentence. We can pin storage to a Canadian region at any posture, and at Strict we can enforce in-country inference, at which point the model list you can use is the previous-generation set named above. If you need current-generation models, the request is processed outside Canada and we will say so in writing. The honest formulation is the one we use everywhere: data residency is configurable, pinned to your region when you need it.
Shipped and enforced: an identity policy scoped to in-country destinations plus the request-time refusal, exercised in our own testing. If you need the pin, it is a posture selection and a deploy, not a development project.
The index sits in your storage region and retrieval runs there, so the search itself is in region regardless of posture. What crosses is the question and the retrieved passages, as part of the inference request. That is the same crossing described on the boundary, and it is governed by the same four denies.
It was generated on 5 September 2026 from the provider's live catalogue, and the providers change it frequently. We regenerate it as part of managed operations rather than editing copy by hand, which is why the numbers on this page and the model list in your product come from the same file. See model access for how the catalogue is produced and classified.
Then the cheap half of the decision is the half you need, and you should probably take the flexible position: storage pinned to your region, inference crossing where the models are, disclosed in writing. Paying a capability price for a constraint your obligation does not impose is a common and expensive mistake, and we will argue you out of it.
A contractual commitment is a promise about behaviour. The pin is an identity policy that permits only in-country destinations, plus a request-time refusal when no compliant route exists. You can read the policy in your own account, and you can test it by asking for a model that has no in-country endpoint and watching the refusal come back with its reason.
Not "your data never leaves Canada". The first sentence is true at every posture and survives a reviewer reading the model catalogue. The second one does not, which is why it is not on this site.
Bring the obligation you are actually under, and we will show you what it costs in models before anyone signs anything.