PIPEDA and AI Procurement: 10 Mistakes Legal and Privacy Teams Keep Making

The Office of the Privacy Commissioner of Canada has pointed to several hundred breach reports tied to automated decision systems and AI tools in recent public remarks on generative AI oversight. It has not published a precise annual figure broken out by system type. Most of those reports trace back to the same handful of procurement mistakes, repeated by legal and privacy teams evaluating Canadian AI platforms 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.

Ten mistakes surface more than any others, according to privacy counsel who review vendor contracts for a living and OPC guidance published since 2023.

PIPEDA 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 applying PIPEDA's ten fair information principles to AI systems, but 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.

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 guidance with provincial counterparts, 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.

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. Legal teams need to ask a plain question during procurement: where does the model run, not just where is the data warehoused.

One Toronto privacy lawyer, speaking on a 2025 CBA panel on AI procurement, framed it this way. Inference location is a privacy fact, not a marketing detail, and organizations that skip the question are accepting risk they never measured.

Some vendors disclose where inference runs as a matter of course. Augure 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

Ontario's Consumer Protection and Cybersecurity Sector Council guidance and the broader Canadian Program for Cyber Security Certification get less attention than PIPEDA or Law 25 in most AI procurement checklists. They are newer and less litigated. Teams focused on federal and Quebec obligations often miss sector-specific cybersecurity certification requirements sitting on top of privacy law, particularly for defence contractors and critical infrastructure operators.

Law 25 is not PIPEDA with an accent

They overlap substantially but are not the same statute. Quebec's private-sector privacy law, in force since September 2023, requires a privacy impact assessment for any project involving personal information transfer outside Quebec, administered by the Commission d'accès à l'information. 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.

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.

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.

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.

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. A Canadian mailing address alone establishes none of it.

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 options positioned that way, alongside larger US incumbents adding Canadian regions to existing global infrastructure. Those are not the same architecture. 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. Whatever 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 — and the ten mistakes above are the ones showing up most often in the files regulators are already reviewing.