Where your data actually goes when you use AI
This is the post people should read first and usually read last, generally after someone discovers what has been pasted into a free account. It is not complicated. It is just nobody's job.
We are not lawyers and this is not legal advice. It is the practical version, from doing this work with Ontario organizations that have real obligations and no compliance department.
Three doors, three different answers
The single most useful thing to understand is that "using AI" describes at least three arrangements with materially different properties.
The free consumer account
Someone signs up with an email address and starts pasting. The terms are consumer terms; historically, free tiers across the industry have been the most likely to use submitted content to improve the product, and settings vary and change. There is no contract between the vendor and your organization, no administrative visibility, no way to retrieve or delete what was submitted, and no record of what went in. If your staff are doing this with client data — and in most organizations we look at, some are — you have an unmanaged disclosure of personal information that you cannot describe, which is the part that matters under PIPEDA.
The paid business plan
A managed subscription with an administrator. Business and enterprise tiers generally carry a commitment not to train on your content, plus administrative controls, retention settings, and an actual contract. This is the right default for staff using AI as a tool at their desk. The important part is that it is your tenancy, so you can set policy, see who has access, and revoke it.
The API
Software you or someone like us builds, calling the model programmatically. Commercial API terms exclude training on submitted data, and you control precisely what is sent, when, and with what retained. This is the right choice when AI is part of a system rather than a person's tool, and it is the only option that gives you engineering-grade control — you can strip identifiers before sending, log every request, and prove what happened.
Most organizations end up wanting the business plan for people and the API for systems. Almost nobody should be relying on the first door for anything that matters.
What PIPEDA actually asks of you
Canada's federal privacy law applies to commercial activity, and provincial rules layer on top for health and some public-sector work. The obligations that bite in an AI context are unglamorous:
- Accountability. A named person is responsible for personal information in your organization. If nobody can tell you who that is, start there — it costs nothing and it's the foundation for everything else.
- Knowing where it goes. You are expected to be able to describe what personal information you hold, why, and who processes it. "Staff sometimes use an AI tool" is not a description. A written list of which tools are approved for which categories of data is.
- Consent and identified purpose. You collected client information for a purpose. Feeding it to a new processor to do something new can exceed that purpose. Usually the fix is straightforward — often you don't need identifiable data for the task at all.
- Safeguards proportionate to sensitivity. Health and financial records demand more care than a marketing list. This is where the local-versus-cloud question from last month's post earns its keep.
- Transparency on request. Someone can ask what you hold about them. That answer has to include the AI processing.
Note what isn't on that list: any requirement to avoid AI. PIPEDA is not an obstacle to using these tools. It's a requirement to be able to explain what you're doing, which is a low bar that most organizations fail only because nobody wrote anything down.
Cross-border, honestly
PIPEDA does not prohibit sending personal information outside Canada. It requires comparable protection and transparency about it. Some funder agreements and provincial public-sector rules are stricter, and those are the ones to actually read — the constraint usually comes from a contract you signed, not from federal privacy law.
Where residency does matter, the practical routes are Canadian-region hosting where the platform offers it, or local inference for the sensitive portion. Both are achievable. Both need deciding before you build, not after.
The five questions to ask any AI vendor
Ask these in writing. A vendor who can't answer them crisply is telling you something.
- Do you train on our data? Under which plan, and where is that in writing?
- How long do you retain our inputs and outputs, and can we change it?
- Which regions is our data processed and stored in?
- Who are your sub-processors? The answer is never nobody, and their obligations should flow down.
- What happens on termination? What's deleted, when, and how do we verify it?
The half-day version
If you do nothing else: write down which AI tools are approved, for which categories of data, and who to ask when something isn't on the list. Tell staff. Get everyone off personal accounts and onto a managed plan. That's a half day of work and it moves you from an undescribable situation to a defensible one — which is the entire distinction that matters if anyone ever asks.
Want that written down properly?
A short engagement: what you hold, which tools touch it, what your agreements actually require, and a one-page policy your staff will read. Usually a couple of weeks, and you own the document whether or not we build anything afterward.
Request helpNext month: how to choose your first AI project — the four tests a candidate has to pass, and the shapes of work that reliably disappoint.