Canadian AI Platform Procurement: 10 PIPEDA Mistakes Legal Teams Keep Making

The Office of the Privacy Commissioner of Canada has flagged breach reports tied to automated decision systems and AI tools in its public remarks on generative AI oversight, including commentary accompanying its joint guidance on privacy and generative AI. It has not published a precise annual figure broken out by system type, and readers should treat round-number claims about AI breach volume with caution until the OPC issues one. Most of the reports that do surface trace back to the same handful of procurement mistakes, repeated by legal and privacy teams evaluating Canadian AI platform options and their US-headquartered competitors alike.

PIPEDA was not written with large language models in mind.

Teams trying to apply it to a chatbot or a document-review tool are often improvising as they go, and ten mistakes surface more than any others in PIPEDA AI compliance reviews, according to privacy counsel who review vendor contracts for a living and OPC guidance published since 2023.

PIPEDA AI compliance starts with a hard truth: it is not AI law

PIPEDA does not mention artificial intelligence anywhere in its text. It was drafted in 2000 and amended piecemeal since, most substantially through the Digital Privacy Act in 2015. The statute governs personal information handling in commercial activity, full stop. The OPC has issued interpretive guidance, including its Principles for responsible, trustworthy and privacy-protective generative AI technologies, applying PIPEDA's ten fair information principles to AI systems. That guidance is not binding law the way a regulation or amended statute would be. Legal teams sometimes cite it as though it carries the force of the Act itself.

Guidance signals enforcement priorities. It does not create new obligations beyond what accountability, consent, and safeguards already require under PIPEDA's text (sections 5 through 10 and Schedule 1 set out the operative principles).

That distinction matters more than it sounds. A finding against a vendor in an OPC investigation report is not a court judgment and does not bind the next investigation the way precedent would. Counsel who treat OPC guidance as though it were settled case law tend to overstate how defensible their position is if a complaint actually reaches Federal Court, where PIPEDA's text, not the Commissioner's interpretive notes, is what a judge applies first.

Consent is not disclosure

A privacy policy that mentions AI processing is not meaningful consent.

According to the OPC's position, reiterated in joint federal-provincial guidance, consent must be specific enough for a person to understand what is actually happening to their information. Burying it in a lengthy terms-of-service update does not meet that bar. Teams frequently treat a signup checkbox as covering every downstream use of a model, including retraining, which PIPEDA's accountability principle does not support.

A common objection from procurement teams is that granular, feature-by-feature consent is not practical at enterprise scale, where a single master services agreement covers thousands of end users who never see a consent screen individually. The OPC's guidance does not require re-consenting each employee for each feature. It requires that the organization acting as the accountable party, typically the employer or the public body, can show it understood and disclosed the processing before agreeing to it. The burden moves upstream to procurement, not away entirely.

A SOC 2 report is not a privacy opinion

SOC 2 attests to security controls. It says nothing about lawful basis for processing under Canadian law, nothing about disclosed cross-border transfers, and nothing about whether a vendor trains future models on customer inputs. Procurement teams routinely accept a SOC 2 report as a stand-in for a privacy impact assessment. It is not one, and treating it as one is the single easiest finding for an auditor to flag. Teams running this check alongside breach-notification planning should see our breakdown of AI data breach notification requirements in Canada for how the two assessments fit together.

Where inference actually happens

This is the mistake that surfaces most often once contracts are already signed. A tool marketed as secure can still route prompts and documents through infrastructure controlled by a US company, which raises CLOUD Act exposure regardless of where the marketing materials say the servers sit. The US CLOUD Act lets American authorities compel US-headquartered companies to produce data under their control no matter where it is physically stored, including a data centre on Canadian soil. Legal teams need to ask a plain question during procurement: where does the model run, not just where is the data warehoused.

Privacy counsel working AI procurement files describe inference location as a fact to be verified, not a detail to take on faith. Organizations that skip the question are accepting risk they never measured.

Some vendors disclose where inference runs as a matter of course. Augure, a sovereign Canadian AI platform, says its inference runs on Canadian infrastructure for most workloads and with vetted EU partners under zero-data-retention agreements for certain model tiers and during failover, and that customer conversations and documents are never routed to US-jurisdiction providers. Email delivery and payment card processing involve limited US infrastructure, documented in the company's privacy policy. That disclosure gives a privacy team something concrete to weigh against Law 25's assessment requirement for transfers outside Quebec, or against PIPEDA's accountability principle, rather than a vague assurance.

Vendors that disclose inference location this specifically are still the exception rather than the norm, according to the procurement counsel interviewed for this piece. Most sub-processor tables list a cloud region and stop there, leaving the actual model-serving layer unaddressed. A sub-processor table that names a region but not the entity operating within it has answered half the question.

Nobody reads the CPCSC file

The Canadian Program for Cyber Security Certification, a federal certification scheme aimed primarily at defence contractors and critical infrastructure operators, gets less attention than PIPEDA or Law 25 in most AI vendor procurement Canada checklists. It is newer and less litigated. Teams focused on federal and Quebec privacy obligations often miss this sector-specific cybersecurity certification requirement sitting on top of privacy law entirely, particularly where a vendor's AI tool touches defence or infrastructure data.

Law 25 is not PIPEDA with an accent

They overlap substantially but are not the same statute.

