← Back to Insights
Compliance

Law 25 compliance: how to document AI systems properly

Law 25 compliance requires PIAs, data mapping and audit trails for AI systems. Here's what Quebec privacy law actually demands — with correct citations.

By Augure·
Two businessmen collaborating over a laptop.

Getting Law 25 compliance right for an AI system means producing documents a regulator can actually follow: a privacy impact assessment, a data map, consent records, and a trail showing how automated decisions got made. Quebec's private sector privacy law doesn't have one tidy "AI chapter" — its requirements are scattered across general provisions that happen to bite hardest when a machine is doing the deciding. That's the part most compliance checklists get wrong, and it's why citations matter more than they might seem to.

This piece walks through what to document, tied to the sections that genuinely apply, not the ones that sound plausible. For a broader view of how AI governance platforms handle this in practice, see our post on AI governance platforms and Quebec Law 25 compliance.

Privacy impact assessments come first

Section 3.3 of the Act respecting the protection of personal information in the private sector is the operative provision here. It requires a privacy impact assessment before any project to acquire, develop, or significantly overhaul an information system or electronic service delivery that involves personal information. Most AI deployments qualify. Full stop.

The assessment should cover the AI's purpose, its data sources, the processing logic, and the safeguards against discriminatory outcomes. Document what the model does with sensitive information, and be specific about it — vague descriptions of "AI processing" won't survive scrutiny if the Commission d'accès à l'information du Québec (CAI) ever asks to see the file.

A privacy impact assessment under Section 3.3 must precede deployment, not follow it. Retrofitting a PIA after launch defeats the purpose and signals to a regulator that privacy wasn't designed in.

Submission to the CAI isn't automatically mandatory for every PIA — that overstates the actual requirement. The obligation is to conduct the assessment and be prepared to produce it on request, which is a meaningfully different bar. For systems that affect legal rights or produce similarly significant outcomes, document your human oversight procedures too, since Section 12.1 gives individuals a right to request human intervention in automated decisions.

Our related post on PIA documentation as a collaboration exercise covers how to make this a cross-team process rather than a compliance-team fire drill.

Data mapping and information flows

There's no dedicated "data mapping" section in the Act — that's worth saying plainly, because plenty of compliance guides invent one. What exists instead is a set of obligations that, taken together, require you to know where personal information comes from, where it goes, and why.

Document information sources, the stated purposes under Section 13, storage locations, and any third-party sharing arrangements. For AI systems specifically, this means training data, real-time inputs, and outputs that might inadvertently contain personal information. Machine learning systems are good at finding personal information in places you didn't expect it.

Cross-border transfers are governed by Section 17, which requires a comparable-protection assessment before personal information leaves Quebec. This is a single provision, not a range of sections — get the citation right, because it's the one most often cited incorrectly. Organizations using Canadian-hosted AI platforms avoid much of this analysis entirely. Augure's Canadian data residency, for instance, sidesteps the Section 17 assessment for most workflows because the data never crosses the border in the first place.

Document data minimization practices specific to the AI implementation. Show how collection is limited to what the stated purpose requires, and how you're avoiding function creep as the system's capabilities expand — because they always do.

Consent and legal basis

Consent provisions in Law 25 are distributed across several sections rather than concentrated in one, so be careful with citations here. When consent is the legal basis for AI processing, document the information given to individuals: the automated nature of the decision, the logic involved, and the consequences that follow. A generic privacy notice that mentions "automated processing" in passing does not meet the transparency bar.

For minors, the relevant threshold and consent mechanics sit in Section 4.1, which sets rules around information relating to minors under 14 — not the provision commonly cited for this purpose. Get this one right; it's a common error and an easy one to catch on review.

Maintain a record of withdrawal mechanisms, and document how a consent revocation affects the AI system's operation going forward. Individuals keep the right to withdraw even when doing so limits functionality, and your documentation should show you've built for that outcome rather than treating it as an edge case.

Audit trails and decision logging

Section 12.1 addresses automated decision-making specifically — this is the provision that actually deals with profiling and decisions rendered exclusively by automated means, and it's frequently misattributed elsewhere. Get the number right; it changes how you build the audit trail.

