The Vendor Questionnaire Your AI Pilot Can’t Answer Yet
Your pilot works. The model is responding in-tone, the stakeholders nod along, the demo lands. Then procurement sends a security questionnaire with 140 questions of the original paying customer, and no one in the team is able to answer question seven.
Most AI projects stall at the moment between the actual distance that is required to be covered between a pilot that requires work and a pilot that a buyer can actually purchase. Model quality isn’t the problem. The issue is the paperwork that a risk team of a buyer requires before a single signature, and assumptions that founders make during such talks that turn out to be incorrect.
The AI Questions are not covered in a SOC 2.
A SOC 2 report is about the way you operate a company, and not how you operate a model. It addresses access control, change management, in-rest encryption and vendor review. None of that tells what a buyer today may wish to know about the model itself: what it has been trained on, whose input it can respond to, what it can do without, or what it does when it has made an inference.
Risk teams have caught up. The questions coming through sound like these: does the model retain prompts, is there a human-review step for outputs that trigger an action, how do you detect prompt injection, and what’s your rollback plan when the base model provider pushes an update. A SOC 2 says nothing about any of that. Teams running a serious pilot are starting to publish a separate AI fact sheet that sits next to the SOC 2, and some are moving toward a private LLM stack specifically so the answers to those questions are ones they control rather than inherit.
The Vendor’s Model Card Is Not Enough
It is efficient to point the buyer towards documentation of the base-model provider. It hardly fills the questionnaire. The customer does not want to know what the general functionality of the base model is. They want to know how their deployed system manages their data, who is using it, and their workflow attached to it.
Buyer-side reviewers want specifics about your implementation:
- Data flow. Where the prompt goes, what gets logged, how long logs live, and whether anything leaves the customer’s region.
- Fine-tuning posture. Whether their inputs ever influence a model that serves other customers.
- Tool permissions. What the model is allowed to call on its own, with what credentials, and under what approval.
- Human review. Which outputs require a person in the loop before anything in the customer’s systems changes.
The upstream card is background. The answers have to be about your product.
Prompt Injection Has Moved Out of the Research Lab
Prompt injection takes the first place in the OWASP LLM Top 10 and was not displaced. Any pilot accessing an untrusted data, such as email messages, PDF files, scrapped web pages, or support tickets, has an attack surface the questionnaire will directly investigate.
Whether you stop injecting immediately is hardly ever a question, since no one truly does that. It involves what you do regarding it: should the input be isolated, should an output be filtered, what constraints are placed on which tools can be invoked without human intervention by the model, and how do you know when a model is operating outside the usual envelope. A pilot, who is able to explain those controls in everyday language, passes. A pilot that contributes a base model name does not.
Compliance – Not after the Deal.
Another assumption founders make has been using regulatory questions on the buyer, rather than on the vendor. This ceased to be the case when deployer requirements began trickling down in contracts. Article 26 of the EU AI Act details what must be carried out by the deployer of a high-risk system: human oversight, monitoring, retention of logs, incident notification to the providers and authorities. The paper places those obligations upon the vendor by the buyers.
You will be questioned to keep inference logs long enough to help the buyer in retention responsibility. The ability to inform them about a severe event within a specific period of time. Whether you can fix so well on the intended purpose of the system that they can turn it over to their own regulator.
All this cannot be answered at the eleventh hour. Only when someone had constructed the logging, and the notice workflow and the documentation into the pilot even when the pilot was still enjoyable to work on do you hold it accountable.
A Longer Questionnaire Does Not Mean a More Serious Buyer
The length informs you, not what founders tend to think. Majority of enterprise buyers are not making single customized documents. They are sending the pile of questionnaires that their TPRM program already runs on each vendor with AI-specific addenda over the top. It is not an indicator that your product is special, but rather the system itself that is known as the sprawl.
The action plan approach is to cease regarding every questionnaire as a one-off writing task. Arrange an internal answer library is used to arrange how reviewers query: data handling, model lifecycle, access control, incident response, autonomy and tool use, third party dependencies and change management. Assign answers to evidence files, policy snippets, drawings, log snippets, and so on, so that the 55 questions form takes a day rather than a sprint. Purchased pilots are those that had discussed the questionnaire as a product requirement early in the process, and not as a shocking revelation at the finish line.
