AI in Canada: Law 25, PIPEDA and Data Residency Rules

Picture a 300-person manufacturer in the Montérégie. The COO wants an AI system that reads incoming purchase orders, matches them against inventory and pricing rules, and drafts the order confirmation. The vendor demo was excellent. It ran on a US cloud region, the interface was English only, and the vendor’s answer to “where does our customer data go?” was a link to a trust page.

None of that is unusual. Most AI tooling and most AI implementation playbooks are built in the United States, for US buyers, under US assumptions. Many of those assumptions don’t hold in Canada. In Québec, even fewer do.

This post covers what changes when you put AI into production at a Canadian company. There’s a checklist at the end you can bring to your next planning meeting.

This is general information for operators, not legal advice. Talk to your privacy counsel before you make decisions that depend on how a specific rule applies to you.

Which rules apply to AI projects in Canada today?

For a mid-market company, most of what matters right now comes from privacy law that already exists, not from AI-specific legislation. That means PIPEDA federally, Law 25 in Québec, and the Charter of the French Language for anything people use at work or as customers. Canadian AI governance is easy to overcomplicate. Start with these.

What does PIPEDA require from an AI system?

The Personal Information Protection and Electronic Documents Act (PIPEDA) governs how private-sector organizations collect, use and disclose personal information in commercial activity. It doesn’t apply in provinces with their own substantially similar laws: Québec, Alberta and British Columbia have their own private-sector statutes.

Two PIPEDA principles do most of the work for AI projects.

Accountability travels with the data. When you send personal information to a third party for processing, including a cloud provider or a model API, you’re still responsible for it. The Office of the Privacy Commissioner expects you to use contracts or other means to make sure the processor protects that information at a comparable level. “The vendor handles security” isn’t a compliance position.

Purpose limits still apply. Data you collected to fulfil orders was collected for that purpose. Feeding years of customer correspondence into a model to train a sales assistant is a different use. Whether that’s allowed depends on what you told people and what they’d reasonably expect. Plenty of AI projects quietly expand the purpose of data that’s been sitting in a CRM for a decade.

PIPEDA doesn’t impose a general data residency requirement. It does expect transparency. If personal information will be processed outside Canada, people should be told it may be accessible to foreign courts and authorities.

Why is Québec’s Law 25 the one to design around?

Law 25 (originally Bill 64) modernized Québec’s private-sector privacy act in phases between 2022 and 2024. It’s the strictest regime in the country. If you have customers, employees or operations in Québec, design your AI program around it. Three provisions hit AI projects directly.

Privacy impact assessments for new systems. Any project to acquire, develop or overhaul an information system or electronic service delivery that involves personal information requires a privacy impact assessment (PIA). An AI system that ingests customer records, employee data or support tickets almost always qualifies. The PIA belongs at the start of the project, where it can shape design choices. Bolted on at the end, it becomes a document describing decisions nobody can reverse.

Transparency for automated decisions. When you use personal information to make a decision based exclusively on automated processing, you have to tell the person. On request, you have to explain what personal information was used and the main reasons and factors behind the decision. The person can also submit observations to someone at the company who’s able to review it. Think of a system that auto-declines credit applications, scores job candidates or decides which claims get fast-tracked. Each one needs a disclosure path, an explanation you can actually produce, and a human who can step in.

Assessments before data leaves Québec. Before you communicate personal information outside Québec, including to a cloud region in Ontario or Virginia, you have to assess whether it’ll receive adequate protection. That assessment weighs the sensitivity of the information, the purpose, the protection measures and the legal framework at the destination. The transfer has to be governed by a written agreement.

Law 25 also requires a designated person in charge of protecting personal information (the CEO, by default), privacy-by-default settings on products and services, and disclosure when you use technology that can identify, locate or profile someone. Penalties are serious. Administrative monetary penalties can reach $10 million or 2% of worldwide turnover, and penal fines go higher.

For a Québec company, the practical effect is simple: you can’t separate the design of an AI system from its governance. The PIA, the transfer assessment and the automated-decision disclosure all depend on architecture choices made in the first few weeks.

Is there a federal AI law in Canada?

No. The Artificial Intelligence and Data Act (AIDA) was introduced in 2022 as part of Bill C-27, alongside a replacement for PIPEDA. Bill C-27 died on the order paper when Parliament was prorogued in early 2025, so AIDA never became law.

