AI Vendor Risk Assessment: What to Ask About a Model

Key takeaways:

• Asking about SOC 2 compliance is not an AI vendor risk assessment. It’s only a baseline security check that misses the risks specific to AI: data ingestion, output liability, model drift, and sub-processor chains.
• Embedding a third-party AI model into your product makes you accountable for how it behaves, including what data it touches, what it outputs, and what happens when it fails.
• The risk profile of an AI vendor changes significantly depending on whether you’re using a pre-trained model via API, fine-tuning on your own data, or embedding an AI component directly into your product architecture.
• Four categories of questions every AI vendor assessment needs to cover: data governance, model behavior, incident response, and contractual protections.
• SOC 2, ISO 27001, and ISO 42001 all create obligations around vendor risk. A properly documented AI vendor assessment satisfies evidence requirements across all three simultaneously.

‍

Many founders believe a SOC 2 certification or a Trust Center to be their vendor security documentation, and that it is enough to have them covered.

They are not. The SOC 2 report from an AI vendor tells you something real and useful about the security of their infrastructure. 

‍

But it tells you almost nothing about the risks that are actually specific to AI: what happens to the data you send to the model, whether the model can be trusted to behave consistently in your product context, what your legal exposure is if an output causes a problem, and who else in the supply chain has visibility into your pipeline. 

‍

Those are the questions that matter.

Why SOC 2 Certification Isn’t an Answer

‍

A vendor’s SOC 2 certification covers the security of their own systems, such as their infrastructure, their access controls, and their incident response processes. 

‍

It does not extend to what you build on top of it, what data you send through it, or what your users experience as a result of it. The boundary between their certification and your responsibility is exactly where AI-specific risk lives.

‍

When you embed a third-party AI model into your product, four distinct risk vectors open up that SOC 2 was never designed to address:

• Data ingestion: Every prompt you send to a third-party model is data leaving your environment. The question is what they do with that data after it arrives: retain it, use it for training, expose it to sub-processors, or discard it immediately.
• Output liability: If the model produces an output that misleads, discriminates against, or harms one of your users, the legal and reputational exposure sits with you, not the vendor. You deployed it in your product context, and it’s your terms of service that govern what your users experienced.
• Model drift and version changes: AI models are not static. Vendors update, retrain, and retire model versions. A model that passed your internal testing in January may behave differently in June, without any notification to you unless you specifically negotiated for it.
• Sub-processor chains: Most enterprise AI vendors rely on infrastructure sub-processors. OpenAI, for example, uses Microsoft Azure as its primary cloud provider. Understanding who has access to data flowing through the model requires mapping the full vendor chain.

The Three AI Embedding Scenarios

‍

Not all AI vendor relationships carry the same risk. Before running an assessment, it helps to be precise about how you’re actually using the vendor’s technology.

‍

Using a pre-trained model via API

‍

The most common pattern for SaaS startups: you send prompts to an endpoint (OpenAI, Anthropic, Google, Mistral) and receive completions. You have no control over the underlying model and limited visibility into how it processes requests. 

‍

The primary risks here are data retention policies, sub-processor exposure, and output unpredictability. Your leverage is entirely contractual: what the vendor agrees to in their Data Processing Agreement and Terms of Service.

Fine-tuning on your own data

‍

When you fine-tune a base model using your proprietary data, the risk surface expands. Your data is now potentially embedded in a model artifact that the vendor controls. The key questions become: where is the fine-tuned model stored? Who can access it? Can you retrieve or delete your data if you terminate the relationship? Does the fine-tuning process expose your data to the vendor’s broader training pipeline?

Embedding an open-source or self-hosted model

‍

Deploying an open-source model (like Llama, Mistral, or Falcon) in your own infrastructure shifts risk significantly. You gain control over data retention and don’t share data with a third party, but inherit full operational responsibility: security of the deployment, model updates and vulnerability patches, and the governance questions ISO 42001 asks about any AI system in your environment. The “vendor” risk becomes an internal operational risk.

The Four Question Categories Every AI Vendor Assessment Needs

‍

