PIPEDA and Quebec Law 25 for AI in Canada: 2026 Compliance Checklist

This post is for founders, CTOs and privacy officers scoping an AI system that will touch Canadian residents' personal information. It sets out the layered regimes that apply (PIPEDA, Quebec Law 25, the provincial acts, OSFI E-23) and the engineering controls each one actually demands, in checklist form.

Canadian AI compliance in 2026 is a layered system. PIPEDA, the Personal Information Protection and Electronic Documents Act, is the federal floor for commercial AI handling personal information across provincial lines. Quebec's Law 25, the phased update to provincial privacy law that finished coming into force in September 2024, is the strictest provincial overlay and applies to any system handling Quebec residents' personal information. British Columbia's PIPA and Alberta's PIPA add provincial variants for those provinces. Ontario's PHIPA layers on top for health-information custodians. And for federally regulated financial institutions, OSFI Guideline E-23 on model risk management is the framework AI systems need to operate within.

The mistake most Canadian AI engagements make is treating PIPEDA as the only regime. PIPEDA is the floor; Law 25 is meaningfully stricter; OSFI E-23 demands artifacts most prototype AI systems do not produce. The checklist below is the one we run on Canadian engagements before architecture is locked in. It is not exhaustive, but it covers the controls that determine whether the system will pass a Privacy Commissioner review or a federal regulator examination.

1. Identify the regimes that apply to this specific system

Step zero. A Canadian AI system handling personal information is subject to PIPEDA federally for commercial activity, plus the provincial regime of every province whose residents' data is processed. A Toronto-headquartered fintech serving customers across Canada is subject to PIPEDA, Quebec Law 25 (for Quebec customers), BC PIPA (for BC customers) and Alberta PIPA (for Alberta customers). The relevant differences are not just naming. Law 25 has stricter consent, automated-decision disclosure and de-indexation requirements than PIPEDA.

What this means in engineering terms: scope the data classification per province, route the consent flows per provincial overlay, and document the regime mapping in the privacy impact assessment. A system designed for PIPEDA alone will fail a Law 25 audit for Quebec users.

2. PIPEDA's ten principles, mapped to AI engineering decisions

PIPEDA is structured around ten fair-information principles. They are general principles, but each maps to specific AI engineering decisions:

• Accountability. Name a privacy officer with authority over AI design decisions; document the accountability chain in the PIA.
• Identifying purposes. Document the purpose of every model input, every training data source and every downstream use, before processing begins.
• Consent. Collect consent per identified purpose; do not bundle AI training consent with service-delivery consent.
• Limiting collection. Minimize input features to what is necessary for the model task; do not collect demographics for a tone-classification system.
• Limiting use, disclosure and retention. Purpose-limit the use of training data; set retention horizons on embeddings, prompts and model outputs.
• Accuracy. Accuracy applies to AI outputs that become personal information; a hallucinated fact about a data subject is inaccurate personal information.
• Safeguards. Encryption at rest and in transit, access controls, audit logs. Standard, but documented.
• Openness. The privacy policy needs to describe AI use in plain language, not buried in a clause.
• Individual access. A data subject can request access to the personal information held about them, including derived representations such as embeddings.
• Challenging compliance. A documented mechanism for data subjects to escalate concerns to the Privacy Commissioner.

3. Quebec Law 25: what is meaningfully different

Law 25 sets a higher bar than PIPEDA in several specific areas that matter for AI. Engineering teams that have built for PIPEDA need to add controls for Law 25 if Quebec residents' data is in scope.

• Granular consent per purpose. PIPEDA's purpose-bundling tolerance is lower under Law 25. AI training, AI inference and AI personalization are typically three separate purposes requiring three separate consents.
• Automated decision disclosure. When a decision affecting a data subject is made exclusively by automated processing, Law 25 requires the data subject to be informed, told what personal information was used, and given the right to request review by an individual.
• Right to de-indexation. Law 25 grants a right analogous to the EU's right to be forgotten: a data subject can request that personal information be de-indexed in defined circumstances. This applies to AI search and retrieval systems too.
• Privacy by default. New products must default to the most privacy-protective setting; opt-in is the floor, not opt-out.
• Mandatory breach notification to the Commission d'accès à l'information (CAI) and to data subjects when the breach presents a risk of serious injury.
• Mandatory privacy impact assessment before deploying any system that involves automated decision-making or sensitive personal information.

4. Automated-decision disclosure: beyond a checkbox

Section 12.1 of Quebec's private-sector privacy act, as amended by Law 25, is explicit: where a decision is made exclusively by automated processing of personal information, the data subject must be informed at the latest when the decision is communicated, told what personal information was used, the reasons the decision was made, and the principal factors and parameters that led to it. The data subject can also request review by a person and submit observations.

What this means in engineering terms: an explanation-generation step in the model pipeline that surfaces the top input features, the retrieval citations (if RAG) and the threshold the decision crossed. The explanation needs to be understandable to a non-technical data subject, not a SHAP plot or a confidence vector. The review-by-a-person path is a workflow in your product, not a legal disclaimer in the footer.

5. Cross-border data transfers from Canada

PIPEDA permits transfers of personal information for processing, including outside Canada, provided the transferring organization remains accountable for the protection of that data. Quebec Law 25 is stricter. Transfers of personal information outside Quebec require a privacy impact assessment specifically addressing the transfer, and the assessment must conclude the personal information will receive adequate protection.

