Cross-border data transfer Canada: Rules, risks, and exceptions

The question that stalled our AI vendor selection wasn't whether the tool could summarize a contract well. It was whether our privacy lawyer could answer, in writing, where the prompt went after we hit send. That turned out to be harder than the product demo made it look, and it's the reason we ended up running a full cross-border data transfer Canada review before signing anything.

We're a mid-size firm doing regulated work. Client files with health information, financial records, sometimes both. Two different clients in the same quarter had asked whether our AI tools sent data outside Canada. Not "do you use AI." Specifically: where does it go. I didn't have a confident answer, and neither did the IT lead I asked first. That gap is what started the review.

What counts as a Law 25 data transfer

My first assumption was wrong, and it cost us a week. I thought a cross-border transfer meant data physically crossing the border, servers in Virginia versus servers in Toronto. Quebec's Law 25 doesn't frame it that way. The relevant provision — our privacy officer worked from section 17, though we'd flag that anyone relying on this should have counsel verify the current section number against the official consolidated statute rather than take our word for it — requires an organization to assess a disclosure before sending personal information outside Quebec, not just outside Canada, weighing sensitivity, purpose, protective measures, and the legal framework of the destination. A transfer from a Quebec office to an Ontario data centre is, technically, in scope for that assessment even though nothing left the country.

Our privacy officer's read, and I'll say plainly this is her read, not a settled legal conclusion, was that most AI vendors' privacy pages are written for PIPEDA's accountability principle instead. PIPEDA is built around ten fair information principles, of which accountability is one, and the Office of the Privacy Commissioner can investigate and, since 2023 amendments strengthened its position, seek Federal Court orders and recommend penalties in serious cases. But that framework is broader and more general than Quebec's transfer-specific test, and it doesn't actually address the comparative assessment Law 25 demands. That mismatch is roughly where half our vendor questions came from.

The part I hadn't worked through until our privacy officer pushed on it: a Law 25 data transfer assessment isn't a one-time checkbox. It's a comparative assessment, meaning you're not just documenting that a transfer happens, you're documenting why the destination's protection is equivalent to what the data would get if it stayed put. That means naming the specific law you're comparing against, not just gesturing at "similar protections." For a transfer into a US-controlled system, the comparison point is PIPEDA versus whatever the US CLOUD Act and US surveillance law would allow, and that comparison does not flatter the US side. Our privacy officer's document ended up citing the CLOUD Act by name inside the memo itself, which I hadn't expected going in — I'd assumed the two analyses would stay separate. We also noted, for the file, that Quebec's penalty regime under Law 25 is not decorative: administrative monetary penalties can reach C$25 million or 4% of worldwide turnover, whichever is greater. That number is what got the review prioritized on the partners' desks when nothing else would.

The CLOUD Act Canada problem our counsel would not move on

Here's the part that mattered more than I expected going in. The US CLOUD Act — the Clarifying Lawful Overseas Use of Data Act, enacted in 2018 — allows US law enforcement to compel a US-headquartered company to produce data it controls, regardless of where the server storing that data physically sits. A vendor with servers in Montreal but a US parent company doesn't necessarily solve the exposure. The legal reach follows corporate control, not geography alone. Our outside counsel flagged this early and wouldn't soften it: for the file types we handle, a US corporate parent was, in her professional opinion rather than as settled statute, a disqualifying fact on its own, independent of where the servers were. We're presenting that as her legal judgment on our specific fact pattern, not as a general rule every firm should apply without its own advice. For readers who want the deeper mechanics, we've covered how the CLOUD Act actually works against Canadian data separately.

That reframed the whole search. We stopped asking "is the data stored in Canada" as the first question and started asking "who is the parent company, and under what jurisdiction can they be compelled to produce customer content." Server location became the second question, not the first.

One thing a skeptical partner raised, fairly: doesn't a mutual legal assistance treaty request accomplish roughly the same thing anyway, so why does corporate parentage matter so much? My read, and I want to flag this as my own layperson's understanding rather than a legal conclusion I'm qualified to certify, is that the difference is procedural friction. An MLAT request runs through Canadian courts and Canadian process before anything moves, with a Canadian judge somewhere in the chain. A CLOUD Act order to a US parent skips that entirely and compels production directly from the US entity, regardless of where the data sits. Counsel's view was that friction is the whole point, not a technicality, but I'd tell anyone reading this to verify the current state of that comparison with their own counsel rather than treat it as settled. Our board-level summary of these questions borrows from the CLOUD Act questions Canadian boards are asking now, which is a useful gut-check before a vendor conversation even starts.