Whatever scenario applies to your situation, a complete AI vendor risk assessment needs to cover four areas. The questions below are structured to be sent directly in a vendor questionnaire or used as an internal evaluation framework.

‍

1. Data Governance

• Data retention after each API call: Is prompt and completion data retained after the request completes? If yes, for how long, and for what purpose?
• Training data use: Is data submitted via the API used to train, fine-tune, or improve any model? This needs to be explicitly excluded in the contract or DPA, not assumed.
• Sub-processor disclosure: Which third-party sub-processors have access to data processed by the model? Are those sub-processors listed in the DPA, and does the vendor commit to notifying you of changes?
• PII handling: If personal data is passed in prompts (deliberately or accidentally), how is it handled? Is there filtering, anonymization, or automatic deletion?
• Data residency: Where is data processed and stored? Is EU-only processing available if required by GDPR or your customers’ contracts?

2. Model Behavior and Reliability

• Version change notification: How are model version changes communicated? Is there a notice period before a version is deprecated, and can you pin to a specific version for production use?
• Behavior documentation: Is there published documentation on known failure modes, edge cases, and adversarial inputs for the specific model you’re using?
• Availability SLA: What is the contractual uptime commitment? What remedies apply if availability falls below the SLA threshold?
• Output filtering and safety controls: What content filtering or safety controls are applied to outputs by default? Can they be configured or disabled for specific use cases?

3. Incident Response

• Breach notification timeline: If a breach occurs involving data that passed through the model, what is the contractual notification timeline? Most DPAs target 72 hours to align with GDPR requirements. Confirm if this is included.
• Audit log access: Do you have access to logs of all API calls made from your account, including timestamps, token counts, and metadata? This is required for compliance evidence.
• Rollback or circuit breaker options: If the model begins producing outputs that are harmful, incorrect, or policy-violating, what options do you have to suspend use while the issue is investigated?
• Incident history: Has the vendor experienced security incidents affecting customer data in the past 24 months? What is the public or contractual disclosure mechanism?

4. Contractual Protections

• Data Processing Agreement: Is a DPA available and does it explicitly cover AI-specific data flows? Many AI vendors have updated DPAs following regulatory pressure, so confirm you’re signing the current version.
• Liability allocation: What is the vendor’s contractual liability in case of service failure or output-related harm? Most AI vendor contracts heavily cap liability, so understand that cap before you build a product feature that depends on the output.
• Audit rights: Does the contract give you the right to audit or request independent verification of the vendor’s security claims? For enterprise deals, this is increasingly standard.
• Termination and data deletion: If you end the relationship, what is the process for deleting your data from the vendor’s systems? Is deletion confirmed in writing, and within what timeframe?

How This Fits Into SOC 2, ISO 27001, and ISO 42001

‍

Running a documented AI vendor assessment doesn’t just reduce operational risk. It also generates compliance evidence that satisfies requirements across multiple frameworks simultaneously.

SOC 2 requires that organizations assess third-party vendors before granting access to systems and data. An AI vendor that processes your users’ data via API is a sub-processor. Your assessment documentation, like the questionnaire responses, the DPA review, and the ongoing monitoring cadence, is exactly what an auditor will ask to see. 

‍

For more on SOC 2’s vendor requirements, check SOC 2 Vendor Management for Startups.

‍

ISO 27001 requires that information security requirements be agreed with suppliers who can access, process, or store organizational information. An AI vendor fits squarely within scope, and your assessment process provides the documented due diligence.

‍

As for ISO 42001, it goes further than both. It’s the only framework of the three that addresses AI-specific supplier risk explicitly. Its controls around AI system supply chain require organizations to understand the AI systems they procure, assess risks associated with third-party AI components, and maintain documentation of that assessment as part of the AI Management System. 

‍

The questions above are calibrated to generate the evidence ISO 42001 asks for. For a full breakdown of what ISO 42001 covers and when it applies, check AI Compliance for Startups: EU AI Act, ISO 42001 & NIST.

Building the Assessment Into Your Process

‍

The most common failure mode in AI vendor risk management is treating it as a one-time event and never revisiting it. AI vendor relationships change faster than most other vendor relationships, and the risks change with them.

