Does PIPEDA apply to AI systems?

It applies to the collection, use, and disclosure of personal information in the course of commercial activity, regardless of the technology involved. The OPC has been explicit about this in practice, publishing joint findings into OpenAI on 6 May 2026 and initiating complaints against X Corp. and X.AI on 15 January 2026, both analysed against the existing principles rather than any AI-specific statute.

Is there AI-specific privacy legislation in Canada?

No federal AI-specific privacy statute is in force. Bill C-27, which contained the Consumer Privacy Protection Act and the Artificial Intelligence and Data Act, died when Parliament was prorogued in January 2025. Federal, provincial and territorial privacy authorities published principles for responsible generative AI in December 2023, which are guidance rather than binding law, and PIPEDA remains the operative instrument.

What did the OPC find in the OpenAI investigation?

The joint investigation, published 6 May 2026, found collection from publicly accessible sources overbroad and therefore inappropriate under section 5(3), no valid consent for collection from public sources or user interactions, incomplete transparency about data sources and training practices, no general assessment validating accuracy of personal information in outputs, inadequate access, correction and deletion mechanisms, no formal retention and disposal policies at deployment, and insufficient governance before launch. The OPC deemed the issues conditionally resolved while Quebec's CAI found consent and retention issues unresolved.

What records must we keep after an AI-related breach?

Under section 10.3, a record of every breach of security safeguards, whether or not it met the real-risk-of-significant-harm threshold, retained for 24 months and detailed enough for the Commissioner to verify compliance with the reporting obligation. Knowingly failing to keep them carries a fine of up to CAD $100,000.

How do we answer an access request that involves AI processing?

By producing what personal information about the requester the organisation holds and to whom it has been disclosed. The disclosure half is where AI tools complicate matters, since a prompt sent to a third-party model is a disclosure to a processor. Answering it needs a record of which requests carried that individual's information and where they went.

Does using a vendor's enterprise plan transfer the obligation?

No. Accountability under Principle 4.1 remains with the organisation that transferred the information for processing, and PIPEDA treats a transfer to a processor as a use rather than a disclosure only where the organisation retains that accountability. The general argument sits in You Own the AI Liability, Not the Vendor.

PIPEDA AI Audit Evidence: What the OPC Asked OpenAI For, and What It Will Ask You For

On 6 May 2026 the Office of the Privacy Commissioner of Canada published the findings of a joint investigation into OpenAI conducted with the Commission d'accès à l'information du Québec, the Office of the Information and Privacy Commissioner for British Columbia, and the Office of the Information and Privacy Commissioner of Alberta. The overview of findings ran the analysis against appropriate purposes under section 5(3), consent, openness, accuracy, access, retention, and accountability.

Read as a compliance document, it is a list of the artifacts the regulator expected to see and did not. Two months earlier, on 15 January 2026, the Commissioner had initiated complaints against X Corp. and X.AI LLC under subsection 11(2) covering Grok. The pattern is a regulator now examining AI deployments with the ordinary PIPEDA principles rather than waiting for AI-specific law, which matters because Bill C-27 and the artificial intelligence framework inside it died on prorogation in January 2025.

I want to walk the evidence each principle asks for in a deployment context, since most Canadian organisations in scope here are deployers rather than model developers, and the deployer's obligations attach to a different set of records.

Accountability: Principle 4.1

The principle requires a designated individual accountable for compliance and policies giving effect to it. The OPC's finding against OpenAI cited insufficient governance structures in place before launch, which is a timing point rather than a documentation point.

The artifact is a dated governance record predating deployment: who signed off, against what assessment, on what date. A privacy impact assessment produced three months after a tool went live establishes that somebody eventually worried about it.

Appropriate purposes: section 5(3)

Section 5(3) permits collection, use, and disclosure only for purposes a reasonable person would consider appropriate in the circumstances. It sits above consent, which means consent does not rescue an inappropriate purpose.

