"Where does our customer data live?" is the wrong first question. For AI customer support in Canada, the questions that actually decide compliance are where data is processed, who the sub-processors are, and whether the language model layer trains on your conversations.
Canadian data residency for AI customer support is the set of controls that govern where customer data is stored, where it is processed, and which third parties touch it when an AI agent resolves a ticket. Two laws set the bar in 2026: the federal Personal Information Protection and Electronic Documents Act (PIPEDA) and Quebec's Law 25. Neither one mandates that data physically stay inside Canada, but both impose obligations on accountability, transparency, and cross-border transfer that are easy to fail when an AI vendor routes conversations through a US-hosted large language model.
PIPEDA does not require Canadian-only storage. It requires comparable protection wherever data goes and disclosure that transfers happen, per the Office of the Privacy Commissioner of Canada (OPC).
Quebec's Law 25, fully in force since September 2023, adds a privacy impact assessment requirement before any transfer of personal information outside Quebec.
Storage residency and processing residency are different controls. An AI vendor can store data in Canada and still process it on US infrastructure during inference.
The language model is a sub-processor. If the LLM provider trains on your conversation data, that is a downstream transfer most data maps miss.
The verifiable artifacts are a sub-processor list, a data flow diagram, contractual no-train terms, and a region commitment in writing.
Last updated: June 2026
This guide is written for privacy, security, and CX leaders at Canadian companies, or companies serving Canadian customers, who are evaluating an AI customer support platform. It is not legal advice. It is a practical map of what the law actually says, where AI changes the calculus, and the specific things to verify with a vendor before you sign. The recurring theme: data residency is a marketing word, and the obligations that matter sit underneath it.
What Canadian data residency means (and does not mean)
Data residency is the requirement or commitment that data be stored in a specific geography. Data sovereignty is the broader idea that data is subject to the laws of the country where it is located. Neither PIPEDA nor Law 25 imposes a blanket data-localization mandate on private-sector companies. This surprises buyers who assume "Canadian compliance" means "data never leaves Canada." It does not.
What the laws require instead is accountability for the data wherever it travels. Under PIPEDA, an organization that transfers personal information to a third party for processing remains responsible for that information and must use contractual or other means to ensure a comparable level of protection. The OPC has been consistent on this point: a transfer for processing is a use of the data, not a disclosure, and the transferring organization stays accountable. The practical consequence is that moving data to a US cloud region is permitted, but you own the obligation to verify the protections around it.
Data residency: a commitment that data is stored within a defined geographic boundary, often a country or region. It addresses storage, not necessarily processing.
Cross-border transfer: any movement of personal information across a national boundary, including transient processing during a single AI inference call.
PIPEDA: the federal baseline
PIPEDA governs how private-sector organizations collect, use, and disclose personal information in the course of commercial activity across Canada (with British Columbia, Alberta, and Quebec operating substantially similar provincial laws for intra-provincial activity). For an AI customer support deployment, four PIPEDA obligations bear directly on residency and AI.
Accountability for transferred data
If your AI vendor stores or processes Canadian customer data outside Canada, you remain accountable for it. You need a written agreement that binds the vendor (and the vendor's own sub-processors) to a comparable standard of protection. "Comparable" is the OPC's word, and it is the standard you have to be able to defend.
Transparency and openness
PIPEDA's openness principle requires that you be transparent with individuals about your handling of their information, including the fact that it may be processed in another country and could be accessible to that country's legal regime (for example, under US lawful-access mechanisms). For most companies this lives in a privacy policy update, but it has to be accurate to how the AI platform actually routes data.
Limiting use and purpose
Personal information collected to resolve a support ticket can be used for that purpose. Using the same conversation data to train a third party's general-purpose model is a different purpose, and one most customers did not consent to. This is exactly where the LLM layer becomes a compliance question rather than a technical detail.
Safeguards
PIPEDA requires safeguards appropriate to the sensitivity of the information. For regulated data (financial, health), that means encryption in transit and at rest, access controls, redaction of personal information where feasible, and a clear retention and deletion policy that the AI vendor can actually honor.
Quebec Law 25: the higher bar
Quebec's Law 25 (formerly Bill 64) is the most consequential privacy reform in Canada, with its main provisions in force since September 22, 2023. If you serve customers in Quebec, it raises the bar above PIPEDA in ways that matter for AI.
Privacy impact assessment before transfer
Law 25 requires a privacy impact assessment (PIA) before communicating personal information outside Quebec. The assessment must weigh the sensitivity of the information, the purpose, the protection measures (including contractual ones), and the legal framework of the destination jurisdiction. In practice, deploying a US-hosted AI agent for Quebec customers triggers this assessment. You cannot retrofit it after launch.
PIA for any system handling personal information
Law 25 also requires a PIA when acquiring, developing, or overhauling an information system that handles personal information. An AI customer support platform is squarely that kind of system. Build the assessment into procurement, not as an afterthought.
Transparency on automated decisions
Where personal information is used to render a decision based exclusively on automated processing, Law 25 gives the individual the right to be informed and to have the decision reviewed. An AI agent that approves or denies a request without a human in the loop can fall within this. Knowing where your AI makes a final automated decision versus where it escalates to a human is part of the compliance picture, beyond a product preference.
Penalties that change the math
Law 25 introduced administrative monetary penalties of up to CAD 10 million or 2% of worldwide turnover, and penal fines up to CAD 25 million or 4% of worldwide turnover, whichever is greater. Those numbers are why Quebec exposure deserves its own line in an AI vendor evaluation rather than being folded into a generic PIPEDA checkbox.
Storage vs processing vs sub-processors: the three layers that actually matter
"Is your data in Canada?" collapses three distinct controls into one question. An honest AI residency review separates them.
Storage residency
Storage residency is where data sits at rest: the database, the object store, the backups, the logs. This is the layer vendors mean when they advertise "data residency in Canada" or "Canadian region." It is necessary but not sufficient. A platform can store everything in a Canadian region and still send data abroad the moment it processes a ticket.
Processing residency
Processing residency is where computation happens. For an AI agent, the heaviest processing is inference: the moment a customer message plus context is sent to a large language model to generate a response. If the model runs in a US region, the personal information in that prompt crosses the border for processing even if the canonical record never leaves Canada. This is the layer most data maps under-describe, and the one regulators care about because transient processing is still a transfer.
Sub-processors (including the LLM layer)
A sub-processor is any third party the vendor uses to deliver the service: cloud infrastructure, the LLM provider, a voice transcription engine, an analytics tool. Each is a place your customer data can flow. The large language model provider is the sub-processor buyers most often overlook, because it does not feel like a vendor. It is. The two questions that matter for the LLM layer are which provider runs the model, and whether that provider is contractually barred from training on your data.
The training question is the one that turns a residency review into a real risk assessment. Public consumer endpoints of major model providers have historically reserved the right to use submitted data to improve models unless you opt out or hold an enterprise agreement. A no-train contractual commitment, in writing, is the control that closes this gap.
Cross-border transfer: what triggers it and how to handle it
A cross-border transfer happens any time personal information moves outside Canada, including a sub-second inference call to a model hosted in another region. Under PIPEDA it is permitted with accountability and disclosure. Under Law 25 it requires a documented PIA first. Handling it well comes down to a short list of artifacts.
A written region commitment from the vendor stating where storage and processing occur, by component.
A data processing agreement that flows comparable-protection obligations down to every sub-processor.
A current sub-processor list, ideally with notice-of-change terms.
A completed PIA for Quebec exposure, dated before go-live.
A privacy policy that accurately discloses the transfers to your customers.
What to ask an AI support vendor
Residency claims on a website are marketing. The questions below are designed to surface what the architecture actually does. Bring them to a security review.
Where is customer data stored at rest, and can you commit to a Canadian region in the contract? If not Canada, where, and under what protections?
Where does inference happen? When my customer's message is sent to the language model, which region processes it?
Who is your full sub-processor list, including the LLM provider, voice and transcription vendors, and analytics?
Do you have a contractual no-train agreement with your model providers, and will you put it in our DPA?
Can you isolate our instance so our data is not commingled with other customers' data in storage or in prompts?
What personal information is redacted before it reaches the model, and what is retained in logs and for how long?
Can you support a Law 25 privacy impact assessment with a data flow diagram and the documentation it needs?
Where does the AI make a fully automated decision versus escalate to a human, given Law 25's automated-decision rights?
How Lorikeet supports Canadian data residency obligations
Lorikeet is an AI customer support platform built for complex and regulated companies, with roughly 80% of its customers being financial institutions and fintechs that pass bank-grade security reviews. Lorikeet does not eliminate your obligations under PIPEDA or Law 25 (no vendor can), but it is built to support them and to give your privacy team the artifacts they need.
Instance isolation
Lorikeet runs customer deployments with instance isolation, so one company's data and configuration are not commingled with another's. For a residency review, isolation matters because it makes the data flow legible: your data is your data, and the path it takes is one you can document in a PIA.
Contractual no-train terms with model providers
Lorikeet dynamically routes tasks across Anthropic, OpenAI, and Gemini, and holds contractual no-train agreements with these providers, meaning conversation data is not used to train their general-purpose models. This is the control that closes the LLM-layer gap described above, and it is the answer to the single most important question in an AI residency review. It is a contractual commitment, so verify the current terms in your own DPA rather than taking it on faith.
Data residency options and security posture
Lorikeet offers data residency in the US, Australia, and the UK, and is SOC 2 compliant, GDPR-aligned, and BAA-ready for HIPAA, with PII redaction and role-based access control. An honest note for Canadian buyers: Lorikeet's published residency regions are US, AU, and UK rather than a dedicated Canadian region as of mid-2026. Under PIPEDA that is workable, because the law turns on comparable protection and disclosure rather than Canadian-only storage, but it does mean a Quebec deployment will require a PIA covering the chosen region, and you should confirm current region availability and contractual commitments directly with Lorikeet.
Defence in depth and audit trails
Lorikeet layers pre-launch adversarial simulations, inbound message checks, outbound guardrails, and 100% post-facto QA through its Coach agent, with audit trails of agent actions. For a privacy team, the value is evidence: you can show a regulator not only where data went but how the system behaved, including where it redacted information and where it escalated to a human instead of deciding automatically.
Residency is a layered control, not a single checkbox. Talk to Lorikeet about your data flow and bring your privacy team.
Lorikeet's take
Most AI vendors will answer a residency question with a region badge and move on. For a Canadian buyer that badge is the start of the diligence, not the end of it. The obligations that decide compliance under PIPEDA and Law 25 live one layer down: where inference runs, who the sub-processors are, and whether your conversations train someone else's model. The right test is whether a vendor can hand your privacy team a data flow diagram, a sub-processor list, and a no-train commitment in writing, and whether the architecture matches what those documents say. If a vendor cannot produce all three, the residency claim is a marketing line, not a control.
Key takeaways
Neither PIPEDA nor Quebec's Law 25 requires Canadian-only data storage. Both require accountability, transparency, and (for Law 25) a privacy impact assessment before cross-border transfer.
Storage residency, processing residency, and sub-processors are three separate controls. Verify each one; a Canadian storage region does not mean Canadian processing.
The language model is a sub-processor. The decisive question is whether the provider is contractually barred from training on your conversation data.
Quebec's Law 25 carries penalties up to CAD 25 million or 4% of worldwide turnover, which is why Quebec exposure deserves its own evaluation line.
Lorikeet supports these obligations through instance isolation, contractual no-train terms with Anthropic, OpenAI, and Gemini, SOC 2 and PII redaction, and audit trails. Its published residency regions are US, AU, and UK, so confirm region and contract terms directly.
Conclusion
Canadian data residency for AI customer support is less about a flag on a map and more about a chain of controls you can document and defend. PIPEDA lets data cross the border as long as you stay accountable and transparent. Law 25 demands a privacy impact assessment first and carries penalties large enough to make the assessment worth doing properly. The AI-specific wrinkle, and the one most evaluations miss, is the language model layer: it is a sub-processor, and the no-train question is the one that turns a residency badge into a real risk decision. Map your three layers, ask your vendor the eight questions above, and require the artifacts in writing.
