Vendor AI Questionnaire Template: 40 Questions to Ask Every AI Supplier

Last updated: September 17, 2026

A vendor AI questionnaire is a structured set of questions you send to any supplier whose product uses, embeds, or is built on artificial intelligence, so you can understand what the AI does with your data, how it is governed, and what risk it introduces before you sign or renew. The full questionnaire below is free to copy, needs no form to access, and is organized to produce the evidence ISO 42001 expects for supplier relationships (Annex A controls A.10.2 and A.10.3), the third-party risk practices in the NIST AI RMF (GOVERN 6), and the information a deployer needs to meet its own obligations under the EU AI Act. Send it alongside, not instead of, your standard security questionnaire.

This questionnaire is part of our AI governance guide. It pairs with the AI risk assessment template: the vendor’s answers feed the third-party dependency and data rows of your own assessment for that system.

Key takeaways

• Standard security questionnaires (SIG, CAIQ, your own SOC 2 checklist) do not ask whether your data trains the vendor’s model, whether outputs are logged, or who is the provider versus the deployer under the EU AI Act. This questionnaire fills that gap.
• Tier your vendors. A full 40-question review is proportionate for a vendor whose AI touches customer data or makes decisions about people; a 10-question short form is enough for an AI feature inside a low-risk SaaS tool.
• The most important answers are about data: training use, retention, sub-processors, and the ability to opt out. Get those in the contract, not just the questionnaire.
• Ask for artifacts, not assurances. Model cards, system cards, evaluation results, and certification reports are evidence. “We take AI safety seriously” is not.
• Re-issue the questionnaire on model changes and at renewal. AI vendors change models, terms, and sub-processors far more often than traditional SaaS vendors.

Why do you need an AI-specific vendor questionnaire?

Most organizations already run third-party risk management for security and privacy. AI adds questions those programs never asked. Will the vendor use your prompts and documents to train or fine-tune models that serve other customers? Does the product silently call a foundation model provider as a sub-processor? Has anyone tested the feature for biased outputs in your use case? Who is accountable when a generated answer is wrong and a customer acts on it? Under the EU AI Act, a vendor supplying a high-risk system is the provider, but you, as the deployer, carry your own obligations under Article 26 and need the vendor’s instructions for use, logging capability, and oversight design to meet them. Under ISO 42001, control A.10.3 requires a process to ensure suppliers’ AI practices align with your own AI policy, which is impossible without asking.

The questionnaire below is written for the buyer. Everything in brackets is a placeholder or instruction. Send it as a shared document or load it into your vendor risk tool, and score the returned answers with the rubric in the section after the template.

Vendor AI questionnaire template

Part A: Vendor and product overview (all vendors)

1. Product name, version, and a plain-language description of every feature that uses AI or machine learning.
2. Is AI core to the product’s function, or an optional feature that can be disabled? If optional, how is it disabled, and at what level (tenant, user, feature)?
3. Which models power these features? For each: model name and version, whether developed in-house, fine-tuned from a third-party foundation model, or called via API from a third-party provider (name the provider).
4. Who at your company is accountable for AI governance? Provide the role and the reporting line.
5. Do you maintain an AI system inventory and a documented AI policy? Provide the policy or a summary.
6. Which of the following do you hold or are pursuing: ISO/IEC 42001 certification, ISO/IEC 27001, SOC 2 Type II (with AI features in scope), other. Provide reports or certificates.

Part B: Data handling and training (all vendors)

7. Is any customer data (prompts, uploaded content, outputs, metadata, usage patterns) used to train, fine-tune, evaluate, or improve any model? If yes, which data, which model, and is it opt-in or opt-out by default?
8. Can we contractually prohibit training on our data? Provide the contract language or DPA clause.
9. Where is customer data processed and stored for AI features, and does it leave the primary hosting region?
10. List every sub-processor involved in AI features, including foundation model providers, and their locations. How are we notified of changes?
11. What is the retention period for prompts, inputs, outputs, and logs? Can it be configured to zero?
12. Is customer data segregated between tenants at the model level (for example, no shared fine-tuning, no cross-tenant retrieval)?
13. Are inputs or outputs ever reviewed by humans at your company or a sub-processor? Under what circumstances, and with what access controls?
14. What personal data categories can the AI features process, and do you support data subject requests (access, deletion) for data held in AI logs or vector stores?

Part C: Model governance and performance (medium and high tier)

15. Provide a model card or system card for each model, covering intended use, limitations, training data summary, and known failure modes.
16. What evaluations have you run for accuracy, robustness, and hallucination rate, and what are the results for use cases similar to ours?
17. Have you tested for bias or disparate performance across demographic groups? Provide the method, groups tested, metrics, and findings.
18. How are model updates handled? Are customers notified before a model version changes, can we pin a version, and what is the rollback path?
19. How do you monitor model performance and drift in production, and what triggers a retrain or rollback?
20. What content filtering, output moderation, or guardrails are applied, and can we configure them?
21. Describe the human oversight the product supports: can users see when output is AI-generated, override it, and provide feedback that is acted upon?
22. What explainability features exist? Can a user or auditor see why an output or recommendation was produced?

Part D: Security (medium and high tier)

