AI Vendor Due Diligence: What to Ask and Where the Answers Live

Most AI vendor reviews fail in the same place: the buyer asks the questions, the vendor answers from a marketing page, and nobody checks the document where the answer is actually binding. The trust page says "we never train on your data." The contract says something narrower. The upstream model provider's terms say something narrower still.

The fix is not more questions. It is nine questions, each tied to the specific document that answers it. For each one below I cover why it matters, what a good answer looks like, and which document to ask for. At the end there is a questionnaire you can paste into your own review.

Verified as of 30 October 2026. Every provider claim below is quoted from the provider's own terms or documentation, linked inline, and was accessed on 29 October 2026. Regulatory text is quoted from the published legislation. Provider terms change without announcement, so check the source before you rely on any of this in a contract.

First, find out what you are actually buying

Very few AI products are a single company. A typical one is a SaaS application, calling a model from one provider, through a cloud platform run by another, with a vector store and a logging pipeline on top. Each layer has its own terms. A promise from the top layer is only as strong as the weakest layer underneath it.

So the first question in any review is a mapping question: which model, from which provider, reached through which route. "We use Claude" is not an answer. Claude through Anthropic's own API, through Amazon Bedrock, and through Google Cloud are three different contracts with three different retention, residency, and notification rules, as the sections below show.

Get the map before you read anything else. Every other answer depends on it.

1. Is our data used to train models?

Why it matters. This is the question every buyer asks and the one most often answered from the wrong document. A "we do not train on your data" line on a website binds nobody. The commercial terms do.

What the providers' own terms say. The large providers have put this in their contracts, and the wording is worth reading closely:

• Anthropic's Commercial Terms, Section B: "Anthropic may not train models on Customer Content from Services." Feedback is handled in a separate clause, Section A.3, so ask how thumbs-up and thumbs-down submissions are treated.
• Google Cloud's Service Specific Terms, Section 18: "Google will not use Customer Data to train or fine-tune any AI/ML models without Customer's prior permission or instruction."
• Microsoft's Foundry data privacy page covers prompts, completions, embeddings and training data. It says they "are NOT available to OpenAI or other providers of Models sold by Azure" and "are NOT used to train any generative AI foundation models without your permission or instruction."
• OpenAI's API data documentation states that data sent to the API "is not used to train or improve OpenAI models" unless you explicitly opt in.

Notice the phrase that two of these share: "without your permission or instruction." That is a reasonable clause. It also means a setting someone in your organization switches on can count as the instruction. Ask which console settings, feedback buttons, or fine-tuning jobs would count.

A good answer quotes the clause and names the document it lives in. It covers your prompts, outputs, files, fine-tuning data, and feedback. If the vendor is a SaaS product built on someone else's model, it also states what the upstream provider's terms say, because the vendor cannot promise more than it bought.

Ask for: the training clause in the master agreement or commercial terms, the data processing addendum (DPA), and, for a SaaS vendor, confirmation of which upstream terms apply.

2. What is retained, for how long, and is zero data retention available?

I covered this in detail in Zero Data Retention: What Every AI Provider Actually Promises You. The short version: retention means four different things, ZDR is a contract term with a scope, and the scope varies by model and by feature. Read that before you ask this question.

Three additions since that piece, because they change what a good answer looks like:

• Caching is retention too. On Vertex AI, implicit caching is on by default for Google's Gemini models. Google documents how to turn off durable caching per project if your policy does not permit data at rest.
• Some features retain with no off switch. On the same page, Google says Grounding with Google Search stores logs with customer data "for up to three (3) days," and "There is no way to disable the storage of this information."
• The vendor's own logs count. Amazon Bedrock's model invocation logging is disabled by default. Once enabled, it captures full request and response bodies, and "logs are stored until the logging configuration is deleted." A vendor can buy a zero-retention model and then keep every prompt in its own bucket.

