The AI Questions Enterprise Buyers Ask About Your LLM, With Answer Templates

The questionnaire arrives as a spreadsheet. Most tabs look familiar: access control, encryption, backups. Then there is a tab you haven't seen before, and it is about the AI feature you shipped last quarter. Does the model train on our data? Who else sees our prompts? What happens when the model is wrong?

This page is the answer bank for that tab. It covers the questions a buyer asks about an AI feature, where those questions come from, and how to answer each one honestly. For each theme you get what the buyer is checking, a template with blanks you fill from your own setup, and the evidence to attach. It is written for the most common shape of AI startup in 2026: a small team that calls a hosted model like OpenAI's or Anthropic's and doesn't train its own.

Why your questionnaire now has an AI section

Because the questionnaires themselves changed. Shared Assessments added an Artificial Intelligence domain to its SIG questionnaire, one of 21 risk domains it now covers. The Cloud Security Alliance published a separate AI questionnaire, the AI-CAIQ. Buyers reach for these standard sets, so your AI feature gets reviewed whether or not you mention it.

The demand is measurable. In A-LIGN's 2026 benchmark, a survey of 1,043 companies run by an audit firm, 80% of companies using AI said customers ask them risk questions about it.

This is different from what a SOC 2 auditor asks. An auditor tests the controls you run over time. A buyer's questionnaire asks what you do today, in your own words, and decides whether to trust it. The auditor's list for LLM features lives in SOC 2 for AI startups. The generic questionnaires (SIG Lite, CAIQ, VSA) and what to send the week a buyer asks are in your first enterprise customer asked for SOC 2. This page is only the AI part.

Where the AI questions come from

Six published sources feed almost every AI question you'll see. Two are questionnaires buyers send directly: the SIG and CSA's AI-CAIQ. Two are frameworks buyers borrow wording from: NIST's AI Risk Management Framework and ISO/IEC 42001. One is a security risk list, the OWASP LLM Top 10. One is law: Article 50 of the EU AI Act.

Here is what each issuer says about its own document:

A note on the SIG. Its question text is licensed, and Shared Assessments doesn't publish the AI domain's individual questions. What it does say, in its 2026 workbook notes, is that the SIG now references ISO 42001 for "oversight of AI lifecycle stages such as data collection, model training, deployment, and monitoring," so buyers can assess vendors' "AI practices for fairness, transparency, and accountability." The themes below cover those stages. I haven't reproduced any SIG question, because I can't see one without a license.

The CSA material is the most useful for a small team, because it is free and role-aware. The AI Controls Matrix defines five roles. The one that fits you is the Application Provider, which "builds end-user AI applications that leverage models." Your answers can lean on that split: some controls belong to OpenAI or Anthropic, the rest are yours. CSA also lets you publish a completed AI-CAIQ on its registry as STAR for AI Level 1, which saves answering the same questions twice.

The eight themes, and what to attach to each

Read across the six sources and the AI questions fall into eight groups. The grouping is ours; the questions are theirs. Each section below gives the buyer's intent, a template and the evidence.

One rule covers all eight. Answer with a fact you can show, not a feeling. "We take privacy seriously" is not an answer. "Our model provider's API terms say inputs are not used for training; link attached" is.

1. "Do you, or your AI providers, train models on our data?"

Answer with the exact published term of every vendor that touches their data, and say what you do yourself. This is the question buyers care about most. It maps to the SIG's "data collection" and "model training" stages and to NIST's Data Privacy risk.

What the buyer is checking: that their documents, tickets or customer records won't end up improving a model someone else uses.

What the vendors publish. You can quote these, with links:

• OpenAI API: "As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)." (OpenAI, read 2 Oct 2026)
• Anthropic API: "By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models." (Anthropic, read 2 Oct 2026)
• Azure OpenAI and Vertex AI publish similar no-training language in their data-privacy docs (Microsoft, Google).

Check the tools you built with, too. Lovable's docs say that since 9 September 2026, Free and Pro plan data may be used for training unless you opt out, while Business and Enterprise are excluded by default. That covers your prompts and code, not your app's end-user data, but a buyer will still ask. The platform-by-platform picture is in is your vibe-coding stack SOC 2 ready.

Evidence to attach: the provider's no-training page (link and a dated screenshot), your DPA with the provider, and a screenshot of any opt-out setting. Never answer "no" for a vendor whose terms you haven't read on the current page.

2. "Which AI providers and subprocessors process our data?"

Name every company that sees their data through the AI feature, what each one does and where. Your model provider is a subprocessor and belongs on your list. Buyers check this against NIST's Value Chain and Component Integration risk and OWASP's LLM03 Supply Chain.

What the buyer is checking: who else sees their data, and whether you vetted those vendors before using them. NIST's generative AI profile describes the risk as "improper supplier vetting across the AI lifecycle."

The CSA's role split helps here. You are the Application Provider; the lab is the Model Provider. Your answer should make that line visible: these controls are the provider's (attach its reports), these are ours (described below).

Evidence to attach: your subprocessor list, the provider's own subprocessor list (OpenAI and Anthropic each publish one, linked from their trust portals), and the provider's SOC 2 or ISO report. OpenAI's and Anthropic's trust portals both take report requests. If an EU buyer asks where processing happens, EU data residency for AI APIs shows which providers offer an EU option and at what price.

3. "How long are prompts and outputs retained, and where?"

Give a number for every place a prompt or output lives: your provider, your database and your logs. The provider's default is published; yours is a setting you choose.

What the buyer is checking: that their data doesn't sit indefinitely in a log nobody remembers.

What the vendors publish:

