A new section is showing up in security questionnaires. After the encryption questions, after the sub-processor list, after the data-residency table, there is now a block about AI governance: Do you use AI in your product? Do you train models on our data? Where does inference run? Can you turn it off?
Two years ago almost nobody asked. Now it is becoming a standard part of customer due diligence — and most vendors are answering it badly.
Why the question arrived all at once
Two forces met. The EU AI Act gave enterprises a regulatory reason to ask their vendors how AI is used and governed. And the explosion of AI features in every SaaS product gave their security teams a concrete worry: the tool we are buying might quietly send our data to a model we never approved.
So the AI section got added to the questionnaire — the same instrument buyers already use to vet your encryption and your data handling. It is not a new process. It is a new column in an old one.
AI governance didn't create a new review. It became a new line item in the review you already struggle to answer.
Why most vendors answer it poorly
The answers come back vague, inconsistent, or quietly alarming. One deal gets told "we don't train on your data"; another gets a hedge because a different person answered. Nobody is sure which is true, because nobody owns the answer.
And often the honest answer is worse than the inconsistent one. A lot of products bolted AI on by piping customer data straight to a third-party model under a consumer account — no data-processing terms, no region control, training left on by default. When the buyer asks "where does our data go," there is no good answer to give.
You can't answer what you didn't build for
This is the part teams miss. AI-governance due diligence is not a writing problem you solve with better questionnaire copy. It is an architecture problem. "Do you train on our data?" and "where does inference run?" have real answers only if your product was built so those answers can be yes-or-no, not "it depends who set it up."
A vendor whose own AI runs on a customer-controlled account, never trains on customer data, and can be pinned to an EU region can answer the AI section in one confident sentence. A vendor who wired AI in without those choices has to either obscure the truth or disclose something a security team won't like.
The same knowledge should answer all of it
Here is the connection worth seeing: the AI-governance questions are not a separate workflow. They are more of the same due diligence — security, privacy, and now AI — landing on the same desk, asked by the same buyers, needing the same property your other answers need. They have to be consistent, sourced, and ready, deal after deal.
The company that answers its security questionnaire from one governed source of truth is the same company that can absorb the AI section without flinching. The one re-assembling answers from inboxes will give three different answers to the AI question too — and on AI, an inconsistent answer reads as a red flag.
The vendor you trust on AI is the one who lives it
When AI governance becomes table stakes in due diligence, credibility flows to the vendors who can answer it plainly because they made the right architectural choices early — bring-your-own AI account, no training on customer data, inference you can keep in your own region or your own walls.
The AI section of the questionnaire is not a threat to those vendors. It is the question they were built to pass. Everyone else is about to find out their answer is "let me check with someone" — three weeks before the deal needed it.