A good answer is a table: per model, per feature, what is kept, where, for how long, and whether it is in the vendor's logs as well as the provider's. It is not a single number.

Ask for: the retention schedule in the DPA, the ZDR or modified-abuse-monitoring amendment if one exists, and evidence it is switched on. Microsoft documents one form of evidence: for customers approved to turn off abuse-monitoring storage, a "ContentLogging" attribute set to false appears in the resource's JSON view. Ask the vendor to show you the equivalent for its stack.

3. Who are the sub-processors, and which model provider sits behind the product?

Why it matters. For an AI product, the model provider is usually the most important sub-processor on the list, and the hosting route decides whether that provider ever sees your data. Under the UK GDPR, Article 28(2) says a processor "shall not engage another processor without prior specific or general written authorisation of the controller". With general authorisation, the processor must tell the controller about intended changes, "thereby giving the controller the opportunity to object to such changes."

What the providers' own documents say. The same model can sit behind very different chains:

• On Azure, Microsoft says models sold by Azure "do NOT interact with any services operated by providers of Models sold by Azure, for example, OpenAI."
• On Bedrock, AWS runs each model in a Model Deployment Account owned by the Bedrock team, and says model providers "don't have access to Amazon Bedrock logs or to customer prompts and completions."
• OpenAI says it "uses sub-processors to provide its services," and that for its US and EU regional endpoints it uses Cloudflare Regional Services so TLS termination happens in the processing region. A network provider in the data path is a sub-processor question too.

A good answer names the model provider, the route (direct API, Bedrock, Vertex AI, Foundry), and every other party that touches prompts or outputs. It explains how you will be told when any of them changes, and how long you have to object.

Ask for: the current sub-processor list, the DPA clause on sub-processor changes, and a data flow diagram that shows the AI feature specifically, not the whole platform.

4. Where is our data processed, and where is it stored?

Why it matters. "Data residency" usually gets answered with a storage location. AI inference adds a second location: where the model actually runs. Several providers separate the two explicitly.

• OpenAI: "Support for regional storage does not imply support for regional processing." Residency is configured per project, and eligibility goes through sales.
• Anthropic runs two independent settings. Inference geo controls where the model runs, per request, with "us" or "global" as the only values. Workspace geo controls storage at rest, and "us" is the only option today. US-only inference is priced at 1.1x the standard rate on Claude 4.6 and later models.
• Microsoft: for a "Global" deployment, prompts and responses "may be processed in any geography where the relevant model sold by Azure is deployed." A "DataZone" deployment keeps processing inside a zone, such as the EU member states. Data at rest stays in the customer-designated geography either way.
• Google: when you use the Vertex AI global endpoint, "requests and their cached data can be served from any region."
• AWS: with cross-region inference enabled, retained inputs and outputs "are stored in destination Regions," meaning wherever the request was processed.

The route matters here as well. Anthropic's own page says its inference_geo setting does not apply on Bedrock or on Google-managed Claude, where the region is set by the endpoint or inference profile instead.

A good answer states the processing geography and the storage geography separately, names the deployment type or endpoint that enforces them, and lists any feature that falls outside, such as search grounding or batch jobs.

Ask for: the data location schedule in the DPA and the deployment configuration for the AI feature. A screenshot of the setting is better evidence than a sentence in a questionnaire.

5. Do the security attestations cover the AI feature?

Why it matters. A vendor can hold a clean SOC 2 Type II report on its core platform while the AI feature launched last quarter sits outside the audited system. The report is real. It just does not describe what you are buying.

What the providers publish. Scope statements exist, and they are specific:

• Anthropic lists SOC 2 Type I and Type II, ISO 27001:2022, ISO/IEC 42001:2023 and a HIPAA-ready configuration for its commercial products, which it names as Claude for Work and the Anthropic API. Reports are on its trust portal.
• Microsoft's ISO 42001 page lists the services in scope, including Microsoft Foundry and GitHub Copilot. It also says customers who rely on that certificate remain responsible "for engaging an assessor to evaluate the controls and processes within your own organization."
• AWS announced ISO 42001 certification covering "Amazon Bedrock, Amazon Q Business, Amazon Textract, and Amazon Transcribe."

