The pattern is always the same and it is worth describing precisely, because most sales leaders misread it.
The deal is progressing. Commercials are agreed in principle. The buyer's security team requests a vendor assessment. Your team completes it, including a new AI section that nobody had seen before, and sends it back with a covering note offering to answer any questions. Then nothing. Two weeks pass. The champion says security is still reviewing. Four weeks pass. The champion goes quiet, then reappears with a follow-up list. Six weeks pass and the deal has slipped a quarter.
Nobody rejected you. Deals in this position do not get rejected, they stall, and the buyer's security function has no obligation and no incentive to tell you that it has stopped. From the inside it looks like slow progress. From the buyer's side, your response went into a pile marked insufficient and it will stay there until someone senior enough asks why.
The AI domain is now the most common place this happens.
The instruments
Three families of assessment carry AI content and it helps to know which one you are looking at.
Cloud Security Alliance AI-CAIQ. The Consensus Assessments Initiative Questionnaire is the long-standing CSA instrument for cloud vendor self-assessment, structured against the Cloud Controls Matrix. The AI extension of that work brings the total control objective set to 247 across 18 domains, adding AI-specific coverage on top of the existing cloud security control families. If a buyer sends you a CAIQ with AI content, they are working from a structured control framework and they will expect answers at control level, not narrative.
Shared Assessments SIG. The Standardised Information Gathering questionnaire is the instrument most common in financial services and large regulated enterprises, and it is scoped by the buyer rather than fixed. The 2026 iteration carries a dedicated AI domain, and Shared Assessments has mapped that content to ISO 42001. That mapping is practically useful: it means an organisation with an operating AI management system can trace SIG AI questions back to management system evidence rather than answering each from scratch.
Sector and buyer-specific instruments. Large enterprises increasingly append their own AI addendum to whichever base instrument they use, and some publish supplier requirements directly. Microsoft's Supplier Data Protection Requirements is the clearest current example of a buyer stating its AI expectation in contract terms rather than in a questionnaire.
The important point is that these instruments converge. The wording differs. The underlying six questions do not.
The question categories
Training data. What data was the model trained on, where did it come from, on what lawful basis, does it contain personal data, does it contain the buyer's data or the buyer's customers' data, and can you evidence provenance. For organisations building on third-party models, this becomes a question about what your model provider discloses and what you can contractually rely on.
Model documentation. What model, what version, produced by whom, intended for what, and known to be unsuitable for what. Buyers are increasingly explicit that they want the limitations section, and a document without one reads as marketing.
Human oversight. Where is the human, what do they see, what authority do they have to override, and what stops them rubber-stamping. That last part is the one that separates a serious answer from a box tick. A buyer in a regulated sector knows that automation bias is the failure mode and will ask what you do about it.
Incident response for AI. What counts as an AI incident in your organisation, how is it detected, who is notified, and would the buyer hear about it. Model degradation and harmful output are not security incidents and your existing security runbook does not cover them.
Third-party model governance. Which providers, under what terms, with what notice of behavioural change, and what happens if the provider deprecates a version you depend on. This category has grown fastest, because buyers have worked out that their AI supply chain runs through your AI supply chain.
Accountability. A named role that owns AI risk, an escalation path, and evidence that it is exercised rather than nominal.
What a good answer looks like, and what most vendors send
Most vendors send one of three things, and all three fail in the same way.
The first is the certificate. ISO 27001, sometimes ISO 42001, attached with a note saying we are certified. A certificate demonstrates that a management system was audited. It does not answer what the model was trained on.
The second is the policy. A twelve-page responsible AI policy full of principles about fairness, transparency and human-centred design. Buyers do not read these. A policy states intention. The question asks for outcome.
The third is the confident one-liner. "We do not use customer data for training." That is the right answer if it is true and complete. It is usually neither, because logging retains prompts, or a sub-processor's terms permit improvement use, or the statement is true for the production model and not for the evaluation pipeline. A buyer who finds the qualification later treats everything else you said as suspect.
A good answer has four properties. It is specific, naming the model, the version, the data, the retention period. It is evidenced, pointing to an artefact the buyer can read rather than asserting a state of affairs. It states limits honestly, including what you cannot verify about a third-party model. And it is consistent with every other answer in the pack, which sounds trivial and is the most common failure in questionnaires answered by three people in a hurry.
The honest answer outperforms the confident one, reliably. The person reading it has seen dozens. They are not looking for perfection, they are looking for a supplier who understands their own system well enough to describe its edges.
The artefacts that answer the substance
You cannot answer the substance from a policy library. You answer it from a small set of artefacts, each of which is written once and referenced repeatedly.
A model card or system description for each customer-facing AI system: purpose, model and version, inputs and outputs, intended use, out-of-scope use, known limitations, and performance characteristics.
A training data and provenance statement, covering what you train or fine-tune yourself and what your model providers disclose about theirs, with the gaps named rather than glossed.
A data flow description for the AI path specifically, tracing what happens to an input from submission to deletion, including logging, retention, jurisdiction, and any sub-processor involvement.
A stated training position in one unambiguous paragraph, covering production, evaluation, and logging, and any opt-out available.
Testing and evaluation evidence: what was tested, on what, with what result, and what changed as a result. Where subgroup or bias testing is relevant to your domain, this is the artefact buyers weight most heavily.
A human oversight description: the role, the information the human receives, the override authority, and the controls against automation bias.
An AI incident procedure distinct from the security incident procedure, with detection, triage, notification and customer communication defined.
An accountability statement: the named role, the governance forum it reports into, and the cadence.
Eight artefacts. Between them they answer the substance of every AI domain I have seen, in whichever instrument it arrives.
Why answering once is the only sustainable approach
Organisations that treat each questionnaire as a discrete task pay for the same work repeatedly and get worse at it each time.
The costs compound in three ways. There is the direct effort, which typically consumes senior engineering and legal time rather than junior time, because nobody else can answer the questions. There is the inconsistency risk, where the answer given to buyer A in March contradicts the answer given to buyer B in July, and one of them notices. And there is the drift risk, where the answers were true when written and nobody updated them when the model provider changed or the retention policy moved.
The alternative is to build the artefact set once, maintain it on a defined review cycle, and answer questionnaires by mapping questions to artefacts. The first questionnaire after that shift takes about as long as it did before. The fifth takes an afternoon.
There is a governance point underneath the efficiency one. Artefacts that are maintained rather than assembled on demand require something to maintain them, which is what a management system is for. ISO 42001 is the instrument that gives the artefact set an owner, a review cadence, and an audit that notices when it has gone stale. That is why the SIG mapping to ISO 42001 matters commercially and not just structurally: buyers are beginning to ask not only what your answer is, but what keeps it true.
Answer once, keep it current, and the AI section stops being the reason a deal sits in security review for six weeks.
Who should own the response
The most common structural mistake is routing the AI domain to whoever answered the security domain.
Security teams answer security questions well and AI questions badly, not through any deficiency but because the questions are about a system they do not build. The engineering team knows the model and the data flows but writes for engineers rather than for a procurement reviewer. Legal knows the contractual position and cannot describe the oversight design.
What works is a single owner who holds the artefact set and can draft from it, drawing on the other three for verification rather than for content. In smaller organisations that is usually a single senior person with a governance remit. In larger ones it is the AI governance function if one exists, and if one does not, the absence is itself an answer to the accountability question the questionnaire is about to ask.
Whoever owns it needs authority to say no. A meaningful proportion of questionnaire damage comes from someone under commercial pressure giving a reassuring answer that later turns out to be qualified. The person answering has to be able to tell the deal team that the honest answer is the one going in the box.
What to do when the answer is no
Vendors dread the questions they cannot answer well. In practice the negative answer, handled properly, costs less than the evasive one.
If you do not currently carry out subgroup bias testing, say so, say why in terms of your use case, and say what you do instead and what your plan is with a date. A buyer can risk-accept a gap with a remediation date attached. They cannot risk-accept an answer they suspect is untrue, because their own governance requires them to evidence the basis for the acceptance.
If you cannot verify a model provider's training data claims, say that, name what the provider publishes, and state what contractual protection you hold. Every buyer already knows the answer to this question is imperfect for every vendor. What distinguishes suppliers is whether they know it.
The one thing not to do is leave a field blank or write "available on request". Both read as concealment, and both guarantee a follow-up cycle that adds two weeks.
If your deals are stalling in AI security review, the AI Trust Evidence Pack builds the artefact set that answers the substance. See what it contains.
Last reviewed: August 2026.