Your AI Vendor Risk Assessment Is Missing Half the Story

Most vendor risk programs weren't built with AI providers in mind. They were designed for cloud infrastructure vendors, SaaS platforms, payroll processors - the kind of third parties where the risk model is relatively well understood. You send a questionnaire, you review the SOC 2 report, you check the subprocessor list, you move on.

AI vendors don't fit cleanly into that model. The data flows are different, the failure modes are different, and the questions that matter most aren't on any standard questionnaire template. This post walks through how to assess an AI vendor properly, using Claude and Anthropic as the worked example, partly because it's the most relevant AI tool for most GRC practitioners right now, and partly because the specifics are genuinely instructive.

If you haven't already read the post on Claude's enterprise data policies, start there. What follows assumes you understand the difference between consumer and commercial plans and why it matters.

Why standard vendor questionnaires fall short

A Standardized Information Gathering (SIG) questionnaire or a basic security due diligence form will get you useful information about Anthropic: their SOC 2 Type II status, encryption standards, incident response procedures, subprocessor list. Anthropic's compliance posture is legitimate and well-documented, and they will pass those sections without difficulty.

What those questionnaires won't surface are the risks that actually matter for an AI deployment. Standard third-party risk frameworks were designed around a core assumption: the vendor processes your data in a defined, predictable way. AI changes that assumption. The model processes whatever your employees send to it. The scope of data access is defined by your employees' behavior, not by a contract. The outputs influence decisions in ways that are difficult to audit. Model updates can change behavior without a version bump. None of that maps to the standard vendor risk question set.

The way to address this is to treat an AI vendor assessment as two assessments layered on top of each other: the standard infrastructure and security assessment, plus an AI-specific addendum that covers the risks the standard form misses.

The AI-specific questions to add

Start with data training posture, because this is where the stakes are highest and the answers vary most dramatically between vendors and between plans. For Anthropic specifically, the questions are:

Which plan is your organization licensed for, and is training disabled contractually or only by configuration? The distinction matters because a configuration can be changed accidentally or by an uninformed administrator. A contractual prohibition cannot. Team and Enterprise plans disable training contractually. Consumer plans rely on a toggle.

Who in your organization administers the privacy settings, and how do you verify their current state? This is surprisingly often unanswered. Many organizations assume IT has it handled, and IT assumes someone else does.

For any consumer-plan usage detected in your environment: has the training toggle been confirmed off for every active user? If you can't answer this, you have an open question on data exposure.

Data classification and access scope

Standard assessments ask what data the vendor can access. For an AI vendor, the more useful question is what data your employees are actually sending, because the vendor's access is effectively unlimited within your subscription tier. You're typing things into a chat interface, and the model processes whatever you type.

This means the vendor risk assessment needs to connect to your internal data classification policy. For each data category you've classified (confidential, regulated, client data, whatever your taxonomy is) you need a clear answer on whether that category is permitted in Claude interactions, and if so, under which plan and configuration.

If you don't have a data classification policy that addresses AI tools, that's the gap to close before you finish the vendor assessment. An AI vendor assessment that doesn't connect to a usage policy is academic.

Model behavior and output governance

Here's where most assessments stop, because they're focused on inputs and data handling, and the output side is harder to structure.

The questions worth adding: For any workflow where Claude's output influences a material decision - a compliance determination, a contract interpretation, a risk rating - what review process exists before that output is acted on? Who is responsible for validating it? Is that process documented?

Model updates are the other issue to address explicitly. Anthropic updates Claude models on an ongoing basis. Unlike a traditional software update, a model update doesn't come with a diff you can review. Behavior can change in ways that are subtle and not immediately obvious. If your organization has built workflows around specific Claude behavior, you need a process for testing those workflows after model updates. If you don't have one, that's a control gap worth documenting.

Subprocessors and fourth-party risk

Anthropic's subprocessor list is available through their Trust Portal. Review it the same way you'd review any cloud vendor's list, with one addition: pay specific attention to any subprocessors that touch conversation data, and trace where that data goes geographically. For organizations with EU data residency requirements, this matters for GDPR compliance. It's not enough that Anthropic has SCCs (Standard Contractual Clauses) in place if conversation data is flowing through a subprocessor in a jurisdiction that creates problems for your DPA.

Incident notification

Under Enterprise terms, Anthropic's contractual obligation to notify you of a security incident affecting your data is defined. Under consumer terms, it effectively isn't - you're relying on Anthropic's public disclosure practices rather than a contractual SLA. This is worth documenting explicitly in your risk assessment, because it affects how you'd respond to an incident involving Anthropic data.

Putting it into a program

The practical challenge with all of this is that vendor risk assessments are typically point-in-time. You assess the vendor, you document the findings, you approve or conditionally approve, and then you schedule a review for next year. That model works badly for AI vendors, because the risk profile changes continuously. Model updates ship, new features get released, policy terms get updated, employee usage patterns evolve.

The right approach is to treat your AI vendors as a distinct tier requiring more frequent review cycles and continuous monitoring signals. At minimum, that means reviewing your Anthropic vendor assessment whenever Anthropic makes a material change to their terms or certifications, whenever your organization changes its Claude plan or configuration, and whenever your data classification policy is updated.

Compliance automation platforms with vendor risk management modules (Vanta is the one most commonly used by the Series A to mid-market organizations that make up the core GRC practitioner audience) can structure and track this kind of ongoing review. The AI-specific questions won't be in their default templates, but the workflow infrastructure is there. Build the template once, run it repeatedly.

What you're actually trying to document

The goal of a vendor risk assessment isn't to prevent all risk. It's to make an informed, documented decision about what level of risk you're accepting and why, so that you can demonstrate due care if something goes wrong.

For Claude specifically, the defensible position is straightforward to achieve: commercial terms, SSO enforced, DPA in place, data classification policy that addresses AI usage, and a record of when you assessed all of the above. That's a vendor risk file you can put in front of an auditor with a straight face.

What you can't defend is "we were using the free version and didn't really think about it." That's the current state at a lot of organizations. The gap between where most companies are and where they need to be is not technically complicated. It's mostly a matter of having thought it through.