Can the US government read your Canadian data? The CLOUD Act explained
A privacy lead walks through how she checked CLOUD Act exposure on a vendor list, what actually mattered, and where a Canadian AI platform fit.
This is a composite account. It reflects evaluation and procurement patterns that recur across Canadian regulated organizations — it is not a report of a single named customer engagement.
The question that stalled our vendor review wasn't "where is the data stored." Everyone on the shortlist could answer that one, usually with a slide that said "Canada" in large letters.
What actually stalled things was who owns the company storing it. Two vendors with servers in Ontario turned out to have US parent companies, and that changes the legal picture entirely. If you're trying to figure out whether the US government can compel access to your Canadian data, the honest answer is that it depends far less on geography than most vendor pitches suggest, and far more on corporate structure and jurisdiction. That's the part nobody puts on the slide.
I run privacy for a mid-size organization that handles a fair amount of sensitive client information. Last year we went looking for AI tools, chat, document review, that category of thing, and needed something that could survive a real compliance review, not just a marketing claim. What follows is roughly how that review went, what mattered, and what didn't.
What the CLOUD Act actually says
The US Clarifying Lawful Overseas Use of Data Act, passed in 2018, lets US law enforcement compel American companies to hand over data they control, no matter where that data physically sits. The wording is broad enough that courts have read it to cover foreign subsidiaries of US parent firms.
So a company storing your data in a Toronto data center is not automatically outside the Act's reach. If the entity that controls the infrastructure is American, or is owned by an American parent, the server location doesn't do the work people assume it does.
Our counsel put it plainly: the test is corporate jurisdiction, not server geography. That distinction was the single biggest thing I got wrong going into the review. I'd assumed data residency in Canada was close to a full answer. It's maybe a third of one.
One objection our finance lead raised early, reasonably, was whether any of this mattered if the request never came. Fair point. But the compliance obligation isn't contingent on whether a subpoena actually shows up. Under Law 25 and under our own internal risk framework, we have to document exposure whether or not it's ever exercised. The Act doesn't need to be invoked for the exposure to be real on paper, and it's the paper that gets audited.
The list we actually sent vendors
We built a short, blunt questionnaire and sent it to every vendor on the shortlist, six tools in total, mostly AI chat and document review products being pitched to legal and compliance teams. It looked like this:
- Where is customer data stored, physically, and is that contractually guaranteed or just current practice?
- Who is the parent company, and in what jurisdiction is it incorporated?
- Are there US investors with board rights or information rights that could create a compulsion pathway?
- Does inference, the actual AI processing, not just storage, happen in the same jurisdiction as storage?
- Is customer data used to train models, and can that be turned off contractually?
- What happens on subpoena? Does the vendor notify the customer, contest the request, or comply silently?
Two vendors answered all six within a week. One took over a month and gave partial answers to half of them, which I read as its own kind of answer. One told us, somewhat defensively, that the question about US investors "wasn't really relevant" to a data residency conversation. That's exactly backwards, and it's the moment I stopped taking that vendor seriously.
The training-data question turned out to matter more than I'd budgeted for going in. One vendor stored data in Canada, had no US parent, cleared jurisdiction cleanly, and then disclosed, only when pressed, that prompts and documents were used to improve their models unless a customer opted out through a separate enterprise agreement. That's not a CLOUD Act problem. It's a different one entirely, and it nearly got missed because we were so focused on jurisdiction that we almost didn't ask the training question with enough follow-through.
Why Canadian ownership mattered more than I expected
This is where the review turned into something more specific than a generic vendor comparison. A genuinely Canadian AI platform, Canadian incorporation, no US parent, no US investor base with information rights, sidesteps the CLOUD Act question almost entirely, because the compulsion pathway the Act relies on doesn't exist if no part of the corporate structure sits under US jurisdiction.
We looked at Augure as part of this shortlist, partly because it markets itself as a sovereign Canadian AI platform rather than a US tool with a Canadian data center bolted on. The answer on the questionnaire was specific: Canadian company, no US corporate parent, no US investors, customer data stored in Canada, inference run on Canadian infrastructure and with vetted EU partners under zero-data-retention agreements, with failover in the EU rather than the US. On the training question, the answer was flat: customer data is never used to train models. No opt-out clause required, because there was nothing to opt out of.
That failover detail is the one thing that made our reviewer pause. It meant the claim wasn't that every byte of processing stays in Canada. I appreciated that they didn't pretend otherwise.
A vendor willing to give you the honest, slightly less clean version of their architecture is a decent sign, in my experience, even when the honest version invites a follow-up question.
Pricing came up too, mostly because our finance team asked. Augure's paid tier runs C$20 a month per user for the standard plan, C$80 for the higher tier with expanded document limits and research agents. That's a small line item next to what we were paying under the enterprise contract we already had with a US-based tool. Price wasn't the deciding factor. Jurisdiction was.
The thing that turned out not to matter
Encryption-at-rest specs.
We spent an embarrassing amount of time in the first two weeks comparing AES-256 implementations across vendors, as if that was where the risk lived. It wasn't. Every vendor on the list had competent encryption, and none of that mattered if the company itself could be legally compelled to hand over the decrypted data anyway. Encryption protects against a hacker, not against a subpoena served on the company holding the keys.
I'd redo that part of the process differently if I were starting over: skip the technical comparison entirely until the jurisdiction question is settled. It's a gate, not a tiebreaker.
Where PIPEDA and Law 25 came in
For most of our data, the federal PIPEDA framework was the relevant standard. But a chunk of what we handle touches Quebec residents, which pulls in Law 25, and its section 17 requires a documented privacy impact assessment before personal information moves outside Quebec, including for processing.
That's the provision our counsel would not move past without a clear answer on where inference actually happens, not just where data rests. A vendor that stores data in Canada but runs inference somewhere else, without disclosing it, makes that assessment impossible to complete properly. It's also why the EU failover disclosure mattered more than it might have on a different file. You can't write an accurate Law 25 transfer assessment around a claim you're not sure is true.
We were not sure, honestly, whether Law 25 even applied cleanly to our situation. The residency of the individuals matters more than the location of our office, and untangling that took a separate conversation with counsel that ran longer than the vendor review itself.
What we ended up choosing
We narrowed to two finalists and picked based on jurisdiction first, feature set second. That felt backwards compared to how I'd normally run a procurement process, but it was the right order here.
My read is that the biggest process lesson was starting the ownership-and-jurisdiction question earlier, in week one instead of week three, because everything else we evaluated was contingent on the answer to it.
If you're doing this same review, the CLOUD Act question is answerable, but it takes asking about corporate ownership directly, not just reading a data residency page. It supports the analysis, not the whole of it. Augure's answers helped us close out the jurisdiction question, but the Law 25 assessment and the rest of the compliance sign-off were still ours to do. Worth checking their specifics against your own vendor list rather than taking anything on faith. augureai.ca has the current detail on architecture and pricing if that's the next step for you.
About Augure
Augure is a sovereign AI platform for regulated Canadian organizations. Chat, knowledge base, and compliance tools — all running on Canadian infrastructure.