That last Microsoft sentence is the general rule. Your provider's certificate covers your provider. It does not cover the SaaS vendor that built on top of it. For what ISO 42001 does and does not attest, see ISO 42001: What It Actually Certifies.

A good answer names the AI feature inside the SOC 2 system description and in the ISO certificate scope. It says whether the model provider is included or carved out as a subservice organization, and if carved out, which provider report covers it.

Ask for: the SOC 2 Type II report plus a bridge letter if the period is stale, the ISO 27001 certificate and Statement of Applicability, the ISO 42001 certificate and scope statement if held, and the model provider's own reports.

6. Will you tell us about incidents and model changes, and how fast?

Why it matters. Two kinds of change hit an AI product: a security incident, and a change to the model underneath it. The first has legal deadlines. The second usually does not, and it can quietly change retention, behavior, or cost.

For incidents, Article 33(2) of the UK GDPR says: "The processor shall notify the controller without undue delay after becoming aware of a personal data breach." "Without undue delay" is not a number. Your contract should turn it into one.

For model changes, the providers publish notice periods:

• Anthropic gives "at least 60 days' notice before model retirement for publicly released models," by email and in the documentation. Those dates apply to Anthropic-operated platforms. Its own page says Amazon Bedrock and Google-managed Claude "set their own retirement schedules."
• OpenAI commits to at least six months for generally available models, unless safety or compliance concerns require faster action. Specialized variants get at least three months, and preview models can go on much shorter notice.
• Anthropic's Commercial Terms, Section M.3, say updates to the terms take effect "30 days after the updates are posted," with changes required by law taking effect immediately.

A SaaS vendor sits in the middle of all this. When its provider retires a model, the vendor picks a replacement, and that replacement may carry different retention terms. The Covered Models example in the ZDR piece is exactly this. For how retirement notices play out in practice, see Model Sunsets Are the New Patch Tuesday.

A good answer commits to a breach notification window in hours, and to advance notice before the vendor changes the model, the model provider, or the hosting route behind the feature you bought.

Ask for: the breach notification clause in the DPA, the vendor's change-management or model-change policy, and the subscription link for its status and sub-processor notices.

7. Who carries the IP risk on outputs?

Why it matters. Generative output can reproduce third-party material. Several providers now offer an IP indemnity, and every one I read comes with conditions that decide whether it applies to your use.

• Google (Service Specific Terms, Section 20) covers "an unmodified Generated Output from a Generative AI Indemnified Service using only Google Pre-Trained Model(s)" or Google-modified or customer-adapter versions of them. It does not apply if the customer "disregards, disables, modifies, or circumvents source citations, filters, instructions, or other tools." The service must not be free of charge. Section 14 adds: "Agentic AI Actions are not Generated Output."
• AWS (Service Terms, Section 50.10) lists its own Indemnified Generative AI Services, including Amazon Nova and Titan models. Exclusions include disabling filters, fine-tuning or modifying the service, and output the customer knew or should have known may infringe. Section 50.12.1 treats third-party models on Bedrock as Third-Party Content.
• Microsoft's Customer Copyright Commitment for Azure OpenAI requires mitigations: a metaprompt directing the model to avoid infringing output, a retained testing and evaluation report, and protected material and jailbreak filters switched on for the relevant use cases. Output flagged retroactively by the asynchronous filter is not covered.
• Anthropic (Commercial Terms, Section K) defends customers against third-party IP claims about paid use of the Services or Outputs. Section K.3 excludes claims arising from customer modifications, combinations with non-Anthropic technology, customer inputs, and "the practice of a patented invention contained in an Output."

