The AI Vendor Security Questionnaire — 47 questions a CAIQ doesn't ask

The Cloud Security Alliance Consensus Assessment Initiative Questionnaire (CAIQ) v4 has 261 questions. The Shared Assessments Standardized Information Gathering (SIG) questionnaire has roughly 1,200. Neither asks about model lineage. Neither asks whether the vendor trains on customer prompts. Neither asks what happens when an autonomous agent the vendor sold you decides to call an API at 3 AM that costs €40,000 before anyone notices.

This questionnaire fills that gap. Forty-seven questions across seven sections, each tied to a specific failure mode the standard procurement questionnaires were not designed to surface. Use it as an addendum to your existing CAIQ or SIG, not a replacement. The base questionnaires still cover the cloud and SaaS layer correctly; this one covers the AI layer those frameworks predate.

Why a separate questionnaire

The CAIQ v4, last updated in October 2024, treats AI as one of many workloads running on a cloud platform. That made sense in 2018. In 2026, “the AI is the workload”: the model, the inference endpoint, the agent runtime, and the tool-use surface are themselves the product. Asking a vendor whether they encrypt data at rest tells you nothing about whether they fine-tune on your prompts. Asking whether they have SOC 2 Type II tells you nothing about whether their agent runtime can be halted within 30 seconds when it goes off the rails.

Three regulatory pressures have converged in the last twelve months that make AI-specific vendor diligence non-optional:

1. EU AI Act Article 11 + Annex IV technical-documentation requirements apply to high-risk AI systems from 2 August 2026. Deployers (your organisation) must hold documentation about model architecture, training data sources, intended use, and known limitations. If the vendor cannot supply this on request, your deployer documentation has a gap.
2. GDPR Article 22 rights against solely-automated decision-making remain enforceable, and supervisory authorities including the Dutch Autoriteit Persoonsgegevens and the Italian Garante have ruled in 2024–2025 that AI-assisted decision systems require explicit deployer documentation of human oversight.
3. NIST AI Risk Management Framework (AI RMF 1.0) Section 4 (“Govern”) and Section 5 (“Map”) explicitly call for “characterisation of AI actors throughout the lifecycle”, including third-party model providers. US federal procurement now references AI RMF in its standard contract clauses.

A vendor that cannot answer the questions in this pack is not necessarily dangerous. They may simply not yet have the documentation discipline that the regulatory frame now expects. Either way, the answers (or absence of answers) let your risk register reflect what you actually know.

How to use this

Send the questionnaire to the vendor before the proof-of-concept, not after. The most expensive moment to discover a vendor cannot tell you what their model was trained on is the week before contract signing.

Score each section binary: answered with evidence, or unanswered. A vendor that supplies plausible prose but no documentation, audit log sample, or contract reference scores as unanswered. The scoring rubric is intentionally strict because the cost of a wrong answer in production is asymmetric.

Vendors that cooperate on this questionnaire ship you back a folder of artifacts: model card excerpts, sample audit logs, contract addendum redlines, kill-switch SLA statements. Keep that folder. It is the evidence trail your auditor (internal or external) will ask for in 2027.

Section 1: Model lineage and provenance (5 questions)

What is being deployed. Most AI vendors in 2026 are wrappers around foundation models from Anthropic, OpenAI, Google, Meta, or Mistral. The question is not whether the wrapper exists; it is whether the vendor will name the underlying model in writing.

1. Name the foundation model(s) underpinning this product, including version numbers. Provide the model card URL.
2. Disclose any fine-tuning, distillation, or post-training applied to the foundation model. Provide the dataset description.
3. State whether the deployed model can change without customer notification, and the SLA window for notification when it does.
4. Provide the model card or equivalent technical documentation conforming to NIST AI RMF Map function 1.1.
5. Confirm whether model outputs are deterministic given identical inputs and parameters, and if not, state the temperature, top-p, and seed defaults.

A vendor that refuses to name the foundation model is hiding a dependency you will inherit. When OpenAI deprecated GPT-4 base in October 2024, every wrapper built on it had to migrate within the deprecation window. If you do not know which foundation model your vendor sits on, you cannot price your own migration risk.