That leaves Canada without a federal statute specifically governing private-sector AI systems. Ottawa published a voluntary code of conduct for generative AI in 2023 and has said AI policy remains a priority. What form future federal rules take, and when, isn’t settled.

Two things follow. If a vendor tells you they’re “AIDA-compliant,” be skeptical, because there’s nothing to comply with. And don’t treat the gap as permission. Privacy law already covers most of the risk in an AI system that touches personal information. Future AI rules will likely ask for what a well-run system already has: documentation of what the model does, test records, human oversight on consequential decisions and a way to explain outcomes. Build those in now and new rules become paperwork, not a rebuild. Our guide to AI governance for product teams covers how to set that up.

Where does data actually go in an AI system?

Further than most teams think. “Our data is in a Canadian region” is a fine starting point, but residency conversations often stop at storage, and an AI system moves data around more than a traditional application does. Walk through the path of a single request.

1. Source data. Where do the documents, records and spreadsheets the system draws on live? On-premise, in a Canadian cloud region, in a SaaS tool hosted somewhere else?
2. Embeddings and indexes. If you’re building retrieval over company documents, the vector index holds representations of that content. It’s sensitive data, and it has a location.
3. Inference. When the system calls a model, the prompt (often containing personal or confidential information) goes wherever that model runs. Teams miss this step more than any other.
4. Logs and traces. Observability tools capture prompts and outputs for debugging. They’re often hosted by a third party in another country.
5. Vendor sub-processors. The model provider may use its own sub-processors for abuse monitoring or support.

Can you run frontier models in a Canadian region?

Sometimes. AWS, Microsoft Azure and Google Cloud all operate Canadian regions, and several now offer foundation model inference inside them. Availability by region changes often, and the newest models usually launch in US regions first. So the most capable model may not be available in Canada on day one, and the one that is may be a generation behind.

A system that drafts copy from public product specs doesn’t need the same residency posture as one that summarizes employee performance reviews. Classify the data first, then pick the inference location to match. We go deeper on this trade-off in Canadian AI data sovereignty.

One more nuance. A US-headquartered provider running a Canadian region still answers to US legal process. For most mid-market workloads that’s a manageable risk you document in your transfer assessment. For some regulated sectors and public-sector contracts, it decides the question. Know which group you’re in before you sign.

Do internal AI tools need to work in French?

Yes, if your people in Québec use them. The Charter of the French Language, significantly strengthened by Bill 96 in 2022, makes French the normal language of work and commerce in Québec. US playbooks rarely account for it, and it touches AI systems in two places.

Customer-facing systems. Commercial communications, product information, websites and customer service generally need to be available in French, with French given at least equal prominence. A chatbot, a self-serve support assistant or an automated email workflow that only works well in English is a compliance problem and a customer experience problem at once.

Internal tools. The Charter covers the workplace too. Employers are expected to provide work documents and work tools in French, and Bill 96 extended francization obligations to smaller employers than before. An internal AI assistant your Québec operations team uses every day is a work tool. If it only answers in English, or answers in French that reads like a bad machine translation, you’ve got an adoption problem before you’ve got a legal one.

What does bilingual AI delivery involve beyond translation?

Translating the interface is the easy part. In practice, bilingual delivery means:

• Evaluation sets in both languages. A model that scores well on English test cases can do noticeably worse on Québec French, especially with industry vocabulary, abbreviations and the anglicisms that show up in real shop-floor documents.
• Retrieval that works across languages. Policies may exist in French, technical specs in English and email threads in both. The system has to find the right source no matter which language the question came in.
• Native French prompts and guardrails. Prompts, guardrails and refusal messages get written in French from the start, not translated after the fact.
• A delivery team that works in French. Operator interviews, workflow mapping sessions and user testing in Québec should happen in the language people actually work in. Knowledge gets lost in translation, and capturing it is half the job. More on that in turning institutional knowledge into production systems.

Why don’t US AI playbooks transfer cleanly to Canada?

Because the defaults were set for a different legal environment and a bigger market. That’s not a knock on US vendors or advisors. Many are excellent. The issue is structural.

Defaults assume US law. A US vendor’s standard data processing agreement, default region, logging configuration and model choice reflect US law and US customers. Each one has to be checked, and often changed. If your partner treats Canadian requirements as edge cases, you’ll be the one finding them.

Market size shapes the product. For a US SaaS company, Québec is a small market. French support arrives late and gets handled as a localization task.

The governance documents are different. A US AI governance framework built around sector-specific federal guidance and state laws won’t produce a Law 25 PIA or a cross-border transfer assessment. You need documents that map to the rules you’re actually under.