23. How do you defend against prompt injection, jailbreaks, and data exfiltration through the model, including indirect injection via documents or web content?
24. Are AI features covered by your penetration testing and red-teaming program? Provide the date and scope of the last AI-specific test.
25. How is access to models, training pipelines, and fine-tuning data controlled and logged internally?
26. Do AI features have access to tools, plugins, or external systems (agentic capability)? If so, what actions can they take, and how are permissions scoped?
27. How are secrets, API keys, and customer credentials protected from appearing in prompts, logs, or outputs?
28. Describe your process for AI-specific incidents (harmful output, data leak via model, model compromise) and customer notification timelines.

Part E: Regulatory and legal (medium and high tier)

29. Under the EU AI Act, do you classify any product feature as high-risk (Annex I or Annex III), subject to Article 50 transparency, or as a general-purpose AI model? State the classification and your reasoning.
30. If any feature is high-risk, what is your conformity assessment plan and timeline ahead of the applicable dates (2 December 2027 for Annex III, 2 August 2028 for Annex I embedded systems, following the Digital Omnibus on AI)?
31. What documentation will you provide to support our deployer obligations (instructions for use, logging capability, oversight design, technical documentation)?
32. Do you offer IP indemnification for AI-generated output? What are the conditions and exclusions?
33. What are the licensing terms and provenance for training data? Have you received any copyright or data protection complaints related to the models?
34. Which other AI regulations or frameworks do you align to (NIST AI RMF, Colorado AI Act, state or sector rules, UK or Canadian guidance)? Provide mappings if available.
35. Will you notify us of material changes to AI features, models, terms, or sub-processors, and with how much notice?

Part F: Contractual commitments (high tier)

36. Will you commit in the contract to: no training on customer data, defined retention, sub-processor notification, version pinning, and AI incident notification within [24 or 72] hours?
37. What service levels apply to AI features (availability, latency, accuracy thresholds if any), and what are the remedies?
38. What is the exit plan: can we export prompts, outputs, fine-tuned weights, or embeddings, and what is deleted on termination?
39. Do you allow customer audits or provide third-party audit reports covering AI features?
40. Provide a named contact for AI governance questions and incident escalation.

Short form (low tier, 10 questions)

For low-risk tools where AI is a minor feature, use questions 1, 2, 3, 7, 8, 10, 11, 18, 28, and 35. If any answer to 7, 8, or 10 is unsatisfactory, escalate to the medium tier.

How do you tier vendors and score the answers?

Score each answer as acceptable, acceptable with conditions, or unacceptable. Any unacceptable answer in Part B (data) or question 29 (classification) blocks approval until resolved in the contract. Conditions become tracked actions with a due date. Record the final decision, the tier, and the reviewer in your AI system inventory entry for the vendor’s product, so the next reviewer can see what was accepted and why.

What should you do with the answers?

Three things. First, transfer the material commitments into the contract or DPA. A questionnaire answer is a representation; a contract clause is enforceable. Training prohibition, retention, sub-processor notice, and incident notification are the four that most often exist only in the questionnaire. Second, carry the vendor’s disclosed limitations into your own risk assessment for the system. If the vendor says the model was not evaluated for your language or domain, that is an accuracy risk you own. Third, set a reassessment trigger. Most AI vendors now push model updates quarterly or faster, and a vendor whose SOC 2 report did not include AI features in scope last year may have added them since.

One more point on roles. Under the EU AI Act, buying a high-risk system does not make you the provider, but substantially modifying it, rebranding it, or changing its intended purpose can. Question 29 and your own scoping analysis should agree on who holds which role before deployment, and the EU AI Act compliance overview explains the deployer duties that follow.

Frequently asked questions

Should this replace our existing security questionnaire?

No. Send it in addition. The SIG, CAIQ, and similar instruments cover infrastructure, access control, and business continuity well. This questionnaire covers what they omit: training use of data, model governance, AI-specific attacks, and AI regulatory classification.

What if the vendor refuses to answer or gives generic responses?

Treat refusal on Part B questions as an unacceptable answer. A vendor that cannot say whether it trains on your data either does not know or does not want to say, and both are findings. For generic answers, ask for the artifact behind the claim: the model card, the test report, the DPA clause.

Do we need this for AI features inside tools we already use, like a CRM or office suite?

Yes, at least the short form, and often the medium tier. Embedded AI features in existing tools are the most common source of ungoverned data flows because they arrive through product updates rather than procurement.

How does this relate to ISO 42001?

Annex A control A.10.2 requires allocating responsibilities between you and third parties, and A.10.3 requires a process to ensure supplier AI practices align with your policy. The completed questionnaire, the tiering decision, and the contract clauses are the evidence an auditor will ask for.

Who should own the vendor AI review?

The same third-party risk function that owns security reviews, with input from the AI governance lead on Parts C and E and from legal on Parts E and F. Splitting AI vendor review into a separate process creates gaps and duplicate work.

How often should we re-send it?

At renewal, and whenever the vendor announces a new model, a new AI feature, or a sub-processor change. Question 35 exists so the vendor commits to telling you.

Making vendor AI review repeatable

The questionnaire is the easy part. The hard part is running it consistently across dozens of vendors, tracking the conditions you attached, and proving to an ISO 42001 auditor that supplier AI practices are aligned with your policy. Compyl manages vendor AI questionnaires alongside your security reviews, links each vendor to the AI systems it powers in your inventory, tracks conditions as tasks with owners and due dates, and maps the evidence to ISO 42001, the NIST AI RMF, and the EU AI Act. Request a demo to see the full third-party AI risk workflow.