AI Vendor Risk Assessment: A Practical Checklist

Most vendor risk assessments were built before AI tools existed, and they miss what's specific to AI: training on your inputs, generating errors that get treated as facts, or processing regulated data without the right contractual cover. A proper ai vendor risk assessment adds AI-specific questions on top of your standard vendor management checks. Here are seven, in the order they're worth asking, and why each one matters before you approve a new tool.

Does it train on your data?

This is the first question for any AI tool. Consumer tiers of most major AI products train on your inputs by default unless you opt out, and most users never do. Business and enterprise tiers typically don't. Check the specific plan you're evaluating, not the vendor's general default. Ask directly: for this plan, is our data used to train or improve your models? Get the answer confirmed in the plan documentation, not just a sales call, before you approve it. Larger vendors increasingly publish this directly rather than making you ask - Google's generative AI privacy hub for Workspace is one example of the kind of plain-language documentation worth looking for before you rely on a sales rep's answer.

What are the data retention periods?

Even a vendor that doesn't train on your data may retain it for 30, 60 or 90 days for safety, audit or operational reasons. Some vendors have moved to shorter windows recently - Anthropic cut API log retention from 30 days to 7 as of 14 September 2025, a change confirmed on Anthropic's privacy centre, though it applies to the Claude API only, not the consumer Claude.ai product. Understand the retention period before approving sensitive use cases; shorter is better for anything genuinely confidential. A few enterprise tiers offer zero retention, where prompts and responses aren't stored past the session - worth asking about if your team regularly handles sensitive material, and worth re-checking annually since these terms shift more often than a standard vendor contract would.

Do they have a DPA or BAA?

If any personal data flows into the tool, you need a Data Processing Agreement with the vendor under GDPR. If any protected health information flows into it, you need a Business Associate Agreement under HIPAA - HHS guidance sets out what a business associate relationship requires and what it must cover. Check the tier: most enterprise plans include these agreements, most consumer and standard business plans don't. Treat the absence of a DPA or BAA as a hard blocker for regulated data, not a risk to manage around - no signed agreement means no regulated data goes near the tool, full stop.

What certifications does the vendor hold, and can you verify them?

SOC 2 Type II is the minimum baseline for a business AI tool, tested against the AICPA's Trust Services Criteria; ISO 27001 is stronger still. For EU operations, check the vendor's GDPR documentation and Standard Contractual Clauses status. For healthcare, confirm HIPAA eligibility explicitly rather than assuming it. Ask for the most recent SOC 2 report - the abstract is usually public - rather than taking the vendor's word for it. Certifications don't guarantee safety, but their absence is a meaningful signal worth weighing, and a vendor that can't produce one at all is a different risk category from one that simply hasn't sent it yet.

Does the vendor support SSO and role-based access?

Can the tool be scoped to your organisation only? Does it support single sign-on, so employee accounts tie into your identity provider and can be revoked centrally the moment someone leaves? Does it offer role-based permissions so you can limit who can do what? A tool with solid access controls limits your exposure if an account is compromised or an employee departs without an offboarding step being missed. This is often the difference between an incident that's contained in minutes, because one account gets switched off centrally, and one that drags on because nobody can say for certain who still has a login.

What happens if the vendor's own answers don't match their documentation?

It happens more than you'd think. A support lead at a Series A startup once asked an AI note-taking vendor's sales rep whether call transcripts were used for training, got a verbal "no", and then found the plan's own terms page said training was on by default unless the admin flipped a toggle. The lesson isn't that vendors lie - it's that sales answers and plan documentation sometimes drift apart, and only the documentation is enforceable. Always get the answer in writing, ideally quoted from the vendor's own privacy or business-data page, and keep a copy of the exact wording alongside your assessment in case the page changes later.

How do you turn seven questions into a repeatable process?

Write the questions down once, run every new tool through the same seven, and keep a record of the answers alongside the vendor's tier, SOC 2 status and DPA status. That record is your AI vendor risk register, and it's the same document that satisfies vendor-management questions in a SOC 2 or ISO 27001 audit later. Doing this consistently from the start, one tool at a time as requests come in, is far less work than reconstructing six months of approvals from memory under audit pressure.

Put the checklist to work

Running all seven questions manually for every tool your team wants to try is realistic for the first one and exhausting by the tenth. ModelCharter's free AI vendor risk assessment walks through this checklist for you and cross-references our AI Tool Risk Directory, which already has training, retention, SOC 2 and DPA answers logged from vendors' own policies for 60-plus tools.