AI Vendor Due Diligence Questionnaire by Deployment Model

Before any question, establish which of three things you are buying. Each one puts a different party between your data and the model.

Hosted API. You send prompts to the model lab's own service. The lab is your processor, and retention, abuse monitoring and the model lifecycle are its decisions, set out in its terms and data-handling pages.

Model service in your cloud tenant. You consume the same family of models through Microsoft Foundry, which includes Azure OpenAI, or Amazon Bedrock. Microsoft's data privacy page says prompts and completions "are NOT available to OpenAI or other providers of Models sold by Azure", and Amazon's Bedrock documentation says model providers have no access to the accounts where models run, so they cannot see prompts or completions. The hyperscaler becomes your processor. Data at rest for stateful features sits in your own tenant, but processing location depends on the deployment type you choose.

Open weights on your hardware. You download weights and serve them on your own infrastructure. There is no processor. Your suppliers are now a licensor and the open-source serving software.

The cost and security trade-off between these options is its own decision, covered in cloud vs on-premise AI security and cost. This post assumes you know which one you are buying and need the right questions for it.

Seventeen questions in five groups. Each cell says who answers: Ask (send it to the vendor and file the response), Evidence (the answer is your own control, so produce the evidence yourself), or N/A.

Read down the columns. The hosted API and the tenant service both send 12 questions to a vendor, answer 1 themselves and skip 4. The open-weights column sends none: 13 rows become your own evidence and 4 do not apply. Same risk topics, different counterparty.

Row 5 is deliberately one line. Parent-company jurisdiction, extraterritorial access and cross-border transfer deserve their own checklist, and that lives in our EU AI Act data sovereignty and residency guide. Here the only question is whether storage location and processing location are the same place, because the next section shows the deployment types where they differ.

Row 13 never belongs to the vendor. A vendor's published benchmark tells you about the vendor's tasks. Whether the model is fit for your claims triage or your credit memo drafting is your evidence to produce, in every column.

Capability evaluation (which model writes the best summaries, which product has the features you want) is a separate exercise. This matrix covers risk only.

The binary version of each data question gets a binary answer that is technically true and practically useless. Use OpenAI's published API data controls as the worked example, because they are detailed.

Training. OpenAI states that since March 1, 2023, data sent to its API is not used to train or improve its models unless the customer opts in. That is a clean answer, and the only clean one in this group.

Retention. Abuse-monitoring logs are retained for up to 30 days by default, longer if the law requires it or if needed to protect the service or others from harm. Some response objects are stored for at least 30 days unless storage is turned off. Stateful features such as file storage, vector stores and stored conversations keep data until you delete it. Zero data retention exists, but it requires OpenAI's approval, and those stateful features are not eligible for it. So "do you retain our data?" has at least three answers depending on which features your team builds on.

Location. OpenAI offers in-region storage and processing for the US and Europe (Europe requires zero retention, modified abuse monitoring or another approved arrangement). Several other regions, including the UK, Canada, Japan and Australia, get storage residency only, with processing elsewhere.

The tenant-hosted services change the counterparty without making the questions disappear. On Microsoft Foundry, stored data for stateful features sits encrypted in your own Azure tenant, in the resource's geography. Processing is a different matter: a standard deployment processes in your chosen geography, a DataZone deployment anywhere inside the US or EU zone, and a Global deployment "in any geography where the relevant model sold by Azure is deployed." Abuse monitoring can sample prompts for review by authorized Microsoft staff unless you apply for, and are granted, modified abuse monitoring, which your Azure team can then confirm as a setting on the resource itself rather than taking it on trust. On Amazon Bedrock, retention can depend on the specific model you select, so ask per model, not per platform.

That turns rows 1, 3 and 5 into sharper questions:

For healthcare buyers, one addition: a BAA covers the features the vendor lists as eligible, not the whole product, so cross-check row 1 against that list.

Retention terms change rarely. Model versions change on a published clock, and that clock differs by vendor and channel.

OpenAI's deprecation policy gives at least 6 months' notice for generally available models, at least 3 months for specialized variants, and much shorter notice, such as 2 weeks, for previews, with a faster timeline possible for safety or compliance concerns. Anthropic commits to at least 60 days for publicly released models, and its published dates apply to Anthropic-operated platforms: the Claude API, Claude Platform on AWS, Anthropic-managed Claude models on Google Cloud, and Microsoft Foundry. Partner-operated platforms, Amazon Bedrock and Google-managed Claude models on Google Cloud, set their own retirement schedules. That is a factor of three between two major labs, and the same model can have two different end dates depending on where you buy it.

