What enterprise AI security questions do buyers ask?

01The questions arrive in a predictable order

Security questionnaires for AI features look new, but most of the questions are old ones asked again with a model in the middle. In our experience they arrive in roughly this order:

1. 01

   Where does our data live, and does any of it leave our region or our cloud account?

2. 02

   Which model provider processes it, under what terms, and is it retained or used for training?

3. 03

   Who on your side can access production, from where, and how is that logged?

4. 04

   Where are secrets and API keys stored, and who can read them?

5. 05

   What can the AI do on its own, and what needs a person to approve?

6. 06

   How do you log prompts, outputs and actions, and how long are logs kept?

7. 07

   How do you prevent one customer's data from reaching another customer's answers?

8. 08

   What happens if the model or a provider fails, and can we switch the feature off?

The first four are about your platform, not about AI. If those answers are weak, a strong AI story will not save the review.

02Fix the plain controls before the AI controls

Teams often prepare long answers about prompt injection and model safety while production access is still loose. Reviewers notice. The basics carry the most weight, because they limit the damage of any failure, AI or otherwise.

None of this is specific to language models, which is exactly the point. The NIST Generative AI Profile, a companion to the NIST AI Risk Management Framework, treats generative AI risk as part of an organization's wider risk management, not as a separate island.

03Then answer the AI specific questions

Once the platform basics are in place, the AI specific questions become easier to answer honestly. The OWASP Top 10 for LLM Applications is a useful map of what reviewers worry about: prompt injection, sensitive information disclosure, excessive agency, system prompt leakage and unbounded consumption among them. For each one, describe the control in plain terms:

• Data in prompts. List which fields can reach the model and which never can. Keep the list in the codebase, not in a slide.
• Model location. State the provider, the region and whether the model runs in your account, the customer's account or the provider's service.
• Agency. Separate analysis from action. If the AI can change records, send messages or place orders, require an explicit user confirmation and log it.
• Tenant boundaries. Show that retrieval and tools are scoped to the current customer before the model sees anything.
• Cost and abuse. Show rate limits and usage logging per tenant and per conversation.

Where possible, offer deployment options rather than one answer. Some buyers accept a hosted service with clear terms. Others need the AI to run inside their own cloud subscription, on a model endpoint they already approved. We compare cloud options in Bedrock vs Azure AI vs Vertex AI for existing SaaS.

04Prepare the evidence, not just the answers

A review goes faster when every answer points to something the buyer can check. Keep a short evidence pack:

• An architecture diagram showing where data flows, including the model call.
• A list of production access holders and how access is granted and removed.
• Sample audit log entries for an AI action, with sensitive values removed.
• The data field list for prompts.
• The steps to switch the feature off for one customer.

Be precise about what you do not have. If you hold no certification, say so plainly and describe the controls you do run. Reviewers trust a clear "not yet" more than a vague claim.

05Common mistakes in enterprise AI security reviews

The same mistakes slow down many reviews, and most of them are avoidable:

• Answering for the model provider instead of for your product. Buyers want to know what your platform does with their data, not only the provider's general terms.
• Describing controls that are planned as if they were live. Reviewers ask for evidence, and a gap found late damages trust in every other answer.
• Using production data in testing. Even one screenshot of real customer data in a demo environment can stop a review.
• Leaving agent permissions broad. An assistant that can call any internal endpoint is hard to defend. Give it a short, explicit tool list scoped to the user it acts for.
• Forgetting offboarding. Buyers increasingly ask how their data, logs and any indexes are deleted when the contract ends.

A useful habit is to run your own review first. Take a recent questionnaire, answer it internally for the AI feature, and fix the weak answers before a customer sees them.

06What we see in production

On a promotional campaign portal we built for a dealership marketing agency, the application ran on AWS in the client's own account alongside its other apps. Before any AI was ever discussed, it got infrastructure monitoring, and production shell access was limited to known office IP addresses. Later, its resources moved with the client's other applications to a new AWS account. These are the plain controls a security review checks first, and any AI work inside a product like this inherits them.

On an AI market intelligence app for retail investors, AI analysis was kept separate from real trades. Orders through the connected brokerage required explicit consent to connect and a mandatory user confirmation. Licensed options data was held to the QA environment only. When the client explored a business version for investment firms, our proposal set out deployment inside the prospect's own Azure subscription, with a managed key vault for all secrets, single sign-on through the prospect's identity provider, monitoring, infrastructure as code, an admin kill switch and human in the loop settings, with the agents exposed only through an authenticated API.

On a governed AI content platform, a fresh install of the second version carries no client documents, data or keys by design, which makes it simpler to stand up a clean environment for a new customer.

Across our work, engineering runs with no standing access to client production data, and we work in the client's cloud and on the client's model by default.

Frequently asked questions