There is no Canadian form called an AI compliance file. What exists is PIPEDA’s ordinary accountability principle, which already expects an organisation to know who is responsible, why it collects what it collects, and what happens to information once it leaves the building — and an AI tool does not exempt any of that. This guide turns those existing obligations into a specific list.
Key takeaways
STEP 01 OF 10
Before treating AI documentation as a new requirement, recognise that PIPEDA’s Schedule 1 already obliges an organisation to designate someone accountable for personal information practices, and to make that person’s identity known on request — clauses 4.1.1 and 4.1.2, at the Act’s full text. Clause 4.1.4 goes further: organisations “shall implement policies and practices to give effect to the principles,” including staff training and public-facing explanatory information.
None of this mentions AI. It does not need to: an AI tool that touches personal information is simply one more thing the existing accountable individual is responsible for, and one more practice the existing policy needs to cover.
STEP 02 OF 10
A short, plain inventory entry per tool: what it is called, what it is used for, and what data it sees — customer records, employee information, financial data, or none of the above. Canada has no national AI registry; a search for one confirms there is nothing to check against, which makes an internal record more important, not less — see is there an AI registry in Canada?.
This inventory is the foundation everything else in this guide builds on. Without it, none of the following steps has a concrete subject to attach to.
STEP 03 OF 10
PIPEDA’s Schedule 1, Principle 2 requires that purposes “shall be identified by the organization at or before the time the information is collected” (clause 4.2), and s.5(3) sets the test as purposes “that a reasonable person would consider are appropriate in the circumstances.” For each AI tool in your inventory, write the specific purpose it serves — not “efficiency” in general, but the actual task the data feeds.
A purpose written down before the fact is also what the OPC’s own generative-AI principles ask for under “Appropriate purposes” — and it is the sentence you will need if anyone ever asks why this particular tool has access to this particular data.
STEP 04 OF 10
Where an AI tool is a vendor’s product rather than something built in-house, PIPEDA Schedule 1, clause 4.1.3 is the operative rule: “An organization is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing. The organization shall use contractual or other means to provide a comparable level of protection while the information is being processed by a third party.”
Write down what that contract actually requires of the vendor — not just that one exists. Accountability does not transfer with the data; if the vendor mishandles it, the obligation to have protected it was still yours.
STEP 05 OF 10
A vendor’s AI model running on servers outside Canada is common and, on its own, not prohibited. The OPC’s cross-border guidance is direct: “PIPEDA does not prohibit organizations in Canada from transferring personal information to an organization in another jurisdiction for processing.” It goes further: “A transfer for processing is a ‘use’ of the information; it is not a disclosure” — meaning no additional consent is required for the transfer itself, provided the original purpose still holds. See Guidelines for processing personal data across borders.
The same guidance states “the transferring organization is accountable for the information in the hands of the organization to which it has been transferred,” and that this is accomplished “through contract.” Document where the vendor actually processes data, and note plainly that “no contract can override the criminal, national security or any other laws of the country to which the information has been transferred” — a risk worth writing down, not assuming away.
STEP 06 OF 10
Ottawa’s Directive on Automated Decision-Making requires departments to complete an algorithmic impact assessment “prior to the production of any automated decision system” (s.6.1.1), covering what the system does and its potential impact, and to review it “on a scheduled basis, including when the functionality or scope of the automated decision system changes” (s.6.1.3) — see the Directive.
A private business does not need the government’s form, but the shape is worth copying: for any AI tool that affects a customer’s status, price, or eligibility, write down what it does, what could go wrong, and when you last checked it. See how to decide what a human must approve for the companion decision about who signs off.
STEP 07 OF 10
Signatories to ISED’s Voluntary Code of Conduct commit to specific, checkable measures depending on their role. Two worth documenting even if you are not a signatory: “Maintain a database of reported incidents after deployment,” and, for public-facing systems, “Monitor the operation of the system for harmful uses or impacts after it is made available, including through the use of third-party feedback channels” — both from the Voluntary Code.
An incident log costs little to keep and is exactly the kind of record that turns “we take this seriously” into something you can actually show someone.
STEP 08 OF 10
PIPEDA’s designated-individual requirement is often satisfied on paper by naming a privacy officer for the business as a whole. See privacy officer requirements for Ontario business for that general obligation — it addresses the underlying PIPEDA accountability duty, not AI specifically, and treat it accordingly.
Whether that same person also owns AI-specific questions, or a different person does, write the answer down. A role that exists on an organisation chart but is never actually asked an AI question is not meaningfully accountable for anything.
STEP 09 OF 10
A one-page policy saying “we use AI responsibly” demonstrates nothing on its own. A dated log — which tools were reviewed, on what date, by whom, and what was found — is what actually shows a pattern of attention over time. This is the same discipline as tracking regulatory guidance, covered in how to track Canadian AI guidance, applied to your own tools instead of the outside rules.
Keep the log somewhere it will actually be updated — attached to the inventory from Step 2 is usually simplest, so the record of what a tool is and the record of what was checked about it live in one place.
This obligation is not limited to incidents serious enough to require notifying anyone. PIPEDA requires an organization to “keep and maintain a record of every breach of security safeguards involving personal information under its control” and provide that record to the Commissioner on request; the accompanying regulations set the floor at “24 months after the day on which the organization determines that the breach has occurred.” PIPEDA, s.10.3 Breach of Security Safeguards Regulations, s.6(1) An AI-vendor incident that never crosses the notification threshold in Step 5 still belongs in this log — it is a separate, lower-bar duty. See Treadstone Law’s case study on a breach notification response for what that record actually needs to cover in practice.
STEP 10 OF 10
Every document in this list goes stale the moment the tool changes, a new vendor is added, or the purpose shifts. Put an actual date on when each entry gets re-checked, mirroring the federal Directive’s own instinct to review “when the functionality or scope… changes,” not on a fixed schedule disconnected from what has actually changed.
A documentation set with no review date attached tends to be accurate on the day it was written and increasingly fictional after that — which is worse than having no record, because it looks current when it is not.
Writing a general AI policy with no tool-specific detail. A statement that the business “uses AI responsibly” documents nothing checkable. Attach every commitment to a specific tool, purpose, and date, as in Steps 2 and 9.
Assuming a vendor contract alone satisfies clause 4.1.3. The clause requires a comparable level of protection, not merely a signed agreement. Document what the contract actually requires the vendor to do, per Step 4.
Treating cross-border processing as automatically requiring fresh consent. The OPC’s own guidance in Step 5 says a transfer for processing is a use, not a disclosure, and does not on its own require new consent — the accountability and contractual protection requirements still apply regardless.
Naming an accountable person who is never actually asked an AI question. A designated individual who exists only on paper does not satisfy the spirit of PIPEDA’s accountability principle, whatever the org chart says.
None of this is a form prescribed anywhere in Canadian law. It is the practical shape that satisfies PIPEDA’s existing accountability principle for a tool that happens to be AI — built from obligations that already exist, not a new compliance category invented for this guide.
No form or template is mandated by name. What is required, for any business subject to PIPEDA, is the underlying accountability, purpose-identification, and vendor-oversight documentation this guide describes — AI does not create a new legal category, it is covered by the existing one.
PIPEDA’s specific requirements attach to personal information, so a tool that never sees customer or employee data sits outside them. It is still reasonable practice to keep a short inventory entry for any tool with meaningful business impact, independent of the privacy-law trigger.
Tie the review to actual change — a new vendor, a new use of the tool, an expansion of what it can access — rather than a fixed calendar date, mirroring the federal Directive’s own approach in Step 10.
A well-documented tool still needs monitoring once it is actually running.
