PIPEDA AI Compliance Checklist: 12 Items With an Objective Completion Test
The Privacy Commissioner of Canada published joint findings into OpenAI on 6 May 2026 and opened complaints against X Corp. and X.AI on 15 January 2026, both analysed against the ordinary PIPEDA principles. This is a twelve-item checklist for a Canadian organisation deploying AI, in dependency order, each with a test somebody outside the privacy team could run, and honest about the four items no architecture purchase closes.
The Privacy Commissioner of Canada published joint findings into OpenAI on 6 May 2026 with the Quebec, British Columbia and Alberta authorities, and had already initiated complaints against X Corp. and X.AI LLC on 15 January 2026 under subsection 11(2). Both were analysed against the Schedule 1 principles that have been in force for all commercial activity since 1 January 2004.
Bill C-27 died on prorogation in January 2025, so nobody in Canada is waiting for an AI statute before being examined. These twelve items run in dependency order, and each states a test somebody outside your privacy team could run.
1. Establish which AI tools are actually processing personal information
Approved-vendor lists describe intent. A first pass usually surfaces model endpoints nobody registered, reached by an agent a developer stood up in an afternoon.
Done when: the list of AI tools processing personal information reconciles against observed egress to model endpoints over the last 30 days, with every unexplained destination either approved or blocked. The method is the same one in shadow AI discovery.
2. Name the accountable individual and date the assessment
Principle 4.1 requires a designated person accountable for compliance. The OPC's finding against OpenAI cited insufficient governance structures before launch, which is about when the assessment happened rather than whether it exists.
Done when: a named individual is documented, and each AI tool in item 1 has a privacy assessment dated before the tool went live.
3. Write down the purpose for each tool, at the level the tool is actually used
Principle 4.2 requires purposes identified at or before collection. A purpose written as improving customer experience covers everything and constrains nothing.
Done when: each tool has a stated purpose specific enough that a reviewer can name a plausible use that falls outside it.
4. Record every outbound AI request off the application path
This is the item items 5 through 10 depend on. A record written by the application that made the call is a statement by the party under examination, which is the self-attestation problem in a privacy setting.
Done when: for a sampled hour, a record exists per outbound request naming the destination, the identity that initiated it, the data classes present, the policy evaluated, and the outcome.
5. Constrain what leaves, field by field
Principle 4.4 limits collection to what the identified purposes require. A prompt carrying a whole customer record for a task needing three fields creates the exposure at the moment of composition.
Done when: a test prompt containing personal information beyond the declared purpose is redacted or refused at the request layer, with the decision recorded.
6. Bind each request to the originating principal
Most stacks authenticate a user at the application and then call the model with one service credential carrying everyone's combined privileges. Attribution ends at exactly that hop, which breaks both the access-request answer and any incident scoping.
Done when: for a sampled request, the record names the person who initiated it rather than the service account. This is the post-authentication gap stated as a test.
7. Classify on the request rather than on documents at rest
Network data-loss prevention runs underneath TLS to a provider API. Document classification reads a file, while a prompt assembles fragments from several systems into one payload.
Done when: a prompt carrying a known sensitive pattern is classified and handled by policy at the request layer, and the decision appears in the record from item 4.
8. Set the default to deny
Principle 4.7 scales safeguards to sensitivity, and a control that falls open on evaluator error is a control during normal operation only.
Done when: an induced policy-service failure in a test environment produces refused requests, recorded and alerted.
9. Make the access-request answer produceable
Section 12 asks what personal information you hold about a requester and to whom it has been disclosed. A transfer to a hosted model is a transfer to a processor that the answer has to account for.
Done when: given a named individual and a date range, someone can list every AI request that carried their personal information and where it went, within your standard access-request turnaround.
10. Prepare the breach assessment path
Since November 2018, sections 10.1 to 10.3 have required reporting to the Commissioner where a breach creates a real risk of significant harm, notification to affected individuals, and a record of every breach whether or not it met the threshold, retained for 24 months. Knowingly failing to keep those records carries a fine of up to CAD $100,000.
Done when: a tabletop covering a misconfigured agent sending prompts to an unapproved endpoint for six weeks produces a documented harm assessment naming the data classes, the volume, and the individuals affected, using records rather than estimates.
11. Set retention and disposal, including on the vendor side
Principle 4.5 limits retention to what the purposes require. Two stores matter here: your own, and the provider's.
Done when: a written retention schedule covers AI request records and outputs held internally, and each provider contract states whether prompts are retained and for how long. This item is owned by data governance and procurement.
12. Address accuracy before an output enters a record system
Principle 4.6 requires personal information to be as accurate as necessary for the purposes it is used for, and the OPC found no general assessment validating accuracy of personal information in outputs. No proxy on the request path evaluates truth.
Done when: each decision type using AI output about an identifiable person has a documented human review step before the output enters a system of record, plus the ability to reproduce what was generated when someone disputes it. This item is owned by the business function making the decision.
What this checklist does not cover
Items 2, 11 and 12 are organisational, contractual, and process work that no component on the HTTP path closes. Consent capture, publishing your privacy practices, and running a complaints channel under Principle 4.10 sit outside the list entirely.
Provincial law adds obligations this list does not carry. Quebec's Law 25 imposes privacy impact assessments and specific automated-decision rules, and the Commission d'accès à l'information found consent and retention issues unresolved in the OpenAI matter where the federal OPC deemed them conditionally resolved. British Columbia and Alberta operate substantially similar private-sector statutes. The full principle-by-principle version is in the PIPEDA controls mapping, and the artifacts a reviewer inspects are in the PIPEDA audit evidence walkthrough.
My candid view: item 9 is the one that will embarrass most organisations first, because access requests arrive from individuals rather than regulators and they arrive on a clock. An organisation that has to tell a requester it cannot determine which AI providers received their information has written its own finding. The fix is item 4, which nobody prioritises because it produces no demo and no dashboard anyone asked for.
DeepInspect
This is the control point items 4 through 10 describe. 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.
That component supplies the reconciliation in item 1, the record in item 4, the field-level constraint in item 5, the principal binding in item 6, the classification in item 7, the fail-closed posture in item 8, the disclosure history in item 9, and the payload and volume figures item 10 needs to assess real risk of significant harm. Items 2, 11 and 12 stay with your privacy, procurement and business functions. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does PIPEDA apply to our use of a third-party AI tool?
It applies to the collection, use, and disclosure of personal information in commercial activity, and sending personal information to a hosted model is processing within that scope. Accountability under Principle 4.1 stays with the transferring organisation, and a transfer to a processor is treated as a use rather than a disclosure only where that accountability and comparable protection are maintained.
- How long do we keep breach records?
Twenty-four months from the day the organisation determines a breach of security safeguards occurred, for every breach whether or not it met the real-risk-of-significant-harm reporting threshold, in enough detail for the Commissioner to verify compliance with the reporting obligation.
- What counts as real risk of significant harm?
The assessment turns on the sensitivity of the information involved and the probability it will be misused. Significant harm is defined broadly and includes humiliation, damage to reputation or relationships, loss of employment, financial loss, identity theft, and negative effects on a credit record.
- Do we need a privacy impact assessment for an AI tool?
PIPEDA does not mandate one for private-sector organisations in the way public-sector policy does, and Principle 4.1 and the OPC's governance findings make a dated pre-deployment assessment the practical expectation. Quebec's Law 25 does impose assessment obligations that apply to organisations operating there.
- Which of these items can architecture close?
Items 1 and 4 through 10, in the sense that a policy enforcement point on the request path supplies the artifact each test asks for. Items 2, 3, 11 and 12 are governance, procurement, and business-process work.
- How often should this be re-run?
Run items 1 and 9 quarterly, since tool inventories drift fastest and the access-request answer is the freshness test for everything underneath it. Items 4 through 8 are architecture and need re-testing when the request path changes, while 2, 11 and 12 follow the privacy programme's normal cycle.