Section 2: Training data and inference data handling (8 questions)

What the model has seen and what it does with what you send it.

1. State whether your model was trained or fine-tuned on data that includes personal information about EU, UK, or California residents. If yes, provide the lawful basis under GDPR Article 6 or CPRA equivalent.
2. Confirm in writing that customer prompts, completions, and tool-use traces from this contract are NOT used to train, fine-tune, evaluate, or improve any model (yours or a third party’s).
3. State the data retention window for prompts, completions, embeddings, and intermediate agent state. Provide deletion-on-request SLA.
4. Disclose every geographic region in which inference data is processed. Confirm EU data stays in EU regions if applicable.
5. Disclose every third-party sub-processor that receives prompt or completion data. Provide the sub-processor list URL and notification SLA for additions.
6. State whether prompt data crosses any jurisdictional boundary that would trigger GDPR Article 44–49 transfer requirements.
7. Confirm whether model providers (Anthropic, OpenAI, etc.) receive customer prompt data under your enterprise contract with them, and the retention applied at that layer.
8. Provide the technical mechanism that enforces non-training of customer data; contract language alone is insufficient.

The eighth question is the one most vendors hate. “We don’t train on your data” in a sales deck is not the same as “our inference path routes customer prompts through a configured no-training endpoint, and we can show you the API parameter that enforces it.” For OpenAI Enterprise and Anthropic Enterprise the parameter exists; for many wrappers, the chain of custody is documented only in marketing copy.

Section 3: Identity, authentication, and authorisation (6 questions)

Who is the agent acting as, and what is it allowed to do. Non-human identity (NHI) is the 2026 procurement category that did not exist in 2024 procurement frameworks.

1. Describe the identity model used by agents this product deploys. Name the protocol (OAuth 2.0 client-credentials, mTLS, SPIFFE, etc.).
2. Confirm that agent identities are distinct from any human user identity and cannot be impersonated through credential reuse.
3. Provide the access-scoping mechanism: how a procurement-team agent is prevented from calling finance APIs.
4. State the agent-credential rotation SLA and the procedure for emergency credential revocation.
5. Disclose every external system this product’s agents will call as part of standard operation (databases, SaaS APIs, MCP servers, internal tools). Provide an inventory.
6. Confirm whether agent-to-agent authentication uses signed tokens or relies on network-position trust.

The fifth question is the one CISOs underestimate. An agentic product that quietly calls fifteen MCP servers as part of “normal operation” expands your authorisation surface by fifteen authenticated paths your existing identity governance program did not know existed.

Section 4: Audit, observability, and explainability (8 questions)

What gets logged, how long it is kept, and whether you can get it out.

1. Provide a sample of the audit log produced for one agent invocation, including prompt, completion, tool calls, and timing.
2. State the audit log retention window and the export format (JSON Lines, OpenTelemetry, CEF).
3. Confirm whether logs include the model version that produced each completion and the parameters used.
4. State whether tool-use calls (functions, MCP tools, retrieval queries) are logged with arguments and results.
5. Provide the SLA for customer-initiated log export, including format and maximum delay.
6. Disclose whether the vendor retains logs after customer deletion, and the basis for any retention.
7. State whether the vendor produces explainability artifacts (decision rationale, retrieval attribution) on request, and the SLA.
8. Confirm whether logs are immutable post-write and the cryptographic basis for that immutability.

A vendor that cannot give you a sample audit log within five business days does not have the observability infrastructure you would assume from their pricing tier. Ask early.

Section 5: Incident response and kill-switch (6 questions)

What happens when the agent does the wrong thing.

1. Define the kill-switch SLA: maximum elapsed time from customer notification to all agents halted.
2. Identify by role every party who can invoke the kill-switch. Confirm at least one customer-side party has authority.
3. Describe the rollback mechanism: how an agent decision (database write, email sent, payment authorised) is reversed when discovered to be in error.
4. Provide the incident-notification SLA for security incidents, model malfunctions, and unintended autonomous actions.
5. Confirm whether the product supports rate-limiting and budget-capping at the agent level, with customer-configurable thresholds.
6. Describe the procedure for preserving forensic state when an incident is detected.

