AI and PIPEDA: A Privacy Guide for Canadian Businesses
Canadian businesses using AI remain responsible for the personal information they handle. Before connecting a model to customer records, define the purpose, confirm the applicable law and authority, check the provider, and decide what people must review. This guide turns those decisions into a workflow checklist.
— Craig Major
Start with the information, the purpose and the owner
An AI workflow can copy information into prompts, retrieved documents, run histories, support logs and backups. Map those destinations before choosing a tool. An approved application can still be used for an inappropriate task.
This is an operational planning guide, checked on 21 October 2026. It does not determine your legal obligations or certify a system. Ask your privacy lead or legal adviser to resolve the law, authority and notice requirements for your use case.
Which privacy law applies?
PIPEDA is Canada's federal private-sector privacy law for personal information handled in commercial activities. Alberta, British Columbia and Quebec have substantially similar private-sector laws. Health information, public-sector work and federally regulated businesses can have different requirements. Commercial personal information crossing provincial or national borders can bring PIPEDA into scope even where a provincial law also applies.
Identify the organization, activity, people and locations involved before approving an AI use. A customer-service workflow and an employee assessment may require different analysis. See the Privacy Commissioner's explanation of PIPEDA's scope.
Use Canadian AI guidance to set the boundary
Canada's privacy regulators say existing privacy laws apply to organizations developing, providing or using generative AI. Their generative AI principles call for lawful authority, appropriate purposes, accountability and safeguards. Publicly accessible personal information still needs a lawful basis for its collection and use.
For a first pilot, use synthetic examples that contain no real customer information. If the task needs live records, document why each field is necessary. Removing a name does not establish anonymity when the remaining details can identify the person.
Make consent understandable
The OPC's meaningful consent guidelines emphasize what information is collected, who receives it, why it is used and meaningful risks or consequences. Where consent is required, explain these points where the person makes the choice. A long policy linked from the footer is not a substitute for understandable information.
Have the privacy owner assess whether the existing purpose and consent cover the proposed use. Preparing a reply from an existing service request differs from reusing years of requests to train a model. Record the decision and any new notice or consent needed before changing the purpose.
Check the provider and the complete data path
Under the OPC's cross-border processing guidance, an organization remains accountable when a processor handles personal information. PIPEDA does not impose a blanket ban on foreign processing. Contracts and other measures must provide a comparable level of protection, and people need transparency about foreign processing and possible access by foreign authorities. Other laws or contracts may impose additional restrictions.
Canadian hosting alone does not establish compliance. Check the actual product, plan, region, subprocessors and support arrangements. Record the evidence and review date; a vendor's marketing badge is insufficient.
| Ask the provider | Evidence to retain |
|---|---|
| Are prompts, files and outputs used to train models? | Applicable terms and the configured training setting |
| Where are content, backups and operational logs processed? | Region documentation and subprocessor list |
| Who can access the information, including support staff? | Access controls, support process and contractual commitments |
| How do deletion and retention work for this plan? | Retention terms, exceptions and a tested deletion path |
| How will incidents and termination be handled? | Notification obligations, contact and export/deletion procedure |
These are procurement checks, not a claim that any particular vendor meets your obligations.
Set retention for the copies the workflow creates
The OPC's limiting use, disclosure and retention guidance says to retain personal information only as long as needed for its identified purposes, subject to applicable requirements. Document retention and disposal procedures.
Set a schedule for inputs, outputs, execution logs, search indexes and backups. Give each store an owner. Test how a correction or deletion reaches downstream copies, and document any lawful retention exception. Avoid collecting full prompts in analytics when a run identifier and outcome will answer the operational question.
A worked example: preparing a customer reply
Consider a service team that wants AI to draft a response from a new enquiry. This is an illustrative design, not a client result or a legal approval.
- The intake owner approves the purpose and the information needed to answer the request.
- The workflow sends only the relevant question and approved reference material to the selected service. It excludes unrelated CRM notes.
- The draft records its source request and flags missing information. It cannot promise a refund, alter an account or send a reply.
- A staff member checks identity, facts and commitments before sending through the normal service system.
- The operator checks errors and deletion behaviour using the agreed retention schedule.
Measure incorrect drafts and review effort alongside time saved. Human review needs sufficient context and authority to stop the action. It does not by itself make an inappropriate use lawful.
Prepare for an incident before launch
PIPEDA requires reporting to the OPC and notification to affected individuals for breaches of security safeguards that create a real risk of significant harm. Organizations must also keep records of all breaches of security safeguards involving personal information under their control, including those below that threshold. The record-keeping period is at least 24 months after determining that a breach occurred. See the OPC's breach reporting and record-keeping guidance.
Name who can stop the workflow, preserve relevant evidence and contact the privacy owner. Test that route with a harmless scenario. Do not wait for an exposed prompt or a message sent to the wrong person to discover who has access to the logs.
A launch checklist for the workflow owner
- Record the purpose, applicable law and the privacy owner's approval of the authority, notice and consent approach.
- Map the fields, systems, providers and people involved, including logs and backups.
- Retain current vendor terms and the settings used for the pilot.
- Restrict access and test with synthetic data before introducing approved live records.
- Define review points, corrections, retention and deletion across the full data path.
- Test the failure and incident route. Name who approves launch and who can pause the workflow.
Keep this evidence with the workflow map and runbook. Review it when a provider, model, purpose or data source changes.
Put the controls into the working system
AI Automation Systems covers a scoped build with tests, documentation and human decision points. Fractional CAO provides ongoing roadmap and governance ownership; implementation is scoped separately. Privacy and legal approval remain with the responsible organization and its advisers.
Book a fit call to discuss one workflow and the information it needs. Bring a description of the process; use synthetic examples rather than sending personal customer records.