The fix is to design for Canadian constraints from the first workshop, with governance and architecture decisions made in the same room. Split them across a strategy firm, a dev shop and a compliance consultant, and each one hands the others a problem.

What should you check before and during a Canadian AI project?

Use this list before you start an AI project, or to audit one that’s already underway. It isn’t exhaustive. It covers the questions that most often get skipped.

Before you build

• Map the data. List every data source the system will touch. Mark which ones contain personal information, and whose (customers, employees, suppliers).
• Confirm the purpose. For each source, check whether the AI use fits the purpose the data was collected for. If it doesn’t, decide whether you need new consent or a different approach.
• Start the PIA. If Law 25 applies, it’s required for most AI systems that handle personal information. Even where it isn’t required, the exercise pays off.
• Identify automated decisions. Does the system make, or effectively make, decisions about people? If so, design the disclosure, the explanation and the human review path now.
• Name an owner. One person accountable for the system’s governance. Not a committee.

Architecture

• Trace the full request path. Source, index, inference, logs, sub-processors. Record where each one sits.
• Match inference location to data sensitivity. Decide which workloads must stay in Canada and which can use models hosted elsewhere, and write down why.
• Complete transfer assessments for any personal information leaving Québec or Canada, with written agreements in place.
• Control logging. Decide what gets logged, where, for how long, and who can see it. Prompt logs often hold more sensitive data than the source system’s own logs.
• Keep ownership clear. Your company should own the code, the prompts, the evaluation sets and the configuration. If a vendor holds all of it, your governance depends on theirs.

Language and adoption

• Define the language requirement per surface. Customer-facing, internal and back-office systems may have different needs.
• Build bilingual evaluation sets from real documents and real phrasing from both language communities in your company.
• Test with French-speaking users before launch, not after the complaints start.

Ongoing

• Monitor quality by segment. Track performance separately for French and English inputs, and for each major user group.
• Review once a year against the current rules. The federal picture will change. Your system’s documentation should make it easy to show what it does and how it was tested.
• Keep the paper trail. Model versions, prompt changes, evaluation results, incidents. It prepares you for future AI rules, and it supports SR&ED (Scientific Research and Experimental Development) claims on experimental work. See how AI transformation work can qualify for SR&ED.

What does a Canada-ready AI project look like?

Back to the manufacturer. A version of that purchase-order project designed for Canada looks different from the demo, though not by much on the surface.

The order data and the vector index sit in a Canadian region. The model runs in a Canadian region too, because purchase orders carry customer contact details and the team chose to keep personal information in the country. Where a stronger model was only available in the US, they tested it on de-identified documents and documented why the Canadian-hosted model was good enough for this workload. The PIA was drafted in week one and updated as the design changed. Confirmations go out in the customer’s language. The inside sales team in Longueuil uses the review interface in French, and the evaluation set includes the actual French and English shorthand their customers write on purchase orders.

The system doesn’t make automated decisions about people, so Law 25’s automated-decision obligations don’t apply. Someone checked that and wrote it down.

The first few weeks were more deliberate. In exchange, the system went into production without a governance review stopping it at the finish line. That’s where a lot of AI projects stall. Other reasons are in why AI pilots stall.

Frequently Asked Questions

Does PIPEDA require AI data to stay in Canada?

No. PIPEDA has no general data residency requirement. It does require you to stay accountable for data you send to processors and to tell people when their personal information may be processed outside Canada. Québec’s Law 25 goes further, requiring a documented assessment before personal information leaves the province.

Does Québec’s Law 25 apply to AI systems?

Yes, whenever the system handles personal information of people in Québec. Most new AI systems that touch customer or employee data need a privacy impact assessment, and any decision made exclusively by automated processing must be disclosed and explainable on request, with a human able to review it.

Is Canada’s AIDA in force?

No. The Artificial Intelligence and Data Act was part of Bill C-27, which died when Parliament was prorogued in early 2025. There’s currently no federal AI-specific statute for the private sector, so existing privacy law covers most AI risk.

Working with Chrono Innovation

Chrono Innovation is a Canadian team that builds AI systems for mid-market companies. Governance, infrastructure and adoption are handled by the same people who write the code. We deliver in English and French, and you work directly with senior people. Most engagements start with a fixed-scope project on one or two operating problems, built to production standard and owned by you. If you’re planning an AI project and want to pressure-test the governance and residency questions before you commit, book a call with us.