A US company can store your data in Toronto and still have to hand it over

The US CLOUD Act does not care where a server is bolted to the floor. Passed in 2018, it compels any company subject to US jurisdiction to turn over data in its possession when a US court orders it. That includes data sitting in a data centre in Toronto or Montreal. One fact, and it's why "data residency" and "data sovereignty" have quietly become two different claims — and why more Canadian buyers are asking vendors to prove the difference rather than assume it.

The claim vendors make, and the one they skip

Search "data residency Canada AI" and the results read almost identically: servers in Canada, encryption at rest, a badge referencing SOC 2 or ISO 27001. All of that can be true and an organization can still be exposed to a US subpoena. The CLOUD Act's reach is defined by possession, custody, or control — a legal test tied to the company, not the country.

The US Department of Justice has been direct about this in its own guidance on the statute, describing it as applying to data controlled by covered providers regardless of where that data is stored. A company can be headquartered in Seattle, lease a data centre in Ontario to satisfy a Canadian client's residency requirement, and still be legally required to hand over that same data under a US warrant. The compelling authority is corporate jurisdiction, not server geography.

Canadian regulators have not been shy about naming the risk. The Commission d'accès à l'information du Québec, in guidance tied to Law 25's cross-border transfer assessment requirements, directs organizations to evaluate not just where personal information is stored but what legal regime governs the entity holding it. That distinction sits at the centre of a proper Privacy Impact Assessment for transfers outside Quebec. It's also the step a lot of procurement checklists skip, because "Canadian data centre" sounds like it already answered the question.

There is a narrower version of this that a skeptical reader will raise, and it deserves a straight answer: does a mutual legal assistance treaty change any of this? MLATs let Canadian authorities request data through a formal government-to-government channel, and some observers assume that channel displaces the CLOUD Act for Canadian subjects. It doesn't. The CLOUD Act was written specifically to give US prosecutors a faster unilateral path than an MLAT request, which is the entire reason the statute exists — DOJ complained for years that MLAT requests to foreign providers took months. A Canadian company's data sitting with a US-jurisdiction provider can still be reached directly by a US warrant without Canadian authorities ever being in the loop, MLAT or not.

What sovereignty actually requires

Sovereignty, in the sense procurement teams should mean it, requires three things to line up: where data is stored, where inference happens, and which country's courts have authority over the company running the stack. Miss one, and the other two don't fully protect the organization.

Encryption at rest is often presented as the fix. It isn't, and it's worth being specific about why. Data sitting encrypted on disk isn't usable — a model can't reason over ciphertext, so the system has to decrypt it somewhere in the pipeline to run inference. If the company operating that pipeline is under US jurisdiction, a valid order compels production of the data in whatever state that company can access it, encryption notwithstanding.

The compelling authority in the CLOUD Act is jurisdiction over the company, not the location of the server. That's the sentence worth repeating to a legal team, a CISO, or a Law 25-designated privacy officer. The right question isn't where the data centre sits. It's who can be legally ordered to open it, and under whose courts.

A second objection, less often raised but worth answering directly: what about a warrant challenge? United States v. Microsoft Corp. — the 2018 case the CLOUD Act was drafted to moot — turned on exactly this question, and Congress resolved it in the government's favour before the Supreme Court could rule. A company can still contest a specific order under the Act's comity provisions, arguing the disclosure would conflict with the law of the country where the data sits. But that's a company choosing to litigate, at its own cost, after the order has already issued. It is not a structural bar to disclosure, and nothing in a Canadian buyer's contract with the vendor can compel the vendor to make that fight.

Where Canadian AI platforms actually differ

This is where the market has started to split, and it's worth being concrete rather than taking a vendor's word for it. Augure, a Toronto-built platform marketed to regulated Canadian organizations, stores customer data in Canada and runs inference on Canadian infrastructure and with vetted EU partners under zero-data-retention agreements — never US providers — with EU capacity also serving as fallback to maintain high uptime. Augure says it has no US corporate parent and no US institutional investors. That's a claim a buyer should check against incorporation records, not a marketing page.

