An AI vendor risk assessment should cover data handling and training use, model provenance, security controls, regulatory fit (PIPEDA, Quebec Law 25), and contractual accountability before you sign anything. Below is the checklist we use with clients, in the order we actually work through it.
Why AI Tools Need a Different Vendor Review Than Regular SaaS
Most companies already run some kind of vendor risk process for new SaaS purchases. AI tools break that process in a few specific ways. The vendor may retrain on your data by default. The output may be non-deterministic, which complicates testing and audit trails. And the vendor's own AI supply chain (the foundation model it wraps, the sub-processors it uses for inference) is often opaque unless you ask directly. A standard vendor questionnaire misses all of this. That is the gap this checklist closes, and it is the same gap our AI vendor risk assessment service is built to close for clients in Toronto, Waterloo, Ottawa, and across Canada who need to move fast on AI adoption without inheriting a vendor's unmanaged risk.
Data Handling and Training Use Checklist
- Does the vendor train on your inputs? Look for an explicit opt-out or, better, a contractual guarantee that customer data is excluded from model training by default.
- Where is data processed and stored? Confirm the regions involved, and check whether any processing happens outside Canada in a way that affects your PIPEDA obligations or, for Quebec-based operations, Law 25 cross-border transfer requirements.
- How long is data retained, and can you force deletion? Many AI tools retain prompts and outputs for "quality improvement" well past the session. Get the retention window in writing.
- Is there a data processing agreement (DPA) available? If the vendor cannot produce one, that alone is a red flag for enterprise or regulated use.
Model Provenance and Sub-Processor Transparency
- What foundation model powers the tool? A vendor wrapping GPT, Claude, or an open-weight model inherits that model's own risk profile, including that provider's data handling terms.
- Who are the sub-processors? Inference infrastructure, vector databases, and logging pipelines are often run by third parties the vendor doesn't advertise. Ask for the sub-processor list directly.
- Can the vendor explain how outputs are generated? You don't need a research paper, but you do need enough to explain a decision to a customer or auditor if the tool is used in anything customer-facing.
Security Controls to Verify Before Adoption
- Does the vendor hold SOC 2 Type II or ISO 27001? Ask for the report itself, not just the badge on the website, and read the exceptions section.
- Is data encrypted in transit and at rest? Standard, but still worth confirming for smaller or newer AI vendors that skip it.
- What is the vendor's incident response and breach notification process? Get the notification timeline in writing, not just a mention in the privacy policy.
- Does the vendor support SSO and role-based access? Tools without enterprise access controls are harder to govern once adoption spreads past a pilot team.
Regulatory and Compliance Fit for Canadian Buyers
This is the step most vendor checklists skip entirely, and it's where a generic template fails Canadian companies. If you handle personal information, PIPEDA applies to how that information moves through any AI tool you adopt, full stop. If you operate in or serve Quebec, Law 25 adds stricter consent and cross-border transfer rules on top of that. And if your organization is aligning to CPCSC or preparing for SOC 2, an ungoverned AI tool in your stack can become an audit finding even if the tool itself never touches regulated data directly, because auditors increasingly ask what AI tools are in use across the business. Companies in Vancouver and Calgary selling into the US market face an added layer: US customers now routinely ask vendors to disclose their own AI tool usage during due diligence, so your AI vendor list becomes part of your sales cycle whether you planned for that or not.
Contractual and Accountability Checklist
- Liability for AI-generated errors or hallucinated output. Confirm who is accountable if the tool produces incorrect output that causes downstream harm.
- Termination and data export rights. Make sure you can get your data out cleanly, and that the vendor commits to deleting it on exit within a defined window.
- Change notification for model updates. AI vendors update underlying models frequently. You want the right to be notified before a material model change, since it can silently change behaviour you've already tested and approved.
- Right to audit or request evidence. Even a lightweight clause giving you the ability to request updated compliance evidence annually keeps the relationship honest over time.
Building an Internal AI Vendor Register
A checklist per tool is useful, but the real control is a running register: every AI tool in use across the company, who approved it, what data it touches, and when it was last reviewed. Without this, shadow AI adoption (a team signing up for a new tool without security involvement) becomes the norm rather than the exception. This is one of the fastest-growing gaps we see in compliance readiness work with Canadian tech companies right now, and it's usually not because teams are careless, it's because nobody owns the register until an auditor or a customer's security questionnaire asks for it.
How Often Should You Re-Assess an AI Vendor
Annually at minimum, and immediately after any of the following: a vendor changes its underlying model, a vendor discloses a security incident, the vendor's use case in your organization expands (a tool piloted for internal notes now touches customer data), or your own compliance obligations change, such as pursuing SOC 2 or expanding into a new market. Treat AI vendor risk as a living assessment, not a one-time gate at procurement.
If you're evaluating a new AI tool, or you suspect your organization already has more AI vendors in play than anyone has actually reviewed, get in touch through our contact page and we'll walk through what a proper assessment looks like for your stack.