Three patterns repeat. The indemnity covers the provider's own models, not third-party models on its platform. It covers paid use. And it can be lost by turning off the safety tooling. If a SaaS vendor reaches a third-party model through a cloud marketplace, the cloud's indemnity may not reach it at all. Only the vendor's own contract decides what passes to you.

A good answer names the indemnity that applies to the specific model and route, says whether the vendor passes any of it through to you, and lists what you must keep switched on to stay covered.

Ask for: the indemnity section of the master agreement, the provider's list of indemnified services, and the required-mitigations list.

8. What admin controls and audit logs do we get?

Why it matters. After an incident, the question is who sent what to which model. Many AI products cannot answer it, and the cloud defaults do not answer it for you.

• On Bedrock, CloudTrail logs InvokeModel and Converse calls as management events, which are recorded by default. Agent invocations such as InvokeAgent are data events, and CloudTrail does not log data events by default.
• CloudTrail records the call, not the content. Prompt and response bodies only appear if model invocation logging is switched on, and that only covers the bedrock-runtime endpoint.
• On Vertex AI, Data Access audit logs "are disabled by default and aren't written unless explicitly enabled," and prediction calls fall in that category.

Good controls also enforce policy rather than just record it. AWS documents a service control policy that denies any data retention setting other than none across an organization. Anthropic lets a workspace restrict which inference geos its keys may use. Those are the kinds of controls to look for in a vendor's admin console.

A good answer covers SSO and SCIM provisioning, role-based admin, and an exportable audit log that records the user, the action, the model, and the data source for every AI call. It also says how long the vendor keeps that log.

Ask for: the admin guide, the audit log schema, and a sample export. A schema shows you what is recorded. A feature list only shows you what is claimed.

9. What can the agent do, and on whose authority?

Why it matters. An AI feature that reads is a data question. One that acts, by sending email, changing records, or calling tools, is an authorization question. It holds credentials, and the vendor has to explain whose.

I covered the provider landscape in Your AI Agent Has No Idea Who Authorized It. The short version: workload identity has improved, but no provider documents a way to carry the human's identity into the inference call itself. AWS STS SourceIdentity can preserve a user's identity across chained role sessions, but only if the integrator wires it up.

The indemnity section above adds a contract angle. Google's terms state that "Agentic AI Actions are not Generated Output." An action the agent takes is not covered by the output indemnity.

A good answer lists every tool and permission the agent holds, scoped to the minimum. It requires human approval for writes and external sends. It shows how to revoke one agent fast, and the logs name the human who started each action.

Ask for: the permission model for the agent, the list of connected systems and OAuth scopes requested, the revocation procedure, and a sample log of one agent action traced back to a user.

The questionnaire

Copy this into your review. The last column is the one that matters. A vendor who cannot point to the document has not answered the question.

