PIPEDA AI Controls Mapping: The Ten Schedule 1 Principles Against AI Traffic

PIPEDA's ten fair information principles sit in Schedule 1, adopted from the CSA Model Code and in force for all commercial activity since 1 January 2004. They were written before anyone sent a customer record to a hosted model, and the Privacy Commissioner is applying them to exactly that without waiting for new law.

The joint findings into OpenAI published 6 May 2026 with Quebec, British Columbia and Alberta ran the analysis against appropriate purposes, consent, openness, accuracy, access, retention, and accountability. Every one of those is a Schedule 1 principle or a section that reads onto one. Bill C-27, with the Consumer Privacy Protection Act and the artificial intelligence framework inside it, died on prorogation in January 2025, so Schedule 1 is what a Canadian deployment is measured against today.

I want to map the ten principles to controls for a deployer, because a mapping written for a model developer answers different questions than the ones your security review is being asked.

The three principles AI traffic does not change

Openness (4.8), Individual Access (4.9), and Challenging Compliance (4.10) are process obligations. Publishing your privacy practices, running an access request workflow, and operating a complaints channel are the same tasks whether or not a model is involved.

Access carries one qualification worth stating. The right under section 12 covers what personal information the organisation holds and to whom it has been disclosed, and a prompt sent to a hosted model is a transfer to a processor that the disclosure half of the answer has to account for. The workflow itself is unchanged, and what feeds it changes considerably, which is why the mapping below scores 4.9 as partial rather than none.

Accountability and Identifying Purposes: 4.1 and 4.2

Principle 4.1 requires a designated accountable individual and policies giving it effect, and it survives transfer to a third party for processing. Principle 4.2 requires purposes to be identified at or before collection.

The control for 4.1 is organisational: a named owner, a dated pre-deployment assessment, and a supplier assessment for each model provider. The OPC's finding of insufficient governance before launch was a timing finding, and a dated record is the only thing that answers it.

The control for 4.2 becomes interesting when the tool is general-purpose. A purpose identified as customer support summarisation is satisfied when support staff summarise tickets and quietly exceeded when the same tool is used to draft performance reviews. Evidence of purpose limitation is a record of what actually went where, not the statement of intent.

Consent and Limiting Collection: 4.3 and 4.4

Consent has to be meaningful, which under OPC guidance means a person can understand the consequences of agreeing. Limiting collection restricts collection to what is necessary for the identified purposes.

The deployer-side control for both is the same: constraining what leaves. A prompt carrying a full customer record when the task needed three fields is a collection and disclosure problem created at the moment of composition, and the only place it can be caught is on the request. Redaction and field-level policy on the outbound payload is the control. Consent capture itself belongs to product and legal.

Limiting Use, Disclosure and Retention: 4.5

This principle splits cleanly for AI traffic. The use and disclosure half is enforceable on the path, since which model endpoint receives which data class is a policy decision that can be made per request and recorded.

The retention half is a data-governance programme covering your own stores, and it reaches well past AI traffic. The OPC found no formal retention and disposal policies at deployment in the OpenAI matter, and no component on the request path fixes that. Worth adding: provider-side retention is a contractual control, since whether your prompts are retained by the model vendor and for how long is settled in the agreement rather than in your architecture.

Accuracy: 4.6

Principle 4.6 requires personal information to be as accurate, complete and up to date as necessary for the purposes it is used for. The OPC found no general assessment validating the accuracy of personal information in model outputs.

This is the hardest row in the mapping and nobody should claim it. A model that generates a plausible but false statement about a named person has produced inaccurate personal information inside your process, and no proxy on HTTP traffic evaluates truth. The controls that exist are human review before an output enters a record system, output-use restrictions by decision type, and the record that lets you reconstruct what was generated when a person disputes it. That last one is the only piece architecture supplies.

Safeguards: 4.7

Safeguards scale to sensitivity, and AI traffic defeats the controls most organisations already run. Network data-loss prevention operates underneath TLS to a provider API. Document classification reads a file, while a prompt assembles fragments from several systems into one payload.

The control is classification on the request itself, with per-role and per-route policy and a fail-closed default. Only 37% of organizations have any detection or governance policies in place for AI usage, according to Netwrix, which sets a realistic expectation for a first assessment.

The mapping

Three rows read Full and three read None. The rest are shared, and shared rows are where compliance programmes fail, because two functions each assume the other owns them.

Breach records under sections 10.1 to 10.3

Sitting outside Schedule 1, and worth including in any mapping used operationally, are the breach obligations in force since November 2018. Reporting to the Commissioner where there is 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 threshold, retained for 24 months. Knowingly failing to keep those records carries a fine of up to CAD $100,000.

Assessing real risk of significant harm turns on the sensitivity of the information and the probability of misuse, and both require knowing what was in the payload.

My candid view: the accuracy principle is the one that will produce Canada's first genuinely difficult AI privacy case, and almost every mapping I have seen skips it or fills it with a sentence about model evaluation. Principle 4.6 does not ask whether your model scores well on a benchmark. It asks whether the personal information you are using is accurate enough for the decision you are making with it, which is a question about your process rather than about the vendor's. The related jurisdictional mappings for Japan's APPI and Korea's AI Basic Act hit the same wall from different directions.

DeepInspect

This is the enforcement point behind the rows marked Full. 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. For every request and response it evaluates identity, data classification, model authorization, and organizational policy, and makes a pass or block decision before the traffic reaches the model.

Against this mapping it fills 4.4 with field-level policy on the outbound payload, 4.5's use-and-disclosure half with per-request destination authorization bound to the originating principal, and 4.7 with classification inside the context window and a fail-closed default. It supplies the disclosure history that 4.9 needs and the reconstructable record that 4.6 relies on when someone disputes an output. Accountability, retention, consent capture, and the complaints channel stay with your privacy function. Book a technical deep dive at deepinspect.ai.