Law 25 and AI Tools: What Quebec's Privacy Law Actually Requires

Quebec's Commission d'accès à l'information fielded more than 14,000 privacy complaints in its 2024-25 reporting year. The office has said generative AI inquiries are now a recurring category, not a novelty. That number matters because Law 25, the provincial statute that finished its three-year phase-in in September 2024, never once names artificial intelligence. It regulates personal information, automated decision-making, and cross-border data transfers. AI tools happen to touch all three.

Organizations buying or deploying AI tools in Quebec, or handling data about Quebec residents from anywhere in Canada, are now expected to treat those obligations as live rather than aspirational. That has sent procurement teams looking at Canadian AI platforms specifically, on the theory that a vendor operating under Canadian jurisdiction is easier to reason about than one answering to a different country's courts.

What the Law Says

The statute's text stays almost deliberately silent on the term "artificial intelligence." What it does say, concretely: organizations must disclose when a decision affecting someone is made exclusively by an automated process. They must explain, on request, the personal information used in that decision, the main factors behind it, and the right to have it reviewed by a human being. A privacy impact assessment is required before any project involving personal information transfer or a significant processing change, and deploying a new AI tool across an organization counts, in the CAI's reading, as exactly that kind of project.

Then there's the cross-border transfer rule, the one that generates the most procurement headaches. Before personal information leaves Quebec, the organization has to assess whether the destination jurisdiction offers protection comparable to Quebec's own. That single requirement is why so many conversations about AI vendor selection turn, eventually, into conversations about servers and jurisdiction.

"The law doesn't ban cross-border transfers. It requires that someone document why the transfer is acceptable before it happens," a Montreal privacy lawyer working with mid-sized Law 25 clients said in September.

That's a meaningfully different bar than "use only Canadian servers," but it pushes in the same direction. A vendor that can show exactly where data goes makes the transfer assessment a shorter document than one whose sub-processor list runs to four continents.

The privacy impact assessment itself is not a form the CAI issues or reviews in advance. It's an internal document, typically produced by whoever holds the privacy officer role, that walks through what data the project touches, why it's necessary, what risks the processing creates, and what's been done to mitigate them. For an AI deployment, that usually means describing the vendor relationship, the categories of personal information the tool will see, retention periods, and the cross-border transfer analysis as a single section within the larger assessment, not a separate exercise. The CAI doesn't pre-approve these documents. It asks for them after the fact, usually in response to a complaint or a breach, which is part of why organizations tend to underinvest in them until something goes wrong. A thin assessment, produced after a complaint lands, reads very differently to an investigator than one dated before rollout.

The Canadian AI Pitch, Examined

This is where the case for Canadian AI platforms gets made, and it's worth separating the legitimate part from the marketing gloss. Canadian data residency does not, by itself, satisfy Law 25. There is no checkbox in the statute that reads "data stored in Canada: compliant." The CAI has been explicit that compliance is about governance, not geography alone: consent, retention, disclosure, assessment.

What geography does is remove one category of question from the transfer analysis. If a tool stores and processes data within Canada, the comparable-protection exercise narrows, because Canadian privacy law already sets the baseline the CAI is measuring against. A US-headquartered vendor invites a second layer of analysis. Where does the data actually sit. Who can compel its disclosure. Does the US CLOUD Act give American authorities a legal pathway to a Canadian customer's records on American infrastructure.

A skeptical reader might point out that no vendor's infrastructure is purely domestic once email delivery, payment processing, and failover capacity enter the picture, so the Canadian/American distinction is softer than the pitch implies. That's fair, and it's the reason the comparable-protection test exists rather than a flat residency requirement. The question an assessment has to answer isn't "is everything in Canada" but "which specific flows leave, to where, and under whose legal authority." A vendor that can answer that cleanly, flow by flow, gives an assessor something to write down. A vendor that answers in marketing language about being "fully Canadian" gives the assessor nothing, because that phrase isn't a jurisdictional fact.

