Standard vendor questionnaires miss eight AI-specific questions - on model providers, prompt logging, inference location, and fine-tuning carve-outs, that matter more than most of what they do ask. Closing those gaps is the starting point of any credible AI governance programme for third-party tools.
Your vendor sent back a SIG questionnaire and ticked all the boxes. The questionnaire didn't ask where their model runs, what data they retain from your prompts, who their upstream model provider is, or whether your prompts may have entered a fine-tuning run last quarter. The questions that matter most for AI vendors are not in the questionnaire.
This piece is the gap audit. What standard questionnaires cover well, what they miss when the vendor is an AI vendor, and a follow-up template for the high-risk subset of vendors that warrant deeper assessment.
What Standard Questionnaires Cover Well
The category exists for good reasons. The Standardised Information Gathering questionnaire, the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire, and the ENISA-aligned vendor assessment frameworks have each evolved through years of practitioner contribution and they remain the right starting point for vendor risk assessment.
What they cover well: information security management system maturity (ISO 27001 alignment, certification status); security operations basics (incident response, vulnerability management, access controls, encryption at rest and in transit); business continuity and disaster recovery; physical security where relevant; personnel security including background checks; sub-processor identification at the contractually disclosed level; data residency at the contractually committed level. For non-AI vendors, these cover the substantial majority of the risk surface.
Both SIG and CAIQ have added AI-specific modules over the last two years. The depth varies, and many firms are still operating against versions of the base questionnaire that predate those additions. The gap that this piece addresses is most acute for firms running older questionnaire versions, and present but smaller for firms running the current AI compliance-aware editions.
Eight AI-Specific Gaps
Each gap describes a question that the standard frameworks either do not ask, ask too generically to be useful, or ask in a way that lets the vendor answer truthfully without disclosing what matters.
Model providers. Where does the vendor's AI capability come from? OpenAI, Anthropic, Google, an open-weight model deployed on the vendor's own infrastructure, a fine-tune of an open model, or a proprietary model? Each answer has different risk implications. The standard frameworks ask about sub-processors but rarely require model provider identification specifically, and vendors that wrap a foundation model rarely volunteer it unprompted.
Training data. What was the vendor's model trained on? For foundation-model wrappers, this question collapses to the foundation model provider's training data position. For vendors with fine-tuned or proprietary models, it is the central provenance question. The standard frameworks do not ask. The reasonable expectation in 2026 is that any high-risk AI vendor can describe their training data lineage in operationally useful terms.
Prompt logging. What does the vendor retain from your prompts? The default behaviour varies materially across providers, some retain prompts for thirty days for abuse monitoring with explicit non-training use; others retain longer; some retain for model improvement absent specific opt-out. The standard frameworks do not differentiate.
The prompt logging question is the one that separates vendors who have thought carefully about their AI data handling from vendors who have not. Ask a vendor where their model runs, and most have a prepared answer. But when you ask them what they retain from your prompts, the room goes quiet. Some answer correctly and specifically: retention period, purpose, and opt-out mechanism. Some say they need to check with engineering. The third group answers confidently but describes their storage policy instead of their prompt retention policy. Those are two different things. The vendors that confuse the two have clearly not considered what happens to client data from prompt submission to output generation. That gap in their thinking is the gap that will appear in your risk assessment. - Ankur Arora, CEO & Co-Founder, Montro |
Data residency for inference. Where does the inference run, geographically? Most vendors disclose data residency at the contractual level, "data is processed in the EU." Few disclose where inference specifically runs, which is often a subset of the broader processing infrastructure. For EU residency commitments to be meaningful in AI contexts, the inference itself has to run in the EU; vendors that route prompts to non-EU inference regions while claiming EU residency are not lying, but the residency commitment is not what the customer thought it was.
Output retention. What does the vendor retain from the AI-generated outputs? This is distinct from prompt retention and often less well documented. Some vendors retain outputs for support and debugging purposes; some retain them indefinitely; some retain them for model improvement under various opt-out structures. The standard frameworks rarely ask.
Fine-tuning carve-outs. Are the customer's prompts excluded from any model improvement work the vendor performs? The default position varies, and the contractual language varies further. The relevant follow-up question, beyond the contractual language, is whether the technical implementation enforces the contractual carve-out, and whether the vendor would notice if the carve-out failed.
Sub-processor visibility down the chain. The standard frameworks ask about direct sub-processors. AI vendors typically have sub-processors that are themselves AI providers, and those upstream providers have their own sub-processor lineage. The fourth-party visibility, knowing not only your direct vendor's sub-processors but their critical providers, is where DORA enforcement is moving, where enterprise risk management for AI vendors is heading, and where the standard frameworks remain shallow. Model versioning. What model version is the vendor running, and how do they communicate version changes? AI capability is not stable across model versions. The vendor that switches from one foundation model to another, or upgrades a fine-tune, can materially change the system's behaviour without any contractual amendment. The standard frameworks do not ask. The reasonable expectation is a version-change notification cadence and the vendor's regression-testing position.
When You Need a Follow-Up Assessment
The full eight-question follow-up is overhead. The triage that scopes when it is warranted:
Vendors processing personal data through AI features that produce decisions about natural persons - recruiting AI, customer-decisioning AI, fraud and KYC AI, credit scoring AI. The eight follow-up questions all apply.
Vendors processing material volumes of unstructured customer or employee data - productivity AI, customer support AI, communication AI. Most of the eight apply, with output retention and prompt logging the priority items.
Vendors providing AI capability to engineering or product teams - code generation, devtools AI, analytics AI. The model versioning and sub-processor visibility questions matter most because these vendors often integrate deeply into engineering workflows where regression matters.
Vendors with any AI surface where the data input includes special category data - health data, biometric data, identification documents. All eight questions apply, with training-data and output retention as gating items.
For vendors in scope of any of these triggers, the eight-question follow-up is part of the third-party risk assessment, not optional. For vendors outside, the standard questionnaire is generally sufficient. The triage itself is an act of AI governance, knowing which vendors warrant deeper scrutiny and why.
The DORA and NIS2 Cross-Reference
For financial entities, the eight-question follow-up is increasingly the operational expression of Article 28 DORA third-party risk obligations and the criticality assessment under Commission Delegated Regulation (EU) 2024/1502. The supervisor's reasonable expectation is that the firm's third-party assessment for AI vendors is materially deeper than for non-AI ICT services, and that depth is what security governance looks like in practice for AI vendor relationships under DORA.
For non-financial NIS2 in-scope entities, the same logic applies through Article 21(2)(d). The supply chain risk-management measure obligation is the operational hook. The eight-question follow-up is one defensible expression of what discharging that obligation looks like for AI vendors specifically, and the firm that has documented its approach has a stronger AI compliance position than the firm that has not.
Frequently Asked Questions
What is a SIG questionnaire and does it cover AI vendors adequately?
The Standardised Information Gathering questionnaire is a widely used vendor risk assessment framework covering security management, operations, continuity, and sub-processor identification. Both SIG and the Cloud Security Alliance's CAIQ have added AI-specific modules over the last two years, but many firms are still running older versions that predate those additions, and the depth of AI coverage in current editions varies materially by vendor type.
What is fourth-party visibility and why does it matter for AI vendor risk?
Fourth-party visibility means knowing not just your direct vendor's sub-processors but the critical providers those sub-processors depend on. AI vendors typically wrap foundation models from OpenAI, Anthropic, or Google - each with their own sub-processor lineage. Standard questionnaires stop at the direct sub-processor level; the upstream model provider chain is where the material risk often sits, and closing that gap is where enterprise risk management for AI vendors diverges most sharply from standard third-party risk practice.
Can a vendor claim EU data residency while running inference outside the EU?
Yes, and it happens more than most firms realise. Vendors disclose data residency at the contractual level, which typically covers storage. Where inference specifically runs is often a subset of the broader infrastructure and is rarely disclosed unless explicitly asked. For EU residency commitments to be meaningful for AI processing, the inference location needs to be confirmed separately.
What should a fine-tuning carve-out clause actually say?
At minimum it should state that the customer's prompts and outputs are excluded from any model training or improvement work the vendor performs, that the technical implementation enforces this exclusion, and that the vendor will notify the customer if the exclusion fails or changes. The contractual language alone is insufficient, the follow-up question is whether the vendor's architecture actually enforces the carve-out.
