The SaaS Guide to AI Security Questionnaires
Enterprise buyers now send SaaS vendors AI-specific security questionnaires about how AI features are governed, logged, and attributed. This walks through what they ask, why promises fail an auditor, and the architecture that lets a vendor answer with evidence.
A security questionnaire used to interrogate infrastructure: encryption at rest, SSO enforcement, SOC 2 Type II scope, backup cadence. The version landing in B2B SaaS inboxes through 2026 carries a new section, and it asks how the AI features inside your product reach decisions, what they record, and whose identity sits behind each call. IBM's Cost of a Data Breach analysis linked one in five of 600 breached organizations to shadow AI and found those breaches cost $670,000 more on average than standard ones. I want to walk through the five questions that section asks, why a written promise fails an auditor, and the architecture that produces evidence instead.
The five questions inside an AI security questionnaire
The AI security questionnaire clusters into five questions, and each maps to a control the buyer's compliance team has to evidence upstream:
- Governance: which models power the feature, which endpoints they call (OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock), and who signed off on each one.
- Logging: whether you record AI decisions at a granularity that reconstructs a single request.
- Identity attribution: whose verified identity sits behind each call, and whether a prompt traces to a named user or agent rather than a shared service key.
- Prompt handling and sub-processors: where prompt content travels, which sub-processors receive it, and whether customer data trains a model.
- Proof: whether you can produce the records on demand, in writing, inside an audit window.
The first four questions describe a capability. The fifth decides whether the buyer trusts the first four.
Self-attestation makes questionnaire answers collapse under audit
Most responses describe logging that the vendor's own application produces. That is the weak point. An application that writes its own AI logs cannot serve as its own auditor, the same way a CFO does not sign the audit of statements they prepared. Application-controlled logs fail in three ways:
- Selective logging: the code records the successes and skips the edge-case denial that matters.
- Suppression: the system that failed can rewrite or remove the entry afterward.
- Loss on crash: the model responds, the process dies before the log commits, and the evidence is gone.
A SOC 2 Type II report tells a buyer your controls operated across a review window. It says nothing about whether one prompt from one named user was authorized at 2:14 on a Tuesday. Auditors now ask the second question, and self-generated logs have no answer.
The EU AI Act splits the deployer from the vendor
On August 2, 2026, the high-risk requirements of the EU AI Act take effect, and Article 12 mandates automatic recording of events over the lifetime of the system, including timestamps, input data, and the identity of the natural persons involved. The deployer carrying that obligation is usually your customer, because they run your product inside a high-risk function such as credit scoring or hiring. The customer inherits Article 12, and your architecture decides whether they can satisfy it. If your product calls Anthropic or Azure OpenAI under a shared key and keeps only application-level logs, your customer cannot reconstruct which natural person drove a given decision. Their compliance gap becomes your failed questionnaire. This is the deployer and vendor split for SaaS, and it is why the AI section reaches into your codebase.
Enterprises inherit the AI liability their vendors decline to sign
Enterprise buyers push these questions down the supply chain because they cannot push them up it. When The Register asked six of the largest enterprise software vendors who is liable when an AI agent makes a costly decision, Microsoft and SAP declined to comment, and Oracle, Salesforce, ServiceNow, and Workday did not respond. Silence is the answer. The deploying enterprise ends up as the insurer of last resort for outcomes its own vendors decline to underwrite. A buyer that has absorbed this lesson stops accepting assurances and starts requiring evidence from every vendor in the chain, including you. When your answer to 'who can prove what your AI did' is a paragraph of good intent, you read as one more supplier shifting risk downstream, exactly the position the buyer already owns.
The architecture that turns answers into evidence
Answering with evidence requires the record to come from outside the application making the call. The pattern is an external enforcement point that sits inline between your authenticated users or agents and the LLM endpoints they reach. Every request is evaluated against who is asking, the role they hold, the data classification in the prompt, and the policy in force. Each evaluation writes a per-decision audit record: identity, role, policy version, data classification, decision outcome, and timestamp, sealed with a tamper-evident signature. The record commits before the response returns, so the calling application cannot suppress it. Because the enforcement point is model-agnostic, it captures the same record in front of OpenAI, Amazon Bedrock, or a self-hosted model, which answers the sub-processor question with a log rather than a diagram.
DeepInspect
This is the architecture DeepInspect provides. DeepInspect is a stateless proxy between your authenticated users or agents and any HTTP LLM endpoint. For every request and response, it evaluates identity, data classification, model authorization, and policy, then makes a pass, redact, or block decision before the traffic reaches the model.
Every decision produces a signed, tamper-evident record holding identity, role, policy version, data sensitivity, outcome, and timestamp. The record commits before your application receives the response, which closes the self-attestation problem the auditor is probing. Because DeepInspect is model-agnostic, one control answers the AI section the same way in front of OpenAI, Anthropic, Azure OpenAI, or a self-hosted model.
When the buyer's AI questionnaire asks you to prove what your AI did, you attach records rather than assurances.
Let's talk today.
Frequently asked questions
- How is an AI security questionnaire different from a standard SOC 2 review?
A SOC 2 Type II review checks organization-level controls: access management, encryption, change management, and whether those controls operated across a review window. The AI section drills into a lower layer, the per-decision behavior of the AI features in your product. It asks whether you can attribute a single prompt to a named user, reconstruct one decision after the fact, and produce the record during an audit. A control catalog confirms you hold a logging policy. The AI questionnaire asks what your model did at a specific moment, for a specific user, under which policy version. That resolution reaches deeper than most SOC 2 programs ever needed to.
- If we build on OpenAI or Anthropic, who owns the AI security answer?
You own it, for how AI operates inside your product. The shared responsibility line holds: the model provider secures the model, and you own how that model is used in your environment and the outcomes it produces. Pointing the buyer at OpenAI or Anthropic does not move the obligation. When The Register asked Microsoft, SAP, Oracle, Salesforce, ServiceNow, and Workday who is liable for an AI agent's decisions, two declined to comment and four stayed silent, which shows where the largest vendors expect liability to land. Your customer's contract holds you accountable for your product's behavior, including the model calls it makes on their data. The questionnaire confirms you understand the obligation rests with you.
- Does the EU AI Act apply to us if we only sell software to other businesses?
Often yes, indirectly. Article 12 attaches to high-risk AI systems defined in Annex III of the EU AI Act, and the high-risk requirements take effect on August 2, 2026. If your customer runs your product inside a high-risk function such as credit scoring or employment screening, that customer becomes the deployer and inherits the record-keeping obligation. Selling only to other businesses does not remove you from the picture. It places you inside your customer's compliance chain, where your architecture decides whether they can produce the logs Article 12 demands. A customer who fails an EU audit because your product could not attribute a decision to a natural person churns.
- How do we answer the identity attribution question if our service calls the model with one shared API key?
The shared key is the exact thing the question is probing. A credential issued to your application identifies the service, not the person or agent the call is made for, so an application log shows one service account making forty thousand calls. Attribution requires identity context to travel with each request to an enforcement point that binds it to the decision record. This is the identity-aware gateway pattern: the caller's verified identity and role arrive with the request and land in the record at evaluation. You keep the shared upstream key to the model provider. The attribution happens one layer earlier, before the request leaves your environment, so the record answers 'which user' rather than 'which service.'
- What evidence should we attach to prove our AI logging works?
Attach a sample per-decision audit record, not a description of your logging policy. For a handful of representative requests, show what an auditor wants: verified identity, role, policy version, data classification, decision outcome, timestamp, and a tamper-evident signature. If the same application that made the AI call also produced the log, an auditor discounts it, because the system under review controls its own evidence. A record produced by a separate enforcement layer, committed before the response returns to your application, survives the question that settles the AI section: could you have altered this after the fact? When the answer is no, backed by the signature and the architecture, one sample record does more than a page of questionnaire prose.