"Where does our data go?" is the question that stalls more AI projects than budget does. It usually gets a vague answer, because the honest answer has three hops and most vendors only document one.
The three hops
When your document goes into a hosted AI automation platform, it travels further than most buyers realise:
- Your application → the platform's servers. This is the hop vendors document. It's usually in their marketing.
- The platform → the model provider. The platform doesn't own the model. It calls a third party — and that provider has its own regions, its own retention policy, and its own terms about training.
- The platform → its own sub-processors. Logging, monitoring, error tracking, analytics. Each one may see payloads. Each one is somewhere.
A vendor can truthfully say "we're SOC 2 Type II certified" and "we don't train on your data" while your invoice text still transits three companies and two countries. Both statements are about hop one.
What the certification does and doesn't tell you
SOC 2 Type II is a real, valuable attestation — it says an auditor tested the vendor's controls over a period of time. It is not a statement about geography. Neither is ISO 27001. Neither is GDPR compliance, which is about lawful processing, not about a maple leaf on a data centre.
A useful test: search a vendor's security page for the words Canada, PIPEDA, PHIPA, and data residency. If all four return nothing, they have not thought about your problem. That's not an accusation — most platforms are built for a US or EU buyer. It just means the answer isn't there.
What actually applies — Canada and the U.S.
PIPEDA, the federal private-sector privacy law, does not prohibit cross-border transfer. What it requires is that you use contractual means to provide a comparable level of protection, that you are transparent about it, and that safeguards are proportionate to sensitivity. Cross-border is allowed; unexamined cross-border is the problem.
PHIPA is where it tightens. If your organisation is a health information custodian in Ontario — a clinic, a dental group, a pharmacy, a lab — then anyone processing personal health information on your behalf is your agent and/or an electronic service provider, with specific obligations attached. This is the category where "we're not sure where it's processed" ends the conversation.
Quebec's Law 25 reaches you if you have Quebec employees or customers, and it is stricter: it requires assessment of cross-border transfers, and imposes disclosure where a decision is based exclusively on automated processing. Its administrative penalties run up to the greater of CAD $10 million or 2% of worldwide turnover.
And to be accurate about the one everybody asks about: there is currently no in-force federal AI statute in Canada. The AI portion of Bill C-27 (AIDA) did not become law. Any vendor selling you "AIDA compliance" is selling something that does not exist. What does exist is ordinary privacy law, sectoral regulation, and your own procurement standards.
The four options, honestly compared
| Option | Data location | Trade-off |
|---|---|---|
| US SaaS platform | Vendor's regions, plus their model provider's | Fastest to start, hardest to answer procurement with |
| Canadian cloud region | ca-central-1 or Canada Central | Strong answer; model provider region still needs naming |
| Your own cloud tenancy | Your account, your keys, your logs | You hold the trust boundary; slightly more setup |
| Your own hardware | Your building | Total control; you buy and run the hardware |
We should be straight about the last one: on-premise is usually not the cheapest answer, and often not the right one. A commercial API in a Canadian region generally wins on cost until you are processing very high volumes — a single capable GPU can cost more than CAD $22,000 before you have hired anyone to run it. On-premise is a control decision, not an economics decision. When someone asks us for it, the first thing we do is check whether they actually need it.
What to ask any vendor
- Name every region where our data is processed and stored — including your model provider's.
- List your sub-processors, and tell us when that list changes.
- Is there a contractual prohibition on using our data to train models? Show us the clause.
- What is your retention period, and what does deletion actually delete?
- Can this run entirely in a Canadian region, or in our own tenancy? If not, say so plainly.
Any vendor should be able to answer those in writing before you sign. Ours are on our trust page, including the parts where the answer is "not yet."