AI Vendor Due Diligence Questionnaire: What to Ask Before You Buy
AI vendor due diligence happens at the procurement gate, runs against a standard questionnaire, and produces an attestation file. The questionnaire most teams inherited from cloud SaaS vendors does not cover the questions a regulator will actually ask about AI use. The Fannie Mae LL-2026-04 framework, the EU AI Act, and the NIST AI RMF all expect ongoing due care, not one-time due diligence. This piece walks through the question categories an AI-aware procurement gate has to cover, the answers that have to live in the file, and the runtime evidence that closes the gap between due diligence and due care.
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:
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:
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:
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:
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:
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:
7. Incident response and termination
The seventh set covers what happens when the AI fails and when the relationship ends.
Sample questions:
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.
Frequently asked questions
- Is the vendor's SOC 2 report enough for AI due diligence?
A SOC 2 report covers the controls the auditor tested at the time of the audit. The report is useful as a baseline. It does not cover the AI-specific questions in the categories above, and it does not produce ongoing evidence between audits. The deploying organization can use the SOC 2 report as one input to the diligence file, but the questionnaire and the runtime evidence are still required.
- How often should the questionnaire be re-run?
The minimum is annual. The practical cadence is event-driven. Major changes to the vendor's AI inventory, an upstream AI provider change, a new regulatory regime taking effect, a security incident in the vendor's environment, or a material change in the deploying organization's AI use all warrant a re-review. The contractual commitment in the questionnaire should require the vendor to notify on these events.
- What happens when a vendor refuses to answer specific questions?
The refusal is itself evidence. The deploying organization records the refusal in the file and assesses whether the gap can be accepted, mitigated through alternative controls, or treated as a deal-breaker. For high-risk AI use cases, the gaps that the deploying organization cannot mitigate through its own controls usually require selecting a different vendor or building the capability in-house.
- Does the deploying organization need separate questionnaires for general-purpose and high-risk AI?
The shape of the questions is similar. The depth required differs. A general-purpose AI used in a non-regulated workflow can be evaluated against a smaller subset of the categories. A high-risk AI used in an in-scope workflow requires the full set, with the answers feeding the Annex IV technical documentation under EU AI Act Article 11 and the corresponding artifacts under adjacent regimes.
- How does this affect open-source AI models the vendor self-hosts?
A vendor self-hosting an open-source model still has all the data flow, audit, identity, and incident response obligations. The model provider questions shift from "which third-party AI provider" to "which open-source model and how the vendor maintains it." The rest of the questionnaire remains the same. The deploying organization is still responsible for understanding what the AI is, what data it touches, and what the audit posture is.