Audit logs should capture input data, processing parameters, and a decision rationale written in language a person can understand. Technical logs by themselves don't satisfy the transparency obligation. Neither does a black-box confidence score.

Document your human oversight procedures for contested decisions. When someone exercises their right to request human intervention, your records need to show a qualified person actually reviewed the case — not that a second algorithm rubber-stamped the first one's output.

Security safeguards for this documentation fall under Section 3.5 of the private sector Act — a different Section 3.5 than the one governing PIAs in some summaries, which is exactly the kind of internal mix-up worth double-checking before publication. Store audit records with appropriate access controls, since they typically contain personal information in their own right.

For high-stakes AI decisions touching employment, credit, or similarly significant outcomes, keep detailed decision trails: the factors considered, the weightings applied, and the alternative outcomes the system didn't choose. If a decision is ever contested, this is what you'll be asked to produce.

Vendor and processor agreements

AI systems routinely involve third-party processors, and those relationships carry their own documentation burden. Processor agreements need to address AI-specific risks, not just generic data-handling clauses lifted from a template built for spreadsheets.

Document the processing instructions given to any vendor, covering model training, inference, and output handling. A standard cloud services agreement usually doesn't address any of this adequately — read the fine print, or better, don't rely on it having any.

For platforms that maintain Canadian data residency, document that fact explicitly as part of your processor due diligence. Augure's infrastructure keeps data within Canada, which removes a layer of cross-border assessment that would otherwise be required under Section 17. That's a meaningful simplification for compliance teams working through vendor risk.

Include security requirements suited to AI workloads specifically: model protection, training data security, output confidentiality. Also track sub-processor relationships, since many AI services chain multiple vendors together for different stages of processing, and each link in that chain needs its own adequate agreement. Our post on tools that meet Quebec's Law 25 standard walks through how to evaluate vendors on this basis.

Individual rights response procedures

Individuals have rights to access their information, to request correction, and — where automated decision-making is involved — to request meaningful information about the logic used and a path to human review. Document the operational procedure for each, not just the policy statement that says the right exists.

A written policy promising "human review on request" means nothing if there's no actual queue, no assigned reviewer, and no record of what happened when someone asked.

Templates help here. Build one for access requests, one for correction requests, and one specifically for automated-decision explanations, since the information required differs meaningfully between them. Coordination between legal and the technical team matters most when someone successfully challenges an automated outcome and the system needs to actually change its behaviour for that person.

For a look at how breach notification timelines interact with these same rights procedures, see AI data breach notification requirements in Canada.

Ongoing monitoring

Documentation isn't a one-time deliverable. AI systems change — models get retrained, functionality expands, new data sources get added — and each meaningful change may warrant an updated PIA and revised notice to affected individuals.

Keep records of staff training on AI-specific privacy obligations. Accountability under the Act isn't satisfied by a folder of documents; it requires a demonstrable program, with people who know what the documents say and why they exist.

Schedule periodic reviews of AI documentation, particularly for systems that adapt over time. A privacy impact assessment written for the system as it existed a year ago may no longer describe what the system actually does today.

Related reading on the operational side of this: CPCSC requirements for AI tooling covers a complementary framework worth understanding alongside Law 25.

For organizations building AI workflows with Augure, the platform's Canadian data residency and built-in processing logs support several of these documentation requirements directly, cutting down the manual work of tracking cross-border transfers and access logs separately.

Proper documentation turns Law 25 compliance from a reactive scramble into a system anyone on the team can maintain. Start with the PIA. Get the data map right. Everything else follows from those two. If your citations are wrong, though, none of it holds up — check them against the Commission d'accès à l'information du Québec's official guidance and the current text of the Act rather than a summary of a summary.

Ready to see how this works in practice? Augure builds Law 25 compliance documentation directly into Canadian-hosted AI workflows.

A

About Augure

Augure is a sovereign AI platform for regulated Canadian organizations. Chat, knowledge base, and compliance tools — all running on Canadian infrastructure.

Ready to try sovereign AI?

Start free. No credit card required.

Get Started