• OpenAI API: abuse monitoring logs are "retained for up to 30 days, unless longer retention is required by law" or needed to prevent harm. Zero Data Retention and Modified Abuse Monitoring are "subject to prior approval by OpenAI." (OpenAI)
• Anthropic API: "we automatically delete inputs and outputs on our backend within 30 days of receipt or generation," with listed exceptions. Zero data retention is arranged through sales and needs Anthropic's approval. (Anthropic)

Don't claim zero data retention unless you hold the approval in writing. "Up to 30 days at the provider, then deleted" is an honest answer most buyers can work with.

Evidence to attach: the provider's retention page, a screenshot of your log retention setting, and your data deletion procedure. If you run the model yourself to keep data in-house, private LLM cost for EU companies prices that route.

4. "How do you protect against prompt injection and unsafe outputs?"

Show that you know the risk class and run layered controls. Buyers ask this because OWASP puts Prompt Injection first on its LLM Top 10, followed on the same list by Improper Output Handling, Excessive Agency and System Prompt Leakage. They are not asking for a demonstration, and you shouldn't give one.

What the buyer is checking: that a crafted input, typed by a user or hidden in a document your feature reads, can't make the model leak their data or take an action nobody approved. NIST's generative AI profile notes that generative AI "itself is vulnerable to attacks like prompt injection."

No vendor and no control can promise zero risk here, and buyers know it. Say "reduces" and "limits," never "prevents." The control categories buyers expect to see:

• Least privilege. The model can only reach the data and tools the current user can reach. Row-level access rules, such as Row Level Security, still apply to anything the model fetches.
• Output treated as untrusted. Model output is validated or encoded before it is shown, stored or passed to another system, like any user input.
• A human confirms actions. Anything that sends, deletes, pays or changes data needs a person's click, not just the model's decision.
• Secrets kept out of prompts. System prompts contain no keys or credentials, and API keys stay on the server.
• Testing on a schedule. A documented set of adversarial test cases, run before releases, with results kept.

If your feature uses agents that browse or run tools, the risk is larger. OpenClaw's security risks and sandboxing covers how agent tool access is contained.

Evidence to attach: a one-page description of these controls, your tool-permission list, and a summary of your last test run (results, not the test inputs). A pen test that included the AI feature helps; scoping and pricing one is on the SOC 2 audit cost page's list of add-ons.

5. "Is there human oversight, and are users told they're using AI?"

Say where a person reviews AI output before it matters, and show how users are told they're dealing with an AI. Two sources drive this: NIST's Human-AI Configuration and Confabulation risks, and, for EU buyers, Article 50 of the AI Act.

What the buyer is checking: that a wrong answer can't quietly become a decision, and that their own staff or customers won't be misled.

NIST's profile names over-reliance and "automation bias" as risks, and describes confabulation as "confidently stated but erroneous or false content." Wrong output is expected behavior, so your answer should describe the check, not deny the risk. Why AI hallucinates code explains the mechanism.

The EU part is law, and it changed this summer. Article 50(1) requires providers to make sure people "are informed that they are interacting with an AI system" unless that's obvious, and it applies from 2 August 2026. Article 50(2) requires generated text, audio, image and video to be marked as AI-generated in a machine-readable way. The Digital Omnibus on AI, in force since 27 July 2026, gives systems already on the market before 2 August 2026 until 2 December 2026 to meet the 50(2) marking duty. Whether your company counts as a "provider" under the Act depends on your facts; ask counsel before you answer a legal question in writing.

Evidence to attach: a screenshot of the AI notice in your UI, a short description of the review step, and your user-facing AI disclosure or help page.

6. "How do you manage changes to the model and prompts?"

Pin the exact model version you call and treat any change of model or system prompt like a code change, with a record, a review and a way back. This matches the "deployment, and monitoring" stages in the SIG's AI lifecycle.

What the buyer is checking: that the feature they tested in the trial is the feature they'll get next month, and that a provider's model update won't silently change its behavior.

Providers retire and replace models on their own schedule. Your answer should say what you do when that happens: test before switching, tell customers if behavior changes materially.

Evidence to attach: a change-log extract or PR list for the last model or prompt changes, and the model ID in your config (a screenshot is fine).

7. "What do you log, and how do you monitor the AI feature?"

Log enough to investigate an incident, and no more of their data than you need. Say which fields you keep, whether prompt text is redacted, who can read the logs and how long you keep them.

What the buyer is checking: that you can answer "what happened?" after an incident, without building a second copy of their data in a log tool. OWASP's LLM10 Unbounded Consumption adds a second check: limits on usage, so a runaway loop or abuse can't run up cost or take the feature down.

Evidence to attach: a list of logged fields, your redaction rule, a screenshot of the spend or rate limit settings, and the log retention setting.

8. "How will you handle and notify us of an AI-related incident?"

Fold AI into the incident plan you already have, with named examples and a notification commitment. A model leaking data, a provider breach and harmful output reaching a customer are incidents; say so.

What the buyer is checking: that you'll notice, act and tell them in time, including when the incident starts at your model provider.

Evidence to attach: the AI section of your incident response plan, the notification clause from your DPA, and the date of your last exercise.

How to keep your answer bank current

Write these eight answers once, store them with their evidence, and re-check the vendor facts before each send. Vendor terms move: Lovable's training default changed in September, and the EU's deadlines moved in July. A dated answer from last quarter can now be wrong.

If the buyer also wants a SOC 2 report, your AI answers become part of that work too. The SOC 2 for AI startups guide has the cost, the timeline and what the auditor tests.

An AI questionnaire is a trust test with an open book. Every answer above can be backed by a page your vendor already publishes or a setting you can screenshot. Fill the brackets, attach the proof, and date it. More on compliance for small teams is on the Security & Compliance hub.