For Canadian AI engagements with US-located LLM providers, the practical implications: document the transfer in the PIA, name the safeguards (encryption, contractual terms, redaction at the boundary), and assess the receiving jurisdiction's protection level. For Quebec-scope systems, default to Canadian-region inference, whether a Canadian region of a major cloud provider's managed LLM service or a self-hosted model in a Canadian-region VPC, unless there is a documented reason otherwise.

6. OSFI Guideline E-23: model risk management for federally regulated banks

OSFI's Guideline E-23 on model risk management is the framework federally regulated Canadian banks operate AI systems under. The revised guideline extends the framework explicitly to AI and machine learning models. The artifacts E-23 expects: a model inventory, a model risk tier, model documentation including data, design, validation and ongoing monitoring, independent model validation, and board-level oversight of high-tier models.

For Canadian fintech AI development engagements that touch a federally regulated bank as a customer or partner, the AI system needs to produce the artifacts E-23 expects, in the format the bank's model risk management function consumes. Aiinfox engagements with OSFI-regulated counterparties ship the model documentation, the independent validation pack and the ongoing monitoring artifacts as part of the deliverables. A vendor that does not know what E-23 is will not survive the bank's model risk review.

7. PHIPA, BC PIPA and the provincial layering

Ontario's Personal Health Information Protection Act (PHIPA) applies to health information custodians and their agents. A healthcare AI development project in Ontario operates under PHIPA, not just PIPEDA. The differences: the consent regime is centered on the circle of care (implied consent for treatment-related disclosures within the circle, express consent outside it), the audit requirements are more granular, and the Information and Privacy Commissioner of Ontario has specific guidance on AI in healthcare that is stricter than the federal floor.

British Columbia's PIPA and Alberta's PIPA apply to commercial organizations in those provinces. They are substantially similar to PIPEDA but include province-specific consent rules and Commissioner powers. For multi-province AI systems, the architecture needs to accommodate the strictest provincial regime in scope: typically Quebec Law 25 if Quebec is in scope, BC PIPA otherwise for customers west of Ontario.

8. The privacy impact assessment as the engineering anchor

Federal guidance under PIPEDA and Quebec Law 25 both expect a Privacy Impact Assessment for AI systems processing personal information at meaningful scale. The PIA, like the DPIA in our UK GDPR AI work, is most useful when written collaboratively with engineering in week two of the build, not after the fact. The PIA identifies the personal information flows, the legal basis for each, the risks to data subjects and the mitigations.

For Quebec Law 25 systems, the PIA is a legal requirement before deployment, not a best practice. Treat it as the engineering specification it is. The architectural decisions about redaction, retention, audit, consent flow and review pathways all live in the PIA's mitigations section.

9. Data subject rights through embeddings and the retrieval index

PIPEDA's individual access principle and Law 25's de-indexation right both apply through derived representations of personal information. A data subject access request needs to surface not just the source-database record but also the embedded representation, the retrieval index entries, the model outputs that referenced the data subject, and the prompt-cache entries that included it.

Engineering pattern, and one we build into every RAG development engagement in scope: tag every embedding, every retrieval-index entry and every cached prompt with the subject identifiers it contains. On a deletion or access request, the system can enumerate and act on every derived representation. Without this, the data subject rights pipeline cannot be honored in practice, a gap that Privacy Commissioner investigations increasingly probe.

10. Breach notification: federal and Quebec clocks

PIPEDA's federal breach notification requires notification to the Privacy Commissioner of Canada and affected individuals "as soon as feasible" where the breach creates a real risk of significant harm. There is no fixed number of hours in the statute, but the practical expectation is fast enough that the on-call team needs to be able to detect, classify and escalate breaches within hours, not weeks.

Quebec Law 25 layers on a CAI notification requirement on the same risk threshold. For Quebec-scope systems, the incident-response runbook needs to handle both notifications in parallel. AI-specific breach classes, such as prompt injection that leaks tenant data, model regurgitation of training PII and embedding-store misconfiguration, need to be in the runbook by name.

What good looks like: the engagement deliverables

On Canadian AI engagements at Aiinfox, the standard deliverables include the architecture diagram and code, the PIA written collaboratively with the customer's privacy officer, the consent UX scoped per province in scope, the automated-decision explanation pipeline for Law 25 jurisdictions, the data-subject-rights tooling that operates through embeddings and the retrieval index, the OSFI E-23 documentation pack for federally regulated counterparties, and the incident-response runbook with AI-specific breach classes.

These are not optional add-ons. They are the engineering work that makes the system compliant in practice rather than on paper. The vendors that ship them as standard are the vendors whose Canadian engagements survive Privacy Commissioner inquiries. The vendors that treat them as phase-two retainer upsells leave their customers with a system that fails the first audit.

Engineer for the layers from week two

Canadian AI compliance in 2026 is a layered regime: PIPEDA federally, the strictest provincial overlay (typically Quebec Law 25), OSFI E-23 for federally regulated banks, PHIPA for Ontario health information custodians, and the sectoral guidance from the Privacy Commissioners that interprets all of the above. The compliant-by-design system has been engineered for the layers from week two, not bolted together after launch.

If you are scoping a Canadian AI build that needs to clear a Privacy Commissioner review, an OSFI E-23 examination or a hospital privacy audit, and you want a 30-minute conversation that names engineering controls instead of reciting principles, book a discovery call. We have shipped Canadian AI under PIPEDA, Law 25 and the OSFI overlay, and the checklist above is the one we run on the first call.