Three triggers should prompt a reassessment, in addition to an annual review as a baseline:

• Model version changes: When a vendor updates or deprecates a model version you’re using in production, the behavior of your product feature changes. That’s a material change to the system under assessment, and it warrants a review of whether the original risk evaluation still holds.
• Changes to terms of service or data policies: AI vendors have updated their data use policies frequently over the past two years under regulatory pressure. A change that expands how prompt data can be used, or that modifies sub-processor relationships, is a trigger for reassessment even if the underlying technology hasn’t changed.
• Vendor acquisition or ownership change: If your AI vendor is acquired, the acquiring company’s data practices, legal jurisdiction, and security posture now apply to your data. This warrants a full reassessment under the new ownership structure.

The reassessment doesn’t have to be as extensive as the initial one. A structured annual review that checks for policy changes, new sub-processors, and model version updates, documented in your vendor register, is sufficient for most compliance purposes and catches the majority of material changes before they become risks.

‍

Build an AI Vendor Assessment Process That Holds Up Under Audit

‍

Most startups encounter AI vendor risk for the first time during a customer security review or a compliance audit, when someone asks for documentation that doesn’t exist yet. 

‍

SecureLeap builds AI vendor assessment frameworks as part of broader AI governance and compliance engagements, covering ISO 42001, SOC 2, and ISO 27001. The result is a documented process that satisfies auditors and enterprise procurement requirements without maintaining three separate compliance projects.

‍

Ready to build an AI vendor assessment process before someone asks for it? Book a free 30-min call or send us an email. 

‍

FAQ: frequently asked questions

‍

What is AI vendor risk?

‍

AI vendor risk is the set of risks that arise from using a third-party AI model or service as part of your product or operations. It includes data privacy risks (what the vendor does with your data), operational risks (model changes, downtime, output unreliability), liability risks (who is responsible if an output causes harm), and compliance risks (whether the vendor relationship satisfies your regulatory obligations). It differs from general vendor risk in that AI systems introduce specific failure modes, like bias, hallucination, or drift, that traditional vendor assessments weren’t designed to evaluate.

Does my AI vendor's SOC 2 cover my data?

‍

Partially. An AI vendor’s SOC 2 covers the security of their own infrastructure and internal processes. It does not extend to what happens with the data you send them, how that data is used after processing, or what your legal obligations are in relation to that data. Your liability for data you send to a third-party AI model is governed primarily by the vendor’s Data Processing Agreement and your own privacy obligations, not by the vendor’s certification.

What is an AI vendor questionnaire?

‍

An AI vendor questionnaire is a structured set of questions you send to a potential AI vendor before integrating their model into your product. It covers data governance (retention, training use, sub-processors), model behavior (version changes, reliability, safety controls), incident response (breach notification, audit logs), and contractual protections (DPA, liability caps, audit rights). The responses form the basis of your vendor risk assessment and serve as compliance evidence for SOC 2, ISO 27001, and ISO 42001.

Do I need to assess AI risk if I'm just using an API?

‍

Yes. Using an API means data is leaving your environment and being processed by a third party. The fact that integration is simple doesn’t reduce your compliance or operational obligations. SOC 2 and ISO 27001 both apply to any vendor that accesses, processes, or stores your data. An API call that sends user data to an AI model qualifies under both.

How often should I review my AI vendor risk assessment?

‍

At minimum annually, and additionally whenever a material change occurs: a new model version deployed to production, a change to the vendor’s data use policies or terms of service, or a change in the vendor’s ownership or corporate structure. AI vendor relationships change more frequently than most other vendor relationships, and the risk profile can shift significantly with policy changes that don’t require any technical change on your end.

What's the difference between vendor risk management and AI governance?

‍

Vendor risk management is the process of assessing and monitoring the risks associated with third-party suppliers. It applies to any vendor, not just AI. AI governance is the broader set of policies, controls, and oversight mechanisms that apply to how AI systems are used within your organization, regardless of whether they come from a third party. An AI vendor assessment sits at the intersection of both: it’s a vendor risk management activity that applies AI governance principles to the evaluation of a specific third-party AI model.