AI Vendor Due Diligence Questionnaire: What to Ask Before You Buy

TL;DR

• An AI vendor questionnaire must document the vendor’s AI inventory, data flows, identity controls, audit records, upstream providers, applicable regimes, and incident and termination procedures.
• Procurement approval is only the starting point, because vendor models, data practices, and audit systems can change after the questionnaire is filed.
• Ongoing supervision requires per-decision records showing who initiated the request, what data and policy applied, and what outcome occurred.
• If the organization controls the AI request boundary, an identity-bound enforcement layer can produce this evidence; otherwise, the vendor must provide accessible audit records under contract.

Fannie Mae LL-2026-04 holds lenders liable for AI mistakes by subcontractors and vendors. The EU AI Act assigns deployer obligations to organizations using high-risk AI, regardless of whether the AI is built in-house or supplied by a vendor. The NIST AI Risk Management Framework expects ongoing governance over the AI lifecycle, including third-party components. The shared pattern across these regimes is that vendor due diligence at the procurement gate is necessary and insufficient. The deploying organization owns the ongoing supervisory obligation.

A vendor questionnaire built for cloud SaaS does not produce the answers the regulator wants for AI use.

I want to walk through the categories of question an AI-aware procurement gate has to cover, the answers that should live in the diligence file, and the runtime evidence that closes the gap between due diligence and due care.

What the regulator wants to see in the file

The regulator reviewing a vendor diligence file for an AI use case is looking for several specific outcomes. The deploying organization knew what AI the vendor was using. The deploying organization understood what data the AI processed. The deploying organization had a contractual basis for the vendor's audit cooperation. The deploying organization had a plan for what happens when the vendor's AI fails. The deploying organization could produce, on demand, the AI-related records for the use case.

A vendor questionnaire that does not produce those answers leaves the deploying organization exposed.

The question categories an AI-aware questionnaire has to cover

The seven categories below cover what the regulator will ask about, organized by the part of the AI lifecycle they touch.

1. AI inventory at the vendor

The first set of questions surfaces which AI components the vendor uses to deliver the service. Vendors routinely embed LLMs from major providers, run classifier models on top of customer data, or invoke third-party AI APIs as part of the workflow. The deploying organization needs the inventory.

Sample questions in this category:

- List every AI/ML model used to deliver the service, including the model provider and the model version.
- For each model, describe whether the model is hosted by the vendor, by a third-party provider, or by us.
- Identify which models are general-purpose AI (GPAI) under the EU AI Act and which are special-purpose.
- Describe the model lifecycle for changes. Notification window for model updates, retraining cadence, retirement procedure.
- Identify the geographic regions where the models run inference.

The answers go into the file. Changes to the vendor's AI inventory trigger a re-review under the contract.

2. Data flows to and from the AI

The second set covers the data the vendor's AI processes. The deploying organization has to know what its data does inside the vendor's environment.

Sample questions:

- Which categories of our data are sent to the vendor's AI models? PII, PHI, financial data, customer content.
- Are our data used to train or fine-tune vendor models, or models offered to other customers?
- What retention applies to our data after model inference?
- Where is the data stored during inference? Is there a residency commitment?
- Does the vendor share our data with any third party as part of the AI workflow? Identify each.

The answers feed the data protection impact assessment and the Article 12 logging requirement when the deploying organization is the EU AI Act deployer.

3. Identity and authorization at the AI layer

The third set covers who, in the deploying organization, is authorized to invoke the vendor's AI features, and how the vendor enforces it.

Sample questions:

- How does the vendor authenticate users on AI-related endpoints?
- Are AI-related actions tied to specific user identities, or do they run under a service account on our behalf?
- Can we restrict which roles in our organization can invoke specific AI features?
- How are agentic AI features (multi-step tool use, autonomous workflows) authorized?
- What identity context does the vendor send to upstream AI providers? OpenAI, Anthropic, etc.

A vendor whose AI runs under a single service account on the deploying organization's behalf is producing an identity model the regulator will not accept under EU AI Act Article 19 or under Fannie Mae LL-2026-04.

4. Audit posture

The fourth set covers the records the vendor maintains and the records the deploying organization can produce on demand.

Sample questions:

