The AI security questionnaire is asking for proof, not promises.

Your champion forwards a 94-row spreadsheet. The deal is no longer with the product team; it is with third-party risk.

In my experience, this hand-off can consume two to six weeks. Often, nobody has found a new vulnerability. The vendor simply cannot turn its security claims into evidence another person can inspect.

Build the evidence pack before the spreadsheet arrives. For one request, show the path, the controls, the resulting effect and the exact point where proof ends. These ten questions define the pack; the five-day sequence at the end builds it.

A polished answer is still not evidence

A questionnaire assesses security. It does not reward confidence for its own sake.

The reviewer is testing whether you know what the system did and whether they can verify it. A policy describes intent. A trace, query, configuration file, or fault-injection test shows the mechanism that was present for a particular request.

Compare two answers. "Data is encrypted in transit and at rest" states an intention. "Prompt bodies are written to spend_logs.messages in Postgres, in plaintext, retained for 90 days, and this query returns the rows" exposes a mechanism. The second answer contains an uncomfortable finding, but it gives the reviewer something concrete to assess.

A pack with no uncomfortable findings is hard to trust. Real systems retain unexpected fields, inherit defaults and contain controls nobody has tested under failure. Record those limits. Do not sand them smooth.

Four public sources predict the questions

Enterprise packs vary, but many questions map to a small set of public procurement and risk frameworks. Read those sources before the customer spreadsheet arrives, then organise your evidence in the same order.

Public-sector and civil-society questionnaires. The ACLU generative AI vendor questionnaire asks about personal data in training sets, leakage analysis, deletion rights, logging, prompt access, and contractual limits on training with customer data. Those are useful prompts for an evidence inventory, not just boxes to tick.

Financial-sector guidance. The FS-ISAC vendor assessment guide moves from general discovery through privacy, model validation, security, integration, nth-party risk, and legal review. Third-party risk covers the vendor a buyer contracts with; nth-party risk covers the providers and services that vendor depends on. Mirroring this order makes the pack easier to navigate.

EU procurement clauses. The updated EU model contractual clauses offer full and light versions for public buyers. They ask suppliers to support documentation, logging, oversight, and traceability. Lifecycle traceability means being able to connect a system decision to the model, configuration, input, control decisions, and resulting effect throughout the system's operation.

The EU AI Act. For systems classified as high-risk, Articles 12, 14, and 15 address record-keeping, human oversight, accuracy, robustness, and cybersecurity. The exact legal obligations depend on role and classification. The engineering question is still concrete: which fields and logs let you reconstruct the required record?

Draw one request before writing ten answers

Start with a data path map: every hop one request takes and every store that retains a copy. Unlike a high-level architecture diagram, it names the fields, endpoints, jurisdictions, retention windows, and deletion mechanisms a reviewer can verify.

Tracing the path from configuration, containers, and schemas takes about a day. It supports questions 1, 2, 3, and 9. Cost attribution in question 10 also requires joining request identifiers to usage records and applicable rates; the map alone cannot price a task. Any unresolved <FILL> is a finding, not a documentation nuisance.

A recurring discovery in my reviews is full prompt bodies stored in plaintext because a gateway logging flag defaulted to on. Nobody made an explicit retention decision. The team inherited one.

Ten questions, ten reproducible answers

For each question, name the mechanism and attach an artifact someone else can reproduce. If none exists, record the limit and give the fix an owner.

1. Where does a prompt physically go, and which stores retain it?

Improvised: "Prompts are processed securely and not stored longer than necessary."

Evidence: the data path map above, plus the query that lists retaining stores and a sample row with the sensitive fields redacted.

2. Are embeddings produced anywhere in this path, and where do the vectors live?

Embeddings, the numeric vectors derived from content for search or retrieval, are not anonymous by default. If you produce them, identify the store, access controls, linkage to source records, and whether source deletion removes the vectors. If you produce none, say so and show the relevant configuration.

3. What is retained, for how long, and what actually deletes it?

The trap is the word actually. A retention policy is not a deletion mechanism. If deletion is a cron job, name it. If deletion is manual, say so. If backups outlive the retention window, that is the honest answer and every reviewer already suspects it.

