Law 25 compliance checklist for AI tools in 2026

The thing that stopped our review wasn't the AI vendor's security posture. It was a single line in the sub-processor table that none of us had thought to ask about six months earlier: email delivery. Not model inference, not data storage — the transactional emails the platform sends when someone shares a document. That routed through a US provider, and our privacy officer sat with it for longer than she sat with anything else on the list.

I work in compliance at a mid-size professional services firm, the kind of place with enough Quebec clients that Law 25 isn't abstract but not enough legal headcount to have a standing AI governance committee. When the leadership team wanted to roll out an AI chat tool for drafting and internal research, it landed on my desk to vet. I want to walk through what we actually asked, because the checklist you'll find on most vendor sites reads nothing like the order these questions came up in real life.

What Law 25 actually requires us to check

Quebec's Law 25 doesn't mention AI tools by name, so there's no line-item checklist a vendor can hand you and say "here, compliant." What it does require, and what mattered to us, is a documented assessment of any transfer of personal information outside Quebec — section 17 — and a person designated internally who's accountable for privacy, which most firms our size hadn't formally named until this came up.

Before communicating personal information outside Québec, an enterprise must conduct an assessment of privacy factors related to the communication.

That's the piece that changed our process. A vendor's marketing page saying "Canadian" isn't the assessment. You need the assessment itself — documented, dated, sitting in a folder somewhere — showing what data flows where, and why the risk is acceptable given what's on the other end.

I should say what that assessment actually involves in practice, because "assessment" sounds heavier than it is and also, in one respect, lighter. Ours ran to about four pages: a data flow diagram, a list of every sub-processor with country of operation, a sensitivity rating for the categories of personal information involved, and a short written rationale for each cross-border flow that couldn't be eliminated. It took our privacy officer roughly two weeks of calendar time, most of it spent waiting on vendors to answer the sub-processor question precisely rather than in generalities. Counsel reviewed it in an afternoon. The part I underestimated was how much of that four pages ends up being boilerplate you reuse across vendors — the categories of personal information don't change, only the destination country does.

Why we started with "Canadian AI" as a search term at all

I'll admit the initial instinct was defensive. Someone on the leadership team had read about a US-based AI tool getting flagged in another jurisdiction and asked, more or less, can we just find a Canadian one and be done with this. That's not how it works, but it's not a bad starting instinct either. Searching for Canadian AI platforms narrowed the field fast — from maybe a dozen tools under consideration to four that could even answer the residency question without a legal team on the call.

What surprised me was how few vendors marketed as Canadian AI actually had the infrastructure to back it up. A couple were reselling access to US-hosted models with a Canadian billing entity bolted on top. That's not nothing, but it doesn't move the needle on a section 17 assessment, because the personal information is still crossing the border the moment it hits inference.

The questions that actually mattered

We ended up building a short list, and I'd say maybe a third of the questions we started with turned out to be irrelevant once we got into it. Here's roughly what we asked each vendor, in the order it came up:

• Where is customer data stored at rest, and is that documented in a privacy policy we can cite?
• Where does inference happen — not "where is the company headquartered," but which country the model actually runs in?
• Is any customer data used to train models, and is that contractual or just a stated policy?
• What's the full sub-processor list, including payment processing and email delivery, not just the AI stack?
• Who has access to logs, and for how long are they retained?
• Does the vendor have a named privacy contact we can reach, and have they handled a Law 25-scoped request before?

The fourth question is the one nobody on our side thought to ask until our security reviewer insisted on it. We'd been treating "where does the AI run" as the whole question. It isn't. A tool can have solid Canadian inference and still route calendar invites or password resets through a US mail server, and depending on what's in those emails, that's still a cross-border flow worth documenting.

A skeptical colleague at another firm pushed back on this list when I described it to her — her point was that if you chase every sub-processor down to the payment network, you'll never finish an evaluation, because Visa and Stripe sit under a dozen vendors' stacks regardless of where the core product runs. I think that's fair, and it's part of why the assessment distinguishes between flows carrying personal information tied to a data subject versus flows that are purely transactional metadata. Card processing for a subscription invoice is a different risk tier than a chat transcript. We didn't treat every sub-processor as equally disqualifying — we just insisted on knowing they existed before deciding that.

The CLOUD Act question our counsel would not move on

This is the one place a US regulation directly shaped the decision, so I'll name it plainly: our counsel would not sign off on any tool where customer content — chats, documents, contract drafts — sat with a vendor under US jurisdiction, because of the exposure under the US CLOUD Act. Not because we had a specific fear of a subpoena. It was more that we couldn't get a straight answer from two of the US-headquartered vendors about whether their own legal team could resist a request if one came, and "we've never had that happen" isn't the same as "we're structurally not exposed."

Augure was one of the four platforms we actually piloted, and this is where it did something the others didn't: it told us plainly, unprompted, that customer conversations and documents aren't handled by any US-jurisdiction provider, so that particular exposure doesn't extend to customer content — scoped to that, not dressed up as a blanket "we're not subject to US law" claim, which I'd have distrusted anyway. Their privacy policy also disclosed the parts I'd have expected a vendor to leave out: EU infrastructure handles inference for certain model tiers and during failover, and email delivery and card payments still run through US processors. I trusted the scoped claim more because of what they admitted alongside it.

The thing that turned out not to matter, in the end, was model performance benchmarks. We'd spent real time early on comparing output quality across tools, and once we got into the compliance review, none of that mattered if the vendor couldn't answer the residency and sub-processor questions cleanly. I regret how much of the first two weeks went into that comparison instead of the questionnaire.

What we'd redo

I think the biggest process mistake was not looping in our privacy officer until week three. We treated this as a procurement and security decision first, privacy second, and Law 25 doesn't really allow you to sequence it that way — the privacy factors assessment is supposed to inform the decision, not audit it after the fact. If I were running this again I'd have her in the room for the first vendor call, not the fourth.

We also assumed PIPEDA and Law 25 would point us in roughly the same direction, and mostly they did, but Law 25's transfer assessment requirement is more specific than anything PIPEDA demands outright, and a couple of our federally-regulated colleagues at other firms hadn't budgeted time for it because their compliance work had been PIPEDA-only up to that point.

None of this gets us to "compliant" in any final sense — a tool doesn't confer that, and I'd be skeptical of any vendor who implies it does. What it gets us is a defensible file: the assessment, the sub-processor table, the named contact, the documented reasoning for why we picked what we picked. That's roughly what a regulator would want to see if it ever came to that, and it's the best any of us can really promise.