Question one is non-negotiable for any deployment that can move money or modify production data. If the vendor’s kill-switch SLA is “best effort” or measured in hours rather than seconds, you are not buying an enterprise product.

Section 6: EU AI Act, GDPR, and regulatory posture (8 questions)

The compliance documentation you will need on 2 August 2026 and beyond.

1. State whether the vendor classifies this product as a high-risk AI system under EU AI Act Annex III. If yes, provide the risk classification rationale.
2. Provide the EU AI Act conformity assessment artifacts: Annex IV technical documentation, declaration of conformity, CE marking where applicable.
3. Confirm whether the vendor will supply the deployer documentation a customer needs to satisfy Article 26 obligations.
4. Provide the GDPR Data Protection Impact Assessment (DPIA) the vendor has conducted, and confirm cooperation with customer DPIAs under Article 35.
5. Disclose whether the product or any deployment configuration triggers German BetrVG §87(1) point 6 co-determination, Dutch WOR Article 27 consent, French CSE consultation, or equivalent works-council requirements in EU jurisdictions.
6. Provide the named data protection officer (DPO) under GDPR Article 37, with contact information.
7. State the vendor’s position on AI training-data copyright and the indemnification provided to customers if model outputs reproduce copyrighted material.
8. Disclose any pending regulatory enforcement action, supervisory authority investigation, or class-action litigation involving the product or model.

Question five is the one most US-headquartered vendors do not handle out of the box. Works council documentation gaps add 9–12 months to mid-market European deployments when discovered late.

Section 7: Contract, indemnification, and exit (6 questions)

What you can do when the relationship ends or the model fails.

1. Provide the standard MSA + AI-specific addendum + DPA. Identify every clause changed in the last 18 months and the rationale.
2. State the indemnification position on hallucinated outputs that cause customer harm: financial loss, reputational damage, regulatory penalty.
3. Confirm whether the vendor indemnifies the customer against IP infringement claims arising from model outputs.
4. Provide the data-portability mechanism on contract termination: export format, retention window for customer data, deletion certification.
5. State the model-deprecation notice period and the supported migration path when a foundation model the product depends on is sunset.
6. Disclose whether the vendor reserves the right to suspend service for usage patterns it deems problematic, and the appeal mechanism.

Question two divides serious vendors from optimistic ones. The serious vendors have an indemnification position; the optimistic ones have not yet decided what they think.

What to do with the answers

The answered questionnaire is now an artifact in your vendor risk register. Three uses follow from there:

The first use is contract negotiation. Every gap in the answers is a clause you can ask for. “We don’t have audit log immutability” becomes a contract addendum requiring the vendor to provide it within an agreed window. “We can’t commit to a 30-second kill-switch SLA” becomes a deployment scope restriction; this vendor is approved for low-stakes use cases only.

The second use is internal risk classification. The seven sections map cleanly to the NIST AI RMF risk categories and to the EU AI Act high-risk system documentation requirements. A vendor that scores well across all seven can be deployed against high-risk use cases; a vendor that scores well in three out of seven is approved for low-risk use cases only, and the gap analysis becomes the basis for the next vendor review.

The third use is the auditor conversation in 2027. When the EU AI Act enforcement window has been operating for a year and the supervisory authorities have published their first round of enforcement actions, the question your auditor will ask is “what diligence did you do before deployment.” A folder of completed questionnaires, vendor responses, and dated correspondence is the answer.

Versioning and review

This questionnaire is on a 90-day review cycle. Sections will be added when new failure modes emerge from published enforcement actions, breach disclosures, or amendments to the underlying frameworks. Removed sections (rare) will be archived with the rationale.

The current version is v1.0, dated 4 May 2026. Section 6 will be revised after the first wave of EU AI Act enforcement actions in late 2026; current questions are anchored to the 2 August 2026 deployment-obligations milestone and will need updating once enforcement patterns are observable.

Spotted a missing question, or a section that does not stand up against your own procurement experience? The corrections policy applies.