4. Can one decision be reproduced end to end from an identifier, and how long does that take?

The reviewer wants to know whether an incident is investigable. Replay here means reconstructing the recorded trajectory of a past request, not rerunning the model and expecting the same output. The strong answer is a command that takes one request identifier and prints every model call, tool call, policy decision, and effect in order.

Demonstrating that reconstruction in under a minute is persuasive because it replaces several claims with one inspectable record. It does not prove the record is tamper-resistant; question 8 covers that separate property.

5. Which model version and which provider endpoint served a given request?

"We use GPT-class models" fails. Model identifiers change under you, providers deprecate versions, and behaviour drifts between them. The answer is a per-request field, not a paragraph.

6. What are the override points, and are changes to them logged?

Routing config, guardrail policy, tool policy. Who can change them, through what interface, and does the change leave a record. If a policy file can be edited without an audit entry, that is a finding, and it is better coming from you.

7. What stops a destructive action, and what happens when that control is unreachable or throws?

The plain-English requirement is simple: authorize the action before it reaches the system that can perform it.

A scanner limited to prose can miss the structured arguments of a tool call. A harmless sentence can accompany a delete with a wildcard identifier. Check which fields your guardrail actually reads; even inspecting the arguments does not establish the caller’s authority to execute them.

Put a policy broker, a separate service that allows or denies tool calls from explicit rules, in front of the tool server. Evaluate the tool name, caller, arguments, and relevant state. Make it fail closed: if the broker is unreachable or its evaluator throws, the action is denied rather than allowed. The evidence is a fault-injection test that breaks the evaluator and still observes a deny verdict.

8. How would tampering with the audit trail be detected?

Keep an audit copy outside the application’s write permissions. Hash chaining can expose an altered record, but the chain alone cannot establish completeness: someone could remove its tail or rewrite records and recompute the hashes. Protect storage and retain checkpoints outside the writer’s control. Test the specific tampering you claim to detect.

9. What leaves the perimeter, to which jurisdiction, and what is the egress evidence?

Egress is data leaving your controlled environment. Name the destination endpoints, data fields, subprocessors, and jurisdictions, then show the network or gateway records that support the claim. If prompts leave the EU, say so. For some buyers, that answer changes which deployment model is acceptable.

10. What does one unit of work cost, and how is spend attributed?

Increasingly asked by procurement rather than security, and it catches people out. Per-key, per-team, per-task attribution. If a runaway agent loop cannot be capped, say what the blast radius is.

Every proof needs a boundary

Every answer in the pack should carry four fields: the claim, the evidence (file path plus the exact command or query), how a third party reproduces it, and what this does not establish.

That fourth field prevents a narrow test from becoming a broad promise. For example: "This demonstrates policy enforcement at the broker. It does not demonstrate resistance to a compromised broker host." The reviewer can now accept the first claim without assuming the second.

In the reviews I have seen, a disclosed limitation creates a remediation discussion. An overstated claim creates another round of audit. Precision is faster than reassurance.

A five-day first pass

Start with the artifacts that collapse the most questions:

• Day 1. Draw the data path map. Do not guess a single arrow. Read the config, inspect the containers, query the schema. Every <FILL> you cannot resolve is a finding.
• Day 2. Build replay. Take one request identifier and reconstruct the full trajectory from your existing stores. Most teams discover their identifiers do not join across systems, which is itself worth knowing before a reviewer discovers it.
• Day 3. Write the destructive-action control test, including the fault-injection case.
• Day 4. Answer the ten questions, each with the four fields.
• Day 5. Have someone who did not build the system try to reproduce three answers from the commands alone. Whatever they cannot reproduce is not evidence yet.

At the end of the week, the pack will not prove that the entire product is secure. It will give the reviewer a reproducible account of one workflow, its controls, and its known gaps. That is enough to replace many follow-up emails with evidence.

Let one request carry the sales conversation

Once the pack exists, stop saying the system is governable and demonstrate one request. Show the data path, replay its recorded trajectory, inject a control failure, and point to the exact limitation. The buyer can see both the mechanism and its boundary.

Sooner or later, every claim meets a query, a trace or a test. Prepare that meeting before procurement sends the spreadsheet.