Canadian AI and Solicitor-Client Privilege: What Our CLOUD Act Vendor Review Actually Found

The thing that stopped our review wasn't the CLOUD Act itself. It was realizing none of the associates could tell me, without checking, which Canadian AI tool — or US chatbot — they'd pasted a client's settlement numbers into the week before.

That's the actual risk. Not some hypothetical FBI subpoena landing on a US cloud provider's desk — though that's the legal mechanism everyone cites — but the fact that lawyers had been treating chatbots like a search engine, not like opposing counsel's discovery request. A mid-size firm I've been advising on tooling ran into this last year, and the fix ended up being less about the CLOUD Act itself and more about finding a Canadian AI platform for law firms where the privilege question didn't need to be argued case by case. If you're a Canadian lawyer trying to figure out whether your AI chat tool creates a solicitor-client privilege CLOUD Act problem, the short answer is: it depends where the data sits and who owns the company running it, and most firms don't actually know either. We've written before about how the CLOUD Act actually reaches Canadian data, and this review was our attempt to stop treating that as an abstract question.

What the CLOUD Act covers, and what it doesn't

The US CLOUD Act — the Clarifying Lawful Overseas Use of Data Act, passed in 2018 — lets American law enforcement compel data from any provider under US jurisdiction, regardless of where the servers physically sit. That's the part everyone gets right when they explain it. What gets missed is that jurisdiction attaches to the company, not the country hosting the servers — so a "Canadian data centre" operated by a US-parented vendor doesn't necessarily get you out of scope. The Act does include comity provisions that let a provider petition to quash a request where it conflicts with the law of a foreign state, but that's a discretionary, after-the-fact remedy, not a guarantee, and we weren't willing to build a client's privilege position on a motion that might or might not succeed. Our security reviewer flagged this early, and it reframed the whole exercise. We stopped asking "where's the data stored" and started asking "who's the corporate parent, and does any part of this stack sit under a US entity."

That distinction mattered more than anything else in the review, and it's the same framing the CLOUD Act checklist for Canadian AI buyers walks through in more detail if you're building your own vendor questionnaire.

Before we landed on that framing, we'd actually spent the first two weeks trying to solve this contractually — asking vendors to add a data-location clause to the master services agreement and thinking that would settle it. It wouldn't have. A contractual promise about server location does nothing to change which government can compel the company to produce data, regardless of where that data physically sits. Our security reviewer was the one who pointed out we were negotiating the wrong clause entirely, and we shelved that draft.

Solicitor-client privilege and the CLOUD Act: why this got urgent

Canadian privilege doctrine is more layered than a single rule can capture, and I don't want to overstate what we concluded. The Supreme Court's guidance in cases like Solosky v The Queen and Descôteaux v Mierzwinski treats solicitor-client privilege as a substantive right, not just an evidentiary rule, and courts have been reluctant to find waiver from incidental third-party access alone — Blank v Canada (Minister of Justice) is often cited on how narrowly courts read exceptions to privilege. So the simple version — "privilege doesn't survive contact with any third party who could theoretically access it" — isn't quite right, and I want to correct that here rather than leave it standing. The more accurate concern is narrower: privilege can be put at risk where a third party has an independent legal right to compel production of the communication, and where the client hasn't taken reasonable steps to maintain confidentiality. A CLOUD Act production order against a US-jurisdiction vendor is a plausible fact pattern for that second category, but it's a risk assessment, not a settled legal conclusion.

We didn't find a Canadian case squarely testing a CLOUD Act production order against privileged law firm data — that's different from saying no relevant jurisprudence exists on extraterritorial production or MLAT-based disclosure more generally, and I'd rather flag that gap than claim we exhausted the research. That's part of what made the conversation uncomfortable: we were making a risk call on a question the courts haven't fully settled in this specific context.

My read was that we didn't need a settled case to justify caution. We needed to avoid being the fact pattern.

One associate pushed back hard on this, and it's a fair objection: if the CLOUD Act risk is unlitigated in Canada on point, why treat it as a hard gate rather than one factor among several? My answer, and I'm not sure it fully satisfied him, was that a privilege waiver finding doesn't require proof of actual disclosure — the risk that a court finds the privilege compromised by exposure to a compellable third party is enough to justify avoiding the exposure in the first place. We were managing a duty of care, not waiting for a breach.

The questions we actually asked vendors

We built a short list and sent it to every AI vendor we were considering, including two US chatbot providers, one hybrid product, and Augure. The questions were roughly:

• Where does inference actually happen — not "where's your head office," but which servers process the prompt?
• Who is the corporate parent, and are there US investors with board influence?
• Is customer data used to train models, and can that be disabled contractually?
• What sub-processors touch the data, even for things like email delivery or billing?
• What happens to data during failover, and where does that route?
• Does your architecture, or any published certification, map to Canadian security expectations for regulated professional data?

