Quebec Law 25 Privacy Impact Assessment (PIA / EFVP): A Practitioner’s Guide for AI and Data Projects
Quebec Law 25 requires a Privacy Impact Assessment (PIA — in French, Évaluation des facteurs relatifs à la vie privée, or EFVP) before any personal information is communicated outside Quebec (Section 17 of the Act Respecting the Protection of Personal Information in the Private Sector, as amended by Law 25 / Bill 64, in force September 22, 2023). For AI and data projects, that trigger fires the moment an employee query, a customer record, or a training dataset leaves your infrastructure for a US cloud service. This guide walks through the five practitioner steps — and explains why on-premise AI removes the cross-border trigger entirely.
This page is educational information only and is not legal advice. Consult a Quebec privacy lawyer or certified PIA practitioner for compliance obligations specific to your organization. Law 25 is administered by the Commission d’accès à l’information du Québec (CAI); the CAI publishes official guidance at cai.gouv.qc.ca.
What is a Privacy Impact Assessment (PIA / EFVP) under Quebec Law 25?
A Privacy Impact Assessment is a structured process for identifying, evaluating, and mitigating privacy risks before a project goes live. Under Law 25 (the Act to Modernize Legislative Provisions as Regards the Protection of Personal Information, 2021, CQLR c P-39.1 as amended), conducting a PIA is mandatory — not optional — in specific circumstances.
The CAI defines an EFVP as an assessment that must examine:
- The purpose for which personal information is collected, used, or communicated
- The necessity and proportionality of the data flows
- The legal protection available in the destination jurisdiction
- The contractual or other safeguards protecting the information
- Whether the privacy risks can be adequately mitigated before proceeding
Law 25 governance provisions (including privacy officer designation requirements under Section 3.3) form the organizational backbone that makes a credible PIA possible. Without a designated Privacy Officer and a documented governance structure, the PIA process has no institutional owner — making it both ineffective and non-compliant.
When is a PIA required? The Section 17 cross-border transfer trigger
Section 17 of the Act (as amended by Law 25) is the key provision for AI and cloud-technology projects. It states that before personal information about a Quebec resident is communicated to a person or entity outside Quebec — including to service providers operating under foreign law — the organization must:
- Conduct a PIA to evaluate the adequacy of privacy protection in the recipient jurisdiction
- Ensure the communication serves a serious and legitimate purpose
- Take all reasonable measures to ensure equivalent protection comparable to Quebec’s Act
- Execute a written agreement imposing equivalent privacy protections on the recipient
For practical purposes, every AI or SaaS tool that sends Quebec residents’ personal data to a US or EU cloud provider triggers Section 17. That includes:
- Sending customer support queries to a cloud-hosted LLM (e.g., OpenAI, Anthropic, Google Gemini)
- Uploading HR data to a US-based analytics platform
- Using a US SaaS CRM or ERP that processes Quebec employee or customer records
- Running automated transcription or document analysis on a US cloud endpoint
The US CLOUD Act (2018) complicates this further: US authorities can compel US companies to hand over data stored anywhere in the world. A PIA that ignores this exposure does not meet the CAI’s standard for assessing “legal protection available in the recipient jurisdiction.” See our companion guide: US CLOUD Act and Canadian AI Data — What Organizations Need to Know.
Five steps for conducting a Law 25 PIA on an AI or data project
The CAI does not mandate a single rigid PIA template, but its published guidance (as of 2023–2024) expects the assessment to follow a documented, evidence-based methodology. The following five-step framework aligns with CAI guidance and industry best practice (ISO 29134, NIST Privacy Framework).
Step 1 — Project scoping and data mapping
Define the project scope precisely: what personal information is collected, from whom, for what stated purpose, and where it flows. For an AI project this means documenting:
- Every data input to the AI system (prompts, documents, user profiles, telemetry)
- Every external API, cloud endpoint, or third-party service the data touches
- The jurisdiction where each third-party processor is incorporated and where data is stored
- Data retention schedules and deletion procedures
This step produces the data-flow diagram that anchors the rest of the assessment. If any flow crosses a provincial or national border, Section 17 applies — document it here so it is not missed downstream.
Step 2 — Jurisdiction and legal-protection analysis
For each cross-border flow identified in Step 1, assess the legal protection available in the recipient jurisdiction. The CAI expects organizations to consider:
- Whether the recipient country has privacy legislation “equivalent” to Quebec’s Act
- Surveillance laws that may override contractual protections (e.g., US CLOUD Act, FISA Section 702, UK IPA 2016)
- The recipient’s track record of enforcement and breach notification
- Whether standard contractual clauses or data processing agreements provide meaningful, enforceable protection in practice
Practitioner note: The EU’s GDPR adequacy framework is one reference point, but Quebec Law 25 has its own equivalency standard — the two do not map 1:1. A jurisdiction adequate under GDPR is not automatically adequate under Law 25. Date-hedge: adequacy determinations evolve; verify against current CAI guidance at the time of your assessment.
Step 3 — Risk identification and severity rating
Catalogue the privacy risks arising from the identified data flows. For AI systems, typical risks include:
| Risk category | AI-specific example | Severity factors |
|---|---|---|
| Unauthorized access / data breach | Cloud LLM provider suffers breach; prompt logs containing customer data are exposed | Volume of records, sensitivity of data type, detectability |
| Government compulsion | US DOJ issues CLOUD Act demand to US cloud provider; Quebec customer data produced | Likelihood of demand, ability to notify, contractual right to contest |
| Unauthorized use / mission creep | Cloud AI provider uses customer inputs to train future models (check terms carefully) | Contractual clarity, opt-out mechanisms, audit rights |
| Automated decision-making bias | AI system makes discriminatory recommendations affecting individuals | Reversibility, human oversight, explainability |
| Data retention / deletion failure | Cloud provider retains prompts beyond contractual term | Contractual enforceability, audit rights |
Rate each risk by likelihood × impact. CAI guidance emphasizes that the assessment must be honest — a PIA that minimizes all risks to “low” without evidence is not a compliant PIA.
Step 4 — Mitigation measures and residual-risk decision
For each identified risk, document the measure that reduces it and the residual risk that remains after the measure is applied. Common mitigation categories for AI projects:
- Technical controls: encryption at rest and in transit, prompt-data stripping, anonymization or pseudonymization before transmission, access-control lists
- Contractual controls: data processing agreements, GDPR-style standard clauses adapted for Quebec law, audit rights, breach notification timelines
- Architectural controls: data minimization (send only what the AI needs), on-premise or private-cloud deployment, sovereign jurisdiction routing
- Governance controls: staff training, data-handling procedures, retention schedules, vendor due-diligence checklists
After documenting mitigations, make the go/no-go decision explicit: Is the residual risk proportionate to the purpose? If not, the project must be redesigned or abandoned. This documented decision is what regulators and auditors look for — the written record that a responsible person made an informed judgment.
Step 5 — Documentation, sign-off, and review schedule
The PIA must be documented in writing and retained. Law 25 does not specify a retention period for PIAs themselves, but Quebec’s general administrative-documents framework and the principle of accountability suggest retaining the PIA for the life of the project plus a reasonable tail (practitioners commonly use 5–7 years as a starting point — verify with counsel). The PIA should include:
- Project description and date of assessment
- Data-flow diagram from Step 1
- Jurisdiction analysis from Step 2
- Risk register from Step 3
- Mitigation log from Step 4, including residual-risk ratings
- Responsible person sign-off (your Privacy Officer designated under Section 3.3)
- Scheduled review date — PIAs must be updated when the project materially changes or at a fixed interval
The CAI has the authority to request access to PIA documentation during an investigation. A PIA that exists only as a draft email thread is not sufficient.
How on-premise AI simplifies the PIA process
The single most effective way to reduce Law 25 PIA burden is to eliminate the cross-border transfer entirely. When your AI workload runs on hardware located in Quebec, personal data never leaves provincial jurisdiction — and the Section 17 PIA trigger does not fire.
The practical implications are significant:
| Factor | Cloud AI (US provider) | On-premise AI (Quebec infrastructure) |
|---|---|---|
| Section 17 PIA required? | Yes — mandatory before any personal data leaves Quebec | No — data stays in-province; no cross-border transfer to assess |
| US CLOUD Act exposure | Yes — US provider can be compelled to produce data held anywhere | No — data is on your hardware, under Canadian/Quebec law only |
| Jurisdiction equivalency analysis | Required — must assess US legal protection standard vs. Quebec Act | Not required — same jurisdiction, same law applies throughout |
| Contractual safeguards required | Mandatory — data processing agreement, cross-border clauses | Internal governance only — your own policies and contracts |
| Ongoing third-party audit rights | Dependent on vendor cooperation; often limited to SOC 2 reports | Full — you own and audit your own infrastructure |
| Breach notification complexity | Depends on vendor’s detection and notification practices | Controlled internally; faster detection, direct CAI notification path |
On-premise deployment does not eliminate privacy obligations — you still need to conduct PIAs for new AI projects that involve personal data (best practice under Law 25’s accountability principle, Section 3.3 governance requirements, and the spirit of the Act). But the scope of each assessment is narrower, the residual risks are lower, and the go/no-go decision is cleaner. There is no third-party risk introduced that you cannot fully control.
This is one of the strongest technical arguments for sovereign AI infrastructure: it trades complex, ongoing vendor-management risk for a one-time capital investment and an internal governance exercise.
For a deeper analysis of how Quebec Law 25 affects AI procurement decisions, see our guide: Quebec Law 25 and On-Premise LLMs — The Complete Compliance Guide. For background on why cloud provider jurisdiction matters beyond Quebec, see: US CLOUD Act and Canadian AI Data.
Section 3.3 governance: the foundation your PIA program needs
A PIA is only as credible as the governance structure backing it. Law 25’s Section 3.3 provisions require organizations to designate a person responsible for the protection of personal information (your “Privacy Officer” or responsable de la protection des renseignements personnels). That person’s name and title must be published on your website.
Practically, a Section 3.3-compliant Privacy Officer for an AI project should be able to:
- Understand the technical architecture of the AI system well enough to map data flows accurately
- Assess the legal-protection adequacy of vendor jurisdictions (or engage counsel who can)
- Own the PIA document and defend it to the CAI if challenged
- Maintain a record of every PIA conducted, including updates and the rationale for sign-off decisions
For SMBs that lack a dedicated privacy team, the Privacy Officer role is often held by the CTO, COO, or a senior operations lead — supplemented by external legal counsel for complex cross-border or AI assessments. The role cannot be delegated to a vendor (“our cloud provider handles privacy” is not a compliant answer under Law 25).
Common Law 25 PIA mistakes on AI projects
- Scoping only the storage layer, not the processing layer. Section 17 applies to “communication” of personal information outside Quebec — which includes sending data to a US API endpoint for processing, even if the results come back and are stored locally. The processing counts.
- Treating a vendor’s SOC 2 report as a PIA. SOC 2 addresses security controls, not Quebec privacy law compliance. It is useful evidence within a PIA, but it does not replace the equivalency analysis required by Section 17.
- Conducting the PIA after deployment. Law 25 requires the assessment before the personal information is communicated outside Quebec. A retroactive PIA can demonstrate current compliance but does not cure a past violation.
- Failing to update the PIA when the project changes. If you add a new data source, change your cloud vendor, or expand the scope of AI processing, the original PIA is no longer current. The CAI’s accountability principle requires you to keep assessments current.
- No written agreement with the recipient. Section 17 explicitly requires a written agreement. A vendor’s terms-of-service (which you didn’t negotiate) may not meet this bar — especially on data-use-for-training clauses, audit rights, and breach notification timelines.
Quebec’s digital sovereignty context
Law 25 does not exist in isolation. It is part of a broader Quebec policy direction that prioritizes residents’ control over their personal data — a direction that aligns with the growing global recognition that data sovereignty is an economic and security issue, not just a legal formality.
Quebec’s hydro-electric advantage (among the lowest electricity rates in North America, as of 2024–2025 reporting from Hydro-Québec) creates a genuine local alternative: organizations that deploy AI workloads on Quebec-based on-premise or co-located infrastructure can comply with Law 25 more simply, reduce operating costs relative to major US cloud regions, and strengthen their competitive position as a privacy-respecting service provider.
For a broader view of how this connects to Canada’s digital independence, see: Digital Sovereignty in Canada — A Practical Guide.
How D-Central supports Law 25 PIA readiness
D-Central Technologies — operating since 2016 at 1325 Rue Bergar, Laval, Quebec — helps Quebec and Canadian organizations design and deploy on-premise AI infrastructure that reduces Law 25 compliance complexity. Our work is grounded in the principle that owning your compute is the most durable form of privacy compliance: you cannot be compelled to hand over data to a foreign government if that data never left your building.
We do not provide legal advice, and we work alongside — not as a substitute for — your legal counsel and Privacy Officer. What we do provide is the technical architecture that makes the compliance argument cleaner: private hardware, Quebec-located compute, air-gapped or private-network configurations, and open-source AI models that you can audit end-to-end.
If you are preparing for a Law 25 PIA on an AI project and want to understand the technical architecture options, contact our AI Sovereignty Consulting team — or explore the open-source AI infrastructure paths available through Local LLM deployment in Canada.
Frequently asked questions
- Does Quebec Law 25 apply to my business if I am not based in Quebec?
- Law 25 applies to any organization that collects, holds, uses, or communicates personal information about Quebec residents in the course of carrying on an enterprise, regardless of where the organization is incorporated or headquartered. If you serve Quebec customers or employ Quebec residents, Law 25 applies to that personal information. Confirm the specific scope with legal counsel.
- What counts as “personal information” under Law 25 for AI purposes?
- Law 25 adopts a broad definition: any information that directly or indirectly identifies a natural person. For AI systems, this can include: names or email addresses in prompts, voice recordings, user behavior logs linked to identifiable individuals, employee performance data, and IP addresses (in most contexts). Aggregated, truly anonymized data falls outside the definition — but the anonymization standard under Law 25 is strict; pseudonymization alone is generally not sufficient.
- Is there a minimum size threshold — does Law 25 apply to small businesses?
- Law 25 does not contain a formal SMB exemption equivalent to GDPR’s small-enterprise exclusion for some obligations. All enterprises that collect personal information about Quebec residents are subject to its core provisions, including the Section 17 PIA requirement. However, the CAI’s enforcement priorities and the proportionality principle in the Act mean that a sole proprietor processing a small mailing list faces a different risk profile than a 500-person company running AI on customer records. Consult the CAI’s published guidance for SMBs.
- Can we use a vendor’s PIA to satisfy our own Law 25 obligations?
- No. Your organization is the responsible party for personal information you collect. A vendor may provide useful documentation (SOC 2 reports, DPIAs conducted under GDPR, their own internal assessments), but these supplement rather than replace your own assessment. You must conduct an independent analysis of whether the cross-border transfer satisfies Section 17’s requirements — including the adequacy of legal protection in the vendor’s jurisdiction.
- How often must a PIA be updated?
- Law 25 requires that a PIA be conducted before a cross-border communication begins, and updated when there is a material change to the project, technology, or the recipient’s legal environment. The CAI has not published a fixed review interval, but practitioners commonly schedule annual reviews for active AI projects and triggered reviews whenever: the vendor changes, the data scope expands, the vendor’s terms of service change, or a significant security incident occurs. Document your review schedule in the PIA itself.
- What happens if we skip the PIA and the CAI investigates?
- Under Law 25, the CAI can impose administrative monetary penalties of up to CAD 25 million or 4% of worldwide turnover (whichever is higher) for serious violations — with cross-border transfer without a compliant PIA explicitly listed among the categories subject to penalties. The CAI can also issue orders requiring cessation of the data transfer. Penalties at the higher end are reserved for the most serious violations; however, the absence of any PIA documentation — rather than an imperfect one — is a significant aggravating factor in any investigation. This information is based on the Law 25 penalty framework as enacted; verify current enforcement guidance with the CAI.
- Does on-premise AI eliminate all Law 25 PIA obligations?
- On-premise AI deployed entirely within Quebec eliminates the Section 17 cross-border transfer trigger — which is the most operationally complex PIA obligation for AI projects. You still have obligations to: handle personal information only for the stated purpose, obtain appropriate consent, allow individuals to exercise their rights (access, correction, deindexation), and report confidentiality incidents to the CAI. But the cross-border transfer assessment — typically the most expensive and uncertain element — is removed from the compliance picture entirely.
- Where can I find official CAI guidance on PIAs?
- The Commission d’accès à l’information du Québec publishes official guidance, templates, and educational resources at cai.gouv.qc.ca. The CAI also publishes a guide specific to PIAs for cross-border transfers (Guide pour réaliser une évaluation des facteurs relatifs à la vie privée). Always rely on official CAI publications as your primary source; this page is educational context, not legal advice.
Related products, repair, and setup paths
- Bitcoiner sovereignty hub
- the plebs sovereign stack
- Nostr for Bitcoiners
- run your own Nostr relay
- getting started with Meshtastic
- Bitcoin over Meshtastic mesh networks
- open-source hardware tools directory
- off-grid Bitcoin mining
Last reviewed June 15, 2026.
