Security questionnaires used to ask about encryption, access control, and incident response. They still do. Many now add a section on artificial intelligence, sometimes a few questions and sometimes several pages, and the person answering often discovers they do not know the facts.
The questions are not hard to read. They are hard to answer accurately, because the answers live with different people. Engineering knows which model the product calls. Legal knows what the provider's contract says. Nobody has written either down in a form the security team can reuse.
This article groups the AI questions you are likely to see, explains what each group is testing, and sets out the fact base to build before you answer. The general mechanics of answering questionnaires are covered in answering security questionnaires. This piece is about the AI layer.
The question groups
The wording varies between standard questionnaires and custom ones, as discussed in SIG, CAIQ, and custom questionnaires compared. The underlying questions fall into a few groups.
| Group | Typical question | What the customer is checking |
|---|---|---|
| Use in the product | Does the service use AI or machine learning? Which features? | Whether their data reaches an AI system at all |
| Providers | Which third-party models or AI providers do you use? | New subprocessors and where data goes |
| Training and retention | Is customer data used to train models? How long are prompts kept? | Whether their data could end up in a model or another customer's output |
| Customer controls | Can we disable AI features? Can we opt out? | Whether they can enforce their own policy |
| Human oversight | Are AI outputs reviewed? Do AI features make decisions? | Accountability for what the system does |
| Security of AI features | How do you address prompt injection or data leakage? | Whether AI-specific threats are on your radar |
| Governance | Do you have an AI policy? Do you follow ISO/IEC 42001 or the NIST AI RMF? | Whether anyone owns this |
| Internal use | Do employees use AI tools with customer data? | Whether their data leaks through your staff, not your product |
The last group surprises people. A company with no AI in its product can still get several questions wrong, because staff use AI assistants at work.
Build the fact base first
Do not answer AI questions one questionnaire at a time. Assemble the facts once, get each fact confirmed by its owner, and answer from that.
The fact base needs:
A list of AI features in the product. For each one, what it does, which data it receives, and whether it is on by default.
The providers behind each feature. Model provider, hosting region, and whether they appear on your subprocessor list. If they do not, that is a problem to fix before answering.
The contract terms with each provider. What they may do with inputs and outputs, how long they retain them, and what they must notify you about. The questions in AI vendor risk: questions to ask before you adopt a model are the ones whose answers you now need to repeat.
The controls customers have. Admin toggles, per-workspace settings, and whether disabling a feature stops data flowing to the provider.
Your internal use rules. Your AI acceptable use policy, and which tools staff are approved to use with customer data.
Your governance position. Who owns AI risk, whether you have an AI policy, and which framework, if any, you follow or are certified against.
Each fact needs an owner, and the owner should confirm it on a schedule. An answer that was true when written and is no longer true is worse than no answer.
Writing answers that hold up
A good AI answer has the same qualities as any good questionnaire answer: specific, scoped, and backed by a document. A few AI-specific habits help.
Scope every answer to the product and feature. "Our platform does not use AI" is rarely true across a whole company. "The reporting module uses a third-party model to generate summaries; no other feature sends customer data to an AI provider" is checkable.
Separate defaults from commitments. If a setting controls whether data is used for training, say what the default is and whether a contract term backs it. Customers read these differently, and so will their lawyers.
Avoid absolute claims you cannot verify. "Customer data is never retained" is a promise about every log, cache, and provider system. Write what your contracts and configurations actually establish.
Point to a document. A subprocessor list, a data processing agreement, an AI feature documentation page, or a policy. A reviewer trusts an answer more when it names where the reviewer can check it.
Say what you do not do. If no AI feature makes decisions about individuals, say so plainly. It answers a question many reviewers have not asked yet.
The questions people answer badly
"Do you use AI?"
The common mistake is a flat "no" because the product has no AI features. The reviewer may mean the product, your operations, or your staff. Answer each reading, briefly. If staff use approved AI tools under a policy, say so and say what the policy restricts.
"Is customer data used to train models?"
The common mistake is answering only about your own models. If you send data to a provider, the question covers them too. The answer depends on your contract with that provider, not on their marketing page. This question deserves a carefully drafted standard answer, kept consistent everywhere it appears.
"Do you have an AI governance program?"
The common mistake is overstatement. A policy and an owner are a start, not a program. Describe what exists: the policy, its approval date, the owner, and whether you assess AI risks. If you are working toward ISO/IEC 42001, say that you are working toward it, not that you comply.
"Is AI output reviewed by a human?"
The common mistake is a blanket yes. Some outputs are reviewed and some are not, by design. Say which, and say who is accountable when an unreviewed output is wrong.
"How do you prevent prompt injection?"
The common mistake is claiming prevention. No current technique reliably prevents it, and an experienced reviewer knows that. Describe the measures that limit the damage instead: what data and actions each AI feature can reach, how inputs from untrusted sources are separated from instructions, what you filter on output, and what you log. An answer that treats the model as untrusted and constrains what it can do reads as competent. An answer that says the problem is solved does not.
Keeping answers current
AI answers go stale faster than most. Providers change terms. Features ship. A model is swapped. Set triggers that reopen the relevant answers:
A new AI feature is released or an existing one starts receiving new data
A model provider is added, changed, or removed
A provider changes its terms or data processing agreement
Your acceptable use policy is revised
A customer finds an inconsistency between two of your answers
Store the approved answers in one place with their owner and last review date. When a questionnaire arrives, start from that library, then check whether the facts behind each answer have changed since it was approved.
How TrustLynce helps
TrustLynce's questionnaire automation suggests answers from a reviewed answer library, so your AI answers are written once, approved, and reused consistently. Publishing your subprocessor list and AI documentation in a Trust Center gives reviewers a place to check, with an access log for gated documents.