An AI vendor risk questionnaire is the set of structured questions a procurement or governance team uses to evaluate an AI vendor's data handling, model provenance, security posture, and regulatory compliance before contract signature. It exists because standard IT vendor questionnaires do not ask about training data, model behavior, or algorithmic accountability, and those gaps are exactly where AI-specific risk lives.

Most procurement teams already run a vendor risk questionnaire for software purchases. The mistake is reusing that same document for an AI vendor and assuming it covers the ground. It does not. A generic security questionnaire asks about encryption at rest and SOC 2 status. It does not ask whether the vendor's model was trained on your data, whether that model is shared across customers, or what happens when the model produces an output that harms someone. Those are the questions that separate a compliant AI vendor from a risky one, and they require a different instrument.

Why Standard Vendor Questionnaires Fail for AI Procurement

Traditional vendor risk questionnaires were built for a world where software behaved deterministically: same input, same output, every time. AI systems, particularly those built on large language models, do not behave that way. Outputs vary, models get retrained or swapped without notice, and the vendor's own supply chain often includes a third-party foundation model provider the vendor does not fully control.

This means a vendor can pass a standard SIG (Standardized Information Gathering) or CAIQ (Consensus Assessments Initiative Questionnaire) assessment and still expose you to model drift, training-data contamination, or an inability to explain a decision to a regulator. The questionnaire has to be extended, not replaced, with questions specific to how the AI component was built, trained, and governed.

What Makes AI Vendor Risk Different From Software Vendor Risk

Three characteristics separate AI vendor risk from conventional software risk, and each maps to a category of questions below.

First, data used to train or fine-tune a model can persist inside that model indefinitely, in ways that are difficult to audit or delete. A software vendor breach exposes stored data. An AI vendor breach, or an AI vendor with poor data hygiene, can mean your data influenced a model that other customers now query.

Second, model behavior is probabilistic and can change without a version bump. A vendor updating an underlying foundation model can silently change your output quality, bias profile, or compliance posture.

Third, accountability for an AI system's decision is harder to trace than for a rules-based system. When a loan is denied or a resume is filtered, procurement needs to know who is accountable for that output: the vendor, the model provider, or the deploying organization.

What Should an AI Vendor Risk Questionnaire Cover?

An effective questionnaire is organized into four categories: data handling, model provenance, security, and compliance. Each category answers a different question about where risk sits in the vendor relationship.

Data handling questions establish what happens to your data once it touches the vendor's system. Model provenance questions establish what the model was built from and how it is maintained. Security questions establish whether the vendor's infrastructure and access controls meet a baseline you can defend to an auditor. Compliance questions establish whether the vendor can support your obligations under frameworks like the EU AI Act, ISO/IEC 42001, or sector-specific regulation.

Below is a working set of questions in each category. These are the questions a governance team should expect a vendor to answer in writing, with evidence, not verbally in a sales call.

Data Handling Questions

  • Is our data used to train, fine-tune, or improve your models, and can this be contractually excluded?
  • Where is our data stored geographically, and does this location change based on load balancing or failover?
  • What is the data retention period for inputs, outputs, and logs, and can we set a shorter retention window?
  • Can our data be permanently deleted on request, including from backups and any derived training sets?
  • Is our data ever used to train models shared with other customers, or is model output customer-isolated?
  • What data does the vendor collect about our end users, and is that collection disclosed to those users?
  • Does the vendor use subprocessors for data storage or processing, and is there a current subprocessor list?
  • What encryption standard is applied to data in transit and at rest, and who holds the encryption keys?

Model Provenance Questions

  • What foundation model or models underlie this product, and who developed them?
  • What data sources were used to train or fine-tune the model, and were they licensed or consented for this use?
  • How frequently is the model retrained or updated, and how are customers notified before a material change?
  • Has the model been evaluated for bias across protected characteristics, and can we see that evaluation?
  • What is the model's documented accuracy or error rate for the specific use case we are procuring it for?
  • Can the vendor explain, in terms a non-technical reviewer can follow, how the model reaches an output?
  • Does the vendor maintain version control and rollback capability if a model update degrades performance?
  • Is there a human review step before high-stakes outputs are finalized, or is the system fully automated?

Security Questions

  • What third-party security certifications does the vendor hold, and can current audit reports be provided?
  • Has the vendor undergone a penetration test in the last twelve months, and can findings be summarized?
  • What access controls govern who inside the vendor organization can view customer data or model logs?
  • Is prompt input logged, and if so, who can access those logs and for how long are they retained?
  • What is the vendor's incident response process, and what is the contractual notification window for a breach?
  • Are API keys and credentials rotated on a defined schedule, and is multi-factor authentication enforced internally?
  • Has the vendor tested the system against prompt injection or data exfiltration attempts specific to AI interfaces?
  • What isolation exists between customer environments in a multi-tenant deployment?