- Describe the audit log shape for AI-related actions. What fields does each record contain?
- Are the records signed for tamper evidence? If not, what integrity guarantees apply?
- What is the retention period for AI-related audit records?
- Can the deploying organization access the records directly, or is access mediated through a support request?
- How long does the vendor take to produce records for a regulatory request? Contractual commitment.
- Does the vendor record system prompt versions, model versions, and policy versions in the audit trail?

A vendor whose audit logs are operational telemetry rather than per-decision evidence will fall short of EU AI Act Article 12 requirements when the deploying organization needs to produce records.

5. Vendor's own due diligence on AI providers

The fifth set covers the AI providers behind the vendor's service. A vendor running OpenAI under the hood inherits the OpenAI commitments around data use, residency, and retention.

Sample questions:

- For each AI provider you embed, attach the relevant contractual commitments (data use, training, residency).
- Describe the vendor's process for evaluating AI provider security incidents.
- What happens if an AI provider has an outage? Failover behavior and impact on our service.
- Does the vendor have a Business Associate Agreement (BAA) with each AI provider where PHI is in scope?
- Has the vendor performed a SOC 2 audit that covers the AI-related controls? Reference the audit report.

6. Compliance with named regimes

The sixth set surfaces the vendor's alignment with the specific regimes that apply to the deploying organization.

Sample questions:

- Is the vendor's AI service subject to EU AI Act high-risk classification? Provide the classification decision.
- Has the vendor produced the Annex IV technical documentation for the AI service?
- For US deployers in financial services, does the vendor support the Fannie Mae LL-2026-04 disclosure requirements?
- Does the vendor support HIPAA-aligned audit trails when PHI is in scope?
- Describe the vendor's approach to Article 14 human oversight.
- Provide the vendor's ISO/IEC 42001 certification status or roadmap.

7. Incident response and termination

The seventh set covers what happens when the AI fails and when the relationship ends.

Sample questions:

- Describe the vendor's incident response process for AI-related incidents.
- What is the contractual notification window for an AI-related incident?
- On contract termination, what happens to our AI-related audit records?
- On contract termination, what happens to data that was used to fine-tune vendor models, if any?
- What is the vendor's exit plan for transitioning the AI service to another provider or to in-house?

Where the questionnaire model breaks

The questionnaire produces a snapshot of the vendor at procurement time. The regulator expects ongoing supervision over the life of the relationship. The gap between the snapshot and the ongoing supervision is the due diligence vs due care distinction.

Vendor due diligence happens once. Due care happens continuously.

The vendor changes its AI inventory after the questionnaire is filed. The vendor's upstream AI provider changes its data use commitments. The vendor's audit log shape changes after a product redesign. None of those changes are captured by an annual re-attestation. The deploying organization needs the runtime evidence that the vendor's AI behavior matches what was attested.

The runtime evidence that closes the gap

The runtime evidence the deploying organization needs is the per-decision record of what the AI did with the deploying organization's data, who initiated each decision, what policy applied, and what the outcome was. The record is the proof that the system operates as the questionnaire said it would.

When the deploying organization controls the AI request boundary, the runtime evidence is produced by the deploying organization's own enforcement layer. When the AI runs entirely inside the vendor's environment, the runtime evidence has to come from the vendor's audit trail, and the contractual commitments in the questionnaire are what make the evidence accessible.

For AI features the deploying organization builds in-house using vendor APIs, the architecture choice is to run an identity-bound enforcement layer at the request boundary, which produces the runtime evidence under the deploying organization's control regardless of which upstream AI provider is in play.

DeepInspect

This is the runtime evidence layer DeepInspect produces for AI features the deploying organization runs. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and the LLM endpoints, enforces identity-bound policy on every request, and produces a per-decision audit record that includes the identity, the policy version, the data classification, the decision outcome, and a tamper-evident signature.

For organizations subject to Fannie Mae LL-2026-04, EU AI Act high-risk obligations, or any sector-specific regime that asks for ongoing supervision over AI use, the DeepInspect record is the due care evidence that complements the due diligence file. The questionnaire describes what should happen. The runtime record shows what did happen.

If you are running vendor AI tools in a regulated environment and your due care depends on annual attestations from the vendor, the regulatory expectation runs ahead of that posture. Book a demo today.