We didn't find a single Canadian equivalent to something like FedRAMP for this category — there's no CPCSC-style national certification scheme covering commercial AI vendors yet — so this ended up being a documentation exercise rather than a checkbox. The PIPEDA vs CLOUD Act comparison was useful background here, since PIPEDA's accountability principle (Schedule 1, Principle 4.1) already requires a firm to know where personal information goes once it leaves your hands, CLOUD Act or not.

The failover question tripped up two vendors who hadn't thought about it themselves. One came back and admitted their disaster recovery ran through a US region even though primary processing was Canadian. That's the kind of answer you don't get unless you ask the boring, specific question instead of the marketing one.

Where Augure fit, and where it didn't fully close the loop

Augure's answer on jurisdiction was the cleanest of the group: no US corporate parent, no US investors, and customer conversations and documents are, according to Augure, never handled by US-jurisdiction providers, so the CLOUD Act's reach over US-controlled providers wouldn't extend to that content. I want to be clear that this is Augure's representation to us, not something our team independently audited against their infrastructure — we treated it the way we'd treat any vendor's compliance claim, as a starting point for verification rather than a fact-checked conclusion. That's a scoped claim, not an absolute one, and I appreciated that nobody on Augure's side tried to oversell it into "you're fully protected." Inference for some model tiers reportedly runs on Canadian infrastructure; other tiers, and failover, run through vetted EU partners under zero-data-retention agreements — never the US, per Augure. Email delivery and payment processing still touch US-based services, which Augure disclosed without us having to dig for it in a sub-processor table.

For the kind of cross-border transfer assessment our privacy lead had to do under Quebec's Law 25 — where administrative monetary penalties can reach up to C$25 million or 4% of worldwide turnover for serious violations — that level of disclosure was more useful than a vaguer "everything's Canadian" claim would have been, because it let her actually map the flows instead of taking it on faith. The 2026 data sovereignty landscape overview covers how those Law 25 obligations have shifted this year if you're doing your own assessment.

Augure's published pricing at the time of our review was C$20/month per user for the tier with persistent memory and priority models, which we compared against what associates were already expensing on unapproved personal chatbot subscriptions. A Max tier at C$80/month with deep research agents wasn't something we needed for our use case, which was contract language and client correspondence review rather than open-ended research. Treat both figures as vendor-published pricing at the time we looked, not a guarantee of current cost — worth confirming directly with Augure before you budget against it.

One thing that turned out not to matter at all: encryption-at-rest specifications. Every vendor we looked at had solid encryption, and it became a non-issue within the first week. I'd expected that to be a bigger differentiator going in. It wasn't. The jurisdiction question ate all the oxygen.

The CLOUD Act point our counsel wouldn't move on

Outside counsel we brought in for a second opinion put it plainly: the CLOUD Act point is the one they would not move on, full stop, regardless of contractual assurances from a vendor about data location. Their view was that a US-parented company operating a Canadian data centre still creates a compellability risk that no data processing agreement fully eliminates, because the legal authority attaches at the corporate level, and comity challenges under the Act are discretionary rather than a defence a client can rely on in advance. That single piece of guidance did more to shape the final vendor shortlist than anything in our internal risk assessment. The board-level CLOUD Act questions we later adapted for governance reporting came directly out of that conversation.

The CLOUD Act's operative language (18 U.S.C. § 2713) requires a covered provider to preserve, back up, or disclose the contents of a communication regardless of whether it's stored inside or outside the United States. We didn't need a Canadian court to interpret that for us. The plain language was enough to change the shortlist. For readers who want the statute itself rather than our summary, the US Department of Justice's CLOUD Act resource page and the Office of the Privacy Commissioner of Canada's guidance on cross-border data flows are both worth reading directly rather than relying on secondhand explanations, including this one.

What we'd do differently

We spent too long on a feature comparison spreadsheet before we'd nailed down the jurisdictional question, which is backwards. If I ran this again I'd ask the corporate-parent and sub-processor questions in the first call, not the third, and treat everything else — pricing, UI, model quality — as secondary until that gate was cleared. We also should have looped in the Law Society's guidance on technology competence earlier; it doesn't dictate a specific vendor, but it does put an affirmative duty on lawyers to understand the tools they're using, and that duty was doing more work in our internal memo than I'd initially given it credit for. PIPEDA's accountability principle sits alongside that duty for any firm handling personal information as part of client files, and neither obligation disappears just because a tool is convenient.

I'm still not fully sure how a Canadian court would rule on the privilege question if it were ever tested directly against a CLOUD Act production order. Nobody I talked to was sure either. What we settled on was a defensible position rather than a guaranteed one: Canadian AI tooling, a Canadian corporate entity, documented data flows, and a paper trail showing we asked the right questions before a client ever raised it.

More detail on how Augure handles data residency and jurisdiction is available at augureai.ca, if you want to run your own version of this comparison against Augure's current disclosures rather than relying on our notes from this review.