The failover detail matters more than it looks like it should. A Law 25 transfer assessment doesn't ask whether a vendor is Canadian in a general sense. It asks specifically where data goes and under what legal regime, including backup and failover paths. A vendor that discloses EU failover plainly gives a privacy officer something concrete to assess. A vendor that claims all processing stays in Canada without qualifying failover is making a claim that's hard to verify, and worse for the buyer's compliance file if it turns out untrue.

Other players in the Canadian AI space make similar residency claims. Cohere, built and headquartered in Toronto, has argued its own model training and much of its inference infrastructure sit outside the reach of foreign cloud dependencies, though its enterprise deployments vary by customer contract and cloud partner. In every case, the distinction buyers need to press on is corporate jurisdiction and ownership structure — not just the country listed on a hosting page.

There's a version of the corporate-structure question that gets skipped even by procurement teams that know to ask it: reseller and subprocessor chains. A vendor can be Canadian-incorporated, Canadian-owned, and still route customer data through a US-domiciled subprocessor for a function as mundane as email delivery, analytics, or customer support tooling. Law 25's assessment obligation extends to those downstream transfers, not just the primary vendor relationship, which means the incorporation question has to be asked twice — once of the AI vendor, once of whatever subprocessors sit behind it. A vendor's data processing addendum, not its homepage, is where that chain is supposed to be disclosed.

The compliance angle nobody wants to own alone

PIPEDA doesn't name the CLOUD Act. It doesn't need to. Its accountability principle already puts the burden on the organization collecting personal information to know where that data goes and who can access it, contractually and legally, once it's handed to a processor. Quebec's Law 25 goes further procedurally, formalizing the Privacy Impact Assessment for any transfer outside the province and requiring organizations to document the legal protections of the receiving jurisdiction before the transfer happens, not after a regulator asks.

Neither statute forces an organization to choose an exclusively Canadian AI vendor. Both turn the choice to use a US-jurisdiction vendor for regulated data into a documented risk decision rather than a default one. That's a meaningful shift in where liability sits. It's also part of why procurement conversations that used to end at "is it encrypted" now routinely reach a jurisdiction question that legal counsel, not IT, has to sign off on.

The practical cost of getting this wrong doesn't show up as a fine most of the time. It shows up as the assessment itself becoming indefensible. A Law 25 Privacy Impact Assessment that lists a vendor's Canadian data centre address but never asks who owns the company is a document a regulator can pick apart in an afternoon if there's ever a complaint or a breach investigation. The CAI's own guidance frames the assessment as a substantive analysis of legal protections in the receiving jurisdiction, not a location lookup. An organization that skipped the ownership question has produced paperwork, not an assessment, and that gap tends to surface at the worst possible moment — during an incident review, with counsel asking why nobody checked.

None of this is static. The CAI has signalled continued enforcement attention on cross-border data flows through its published guidance and decisions, and the federal government's effort to modernize PIPEDA through Bill C-27 was still working through Parliament as of the last session before prorogation. The rules an organization is building compliance programs against today may not be the final version. A vendor's jurisdiction claim, unlike a bill's text, tends to be the more stable thing to verify right now.

What a checkable claim looks like

The gap between residency and sovereignty isn't abstract, and it isn't hard to test. A procurement team can ask a vendor three direct questions and get answers that are either checkable or evasive: where is the company incorporated, who are its investors, and is there any reseller or infrastructure agreement with a US-domiciled entity anywhere upstream. Augure publishes its answers to those questions on its own site rather than leaving them to a sales call. That's the standard any Canadian AI vendor claiming sovereignty, not just residency, ought to be measured against.

Verifying incorporation and ownership is not exotic work, and it doesn't require a subpoena of the vendor's own. Provincial and federal corporate registries publish incorporation records and, in many cases, director information, for a nominal search fee. Investor disclosure is thinner — private companies aren't obligated to publish a cap table — which is precisely why a vendor's willingness to state its ownership structure in writing, rather than leave it to inference from a registry search, carries more weight than the registry search alone.

Anyone trying to verify this for a specific deployment should start at augureai.ca and read the architecture documentation directly, rather than the marketing copy sitting above it.