Your Security Questionnaire Now Has an AI Section. Most Teams Are Not Ready.

The vendor security questionnaire used to be a predictable exercise. SOC 2 Type II report, check. Encryption at rest and in transit, check. Penetration test summary, check. Your security team has answered these questions enough times that the responses practically write themselves.

Then procurement started adding an AI section.

What the Questions Actually Look Like

The phrasing varies, but the intent is consistent. Procurement wants to know how you evaluate and monitor AI-generated outputs before they reach users. They want to know what technical controls prevent sensitive or regulated data from passing through your model endpoints. And increasingly, they want ninety days of documented evidence that your AI governance policy is actually being enforced and not just filed somewhere on Confluence.

These are not gotcha questions. They are the same questions any mature security program would ask about any data processing system. The problem is that AI systems inside most SaaS products were not built with those questions in mind.

Why Teams Get Stuck

The controls either do not exist yet, or they exist informally. A senior engineer knows roughly what the system does with user data before it hits the model. There is probably a Slack thread from eight months ago where someone decided not to log certain fields. There may even be a policy document. But none of it is written in language that maps to a regulatory framework, and none of it produces evidence on a schedule.

When procurement asks the question and your team forwards it to engineering, engineering gives an accurate description of what the system does. That description then goes back to procurement, and procurement sends it to their legal team, and legal looks for a framework citation and finds nothing, and the deal sits in a queue while everyone figures out what to do next.

Procurement is not trying to be difficult. They are trying to satisfy their own auditors, and their auditors want citations, not explanations.

What a Citable Answer Looks Like

The difference between an answer that moves a deal forward and one that stalls it comes down to whether you are describing a control or describing a vendor.

A response that describes a vendor sounds like this: your company uses a particular AI platform that has its own trust and safety documentation, and you have reviewed that documentation and are satisfied with it. That answer tells the procurement team you do not actually understand the control surface. It tells their legal team there is nothing to cite. It reads like a sales pitch, not a security posture.

A response that describes a control sounds like this: outgoing model responses pass through an evaluation layer before delivery, which classifies each output and routes it to one of three dispositions depending on content and confidence threshold. The evaluation criteria are defined in policy, the policy is version-controlled, and the outcomes are logged with enough detail to reconstruct the decision for any given response within the retention window. If they want to know which regulation that satisfies, you tell them: NIST AI RMF Govern 1.1, or EU AI Act Article 72, or HIPAA Section 164.312(b) depending on what their vertical requires.

That is not a harder answer to write. It is a different way of thinking about what you built.

The Framework Citation Problem

Most AI governance documentation inside SaaS companies was written for internal audiences. It describes what the system does in engineering terms. It was not written to map onto HIPAA, the EU AI Act, or the NIST AI Risk Management Framework, so it does not.

That is fixable, but it requires someone with enough familiarity with those frameworks to do the mapping. HIPAA’s audit control requirements under 164.312(b) cover activity review for systems that create, transmit, or receive protected health information. If your model endpoint receives PHI and you have logging in place, you may already satisfy that requirement. You just need to say so in the right language.

The EU AI Act’s transparency obligations under Article 72 apply to general-purpose AI systems above certain capability thresholds and require documentation of training data, evaluation results, and risk mitigation measures. If your product uses a third-party foundation model, you need to understand which obligations fall on you as the deployer versus the provider.

NIST AI RMF is the most practically useful framework for this purpose because it is voluntary, domestically recognized, and organized around governance, mapping, measurement, and management in a way that maps cleanly onto how security teams already think about risk. Citing it tells the procurement team you have a structured approach. It does not require you to certify anything.

The Ninety-Day Evidence Problem

The evidence question is where most teams get into real trouble, because evidence requires a system that produces evidence on a schedule, and most informal AI governance does not.

If your AI policy enforcement produces no logs, no reports, and no review records, you cannot answer the question honestly without admitting that. If you try to reconstruct ninety days of evidence after the question arrives, you are not answering the question, you are creating the appearance of an answer, and any auditor worth the title will recognize it.

The path forward is to treat your AI governance controls the way you treat the rest of your security controls: define them, implement them in a way that produces artifacts, and review those artifacts on a cadence.

What This Means for Deals in Flight

If you have a deal that is currently stalled on the AI security section of a vendor questionnaire, the immediate problem is not your controls. It is your documentation. Start by writing down what actually happens to user data before it reaches a model endpoint, what happens to model outputs before they reach users, and what logging exists for both. Write it in complete sentences, not bullet points. Then find the framework language that maps to each control.

That documentation will not close the gap between informal controls and real controls. But it will tell you which gap you are actually trying to close, and it will give procurement something to show their legal team while you close it.

The teams that figure this out first will have a genuine competitive advantage. Vendor security questionnaires travel. Your answers to one enterprise prospect tend to become the baseline that the next one starts from.