An AI Vendor Privacy & Security Checklist for Procurement Teams

The AI tool is bought before procurement hears about it

By the time most AI vendors land on a procurement team's desk, a business unit has already fallen for the product. A demo impressed someone, a free trial is quietly running in a department, and the conversation has shifted from "should we?" to "how fast can we sign?" Procurement is then handed a mandate to close the deal, not to question it.

That is exactly the moment to slow down for one structured pass. AI vendors are not ordinary SaaS suppliers. They ingest your data to produce outputs, sometimes train on what they ingest, and route information through models and sub-processors that are harder to see than a conventional cloud stack. The privacy and security questions are different, and the standard vendor questionnaire was not built for them.

This checklist is the practical version of that pass. It will not slow a good deal down by much, and it will surface the handful of vendors who should never have made the shortlist. Work through it in order; each section builds on the last.

Start with the data: what goes in, and what is it used for?

Almost every AI risk traces back to one question: what data will this tool see, and what is the vendor allowed to do with it? Answer that before anything else, because it sets how hard the rest of your diligence needs to be.

Map the data flow honestly. A copywriting tool that only ever sees public product descriptions is a low-stakes purchase. A tool that will process customer records, employee files, or — in Canadian healthcare and public-sector settings — personal health information governed by PHIPA, or records governed by FOIPPA or Quebec's Law 25, is an entirely different conversation. The sensitivity of the input sets the bar for everything that follows.

• What categories of data will the tool process — and will any of it be personal, health, or otherwise regulated information?
• Is your data used to train or fine-tune the vendor's models? If yes, can you opt out, and is opt-out the default for business and enterprise tiers?
• Are prompts, inputs, and outputs retained — and for how long? Can you set or shorten retention?
• Where is data stored and processed geographically? Does it leave Canada, and does that create residency or cross-border issues for your sector?
• Who are the sub-processors (the model providers, hosting, and analytics behind the product), and is there a current list you can review?

Pin down model training and retention in writing

Training and retention deserve their own section because vendors are at their slipperiest here. "We don't train on your data" is a sentence that often comes with quiet exceptions — a different answer for the free tier versus enterprise, a carve-out for "abuse monitoring," or a sub-processor whose terms differ from the vendor's own.

Ask for the specific, written commitment, not the marketing line. Confirm that the no-training default applies to your tier and flows down to every sub-processor in the chain. If human reviewers can see your inputs for quality or safety purposes, find out who they are, where they sit, and what governs their access. The goal is a clear, contractual statement you could hand to a regulator or a customer without flinching.

• Get the no-training commitment in the contract or DPA, not just a help-centre article that can change overnight.
• Confirm whether human review of your content happens, by whom, and under what controls.
• Verify that retention and deletion commitments survive the sub-processor chain, not only the front-door vendor.

Check the security posture — and ask for proof

Once you understand the data and how it is used, assess whether the vendor can actually protect it. The reassuring news is that AI vendors can be evaluated with the same evidence-based controls you would expect from any serious supplier. Do not let the novelty of "AI" excuse a weaker security review.

Independent attestation is your fastest signal. A current SOC 2 Type II report covers the design and operating effectiveness of controls over a defined period, not a single point in time, while ISO 27001 certifies a working information security management system. Read the report rather than collecting the logo — check the scope, the audit period, and any exceptions noted. A SOC 2 that excludes the AI product itself is not coverage of the AI product.

• Request a current SOC 2 Type II report or ISO 27001 certificate, and confirm the AI product is in scope — not just the corporate website.
• Confirm encryption in transit and at rest, tenant isolation, and access controls on internal staff.
• Ask how access to your data is logged and reviewed, and whether you can get audit logs of activity in your own account.
• Look for a documented incident response and breach notification process, including how quickly they will tell you.
• For higher-risk purchases, ask whether the AI features specifically have been penetration tested or red-teamed.

Read the contract for the clauses that actually bite

The most expensive AI mistakes are usually buried in the terms, not the product. AI vendor agreements and click-through terms frequently reserve broad rights to use your data, disclaim liability for inaccurate or harmful outputs, and change material terms with little notice. Procurement is the last line of defence here, and the leverage is real before signature, not after.

Make sure a Data Processing Agreement is in place and that it reflects the answers you got earlier — training, retention, sub-processors, and deletion on termination. Push back on terms that let the vendor unilaterally expand its use of your data or quietly add sub-processors without telling you.

• Is there a DPA, and does it match what sales told you about training and retention?
• Who owns the outputs, and are you indemnified if an output infringes someone else's rights?
• What are the breach notification timelines, and are they short enough for your regulatory obligations?
• On termination, is your data returned and deleted — and within a defined window?
• Can the vendor change data-use terms or add sub-processors without notice and a right to object?

Match the depth of review to the risk

Not every AI purchase warrants a full assessment, and treating a low-stakes brainstorming tool like a clinical system will only teach your business units to route around procurement. Tier your diligence so the rigour follows the risk.

A simple split works well. Low-risk tools that never touch regulated or confidential data can pass on a light review: confirm the no-training default and basic security hygiene, then move on. Anything that processes personal information, health data, or material confidential business information moves to the full checklist above — and, depending on the data, may warrant a privacy impact assessment or, for healthcare and public-sector buyers, a threat risk assessment before go-live.

If your organization buys AI tools regularly, the durable answer is governance rather than ad-hoc heroics: a lightweight AI policy and intake process so that data-sensitivity tiers, an approved-vendor list, and a clear escalation path are decided once and reused. That is what keeps a shadow tool from becoming a breach.

Turn the checklist into a repeatable gate

The value of this checklist is not any single question — it is making the questions routine, so the next AI tool gets the same scrutiny as the last one without a fire drill. Build it into your intake form, tier by data sensitivity, and keep a short approved-vendor list so business units have a fast lane that is also a safe one.

When a deal is high-stakes — patient data, government records, or a vendor whose answers keep shifting — bring in privacy and security expertise before you sign, not after the contract is live. A focused review costs far less than unwinding a tool that turned out to be training on your customers' information. If you would like a second set of eyes on an AI vendor, or help standing up an intake process that procurement can actually run, that is exactly the kind of work we do.

Related reading

• How to assess the privacy and security risk of an AI vendor
• Does a small business need an AI governance framework