# What Enterprise Buyers Actually Ask About Your AI Features

Canonical: https://kaansystems.com/library/what-enterprise-buyers-ask-ai
Topic: AI · Published: 2026-07-29 · Updated: 2026-10-12
Summary: As you add AI features, enterprise security questionnaires grow an AI section. Buyers aren't testing whether your AI is flawless — they're testing whether you've thought about the AI-specific risks. Five themes, four answer patterns, fifteen pre-filled responses.

## Key takeaways

- Adding AI features grows your enterprise security questionnaire by roughly twenty AI-specific questions, and they aren't testing whether your model is perfect — they're testing whether you've thought about the AI-specific risks well enough to answer honestly.
- The AI questions cluster into five themes: data handling, vendor and sub-processor, output safety and human oversight, isolation, and governance. Recognize the theme and you know what the buyer is actually worried about.
- The same four answer patterns from the core questionnaire apply — yes with evidence, yes with honest scope, compensating control, and not applicable; only the subject matter changes.
- Data handling is the theme buyers care about most, and an undisclosed AI sub-processor discovered mid-review is the fastest way to lose the deal — name the vendor, confirm the agreement, and point to your public sub-processor list.
- Build a versioned answer bank keyed by question, tag each answer with a 'last verified' date, and re-check anything older than three months, since the AI section changes faster than the rest of the questionnaire.
- You don't need an AI ethics board; you need to show a documented process exists. The teams that pass describe their unremarkable, well-governed AI in five honest sentences — that legibility is the product.

**What do enterprise buyers actually ask about your AI features?** The questions cluster into five themes — data handling, vendor and sub-processor, output safety, isolation, and governance. None test whether your model is perfect; they test whether you know where the data goes, who the vendor is, and what happens when the model is wrong. Answer that honestly and you pass.

## What do enterprise buyers ask about AI features?

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](/library/reading-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.

## How do you answer without claiming a perfect model?

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.

```mermaid
flowchart TD
  Q[An AI question on the questionnaire]
  Q --> T1[Data handling<br/>Do you train on our data?<br/>Where do prompts go?]
  Q --> T2[Vendor + sub-processor<br/>Which model vendor?<br/>BAA / DPA in place?]
  Q --> T3[Output safety<br/>Can the AI take<br/>irreversible action?]
  Q --> T4[Isolation<br/>Is our data isolated<br/>at the model layer?]
  Q --> T5[Governance<br/>Who approves AI features?<br/>Plan for a bad output?]

  classDef q     fill:#0d1f1a,stroke:#6FE3B5,stroke-width:1.5px,color:#E8F5EE;
  classDef theme fill:#1F4A3E,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE;
  class Q q;
  class T1,T2,T3,T4,T5 theme;
```

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](/library/ai-features-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 [AI governance framework](/library/ai-governance-for-regulated-products) 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.

## Frequently asked questions

**Q: What do enterprise buyers ask about AI features in a security questionnaire?**

The AI questions cluster into five themes: data handling (do you train on our data, where do prompts go), vendor and sub-processor (which model provider, is there a BAA or DPA), output safety and human oversight, data isolation at the model layer, and governance. Recognize the theme and you know what the buyer is actually worried about.

**Q: Do enterprise buyers expect my startup to have formal AI governance?**

No. A CISO doesn't expect a 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. You need to show a documented process exists, not an ethics board.

**Q: How should I answer 'do you train on our data'?**

If it's true, keep it short and reassuring: you don't train on customer data, prompts are processed by your model vendor under a no-training agreement, logged only in scoped-shape form for debugging with no content, and retained for a set window. Make sure it stays true — re-read your vendor's terms on a schedule, because a default that quietly flips to 'training unless you opt out' destroys the trust this whole exercise builds.

**Q: What if my AI feature actually takes autonomous actions?**

Say so and describe the guardrails honestly. The trust-building pattern is 'the model drafts; it does not decide,' with human review before consequential outputs take effect, but a vague 'we follow best practices' just earns you a follow-up call you don't want.

**Q: How do I answer the AI section faster next time?**

Build the AI answer bank the same way as the security one: every answer goes into a versioned document keyed by question, so the next questionnaire is a copy-paste plus a delta review. Tag each answer with a 'last verified' date and re-check anything older than three months, since the AI section changes faster than the rest.

**Q: Does having more sophisticated AI help me pass the review?**

No. 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.

Template: "Pre-filled responses to 15 common AI-security questions" — branded PDF at https://kaansystems.com/templates/what-enterprise-buyers-ask-ai.pdf

Source: https://kaansystems.com/library/what-enterprise-buyers-ask-ai · Work with Kaan Systems: https://kaansystems.com/contact