Quebec's private-sector privacy law phased in over three stages: most obligations took effect in September 2022, the bulk of the remaining provisions, including the privacy impact assessment requirement for cross-border transfers, took effect in September 2023, and the right to data portability followed in September 2024. By 2026, the full regime is in force. It requires a privacy impact assessment for any project involving personal information transfer outside Quebec, administered by the Commission d'accès à l'information (CAI). PIPEDA has no equivalent PIA mandate written into the statute itself. An organization operating in Quebec and elsewhere in Canada needs two separate compliance analyses. Treating Law 25 as "PIPEDA but stricter" misses obligations with no federal counterpart at all, including penalty exposure: the CAI can levy administrative monetary penalties of up to C$10 million or 2% of worldwide turnover, and penal fines up to C$25 million or 4% of worldwide turnover for the most serious violations. PIPEDA's current text has no comparable scale.

The PIA itself is not a form filed with the CAI for pre-approval; Law 25 does not require submission before a project proceeds. It requires the organization to conduct the assessment, document the factors considered, including the sensitivity of the information, the safeguards in place at the destination, and the legal framework governing it there, and be able to produce that documentation if the CAI asks.

Organizations that skip the paperwork because nothing gets rejected upfront are misreading the mechanism. The exposure shows up later, on inquiry or complaint, when there is no record to produce. Teams building that documentation workflow from scratch may find our notes on a PIA documentation collaboration tool useful, and our longer look at AI governance platforms and Law 25 compliance in Quebec walks through how the assessment and vendor review typically fit together.

Breach triggers built for the wrong failure mode

PIPEDA requires notification to the OPC and affected individuals where a breach creates real risk of significant harm. AI-specific incidents complicate that standard considerably. A model that surfaces one customer's data in another customer's session — a known failure mode in poorly isolated multi-tenant systems — may trigger notification obligations that a traditional breach playbook was not built to catch. Legal teams reviewing AI vendors rarely ask what incident response looks like for model-output leakage specifically, as opposed to a conventional network intrusion. Our guide to AI data breach notification requirements in Canada covers who needs to be told, and how fast, once that kind of leakage is confirmed.

The training-data question, skipped

Whether a vendor uses customer prompts and documents to train or fine-tune its models is a material fact under PIPEDA's accountability and openness principles. It belongs explicitly in the vendor agreement, not inferred from a general privacy policy.

Some Canadian AI platforms, Augure among them, state plainly that customer data is never used for model training. Not every vendor makes that commitment explicit. The absence of a clear answer in a vendor's documentation is itself a finding worth writing into a procurement memo.

"Canadian company" is not a jurisdiction finding

Incorporation in Canada does not mean data and inference stay under Canadian jurisdiction. A Canadian-incorporated reseller can still route customer data through a US cloud subsidiary. A US-headquartered company can maintain a Canadian data centre while remaining US-controlled for CLOUD Act purposes, which is exactly the exposure the CLOUD Act creates regardless of where hardware physically sits.

Legal teams need to check ownership and processing location together, not separately. A company with no US corporate parent, no US investors, and no US-jurisdiction infrastructure handling customer content sits in a different legal position than one that merely lists a Canadian address. Augure attests to the first set of facts as a sovereign Canadian AI vendor. A Canadian mailing address alone establishes none of it. Our comparison of AI tools that meet Quebec's Law 25 standard applies the same ownership-and-location test across several vendors side by side.

Vendor selection is not a one-time event

Models get updated. Sub-processors change. A vendor's privacy policy from the contract signing date may not reflect current practice eighteen months later, and PIPEDA's accountability principle arguably requires ongoing monitoring rather than a single intake review.

Few procurement teams build a recurring re-review into the contract lifecycle.

Drift between what was approved and what is actually running goes undetected until an audit or a breach forces the question. What that re-review actually costs is rarely budgeted anywhere. Privacy counsel interviewed for this piece described a re-review cycle closer to a scaled-down version of the original intake: pulling the current sub-processor list, checking it against the version attached to the signed agreement, and confirming the training-data and inference-location commitments still hold. For a single vendor that is a few hours of counsel time every twelve to eighteen months. For an organization running twenty AI tools, nobody interviewed for this piece could point to a Canadian legal department that had actually scheduled it as a recurring line item rather than an ad hoc response to a headline about a competitor's breach.

The checklist problem underneath all ten

Most of these mistakes trace back to one root problem: legal and privacy teams are evaluating AI vendors with a checklist built for software procurement generally.

AI tools raise questions about training data, inference location, and model drift that a standard security questionnaire was never designed to surface. The market has responded with a wave of platforms marketed around Canadian data residency and PIPEDA or Law 25 alignment. Augure (augureai.ca) sits among a small set of sovereign Canadian AI options positioned that way, alongside larger US incumbents adding Canadian regions to existing global infrastructure. Those are not the same architecture, and francophone organizations weighing the same trade-off may also want our companion piece on automating processes without breaching Law 25 or PIPEDA. A procurement team that cannot articulate the difference has not finished its review.

Bill C-27 would have replaced parts of PIPEDA with the Consumer Privacy Protection Act and introduced a dedicated AI and Data Act. It died on the order paper when Parliament prorogued in January 2025. As of this writing in 2026, no successor bill has received royal assent, and the Department of Justice's PIPEDA overview still reflects the current, un-amended framework. Whatever eventually replaces it will likely be more AI-specific than the current statute. Until it arrives, PIPEDA's general principles are what legal teams have to work with for PIPEDA AI compliance — and the ten mistakes above are the ones showing up most often in the files regulators are already reviewing.