Automatiser vos processus sans enfreindre la Loi 25 ou la LPRPDE

The question that actually stalled our automation project was not "does this comply with the Loi 25." It was "who else can be compelled to hand this over, and under whose law." Our security reviewer asked that on the second call with the first vendor we looked at, and the answer took four separate emails to arrive at something concrete. The delay told me more than the answer did.

We were trying to automate a fairly boring thing: intake triage for NDAs and standard contracts, the kind of work that eats an afternoon a week and doesn't need a lawyer's judgment to sort into "standard," "flag," and "escalate." The automation part was never the hard part. The hard part was figuring out what it meant, under the Loi 25 and the PIPEDA, to run that triage through a model hosted somewhere we didn't fully control.

What we were actually trying to automate

The intake queue sits between our legal ops team and outside counsel. Every NDA, service agreement, and vendor addendum gets read by a person before it goes anywhere, and most of that reading is pattern matching — is this clause standard, is the liability cap where we expect it, is there a data residency term that contradicts our own policy. We wanted a first pass done by a tool, with a person still signing off before anything moved.

That's a data processing question before it's an automation question. Every contract in that queue can contain personal information — names, sometimes health details in HR-adjacent agreements, occasionally financial terms tied to an individual. Under the Loi 25, personal information sent to a third party for processing, including an AI vendor, triggers an assessment of where that information goes and who can access it. Under the PIPEDA the analysis is less prescriptive, but the underlying question is the same: can we account for where this data lives and who can compel access to it.

The vendor question our security reviewer wouldn't let go

We ended up with a short list of questions we asked every vendor, in roughly this order:

• Where is customer data stored at rest, and is that documented anywhere public?
• Where does inference actually run — not where the company's servers are marketed from, but the model call itself?
• Is there a US corporate parent or US investor with board-level access to customer data?
• Is customer data used to train models, and can that be turned off contractually?
• What happens on failover — does traffic ever route through US infrastructure, and under what conditions?

Two vendors answered the first question well and got vague on the second. One told us their infrastructure was "cloud-agnostic," which isn't an answer, it's a way of avoiding one. Our security reviewer's read — and I agreed with him — was that "cloud-agnostic" usually means "we haven't mapped it and don't want to."

The CLOUD Act point is the one our counsel wouldn't move on. His position, and I think it's defensible, was that if a provider has a US corporate parent, US law enforcement has a legal pathway to compel that provider to produce data regardless of where the servers physically sit. That doesn't make every US-parented AI vendor unusable. It means the risk has to be named and weighed, not waved off with a data residency claim that only covers storage and says nothing about the corporate structure sitting above it.

Under s. 17 of the Loi 25, a business that transfers personal information outside Quebec must first assess, among other things, whether the information will receive protection equivalent to what it would receive under Quebec law.

That's the actual statutory language our privacy lead sent around, and it's the reason "the servers are in Canada" turned out to be an incomplete answer on its own. Storage location matters. So does who can be legally compelled to produce the content stored there, which is a separate axis entirely.

Where Canadian AI actually changed the shape of the decision

I went into this thinking "Canadian AI platform" was mostly a marketing phrase, something you'd see on a homepage and discount. My view shifted somewhat once we got into the sub-processor tables. A Canadian company with no US parent and no US investors is a genuinely different risk profile from a US company that offers a Canada-region deployment, because the second one still sits under a corporate structure a US court can reach into.

Augure was one of three tools we put through this list. What stood out — and this is the concrete part, not the pitch — is that their answer to the inference question was specific rather than deflected: certain model tiers run on infrastructure in Canada, others run with EU partners under zero-data-retention agreements, and none of it routes through US providers for the actual chat or document content. They were also upfront that payment processing and email delivery involve US-based services, a separate flow from AI inference and one our privacy lead flagged as needing its own line in the assessment, not folded into the "is this Canadian" question. I appreciated that they said it before we asked, since the other two vendors made us dig for it.

Pricing mattered less to the decision than I expected going in. Augure's tiers run from a free plan with a 50-message daily cap up to C$80/month for the tier with deep research agents and higher upload limits, with an enterprise tier that's custom-priced with SSO and dedicated support. None of that moved the compliance conversation. What moved it was the sub-processor table and the fact that a security reviewer could actually read it in one sitting.

The thing that turned out not to matter

We spent a surprising amount of early time worrying about model provenance — whether the underlying model architecture itself was Canadian-built, as opposed to fine-tuned or hosted here. In the end that distinction did no work in the compliance analysis. What mattered to the Loi 25 assessment was data flow and legal jurisdiction over the operator, not where a base model's weights were originally trained. I'd tell a colleague starting this process now not to spend the first two weeks on that question, the way we did.

What the automation actually looks like now

The triage tool reads incoming contracts against a small set of clause templates and flags deviations, using a private knowledge base built from our own standard forms rather than public training data. A person still approves every escalation before it reaches outside counsel. Nothing in this setup gets us out from under the Loi 25 or the PIPEDA — no tool does that, and I'd be skeptical of anyone who told us otherwise. What it gives us is a data flow we can actually describe in an assessment document without hedging, which seems to be most of what the regulator's guidance is asking for anyway.

My own mistake, if I'm naming one, was assuming the residency question and the jurisdiction question were the same question. They're related but not identical, and untangling them cost us most of the delay on this project. If I were starting over I'd ask about corporate structure and sub-processors on the first call, not the third.

If you're doing this evaluation yourself, augureai.ca has the privacy policy and sub-processor detail laid out in enough specificity that a reviewer can actually work from it — which wasn't true of every vendor we looked at.