If you're an SMB in Canada wiring AI into customer-facing work, three rules cover ~90% of your obligations: PIPEDA (or its provincial equivalent), your sector regulator (FINTRAC, the law society, the college of physicians, etc.), and your contractual commitments to customers and clients. AIDA — the federal AI Act — is still on a moving timeline; design as if it will pass, but don't let the proposed text be a substitute for shipping.
We get one version of this conversation about twice a week. An SMB owner — usually a brokerage, a small law firm, or an accounting practice — wants to use AI in their daily work, but a friend's LinkedIn post about "the new Canadian AI Act" or PIPEDA has put a nervous hand on the brake. The conversation usually ends with a list of rules that don't actually exist, a list of risks that aren't actually risks, and a missing list of the things that do matter.
This is the version we wish we could send to people on day one.
1. PIPEDA — the always-on baseline
The Personal Information Protection and Electronic Documents Act is the federal privacy law that applies to most commercial activity in Canada. It is forty years old in spirit and twenty years old in statute, and it predates "AI" as a legal concept by a long way — but it is still the rule that most often shapes what you can and can't do.
Three things PIPEDA actually requires when you're building or using AI:
- Meaningful consent for the collection, use, and disclosure of personal information. "We may use AI to process your data" is not enough. "We use Anthropic Claude, hosted in the Canadian region, to generate draft responses your representative reviews before sending" gets closer.
- Accountability for transfers across borders. If your AI pipeline sends personal data to a service outside Canada — including OpenAI's US-region endpoints, or any model running outside CA-Central — you remain accountable for that data under PIPEDA even when it's in their hands. You don't lose the obligation by outsourcing the inference.
- Limit collection and retention. Don't shove the entire client file into a prompt when only the relevant section is needed. Don't keep conversation transcripts longer than you'd keep an equivalent paper file. This is the rule most often quietly violated when someone wires the LLM in as a productivity tool.
None of this requires lawyers, certifications, or pause. It requires a one-page record of what data goes where, written by an engineer with five hours of clean thinking. We do that for every customer at the start of an engagement.
2. AIDA — the bill everyone misquotes
The Artificial Intelligence and Data Act (Bill C-27) is the proposed federal AI act. As of mid-2026 it is not yet in force; the public discourse around it is several quarters ahead of the statute book. There are two specific traps we see SMBs fall into here.
Trap one: Treating AIDA's proposed high-impact system definitions as the current law. The draft text proposes ex-ante obligations (impact assessments, transparency notices, human-oversight commitments) for "high-impact" AI systems. The definition of "high-impact" has shifted across drafts. Until the bill receives Royal Assent and ISED publishes the implementing regulations, you cannot reliably file a compliance form against a definition that isn't final.
Trap two: The opposite — assuming AIDA "won't apply to a small business." The draft has explicitly preserved the federal trade-and-commerce hook, which means small Canadian businesses operating across provincial lines, or selling internationally, will absolutely be in scope for whichever final form passes.
The pragmatic response is to design as if a reasonable version of AIDA will pass: maintain an impact-assessment record for any AI feature that touches a customer, log the system's outputs as you would log any other production system, and keep a written description of the human review step. None of that is wasted work even if AIDA never passes — it's the same hygiene any auditor will ask for.
3. Provincial regimes — when PIPEDA hands off
Three provinces have their own private-sector privacy laws that are deemed "substantially similar" to PIPEDA, which means they apply instead of PIPEDA for organizations operating within those provinces:
- Quebec — Law 25 (the artist formerly known as Bill 64). The strictest of the bunch. Imposes specific requirements on automated decision-making, mandatory privacy officers for organizations of basically any size, and 72-hour breach notifications. If you serve Quebec customers from anywhere in Canada, Law 25 attaches.
- British Columbia — PIPA BC. Generally lighter than Law 25 but stricter than PIPEDA on consent. Notable: BC has its own commissioner with subpoena power.
- Alberta — PIPA Alberta. Mostly aligned with PIPEDA but with provincial breach-notification thresholds.
If your customer base spans Canada, you end up de facto operating to whichever is strictest of these — usually Law 25. We design our products that way by default; it is cheaper than building a per-province feature flag for consent text.
4. FINTRAC + financial services
If your business is on the FINTRAC reporting list — money services businesses, real-estate brokerages, dealers in precious metals, accountants in some scopes — adding AI to your workflow doesn't change your existing record-keeping or suspicious-transaction reporting obligations. It does add two specific risks worth designing against.
The first is inadvertent disclosure in a model prompt. If you paste a client transaction list into a third-party LLM for analysis, you have potentially disclosed reportable information to a non-reporting entity in a non-Canadian jurisdiction. FINTRAC will not love this.
The second is shadowing the existing identity-verification process. We've seen brokerages experimenting with letting the AI "screen" applicants — read the ID, summarize the file, draft the first compliance note. That's fine until the AI starts being the decision-maker rather than the drafter. PCMLTFA was never written to contemplate that; structure the workflow so a human compliance officer remains the determining party of record.
5. PHIPA + health-adjacent data
If you operate in or near Ontario healthcare — pharmacies, allied-health practices, mental-health platforms, anything that processes Personal Health Information — you are subject to Ontario's Personal Health Information Protection Act. PHIPA is stricter than PIPEDA in two important ways for AI builders:
- The definition of an "agent" who can process PHI on behalf of a Health Information Custodian is narrow and requires a written agreement that nearly all general-purpose AI vendors' standard terms cannot satisfy out of the box.
- Lock-box rights exist for individuals to specifically restrict the use of their PHI. Any AI feature that processes PHI must respect those locks, which usually means per-record metadata your pipeline reads before deciding whether to include a given record in a model prompt.
The practical implication: PHI work almost always requires a private deployment of whatever AI tooling you use, signed under a custom agreement, with the inference happening inside your tenant. That is exactly the deployment model we ship Jurisnova and several custom builds in, for exactly this reason.
6. Law society and professional rules
If you are a regulated professional — lawyer, accountant, financial advisor — your professional body's rules layer on top of the statutes above. Three Law Society of Ontario practice rules matter for AI in 2026:
- Confidentiality (rule 3.3-1) — solicitor-client privilege does not evaporate because you pasted the matter notes into a chatbot. The LSO's published guidance is increasingly clear that "free-tier" AI use can constitute a confidentiality breach.
- Competence (rule 3.1) — you are responsible for the quality of work you sign off, regardless of whether the first draft came from a model. You cannot blame the AI for a brief.
- Supervision (rule 6.1) — AI tools, in the LSO's framing, are treated like a non-licensee assistant: a lawyer remains responsible for the supervisory check on their output.
The equivalents for CPA, RECO, and CMHC-regulated practices are different in detail but similar in spirit. The throughline is the same: "AI did it" is never a defence; the professional remains responsible.
7. The data-flow questions you'll be asked
Whichever rule above applies most to you, the actual compliance conversation almost always comes down to the same five questions. If you can answer these crisply in writing, you are ahead of 95% of your peers.
- What personal information enters the AI system? Not "customer data" — the specific fields, in a list.
- Where does the inference happen? Country, region, vendor. Whether the connection is private (VNet peering, AWS PrivateLink) or public internet.
- How long are prompts and completions retained? By the vendor; by you. With concrete numbers.
- Who has access to the prompts and completions? Your staff; the vendor's staff; the vendor's sub-processors. The list rarely fits on one line.
- What is the human review step? Who reviews; before or after the customer sees the output; whether the reviewer can override the AI; whether their override is logged.
We write this five-point map for every customer at the start of an engagement. It usually takes 90 minutes and ends the compliance conversation cleanly.
8. A working compliance checklist
Concretely, here is the checklist we run against every system we ship for a Canadian SMB:
- Written one-page data-flow map — five questions above, answered explicitly.
- Inference in a Canadian-region endpoint by default; cross-border only with written justification and customer notice.
- Zero-retention mode enabled on the model provider, where the provider supports it, and the support documented in our own records.
- Vendor agreements that contain explicit "no training on customer data" language — not just a marketing statement on the website.
- Application-level audit log for every AI call: input hash, prompt template version, model version, output hash, reviewing user, timestamp. We never log full prompt content unless the customer specifically requires it.
- Human review step in the UI for any output that reaches a customer, with the reviewer's action logged.
- A lock-box / consent withdrawal path for individuals to opt out of AI processing of their data without losing service.
- A data export and erasure path that includes all AI-derived data, not just primary records.
- An incident-response plan that explicitly contemplates AI-specific incidents (prompt injection, output disclosure, hallucinated false claim about a customer).
- A maintenance commitment in writing — who updates the model when it gets deprecated, who re-runs the impact assessment when the regulation changes.
Most of these don't require additional spend; they require an engineer to spend half a day designing them in at the start, rather than retrofitting them later.
9. What this is and isn't
This is the operator's view from an engineering team that has shipped AI in Canadian small businesses. It is not legal advice. The summaries of PIPEDA, AIDA, FINTRAC, PHIPA, and the LSO rules above are intentionally simplified for engineering use; they are not the source of record. For any decision with material consequences, take this article to your privacy counsel and have them confirm against the statute as it stands when you're reading.
We're happy to be the second set of eyes on a draft data-flow map — [email protected] if that would help.