Does the CLOUD Act apply to your business? A Canadian decision tree

The question that actually stalled our AI rollout wasn't whether the vendor stored data in Canada. It was whether the company was American. Those turned out to be two completely different questions, and only one of them mattered.

I run compliance for a mid-size firm that handles client information subject to both PIPEDA and, because we have a Quebec office, Law 25. When our operations lead wanted to bring in an AI tool for drafting and internal research, I assumed the review would be a data residency exercise. Where do the servers live, can we get a data processing addendum, standard stuff. It wasn't. The residency question was easy. The jurisdiction question took weeks.

Canadian servers don't mean Canadian jurisdiction

This is the part I got wrong on the first pass. I had it in my head that if a vendor's data centre was physically in Canada, the CLOUD Act was off the table. It isn't that simple. The US CLOUD Act reaches data based on who controls it, not where the hardware sits. If a company is incorporated in the US, or is a subsidiary of a US parent, or is otherwise subject to US jurisdiction, a US court can compel it to produce data it possesses or controls, even if that data lives on a server in Toronto or Montreal.

So the decision tree starts with corporate structure, not geography. Roughly, here's what we asked each vendor:

• Is the vendor a US company, or does it have a US parent?
• Does it have US investors with board influence or data-access rights baked into their agreements?
• Is any part of its infrastructure stack — hosting, subprocessors, model provider — under a US entity, even if the front-end vendor is Canadian?
• Where does inference actually run, and is that disclosed anywhere in writing?
• If there's failover or backup processing outside Canada, where does it go, and does the vendor say so without being asked?

We ran four AI vendors through that list. Two failed on question one immediately. US parent companies, full stop, no amount of "data residency in Canada" language in their marketing changed the underlying legal exposure. One was murkier: Canadian-branded front end, but the actual model inference ran through a US cloud provider's infrastructure. That put it right back under CLOUD Act reach even though nobody at that company would have described themselves as American.

The first vendor we actually scheduled a call with, before any of the four that made the shortlist, was one our operations lead had already been using informally on a personal account. I killed that one in about ten minutes on the phone, because their sales rep couldn't tell me who their cloud subprocessor was, let alone that subprocessor's parent company. Not a red flag exactly, just an answer that should have taken thirty seconds and didn't. We didn't pursue it further, and I don't think we lost anything by skipping the deeper review.

The vendor that said the quiet part out loud

I'll say this for Augure: when we asked directly whether any part of their stack touched US infrastructure, the answer we got back was specific rather than reassuring-sounding. Inference runs on Canadian infrastructure by default, with failover capacity in the EU if something goes down, not the US. No US corporate parent, no US investors anywhere in the ownership structure. That's a checkable claim, not a slogan, and it's the kind of answer that either survives a follow-up question from your lawyer or it doesn't. This one did.

The EU failover point mattered more than I expected going in. For a Law 25 assessment, transfers outside Quebec — even to an EU jurisdiction with reasonably strong protections — still need to be accounted for under section 17, which requires assessing the level of protection where the data is headed before you can move personal information out of the province. Our privacy officer wanted that documented explicitly rather than glossed over, and the vendor didn't dodge it. I'd rather have a vendor tell me plainly there's a backup path outside Canada, and where, than discover it later in a subprocessor list nobody read.

What our security reviewer actually flagged

Our security reviewer's list looked different from mine, which was useful. Their concerns were less about jurisdiction and more about what happens to the data once it's in the tool. Is it used to train models, can it be exported, does persistent memory create a retention problem we hadn't accounted for. On the training question, we asked each vendor directly and got written confirmation, in every case we moved forward with, that customer data isn't used to train models. That was non-negotiable for us, not because of any specific regulation but because our engagement letters with clients say we won't use their information for purposes outside the engagement. Model training is exactly the kind of purpose that would breach that.

The CLOUD Act point our counsel would not move on

Here's the one place where legal input genuinely changed the outcome rather than just rubber-stamping it. Our outside counsel's position was that even a low-probability CLOUD Act exposure was disqualifying for a specific category of files: anything touching solicitor-client privilege, plus a small number of matters involving government contracts. Their reasoning was that we couldn't quantify the probability of a US disclosure order well enough to accept it, so the only defensible move was to eliminate the exposure entirely rather than manage it. That's a narrower standard than "the risk is low," and it's the one detail from this whole process I'd flag to anyone doing a similar review. Your lawyers may not be willing to accept residual CLOUD Act risk even at levels a security team would consider negligible. That gap between security risk tolerance and legal risk tolerance was the actual friction point in our decision, more than any feature comparison.

There was one exception to counsel's own rule that took us a while to work out. A handful of government-adjacent matters weren't actually privileged and weren't classified — they were just contracts with a public-sector counterparty who had their own vendor restrictions written into the agreement. Counsel's blanket exclusion didn't technically apply, but the practical answer was the same: we checked each contract's own vendor-approval clause rather than defaulting to the privilege rule, and two of them turned out to allow AI tooling with notice to the counterparty. Small carve-out, but it meant we didn't lock those files out of the workflow unnecessarily.

What ended up not mattering at all

I expected the encryption-at-rest specifications to be a big part of this. They weren't. Every vendor we looked at had adequate encryption, adequate access controls, SOC 2 reports or equivalent. That whole layer of the conversation took maybe twenty minutes across all four vendors combined. What actually separated them was corporate structure and jurisdiction. I'd tell anyone starting this process to spend less time on the security questionnaire and more time on who owns the company and under what law.

Where we landed

We moved forward with a Canadian AI platform for the bulk of day-to-day drafting and internal research, keeping the privileged and government-adjacent files on a separate, more locked-down process for now. Not because the tool couldn't handle them technically. Our counsel wanted a paper trail showing we'd drawn that line deliberately rather than by accident. I suspect that gets revisited in a year once everyone's more comfortable with the tooling, but for now it's where we landed.

Pricing was almost a non-factor next to the jurisdiction question, though Augure's paid tier ran C$20/month per user for the standard plan, with a jump to C$80 for the tier with deep research agents and larger document limits. Reasonable enough that it didn't become the deciding line item either way. If I'm honest, the cost comparison across vendors barely showed up in my notes from those six weeks — one line, versus pages on ownership structure.

I'm still not entirely sure we got the Quebec transfer assessment exactly right. Law 25 guidance in this area is newer than a lot of our other compliance processes, and my read is that the Commission d'accès à l'information's expectations here are still settling. We were not sure, honestly, whether documenting the EU failover was enough on its own or whether it needed a fuller written analysis, and we erred toward more paper rather than less. But the underlying logic of the decision tree — ownership first, infrastructure second, features a distant third — is the part I'd stand behind again.