The Problem
You added AI features. Now the enterprise security questionnaire that used to have 240 questions has 260, and the new twenty are all about the AI. “Do you train on our data?” “Where do prompts go?” “Can the model take an action that can’t be undone?” “Is our data isolated from other customers’ at the model layer?”
Teams freeze on these, for the same reason they froze on the original questionnaire before they’d seen a few: the questions look like they’re testing whether your AI is safe, and you’re not sure it is. It reads like an exam you might fail.
It isn’t. The AI section tests exactly what the rest of the questionnaire tests — see reading an enterprise security questionnaire for the core version. It’s checking whether you’ve thought about the AI-specific risks well enough to answer honestly. A CISO doesn’t expect your Series B startup to have a formal AI governance board. They expect you to know where the data goes, who the model vendor is, and what happens when the model is confidently wrong. Answer that, accurately, and you pass.
The Approach
The AI questions cluster into five themes. Recognize the theme and you know what the buyer is actually worried about, which tells you what a good answer looks like.
The same four answer patterns from the core questionnaire apply: yes with evidence, yes with honest scope, compensating control, and not applicable. What changes is the subject matter.
Theme 1: Data handling
The buyer’s real fear: their data trains someone else’s model, or ends up somewhere they can’t see. This is the theme they care about most.
The questions: Do you train on our data? Are prompts and outputs logged, and where? What’s the retention? Can we opt out of any data use?
The honest answer is usually short and reassuring, if you’ve done the work from adding AI features without breaking your compliance posture: “We do not train on customer data. Prompts and responses are processed by our model vendor under a no-training agreement, logged only in scoped-shape form for debugging (no content), and retained for 30 days.” If any of that isn’t true, the questionnaire is telling you what to go fix.
Theme 2: Vendor and sub-processor
The buyer’s real fear: you’ve added an AI vendor to their data supply chain and didn’t tell anyone.
The questions: Which model provider do you use? Is there a BAA or DPA with them? Is the provider on your sub-processor list? Do they train on inputs?
The answer that builds trust names the vendor, confirms the agreement, and points to the public list: “AI inference runs on [vendor] under our signed [BAA/DPA]; they are listed on our public sub-processor page and do not train on our inputs.” An undisclosed AI sub-processor discovered mid-review is the fastest way to lose the deal.
Theme 3: Output safety and human oversight
The buyer’s real fear: the AI does something consequential and wrong, automatically, to their data or their customers.
The questions: Can the model take actions autonomously? Is there human review before a consequential output? How do you handle hallucinations?
The pattern here is the compensating-control answer: “The model drafts; it does not decide. Consequential outputs require human review before they take effect. We monitor for and log low-confidence outputs.” If your feature genuinely does act autonomously, say so and describe the guardrails honestly — a vague “we follow best practices” gets you a follow-up call you don’t want.
Theme 4: Isolation
The buyer’s real fear: another customer’s prompts leak into their results, or vice versa, through the model.
The questions: Is our data isolated at the model layer? Do you use our data in prompts for other customers (few-shot examples, RAG)? Could our data appear in another tenant’s output?
The answer turns on your architecture. If each request is stateless and scoped to one tenant, say it plainly: “Prompts are constructed per-request from a single tenant’s data. We do not use one customer’s data as context for another’s requests.” If you use a shared vector store or cross-tenant examples, that’s a real design question to resolve before you answer.
Theme 5: Governance
The buyer’s real fear: you’re shipping AI features with no process, so the next one will be the reckless one.
The questions: Who approves AI features? Do you have an AI use policy? What’s your incident plan for a harmful output?
You don’t need an AI ethics board. You need to show a process exists: “New AI features run a documented compliance pre-flight before launch (data flow, vendor, output safety). Harmful outputs are handled under our standard incident response.” A named, followed process beats an aspirational policy every time.
The Template
Fifteen of the most common AI-security questions with answer patterns. Adapt the specifics to your architecture; keep the structure. Vague answers get flagged; brief, specific, honest answers get you to the next stage.
| # | Question | Answer pattern |
|---|---|---|
| 1 | Do you train AI models on customer data? | No. Customer data is never used to train or fine-tune models. |
| 2 | Which AI/LLM provider(s) do you use? | [Vendor(s)], accessed via API under [BAA/DPA]. Listed on our sub-processor page. |
| 3 | Does your AI provider train on your inputs? | No — confirmed in writing under our enterprise agreement; opt-out verified. |
| 4 | Are prompts and responses logged? Where? | Shape only (no content) in app logs. Any retained content is in-boundary, encrypted, scoped. |
| 5 | What is the retention for AI prompt/response data? | [X days]. Set deliberately; not left at vendor default. |
| 6 | Is customer data isolated at the model layer? | Yes. Prompts are constructed per-request, scoped to one tenant. No cross-tenant context. |
| 7 | Can the AI take autonomous/irreversible actions? | No. The model drafts or suggests; consequential actions require human review. |
| 8 | How do you handle hallucinations / incorrect output? | Human-in-the-loop on consequential outputs; low-confidence outputs flagged + logged. |
| 9 | Is there a human-in-the-loop for [use case]? | [Yes — where + how] OR [Compensating: output is advisory only, not acted on automatically]. |
| 10 | Do you have an AI acceptable-use policy? | [Yes — summary] OR [Documented AI feature pre-flight applied before each launch]. |
| 11 | How are AI features reviewed before release? | Documented compliance pre-flight: data flow, vendor agreement, output safety, logging. |
| 12 | Can we opt out of AI features / processing? | [Yes — how] OR [AI features are [optional/tiered]; describe the control]. |
| 13 | Is generated content labeled as AI-generated? | Yes. Users can distinguish AI-generated content. |
| 14 | What is your incident process for a harmful AI output? | Handled under standard IR; severity assessed; affected customers notified per policy. |
| 15 | Do you use our data in a shared vector store / RAG index? | [No — per-tenant isolation] OR [Yes — describe tenant scoping + access controls honestly]. |
These fifteen cover the large majority of any AI section. The rest are environment-specific — your exact model, your exact data flows — and those become the focused work once the baseline is in place.
Operating Notes
Build the AI answer bank the same way you built the security one: every answer you write goes into a versioned document, keyed by question, so the next questionnaire is a copy-paste plus a delta review. The AI section changes faster than the rest, so tag each answer with a “last verified” date and re-check anything older than three months.
The “we don’t train on your data” answer will be re-asked, re-verified, and eventually audited. Make sure it stays true. The single fastest way to destroy the trust this whole exercise builds is to answer “no training” while a vendor default quietly flipped to “training unless you opt out.” Re-read your model vendors’ terms on a schedule, not when a buyer asks.
The teams that handle the AI section well aren’t the ones with the most sophisticated AI. They’re the ones who can describe their unremarkable, well-governed AI in five honest sentences. That legibility is the product.