Real dates make the point. On October 1, 2026 OpenAI announced that gpt-5.1, gpt-5.4-nano and gpt-5.3-codex will be removed on April 1, 2027. On October 14, 2026 it announced removal of GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini on January 14, 2027, adding that fine-tuned versions "follow the same shutdown schedule as their underlying base models." Anthropic notified Claude Sonnet 4.5 users on September 30, 2026 of retirement on the Claude API on November 30, 2026. Any due diligence file that recorded "model: GPT-4.1, fine-tuned" in the spring now holds an answer with an end date.

A forced migration is not a config change. Prompts, tool schemas and output parsing all shift between model families, which is the cost described in migrating AI agents between model families. The control that makes it survivable is row 13: a regression set you own, re-run on every version change, as covered in LLM-as-judge regression testing for non-deterministic outputs.

The September 2026 proposal names this activity directly: its examples of ongoing monitoring include "reviews of updates to information utilized in due diligence." Row 11 matters for a second reason. The vendor's notice starts your own reporting obligations, and which regulator clock starts when an AI incident hits covers how those clocks stack.

This is where deployment model changes the answer most. With open weights on your own servers, rows 1, 2, 5, 6 and 8 are no longer promises you collect from a vendor. They are controls you operate and must evidence to an examiner or auditor: who can query the model, where prompts and outputs are logged, how long those logs are kept, who approves a model version change, and how you confirm the deployed files are the ones you approved. A regulated firm already knows how to evidence access control, logging and change management for any other internal system. The same evidence pack, applied to a model server, replaces most of the vendor form. When we build private deployments on client infrastructure, that pack is part of the delivery, because the auditor will ask for it before the model reaches production.

Rows 3, 4, 7 and 9 drop out. Nobody outside reviews your flagged prompts, no lab can see them, no one retires your model on a notice period, and you hold every file at contract end because there is no contract.

What remains, rows 14 to 17, is the supply chain.

The four-agency proposal was published in the Federal Register on September 15, 2026 (91 FR 58536), with comments due November 16, 2026. If finalized, it would replace the June 2023 interagency guidance on third-party relationships; until then, the 2023 guidance applies. The Federal Reserve published a separate proposed third-party risk management guide for traditional community banking organizations the same day, with the same deadline.

Four passages bear on an AI questionnaire. None of them mentions AI; applying them to AI vendors is our reading, not the agencies' text.

Our recommendation for tiering, which is ours and not the agencies': set depth by data class and by how much the output decides.

For governance, anchor on NIST AI RMF GOVERN 6, the voluntary framework's third-party category. GOVERN 6.1 asks for "policies and procedures ... that address AI risks associated with third-party entities", including intellectual property. GOVERN 6.2 asks for "contingency processes ... to handle failures or incidents in third-party data or AI systems deemed to be high-risk", and its suggested actions include redundancy for vital third-party AI systems and incident response plans that cover them. Map 6.2 to rows 7, 9 and 11: a retirement notice and a vendor incident are the two third-party failures you can plan for in advance. NIST's July 2024 Generative AI Profile, AI 600-1, extends the same framework to generative models.

If you are a bank deciding which hosted generators belong in model risk management and which in third-party risk, our SR 26-2 scope analysis for LLMs draws that line; hosted generators outside SR 26-2 land in the third-party process this matrix feeds. More on the business side of these decisions sits in the AI for business guide.

Take the AI questionnaire you already send. Add three columns: hosted API, your-tenant service, open weights. Mark every existing question Ask, Evidence or N/A for the deployment you are actually buying, then delete the N/A rows from the version that goes to the vendor and move the Evidence rows to your own control owners.

Next, open your current AI vendor files and find each pinned model version. Look up its retirement date on the vendor's deprecation page and write it on the risk register beside the trigger to re-ask.

If you are a bank or credit union, the comment window on the interagency proposal is open until November 16, 2026. The question of whether a public model licence counts as a third-party relationship is a reasonable one to put to the agencies directly.