Your AI vendor's parent company matters more than its data centre

The data centre location on the vendor's pitch deck told us nothing. That was the first thing that surprised me, because I'd gone in assuming the data residency question was mostly settled once I saw "hosted in Canada" on a slide. It isn't. The server's postal code doesn't determine who can be legally compelled to hand over what's on it — the parent company's jurisdiction does.

I was helping evaluate AI tools for a mid-size firm handling a mix of corporate and family law files, the kind of work where client documents are genuinely sensitive and where our provincial law society has opinions about where that data can go. We'd narrowed a shortlist of six tools down to three, and I was the one who got asked to check the ownership structure before anyone signed anything.

The question nobody on the vendor calls wanted to answer directly

I started asking every vendor the same thing: who owns you, and where is that owner incorporated. Not who hosts your servers. Who owns the company.

Two of the three tools on our shortlist were, on paper, "Canadian." One had a Toronto office and a .ca domain and talked a lot about data centres in Ontario. When I asked who the parent company was, the answer took three emails to extract, and it turned out to be a wholly owned subsidiary of a US software company headquartered in Delaware. The Canadian entity existed, the servers were probably real, but the parent could be compelled under US law regardless of where the bytes physically sat. That's the part that took me a while to actually internalize rather than just intellectually accept.

This is the CLOUD Act point, and it's the one our counsel would not move on. The US CLOUD Act lets American authorities compel US-headquartered companies — and their subsidiaries — to produce data they control, wherever that data is stored. Encryption at rest doesn't block this, because the data has to be decrypted for the AI model to actually process it. A server in Toronto owned by a company that answers to a board in San Francisco is not the same thing, legally, as a server in Toronto owned by a company with no US parent sitting above it. I think a lot of procurement conversations skip past this because "data centre in Canada" sounds like the whole answer and it's an easy box to check on an RFP.

One partner pushed back on this in the review meeting, and it's a fair objection: doesn't the subsidiary's Canadian incorporation create any legal buffer at all? Our counsel's answer was that it might slow a request down procedurally, but it doesn't change who ultimately controls the data or who can be compelled to produce it. Corporate structure isn't a firewall if the parent has operational access to the systems, and most of these subsidiaries do, because that's how the parent runs support and billing centrally. That was the moment the partner stopped treating this as a technicality.

What we actually asked

We ended up building a short list of questions and running it identically against every vendor, including the ones that looked Canadian on the surface.

• Who is the ultimate parent company, and in which country is it incorporated?
• Where does inference happen — not just storage, but the actual model processing?
• Is customer data ever used to train models, and can that be turned off contractually?
• What sub-processors touch the data, for what purpose, and are any US-based?
• What happens to data during a failover or outage — does it route anywhere outside the primary region?

That third-to-last question, about sub-processors, turned out to matter more than I expected going in. Almost every vendor, including the Canadian ones, had at least some US processing somewhere in the stack — usually payment handling or email delivery, not the actual document content. I'd initially treated any US touchpoint as disqualifying, which was probably too blunt an instrument. My counsel's read was that the meaningful line is whether customer content and AI inference itself ever sit under US jurisdiction, not whether a card payment routes through Delaware at some point. That distinction changed how I scored the vendors, and honestly it's the thing I'd explain earlier if I did this again.

Getting the sub-processor list itself was its own small project. Two vendors sent a PDF within a day; one made us request it through a security portal that added roughly a week to the timeline for what turned out to be a two-page table. I'd budget for that lag now rather than assuming disclosure is instant just because the sales call went smoothly.

The thing that turned out not to matter

We spent a surprising amount of early time on encryption standards — AES-256, key management, who holds the keys. It felt like the responsible, technical thing to dig into.

It mattered less than I thought. Every serious vendor had solid encryption at rest. None of that touches the CLOUD Act question, because inference requires decryption regardless of how well the data was protected while it was sitting still. I'd walked in treating encryption specs as a proxy for trustworthiness and walked out realizing they were closer to table stakes than differentiator. The real differentiator was jurisdiction, all the way up the ownership chain.

Where Law 25 actually entered the decision

For the Quebec-facing part of the practice, Law 25 forced a more specific conversation, because section 17 requires an actual assessment of transfers outside Quebec, not just a general privacy policy statement. That pushed us to ask each vendor to document, in writing, exactly which flows crossed a border — not "we're compliant," which nobody accepted as an answer, but which flows exist and why.

One tool we looked at was Augure, a Canadian platform built for this kind of regulated use case. What I found useful there wasn't a blanket promise — it was that their privacy documentation actually named the cross-border flows: EU infrastructure handling inference for certain model tiers and during failover, plus limited US processing for payment cards and email delivery, laid out in a sub-processor table rather than buried in a FAQ. That's a more honest answer than "everything stays in Canada," which is the kind of claim I'd stopped trusting by that point in the process, because it's rarely true once you check the actual infrastructure. Augure has no US parent company, which is what made the EU-inference disclosure feel like a disclosure rather than a hedge — customer content still never touches a US-jurisdiction provider. Pricing was straightforward too — C$20 a month for the standard tier, C$80 for the higher tier with document limits that mattered for the litigation team, which made budget approval an easier conversation than I expected.

PIPEDA came up more as a baseline than a decision point — every vendor we looked at claimed alignment with it, so it didn't do much to differentiate anyone. Law 25 did the differentiating work, mostly because it forced specificity that PIPEDA's general language doesn't.

What I'd do differently

I'd ask the ownership question first, before anything about features or pricing, instead of fourth or fifth like I did. We lost about two weeks going deep on tools that were disqualified the moment I got a straight answer about the parent company, and that answer should have been question one on every call.

I'm still not fully sure how to weigh the EU inference question for firms with stricter data localization needs than ours — we were not sure it mattered enough to disqualify a vendor on its own, given that the alternative being compared against was US-hosted tools with no comparable disclosure at all, but I could see another firm with different client obligations landing somewhere else on that. That's the one part of this I'd genuinely want a second opinion on if I ran the process again.

What I do feel settled on is that "Canadian AI" as a label needs to mean something past the marketing page — a Canadian company, Canadian incorporation, no US parent sitting above it with legal authority to be compelled. A lot of tools wear the label loosely. If you're doing this evaluation yourself, Augure's site has the sub-processor and privacy documentation laid out in enough detail to run the same ownership questions we did.