How to vet an AI vendor at a firm

The short answer

Run the diligence you would run for any supplier who will hold client information, then add three questions that are specific to AI. The mistake is not asking too little; it is asking a sales engineer instead of asking for a document, and accepting a confident answer that appears nowhere in the contract.

Why the burden stays with you

The Office of the Privacy Commissioner’s guidelines for processing personal data across borders set out the position clearly. A transfer to a processor is a use by your organisation, not a disclosure. Principle 4.1.3 of Schedule 1 to PIPEDA requires contractual or other means providing a comparable level of protection while the information is processed by the third party. The organisation must be satisfied the third party has policies, processes, staff training and effective security measures, should have the right to audit and inspect how the third party handles and stores personal information, and should exercise that right when warranted. And whatever the contract says, it cannot override the laws of a foreign jurisdiction.

The Commissioner’s principles for generative AI add the AI-specific half. Organisations using these systems should only use tools that respect privacy laws, should be told by the provider about secondary uses such as prompts being used to further train a model, should be told of known or reasonably expected failure cases, and should recognise that accountability for decisions rests with the organisation and not with any automated system. It also asks providers to publish documentation about the datasets used to develop or train the tool.

The eight questions

• • 1. Is our input used to train, tune or improve any model? Including a model dedicated to us. Get it in the agreement, not the FAQ. This is the single question most likely to have a different answer on your plan than on the one described publicly.
• • 2. Where is data at rest, and does that commitment cover the model call? Storage residency and inference routing are separate commitments and vendors often answer only the first.
• • 3. What is logged when a prompt is processed, for how long, and who can read it? The OPC asks that prompts not be retained, used for secondary purposes or disclosed unless otherwise required. Ask the vendor to say what “otherwise required” means to them.
• • 4. Who are the subprocessors and how are we notified of changes? A model provider sitting behind your vendor is a subprocessor whether or not the contract uses the word.
• • 5. What are the known failure modes? A vendor who cannot describe where their tool performs badly has either not tested it or will not tell you. Both are findings.
• • 6. How are we told when the model changes? This has no analogue in ordinary software diligence. An underlying model swap can change output quality without any release note you would normally read.
• • 7. What are your security assurances and can we inspect? The OPC guidance contemplates a right to audit and inspect. If the answer is a certificate, ask for the scope statement rather than the logo.
• • 8. On termination, what is deleted, when, and what evidence do we get? Ask about backups and logs separately from the primary store, because they usually have different retention.

One checkable public fact: the signatory list

Canada’s Voluntary Code of Conduct on the Responsible Development and Management of Advanced Generative AI Systems, published by Innovation, Science and Economic Development Canada in September 2023, sets out commitments grouped under accountability, safety, fairness and equity, transparency, human oversight and monitoring, and validity and robustness. Signatories commit, among other things, to implement a risk management framework proportionate to their activities, to assess reasonably foreseeable adverse impacts, and — for systems made widely available — to publish information on capabilities and limitations, to publish a description of the types of training data used, and to conduct third-party audits prior to release.

The page carries the signatory list, which includes organisations such as BlackBerry, CGI, CIBC, Cohere, Coveo, IBM, Intel, Interac, Mastercard, OpenText, Salesforce, SAP Canada, TELUS and Workday. Two cautions. The code is voluntary and, as the page itself states, does not change existing legal obligations such as those under PIPEDA. And absence from the list is not evidence of anything much — plenty of competent vendors never signed. Presence is a useful, verifiable signal; treat it as one input rather than a substitute for the eight questions.

A template from a regulator you are probably not subject to

If you want a worked model of third-party risk management, the Office of the Superintendent of Financial Institutions publishes a Third-Party Risk Management Guideline. To be explicit about scope: OSFI regulates federally regulated financial institutions, and a law, accounting or consulting firm is almost certainly not one. It is not your obligation. It is, however, a publicly available structure for thinking about criticality assessment, contractual provisions, monitoring and concentration risk, and borrowing that structure is cheaper than inventing one.

Where the answers have to live

An answer given on a call is not a control. Treadstone Law’s guide to the eight key clauses in an Ontario service agreement is the frame to map your answers onto; its note on subcontracting under a service agreement is directly relevant to question four; and before you accept whatever cap the vendor proposes, its answer on whether limitation of liability clauses are enforceable in Ontario is worth ten minutes. Plan the incident path too — the mechanics of mandatory breach reporting under PIPEDA assume you find out promptly, which only happens if the contract obliges the vendor to tell you.

Worked example (illustrative)

An Alberta firm shortlists three tools. It sends the same eight questions to all three and requires written answers. Vendor one answers all eight and agrees to reflect six in the agreement. Vendor two answers seven and refuses the audit right, which the firm accepts for a low-sensitivity use and records as an exception. Vendor three answers by sending a security whitepaper that addresses none of the questions.

The artefact that outlasts the procurement is the answer sheet. When a client asks the firm what happens to their information, the answer already exists in writing. Countable: questions answered in writing per vendor, answers reflected in the signed agreement, and exceptions logged with a named approver.

Where this sits in the firm

This page is written for a firm that delivers work to a book of clients. If the question is really about the front desk — intake, scheduling, recall, reminders — that lives on the professional practice owners page. If it is about your own month-end, reconciliation and payables rather than client deliverables, that is accounting automation. The two overlap on tooling and almost never on risk.

Questions we get asked

The vendor is large and well known. Is this necessary?
Size tells you about their security programme, not about which plan you bought or which subprocessors sit behind the feature you are using. The questions are cheap; skip them for nothing.

They will not negotiate the contract.
Then the questions become a scoping exercise instead: what may this tool be used for, given terms we cannot change. Recording that limit is itself a control.

How often should we revisit this?
At renewal, and whenever the subprocessor list or the underlying model changes — which is why question six exists.

What if the tool is embedded in software we already use?
Then the diligence is on the feature, not the suite. The commitments covering a productivity platform do not automatically cover an AI feature bolted onto it, and vendors usually document the difference if you look for it.