Data residency for Canadian public sector AI: what is actually required

Canadian public sector organisations face a question that most AI vendor material does not answer: where can this data go? The answer depends on the province, the type of data, and the specific legislation governing the institution — and getting it wrong is not a configuration issue but a compliance breach.

What the requirements actually say

Provincial legislation such as FIPPA in British Columbia and Ontario, and health-specific statutes including PHIPA, establish obligations around where personal information may be stored and accessed. The precise obligations vary and have changed in recent years, so the first step in any engagement is confirming the current position with the organisation's privacy office rather than relying on general summaries.

What is consistent is that organisations must be able to document where data flows, who can access it, and what controls apply — and that this documentation has to exist before deployment, in the form of a privacy impact assessment.

Deployment patterns that work

• In-region cloud services. The major cloud providers operate Canadian regions, and most managed AI services can be deployed within them. The subtlety is in the supporting services — logging, monitoring, model endpoints — which must also stay in-region.
• Models inside your tenancy. Open-weight models deployed within the organisation's own cloud tenancy or on-premises infrastructure give the strongest residency position, at the cost of operating the model layer yourself.
• Hybrid retrieval. Keeping the corpus and retrieval in-region while using hosted models for generation is common, but requires care about what leaves in the prompt.

Documenting it

A data flow diagram, a list of every service touching the data with its region, the retention and deletion design, and the sub-processor inventory. Produce these as engineering artefacts during design, and the privacy impact assessment becomes a review rather than a reconstruction.