AI Vendor Due Diligence Checklist: 30 Questions Your SIG and CAIQ Miss

A SIG Lite or a CAIQ never asks where the model runs, who trained it, or how the vendor logs a single AI decision for audit. I built this list to close that gap: 30 questions across model provenance, identity and access, data flow, logging and audit, regulatory mapping, and the AI supply chain, the exact surface a standard SaaS vendor review leaves untouched when the product description includes the word "AI." Each question below names the artifact the vendor should hand back. Send this list alongside our AI vendor security questionnaire if procurement needs the send-today version too.

I want to walk through the questions, the reason each one is on the list, and why the artifact matters more than the answer on its own.

TL;DR

AI vendor due diligence needs 30 questions beyond a standard SIG or CAIQ. Model provenance and regulatory mapping (EU AI Act, NIST AI RMF, HIPAA) get five questions apiece; identity and access, plus data flow and classification, get six each; logging and audit gets five; and the AI supply chain closes it out with three: fourth-party providers, open-weight model licensing, and the tool registry an agent is allowed to call.

Model provenance (Questions 1-5)

These five establish what the vendor is actually calling before any of the later questions can mean anything.

1. Which models does the product use, and from which provider? The vendor lists every model the product can invoke and the provider that hosts it, distinguishing the default model from any the customer can opt into. The artifact is a model catalog listing the provider and model family for each entry, plus the version in use.
2. Where does the model run? The vendor lists the region every model runs in, distinguishing the model's compute region from its data plane. The artifact is a region map for every model in the catalog.
3. Does the vendor train models on customer data? The answer is yes, no, or "only with opt-in." A yes requires a follow-up on what data is used and how it is segregated. The artifact is the training-data policy.
4. Does the vendor use the model provider's API in a mode that excludes the customer's data from training? For OpenAI, Anthropic, and Bedrock the API mode defaults to no-training in the enterprise tier; the vendor confirms which tier it operates on. The artifact is the API contract or the provider's stated training exclusion.
5. What is the model's failover provider? A vendor running OpenAI as primary and Anthropic as failover has a different audit and residency surface than a vendor on a single provider. The artifact is the routing posture.

Identity and access (Questions 6-11)

These six trace whether a human or agent identity survives the trip from the customer's IdP into the model call.

1. How does the vendor identify the calling user inside each AI request? The audit chain requires the natural-person identity to travel with the request, and the vendor describes how that identity propagates from the customer's IdP through the application into the AI call. The artifact is an identity-propagation diagram.
2. How does the vendor identify agents distinct from users? Agentic workflows carry an agent identity alongside the natural-person identity. The vendor describes how the agent is named in the audit and how its authority differs from the user's.
3. Does the vendor support SSO with the customer's IdP for the AI-using surface? A vendor running local accounts for AI capabilities but SSO for the rest of the product breaks the identity chain for AI decisions. The vendor confirms full SSO support.
4. Does the vendor support SCIM provisioning for the AI-using roles? Roles that grant access to AI capabilities get provisioned and deprovisioned through SCIM, not the vendor's local admin UI.
5. How does the vendor handle service accounts and machine identities? A service account driving an agent carries the same identity-chain requirement as a human user. The vendor confirms machine-identity support and the audit-record fields the service account populates.
6. Does the vendor allow customer-side identity binding to AI requests? Where the customer runs an AI gateway in front of the vendor's product, the vendor accepts the identity envelope from that gateway and records it in the vendor's own audit. The vendor confirms whether this integration exists.

Data flow and classification (Questions 12-17)

These six follow the customer's data from the request into the model provider's pipeline.

1. What categories of customer data does the AI capability send to the model? The vendor lists every category, following the customer's classification scheme where possible.
2. Does the vendor classify data before sending it to the model? A vendor sending every input to the model without classification has no DLP-equivalent control at the AI boundary. The vendor describes the classifier and the categories it covers.
3. Can the vendor redact sensitive fields before the model sees them? Redaction covers PII and PHI, plus payment data and source code. The vendor describes the redaction modes and which of them the customer can configure.
4. Does the vendor support customer-managed redaction policies? A customer with its own classifier or redaction rules needs the vendor to accept them. The vendor confirms whether customer-managed policies are supported.
5. What happens to the data inside the model provider's pipeline? The vendor traces the data through the provider, including the provider's data-handling policy, retention, and training exclusion. The artifact is the provider DPA.
6. Does the vendor support data-residency constraints on the AI capability? Residency covers EU traffic staying in the EU, India traffic staying in India, and similar. The vendor lists the residency modes available and the provider region mapping.