For a deployer, the question becomes concrete at the request boundary. When an employee pastes a customer file into a general-purpose model to summarise it, the purpose of that disclosure to a third-party processor is whatever the employee had in mind at 4pm. The evidence a reviewer wants is a record showing which data categories actually reached which model endpoints, which is a different document from the policy saying which ones were supposed to.

Consent and openness: Principles 4.3 and 4.2

The findings cited failure to obtain valid consent and incomplete information about data sources and practices. Consent under PIPEDA has to be meaningful, which requires that a person understand the consequences of what they are agreeing to.

For a deployer the artifact set is narrower and harder: the notice given to individuals whose personal information is processed through an AI tool, the version of that notice in force on a given date, and evidence that processing matched it. That last item is the one nobody holds. A notice saying customer data may be processed by AI service providers is undermined by a destination log showing calls to four providers nobody listed.

Safeguards: Principle 4.7

The safeguards principle scales protection to sensitivity. Applied to AI traffic, the awkward property is that the payload is opaque to most of the controls an organisation already runs.

Network data-loss prevention sits underneath TLS to a provider API. Document-level classification examines a file, while a prompt assembles fragments from several sources inside a context window and ships them as one HTTPS payload. The safeguard evidence a reviewer can inspect is a per-request classification decision and the policy outcome that followed it. IBM's Cost of Data Breach research found customer PII exposure reached 65% in shadow AI breaches against 53% across all breaches, which is the number to expect when this control is absent.

Access and retention: section 12 and Principle 4.5

The OPC found inadequate mechanisms to fulfil access, correction, and deletion rights, and no formal retention or disposal policies at deployment.

An access request under PIPEDA asks an organisation to say what personal information about the requester it holds and to whom it has been disclosed. For an organisation running AI tools, answering the disclosure half requires knowing which prompts carrying that person's information went to which providers. Reconstructing that from application logs after the request arrives is the common approach, and it produces an answer the organisation cannot fully stand behind.

Breach records: sections 10.1 to 10.3

Since November 2018, PIPEDA has required reporting to the Commissioner of any breach of security safeguards creating a real risk of significant harm, notification to affected individuals, and, under section 10.3, a record of every breach whether or not it met the reporting threshold, retained for 24 months. Knowingly failing to keep those records carries a fine of up to CAD $100,000.

Real risk of significant harm turns on the sensitivity of the information and the probability of misuse. Assessing either requires knowing what was in the payload. An organisation that discovers a misconfigured agent sent prompts to an unapproved endpoint for six weeks has a reporting decision to make, and making it needs the content and the volume.

What a proxy on AI traffic does not do

Four of the eight rows above read No or Partial, and the reasons are worth stating rather than glossing.

Accountability is an organisational appointment. Retention and disposal of personal information inside your own systems is a data-governance programme reaching far past AI traffic. Consent capture happens in product and legal surfaces. The OPC's findings against OpenAI concerned training-data collection from public sources at a scale that no deployer-side control touches at all, since the collection happened before any Canadian organisation's request reached the model.

My candid view: the most useful sentence in the OPC findings for a deployer is the accuracy one, that no general assessment validated the accuracy of personal information in model outputs. Principle 4.6 requires personal information to be as accurate as necessary for the purposes it is used for, and a model that fabricates a plausible detail about a named person has produced inaccurate personal information inside your process. Nobody has a good answer to that yet, and the organisations that will handle it least badly are the ones that can at least reconstruct what was asked and what came back.

DeepInspect

This is the record layer underneath the rows marked Yes. DeepInspect sits inline between your users or agents and the LLM APIs they call, as a stateless proxy the calling application has no custody over. It evaluates identity, request classification, and destination on every call, enforces per-role and per-route policy with a fail-closed default, and writes a signed, tamper-evident per-decision record.

For a PIPEDA deployment that record establishes which data categories reached which provider, under which policy, on behalf of which identity, which is the input to the appropriate-purposes analysis, the safeguards evidence, the disclosure half of an access request, and the risk-of-significant-harm assessment when something goes wrong. Consent capture, retention policy, and accountability appointments stay where they are. Book a technical deep dive at deepinspect.ai.