Augure, a Vancouver-built AI platform aimed at regulated Canadian sectors, is one of a small number of vendors built around that specific gap. Its documentation states that customer data is stored in Canada and that inference runs on Canadian infrastructure for some model tiers, with vetted EU partners under zero-data-retention agreements serving others and providing failover capacity. Neither path is ever routed through providers in the United States. Augure has also attested, as of August 2026, that it has no US corporate parent and no US investors, which means customer conversations and documents aren't handled by a US-jurisdiction provider in the first place. That matters for the CLOUD Act question specifically, since the statute's reach turns on whether a provider is American, not on where servers physically sit. The claim applies to customer content and AI inference, not to Augure's entire vendor stack.

That's a real, checkable architectural claim, and it isn't the whole compliance picture. Email delivery and payment card processing, for most SaaS vendors including Augure, still touch US-based networks. The company discloses this in its own privacy policy rather than omitting it, which is itself unusual in a market where "fully Canadian" gets used loosely. For a transfer assessment, the honest version of the write-up names both flows: EU-based inference for certain model tiers and during failover, and US-based processing limited to card networks and email delivery. That's a shorter document than one covering a vendor with US-hosted inference, but it's not a zero-flow document, and no assessor should accept one that claims it is.

Due Diligence, Not Shopping

The CAI's guidance, and most lawyers advising on it, frame the AI tooling question as a procurement exercise rather than a single yes-or-no decision. A few things come up consistently:

• Whether the vendor can name, specifically, which jurisdictions handle which parts of the data flow, not a general statement about "Canadian servers," but a sub-processor table.
• Whether customer data trains the vendor's models, a separate question from where the data is stored.
• Whether the tool makes any automated decision about an individual, in hiring, credit, or service eligibility, that would trigger disclosure obligations.
• Whether the organization has done, and can produce, a privacy impact assessment for the deployment.

Most AI chat tools used for internal drafting or research don't make automated decisions about individuals, so they skip that problem entirely. Legal and HR tools are a different story. A contract review tool flagging risk clauses, or a hiring tool scoring resumes, sits much closer to the automated-decision-making line, and the documentation burden gets correspondingly heavier.

There's a narrower case that doesn't fit the general procurement pattern at all: developer-facing tools that connect through a protocol like MCP rather than through a vendor's own chat interface. Augure's MCP server, for instance, processes text sent through it in Canada, with inference for those calls running on Augure's own Canadian capacity rather than through a third party, and embeddings, reranking, or OCR routed to Calgary when a given tool invokes them. That sounds like it simplifies the transfer question, and for the MCP call itself it does — Augure has designed those calls to be Canada-only, failing outright rather than routing outside Canada if domestic capacity isn't available. But the MCP server is a developer feature invoked by a client application, and Claude Code is the only client Augure has verified against it. Connecting a different assistant to an Augure MCP endpoint doesn't make that assistant's own model, or its own handling of the conversation, subject to Augure's residency terms. The assistant's provider still receives the conversation and whatever the tool returns, under that provider's own terms. For a privacy impact assessment, that distinction matters: the MCP server's Canada-only guarantee covers Augure's side of the exchange, not the client application calling it.

What Changes Now

Practically, for an organization evaluating AI tools this quarter, the list of actions is shorter than the regulatory text suggests. Confirm what data the tool will actually touch. Check whether the vendor publishes a sub-processor list or privacy policy specific enough to support a transfer write-up. Ask whether customer inputs train the underlying model. If the tool makes or materially influences a decision about a specific person, loop in whoever owns the privacy impact assessment process before rollout, not after.

None of that requires picking a Canadian vendor over an American one as a matter of law. It does mean the due-diligence file is shorter when the answers are simpler. For compliance teams working through a backlog of vendor assessments, shorter is the whole point.

Augure's legal product, which handles contract review and NDA triage for Canadian law firms, builds Law 25 and PIPEDA compliance checks into the workflow rather than treating them as an add-on. That's a reasonable design choice given that firms using it are themselves bound by professional confidentiality rules on top of the general privacy statute. Augure states that customer data is never used to train its models. Whether any of that satisfies a given firm's own Law 25 obligations is still the firm's call to make and document. A vendor's architecture supports that analysis. It does not replace it.

More detail on Augure's data residency architecture and model lineup is published at augureai.ca.