Compliance Questions

  • Which jurisdictions' AI regulations does the vendor consider this product to be governed by?
  • Does the vendor's product fall into a risk tier under the EU AI Act, and what obligations follow from that tier?
  • Is the vendor certified or working toward certification under ISO/IEC 42001 or an equivalent AI management standard?
  • Can the vendor provide documentation suitable for our own algorithmic impact assessment?
  • Who is contractually liable if the AI system's output causes harm or a compliance failure downstream?
  • Does the vendor support audit requests from regulators or from our own internal audit function?
  • Is there a documented process for handling a request to explain or contest an automated decision?
  • Does the contract include the right to audit the vendor's AI-specific controls, not just general security controls?

How Should Procurement Teams Score and Weight These Answers?

Not every question carries equal weight, and scoring should reflect the use case. A vendor supplying a low-stakes internal writing assistant does not need the same scrutiny as a vendor supplying a model that screens job candidates or flags financial transactions. Procurement teams that apply one fixed threshold across every AI purchase either over-scrutinize low-risk tools or under-scrutinize high-risk ones.

A defensible approach ties the weighting to the impact of a wrong or biased output. Map each vendor to a risk tier before the questionnaire goes out, using criteria such as whether the system makes or materially influences a decision about a person, whether it processes regulated data categories, and whether its output is disclosed externally. Higher tiers should require documentary evidence for every answer, not a checkbox. Lower tiers can rely on vendor attestation with spot verification.

Who Should Own This Questionnaire Inside the Organization?

Procurement rarely has the technical background to evaluate a model provenance answer, and IT security rarely has the regulatory context to evaluate a compliance answer. The questionnaire works best when it is jointly owned: procurement runs the process and tracks vendor responses, a technical reviewer validates the model and security answers, and a governance or legal reviewer validates the compliance answers against the organization's actual regulatory exposure.

This is also where a documented AI governance role earns its place. Someone in the organization needs standing authority to reject a vendor on AI-specific grounds even when that vendor passes conventional procurement checks, and to translate a vendor's technical answers into a decision the business can stand behind.

How Should Vendor Answers Be Verified, Not Just Collected?

A questionnaire is only as strong as the verification behind it. Vendors answer procurement questionnaires routinely, and the incentive is to answer in the way that closes the deal, not the way that best describes the actual system. Treat every answer as a claim to be tested, not a fact to be filed.

Ask for evidence with a defined format and date. A SOC 2 Type II report from two years ago tells you little about current controls. A bias evaluation the vendor summarizes verbally but will not put in writing is not evidence. Where a vendor claims a certification is in progress rather than complete, get a target date in writing and revisit it at renewal, not just at initial signature.

Cross-check vendor claims against independent sources where they exist. A vendor's own description of its subprocessor list should be checked against its published data processing addendum. A vendor's claim about which foundation model underlies its product should be checked against that foundation model provider's own documented usage terms, because sub-licensing restrictions sometimes conflict with what the reselling vendor has promised.

Build a re-verification cadence into the contract rather than treating the questionnaire as a one-time gate. Models change, subprocessors change, and a vendor's compliance posture at signature is not a guarantee of its posture eighteen months later. An annual refresh of the highest-risk questions, tied to contract renewal, keeps the assessment current without creating a full re-procurement cycle every year.

What Happens When a Vendor Cannot Answer a Question?

An incomplete or evasive answer is itself a data point. A vendor that cannot say where your data is stored, or that answers a model provenance question with marketing language instead of specifics, is telling you something about its own internal governance maturity. Organizations with mature AI governance can usually answer these questions quickly because the information already exists internally for their own compliance purposes. A vendor assembling the answer for the first time in response to your questionnaire is a vendor still building that internal discipline.

This does not automatically disqualify a vendor, particularly in a market where AI-specific governance maturity is still uneven across providers. It does mean the gap should be named explicitly in the risk assessment, assigned an owner, and tracked with a remediation date rather than waived silently because the rest of the proposal was strong.

Key Takeaways

  • A generic vendor security questionnaire does not surface AI-specific risk. It has to be extended with data handling, model provenance, security, and compliance questions specific to how the model was built and maintained.
  • Model provenance, not just data security, is the category most procurement teams under-question. Ask what the model was trained on, how often it changes, and whether that change is disclosed before it happens.
  • Weight the questionnaire to the use case. A vendor influencing a decision about a person warrants documentary evidence for every answer; a low-stakes internal tool can rely on attestation.
  • Contractual rights matter as much as the answers themselves: the right to audit, the right to exclude your data from training, and a defined breach notification window should all be in the agreement, not just the questionnaire.
  • Ownership of the vendor risk process should be shared across procurement, technical review, and governance, because no single function has the full picture an AI vendor decision requires.

Professionals building or running this kind of vendor evaluation process inside their organization can formalize that capability through AICA's Certified AI Governance Professional (CAIGP) credential, which covers AI policy implementation, model risk documentation and impact assessments, regulatory mapping and compliance workflows, AI inventory and lifecycle controls, audit preparation and evidence management, and incident response for AI systems.