How to pick an AI vendor without getting burned

Under Canadian privacy law, your business stays accountable for personal data processed by any AI vendor you use. Here is the practical checklist: data residency, certifications, pricing traps, and the contract clauses that create lock-in.

Under Canada's federal privacy law (PIPEDA), your organization remains accountable for any personal data a third-party AI vendor processes on your behalf — that accountability cannot be delegated through a service agreement. That is the practical starting point for evaluating any AI tool or platform: the question is not whether a vendor is reputable in general, but whether you have confirmed the specific data practices, contract terms, and governance structures that protect your business when something goes wrong. The federal government's ISED AI adoption toolkit for small and medium-sized enterprises recommends evaluating vendor certifications and data practices before committing, and beginning AI deployment with lower-risk internal tasks before connecting any system to customer data or decision-making workflows. The checklist below covers what to verify before you sign.

Data residency and privacy: where your data goes and who can access it

PIPEDA's accountability principle establishes that your organization is responsible for personal information in your possession or custody, including information transferred to a third party for processing. A vendor breach is therefore your legal exposure, not only the vendor's. Before signing, confirm where exactly data is stored at rest and in which geographic region. Many Canadian businesses assume a Canadian data centre means Canadian data sovereignty — but that assumption is not legally reliable for vendors with a US parent company. Under 18 U.S.C. § 2713 (the US CLOUD Act), American companies can be compelled by US courts to disclose data anywhere in their possession or control, including data stored in Canadian facilities. The CLOUD Act does not override Canadian law, but the practical effect is that a US-incorporated vendor cannot guarantee your data will never be accessible to a US court order, regardless of where its servers sit. Ask directly: is your company incorporated in Canada with no US parent, or could a US court compel disclosure of our data? Require a signed Data Processing Agreement that covers security obligations, data-use limitations, breach notification timelines, and which party notifies the Office of the Privacy Commissioner in the event of a breach. If a vendor cannot or will not provide a DPA, that is a disqualifying condition under PIPEDA's accountability principle. In sectors common to Northwestern Ontario — healthcare clinics, mining and resource operations, Indigenous-governed services — any AI tool handling client records, operational data, or community information should be held to the highest standard of these questions.

Training data and model updates: what to fix in writing before you start

Before any AI tool processes your customer data, your operating data, or your employees' information, ask whether the vendor uses that data to train or fine-tune their models. This condition must be explicitly prohibited in writing if you do not consent to it. Vague 'service improvements' language in a terms-of-service is the most common mechanism vendors use to retain reuse rights without your awareness. Also ask who the vendor's sub-processors are — the third parties their platform routes data to — and whether you are notified and have any consent rights if new sub-processors are added mid-contract. A mid-contract sub-processor addition can shift your data to a new jurisdiction without your knowledge. Ask whether model updates are communicated before they are deployed and whether you can defer an update that changes system behaviour in a production workflow. None of these questions are unusual; a credible vendor will answer them directly.

Pricing structures and the overages that catch businesses off guard

AI tools in 2026 follow three broad pricing structures: per-seat subscriptions, usage-based billing (per token, API call, or transaction), and hybrid models that combine a base subscription with variable usage tiers. The risk with usage-based and hybrid pricing is that production costs can be significantly higher than what a pilot or demo environment suggests — tasks that run occasionally in testing may run continuously once a workflow is live. Before committing, ask the vendor to explain overage rates: the rate charged per unit above the included tier, and what triggers a notification before you reach the ceiling. Ask whether the rate card in your contract is fixed for the contract term, or whether the vendor reserves the right to revise usage rates mid-contract. Ask how 'fair use' is defined and whether that definition resets at renewal. If pricing is listed only as 'contact sales,' treat any verbal quote as preliminary until you have it in writing as part of the signed agreement.

Contract clauses that create lock-in

• Data export scope: confirm that 'Customer Data' in the export provisions includes derived assets — embeddings, vector indices, fine-tuned model weights, and agent memory — not only raw input files. Narrow definitions of exportable data are a common lock-in mechanism that makes migration far more costly than anticipated.
• Model deprecation notice: ask for a minimum contractual notice period before any model your workflows depend on is retired, and a parallel-run window during which the old model remains available. No stated notice period means the vendor can force an unplanned migration at any time.
• Sub-processor consent rights: the contract should require vendor notification and your consent before new sub-processors are added, so a mid-contract change cannot shift your data to a new jurisdiction without your knowledge.
• Audit log retention after contract end: confirm how long the vendor retains logs after you leave, and in what format. Your regulatory retention obligations do not end when the contract does.
• Change-of-control rights: a notification-only change-of-control clause means that if the vendor is acquired, you are informed but have no recourse if the acquirer changes pricing or terms at renewal. Require termination-for-convenience rights with a 90-to-180-day window at original pricing if there is a change of control, with data-portability obligations preserved through that window.
• Output IP: the contract should be clear that your organization owns the outputs the AI generates from your data, and that the vendor provides adequate indemnification coverage for IP claims arising from training data it controls.

Sources: PIPEDA Principle 1 (Accountability) — organizations responsible for personal information in their possession or custody, including information transferred to a third party for processing; cross-border transfer obligations; Data Processing Agreement requirements; Privacy Commissioner enforcement priorities including AI: priv.gc.ca/en/privacy-topics/technology/artificial-intelligence/ | Office of the Privacy Commissioner — PIPEDA Schedule 1 Principles including Principle 1 (Accountability) and Principle 4 (Limiting Collection): priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/pipeda_brief/ | ISED Toolkit for Small and Medium-sized Enterprises (SMEs) Deploying AI — built on G7 Kananaskis Summit commitments; recommends ISO/IEC 42001:2023 and CAN/DGSI 101:2025 as vendor certifications to request; progressive deployment guidance starting with low-risk functions; OECD AI Incidents and Hazards Monitor as sector-risk reference tool: ised-isde.canada.ca/site/ised/en/toolkit-small-and-medium-sized-enterprises-smes-deploying-artificial-intelligence-ai | ISED SME AI Adoption Blueprint (G7) — flexible deployment environments, interoperability, certified AI tools, compliance with local regulations, and secure data handling as vendor evaluation criteria: ised-isde.canada.ca/site/ised/en/sme-ai-adoption-blueprint | ISED Voluntary Code of Conduct on the Responsible Development and Management of Advanced Generative AI Systems — six commitment areas: accountability, safety, fairness, transparency, human oversight, and robustness; signatories required to share relevant risk information with downstream users: ised-isde.canada.ca/site/ised/en/voluntary-code-conduct-responsible-development-and-management-advanced-generative-ai-systems | ISO/IEC 42001:2023 — first international AI management system standard; covers risk governance, accountability, model registries, data controls, and supplier management; ISO 42006 (accreditation standard for certification bodies) became International Standard July 7, 2025: iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html | US CLOUD Act (18 U.S.C. § 2713 — Clarifying Lawful Overseas Use of Data Act) — requires US-incorporated companies to disclose data in their possession, custody, or control regardless of physical storage location: congress.gov/bill/115th-congress/house-bill/4943/text | NIST AI Risk Management Framework 1.0 — voluntary framework organized around Govern, Map, Measure, and Manage functions; referenced by Canadian government as complementary to Canadian AI governance practices: nist.gov/itl/ai-risk-management-framework