Questions we actually put to vendors

We sent a fairly blunt list to every AI vendor under consideration, including ones we already used for other things. In order:

• Who is your ultimate parent company, and in what jurisdiction is it incorporated?
• Where does inference run, not just where is data stored at rest, but where does the model actually process the prompt?
• Do you have failover infrastructure, and if so, where is it, and under whose control?
• Is customer content ever used to train models, yours or a third party's?
• Can you provide a sub-processor list, and does it include any US-jurisdiction entity?

That last one produced the most useful answers, honestly, because it's the one most sales reps had to go check with engineering instead of answering off the top of their head. We eventually turned this into something closer to a formal buyer's checklist for a CLOUD Act-free AI stack, which would have saved us time if we'd built it before week one instead of week four.

Where the answers diverged

Two of the big US-based platforms we evaluated gave answers that were technically accurate and functionally useless. Data residency options for storage, sure, but inference routed through US infrastructure regardless of where the customer was billed from, and a parent company squarely under CLOUD Act reach. One offered a Canadian data residency add-on that, when I actually read the fine print with our reviewer, only covered storage, not processing. That distinction, storage versus inference location, is the one thing I'd tell a colleague to check first, because it's the one every vendor's marketing page blurs. For the mechanics of how this specific conflict plays out against Canadian privacy law, our longer piece on CLOUD Act versus PIPEDA walks through it in more depth than we have room for here.

The Augure conversation went differently

Augure was one of the platforms we looked at partly because it doesn't have that structure to untangle. Based on what the vendor represented to us — no US corporate parent, no US investors — the CLOUD Act's reach over US-controlled providers wouldn't extend to the customer content sitting in the platform. That's the specific claim, not a blanket "not subject to the CLOUD Act," and I want to be precise about that because the difference matters to our counsel even if it sounds like hair-splitting to everyone else. We didn't independently audit Augure's cap table; we relied on their representations and their published sub-processor documentation, the same way we did for every other vendor on the list.

Pricing for the tier we'd actually use, with priority models and persistent memory, was C$20 a month per seat. The Max tier at C$80 added deep research agents we didn't end up needing yet.

When we asked directly where inference runs, Augure's answer was Canadian infrastructure for the flagship model tiers, with EU partners under zero-data-retention agreements handling other tiers and failover. Not a "your data never leaves Canada" line, which I'd have distrusted more if they'd said it. They also told us upfront that payment processing and email delivery involve US systems. That's a limitation to weigh, and I noted it because nobody else had volunteered that without being asked twice.

The thing that turned out not to matter

Data residency at rest, the physical location of the storage servers, mattered far less to our final recommendation than I expected walking in.

Once corporate parentage and inference location were sorted out, the storage question mostly resolved itself. A Canadian company under Canadian jurisdiction tends to store Canadian customer data in Canada anyway, largely because PIPEDA and provincial regimes push in that direction regardless. I'd spent real time early on building a comparison matrix of data centre locations that, by the end, told us almost nothing we couldn't have gotten from the parent-company question alone. Our broader read on where the landscape sits going into next year is in Canadian data sovereignty in 2026: what's changed, which covers more ground than we could fit into a single vendor review.

What I'd tell someone starting a cross-border data transfer Canada review now

I'd start with the ownership question, not the infrastructure question, because ownership determines legal exposure in a way server location alone doesn't. I'd also budget more time than I did. We told the partners four weeks and it took six, mostly because vendors took longer to produce sub-processor lists than to produce demo accounts.

And I'd be honest that we still don't have a fully settled answer on how a Law 25 comparative transfer assessment interacts with a vendor's EU failover arrangement. Our privacy officer's current position is that it needs its own documented assessment, separate from the CLOUD Act analysis, and we haven't finished that second document yet. Quebec's Commission d'accès à l'information hasn't, to our knowledge, published guidance directly on point for this exact fact pattern, so we're working from the statutory text and counsel's judgment rather than a settled interpretation. I'm not certain that's the right sequencing, but it's where we landed.

What I can say with more confidence is that a Canadian AI platform, genuinely Canadian, meaning the parent company and not just a marketing page, turned a two-part legal question into roughly one part. That's not nothing when you're billing the review time to a client file.

If you're doing this comparison yourself, augureai.ca has the privacy policy and sub-processor detail laid out. That's the document I'd ask your own counsel to read before anyone signs anything, alongside the current text of Law 25 on Quebec's official legislation site and the Privacy Commissioner's guidance on cross-border data flows.