The AI Fact Sheet Buyers Now Want Before They’ll Sign

A six-figure AI pilot can sit frozen for a full quarter because nobody on the vendor's side can answer question seven of a buyer's security review. The model works. The demo lands. Then procurement forwards a 140-item questionnaire, and the sales cycle stops moving while engineering tries to reconstruct, after the fact, how the thing was built.

That stall is the cost nobody prices into the roadmap. Every week the questionnaire sits open, the pilot's champion inside the buyer loses political capital, a competing vendor gets a second look, and the close date slips. The paperwork is the product now, and most teams are shipping the paperwork last. A useful walkthrough of the problem appears in a recent piece on the vendor questionnaire your AI pilot can't answer yet, and the pattern it describes is the one every founder shipping an agent will recognize.

The Security Questionnaire Grew a New Section

Risk teams used to ask about encryption at rest, access control, change management, and incident response. A clean SOC 2 covered most of it, and a competent sales engineer could clear the spreadsheet in an afternoon.

The new section is about the model. Buyers want to know what happens to prompts after inference, who reviews actions the agent takes inside their systems, how prompt injection is caught before it reaches a tool call, and what the rollback plan looks like when the upstream model provider pushes a silent update that changes behavior overnight. Little of that is covered by SOC 2 or ISO 27001. Those audits certify real controls, written for software that tends to do the same thing twice when you give it the same input.

Public frameworks have started filling the space. The NIST framework is the one buyers cite most, and its Generative AI Profile gives risk teams a vocabulary for questions that didn't exist two years ago. If a vendor cannot speak that vocabulary, the review stalls on translation alone.

The Model Card Is Not the Answer Buyers Want

The intuitive fix is to send the base model provider's model card and hope it absorbs the questions. It won't. A model card describes the foundation model at a point in time: its training data at a high level, its evaluation scores on public benchmarks, its known failure modes in generic settings. It says little about the system the buyer is about to run.

The thing in production is a composite. There is a base model, a retrieval layer pointed at specific documents, a set of tools the agent can call, a system prompt that shapes its behavior, guardrails bolted on at the edges, and a logging pipeline that may or may not retain prompts. The risk the buyer cares about lives in the seams between those pieces. A model card from the foundation vendor usually describes one component inside a larger system the foundation vendor has little visibility into.

The pattern is consistent across the deals that stall: the questions assume the vendor has documented the system, not borrowed documentation for one of its parts.

Prepare the Fact Sheet Before Procurement Asks

The teams clearing these reviews fastest have stopped treating the questionnaire as an inbound event. They assemble an AI fact sheet during the build, keep it versioned alongside the code, and hand it over the moment legal and security join the call. It is a short document, and it answers the questions the buyer is going to send before they send them.

• Prompt and output retention. State exactly how long user prompts and model outputs are stored, where they live, who can read them, and whether any of it is used to train or fine-tune a model. If the answer is zero retention, say zero and point to the configuration that enforces it.
• Human review of actions. For an agent that can act inside the buyer's systems, name which actions require a human in the loop, which are reversible, and where sign-off is logged. 'The agent is supervised' is not an answer; a list of specific tool calls that require approval is.
• Prompt-injection detection. Describe the controls that sit between untrusted input and tool execution. Legitimate answers include input classification, output filtering, allow-listed tools, and separate privilege contexts for retrieved content; leaving the question blank reads as 'we haven't thought about it.'
• Model-update rollback. When the upstream provider deprecates a version or ships new weights, say how the system pins to a known version, how regressions are caught, and how quickly the previous behavior can be restored.
• Evaluation and decision logs. Keep the test sets, the eval results, and the decision logs that show why the current configuration shipped. These are the artifacts a diligence team will ask for during an acquisition or a renewal, and reconstructing them later is far more expensive than writing them down as you go.

A fact sheet prepared this way does two things at once. It compresses the review timeline, because the buyer's analyst gets to copy answers into their template instead of chasing them down. And it forces the engineering team to notice, before a customer does, which of these questions they cannot yet answer about their own system. That second effect is where the real work gets done.