Logging and audit (Questions 18-22)

These five decide whether the vendor's audit trail can survive a regulator's question three weeks after the fact.

1. What audit fields does the vendor record per AI decision? A useful answer lists the natural-person identity, the agent identity, the model used, the policy version, the input classification, the decision, and the timestamp. The artifact is the audit-record schema.
2. How long does the vendor retain the AI-decision audit? EU AI Act Article 19 sets six months as a floor for high-risk systems; longer is better. The artifact is the retention policy.
3. Can the customer export the AI-decision audit? Export is what makes the vendor's audit usable inside the customer's SIEM. The vendor confirms export, format, and frequency.
4. Does the vendor sign the audit records? Signed audit records survive the regulator's tamper-evidence question. The vendor confirms whether records are signed and describes the verification path.
5. How does the vendor link a model output back to the inputs that produced it? The audit chain has to be navigable from output to inputs. A vendor that cannot link output to input is missing the chain the regulator's question depends on.

Regulatory mapping (Questions 23-27)

These five map the vendor's AI capability to the specific regulatory obligations that follow it.

1. Does the vendor classify any of its AI capabilities as high-risk under the EU AI Act? The Annex III categories include HR screening, credit scoring, clinical decision support, and education access. The vendor states which capabilities it classifies as high-risk and under which category.
2. Has the vendor completed a fundamental rights impact assessment (FRIA) for its high-risk capabilities? The FRIA is required under EU AI Act Article 27. The artifact is the assessment; our FRIA template for deployers covers the sections a vendor's assessment should already answer.
3. Does the vendor map its AI capabilities to NIST AI RMF functions (GOVERN, MAP, MEASURE, MANAGE)? The mapping is what the customer's risk team uses to cross-reference. The artifact is the NIST AI RMF mapping.
4. Does the vendor sign a BAA for AI capabilities that touch PHI? This is the HIPAA covered-entity question. A vendor processing PHI through AI needs a BAA that names the AI capability explicitly, not a general BAA written before the capability existed.
5. What is the vendor's incident-disclosure posture for AI-related incidents? The answer covers the notification timeline, the incident categories that trigger notification (model degradation, policy bypass, data leak through model output), and the named contact. The artifact is the incident-response policy.

AI supply chain (Questions 28-30)

Questions 1 through 5 cover the model the vendor calls directly and stop there. Behind that model sits a second layer of providers the vendor rarely volunteers: the embeddings provider, the vector store, the fine-tuning pipeline, and every plugin or retrieval source the model is allowed to invoke. A subprocessor list built for SaaS does not surface any of this, because none of it looks like a subprocessor in the traditional sense.

1. Does the vendor disclose the fourth parties behind its own AI calls? The primary model provider is not the whole chain. Ask for every fourth party touching the request or the data: the embeddings provider, the vector database, and any orchestration layer sitting between the vendor's application and the model. The artifact is a fourth-party subprocessor list scoped to the AI capability specifically.
2. If the vendor fine-tunes or self-hosts an open-weight model, what is the training-data provenance and the license? An open-weight model such as Llama or Mistral carries its own license terms, and the vendor inherits whatever safety testing the model's publisher ran. Ask for the model card, the license name, and whether the vendor ran its own evaluation rather than citing the base model's published benchmarks. The artifact is the model card plus the vendor's own evaluation results.
3. Can the vendor name every tool, plugin, or retrieval source the model is allowed to call? An agentic capability chains the model to tools, a retrieval index, or third-party plugins, and each link carries its own data-access scope. The vendor lists the tool registry and states whether the customer can restrict it. The artifact is the tool registry, current as of the last release.

Scoring the checklist

A useful scoring model assigns three states per question: "satisfied," "partial," "missing." The risk team triages around the missing answers, and procurement balances those gaps against business need. Accuracy is what the audit team verifies, leaving the buying decision to procurement.

DeepInspect

A customer running DeepInspect in front of a vendor's AI capability can answer questions 6, 7, 9, 11, 14, 17, 18, 19, 20, 21, and 22 from its own gateway, regardless of what the vendor's product does. The identity, the classification, the policy version, and the per-decision audit live in the customer's plane. The vendor's product becomes an upstream callee; the regulatory chain stays in the customer's hands.

The gateway runs in-line with sub-50ms p95 enforcement overhead from internal DeepInspect testing. Book a technical deep dive at deepinspect.ai.