#	Question	A good answer looks like	Document to request
1	Which models, from which providers, through which route (direct API, Bedrock, Vertex AI, Foundry, other) power each AI feature?	A named list per feature, including fallback models	Architecture or data flow diagram for the AI feature
2	Is any of our data (prompts, outputs, files, fine-tuning data, feedback) used to train or improve any model, yours or a provider's?	No, quoted from the contract, with every data type covered and what counts as "instruction" defined	Master agreement training clause, DPA, upstream provider terms
3	What is retained, where, and for how long, per model and per feature, including your own logs and caches?	A table, not a single number	DPA retention schedule
4	Is zero data retention or modified abuse monitoring in place, and for which models and features?	A named scope plus evidence it is enabled	ZDR or retention amendment, configuration evidence
5	Who are your sub-processors for the AI feature, and how are we told about changes?	A current list, advance notice, and a right to object	Sub-processor list, DPA change clause
6	Where is inference processed, and where is data stored at rest?	Two geographies stated separately, with the enforcing setting named	DPA data location schedule, deployment configuration
7	Which features fall outside that residency (search grounding, batch, global endpoints)?	An explicit exception list	Product documentation for the feature
8	Is the AI feature inside your SOC 2 system description?	Named in scope, with any carved-out provider identified	SOC 2 Type II report, bridge letter
9	Do you hold ISO 27001 and ISO 42001, and does the scope include this product?	Certificate scope that names the product	Certificates, Statement of Applicability, scope statement
10	How fast will you notify us of a personal data breach?	A fixed number of hours	DPA breach notification clause
11	Will you notify us before changing the model, model provider, or hosting route?	Advance written notice with a stated period	Change-management or model-change policy
12	What IP indemnity applies to outputs from this specific model and route, and do you pass it through?	A named indemnity and a clear pass-through position	Indemnity section, list of indemnified services
13	What must we keep enabled to stay covered by that indemnity?	A listed set of required filters and mitigations	Required-mitigations documentation
14	Do you support SSO, SCIM, and role-based admin for the AI feature?	Yes, on the plan we are buying	Admin guide, plan comparison
15	Can we export an audit log showing user, action, model, and data source per AI call?	Yes, with a stated retention period and SIEM export	Audit log schema, sample export
16	What tools, systems, and OAuth scopes can the agent use?	A minimal, documented list	Agent permission model, scope list
17	Which agent actions require human approval, and how do we revoke an agent?	Approval for writes and external sends, revocation in minutes	Revocation procedure, admin guide
18	Can each agent action be traced to the human who initiated it?	Yes, shown in a sample log	Sample agent action log

Eighteen questions is already a lot for a vendor to answer. If you send a larger questionnaire, the cost of answering it lands on the vendor, a point covered in The Security Questionnaire Is a Sales Weapon. For per-model retention and training facts you can check yourself before sending anything, the AI Models data handling table tracks them from provider sources.

Frequently Asked Questions

What should I ask an AI vendor before buying?

Start with which model and route power the product. Then ask whether your data trains any model, what is retained, and who the sub-processors are. Ask where data is processed and stored, and whether attestations cover the AI feature. Finish with incident and model-change notice, IP indemnity, and admin, audit, and agent controls. For each, ask for the document that answers it.

Do OpenAI, Anthropic, Google, Microsoft, and AWS train on business customer data?

Their published terms say no by default. Anthropic's Commercial Terms say it "may not train models on Customer Content from Services." Google Cloud and Microsoft both say they will not train without your permission or instruction. OpenAI says API data is not used for training unless you opt in. Confirm which settings count as permission.

Does a provider's SOC 2 or ISO 42001 certificate cover the SaaS product built on it?

No. A certificate covers the organization and scope that was audited. Microsoft says customers relying on its ISO 42001 certificate remain responsible for having their own controls assessed. Ask the SaaS vendor for its own report, and check that the AI feature is named in scope.

Does an AI provider's IP indemnity cover every model on its platform?

Usually not. Google's output indemnity covers output from its own pre-trained models. AWS lists its own models as indemnified and treats third-party models on Bedrock as Third-Party Content. These indemnities also exclude cases where you disable filters or modify the output.

What is the difference between data processing location and data storage location for AI?

Storage location is where data sits at rest. Processing location is where the model runs inference. OpenAI says regional storage "does not imply support for regional processing," and Microsoft's Global deployments may process prompts in any geography where the model is deployed. Ask for both.

How much notice do AI providers give before retiring a model?

Anthropic commits to at least 60 days for publicly released models on its own platforms. OpenAI commits to at least six months for generally available models, with exceptions for safety or compliance. Cloud platforms like Bedrock can set their own schedules for the same model.

The document is the answer

Every provider in this piece publishes more detail than most buyers read. The detail is honest and usually precise. The failure is in the review process, which accepts a yes in a spreadsheet cell where a clause, a certificate scope, or a log sample was needed.

Change one habit and most of this fixes itself. For every answer a vendor gives, ask which document it came from, then read that document.