Vendor security questionnaires were built for a world in which a supplier held your data, processed it according to a contract, and either protected it adequately or did not. The questions follow from that model: where is it stored, who can access it, how is it encrypted, what happens at termination. A supplier that has embedded a model into its product does something the questionnaire has no question for. It takes your data and uses it to influence a decision, and the interesting risk is not whether the data leaked. It is whether the decision was any good, and whether anyone can tell.
Your standard diligence pack asks whether the vendor can protect your data. It does not ask what the vendor's software concluded from it, who checked, or what happens when it is wrong
This is the year that gap starts producing findings, because almost every product in your estate has added model features since the last renewal.
The questions worth adding
Seven, and they replace rather than supplement the vague artificial-intelligence section most questionnaires have bolted on. Which model, whose, and where does inference run? A specific answer naming the provider and the region. Vague answers here usually mean the vendor does not know either. Is our data used for training or improvement? In the contract, not the marketing page. Include evaluation, fine-tuning and human review of outputs, which are frequently excluded from the training denial. Can we turn it off? A feature that cannot be disabled per-tenant is a feature you have adopted whether or not you decided to. What happens when the output is wrong? The realistic answer is usually nothing contractual. Knowing that is still useful, and it tells you where to keep a human. Do we see the inputs and outputs? If you cannot log what the vendor's model was given and what it produced, you cannot investigate anything later. What is the change process? Model versions and prompts change without release notes at most vendors. Ask whether you are notified, and expect the answer to be no. Who else is in the chain? The vendor's model provider, its hosting provider, and any intermediary. Each is a party to your data.
| Area | Question to resolve |
|---|---|
| Model and inference | Which model provider and processing region are used? |
| Data use | Does the contract cover training, improvement, evaluation and human review? |
| Disable control | Can the feature be disabled for your tenant? |
| Wrong output | Who reviews errors and what responsibility is agreed? |
| Evidence | Can inputs and outputs be accessed for investigation? |
| Changes | How are model and prompt changes communicated? |
| Provider chain | Which other parties process the data? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Tier the effort, because you cannot do this for everything
The practical split is by what the feature touches and what it decides. A model summarising meeting notes in a collaboration tool is low risk. A model scoring a credit application, ranking candidates, classifying a transaction or drafting customer correspondence is not, regardless of the vendor's size. Run the full set of questions where the output influences a decision about a person or a payment. Everywhere else, ask the training question and the disable question and move on.
The contract clauses that matter
No training on your data, defined broadly. Notification of material model changes. A right to disable. Logging access sufficient for investigation. And an allocation of liability that at least acknowledges the output exists — most current terms disclaim it entirely, which is a negotiating position rather than a law of nature.
Practical Guidance for AI Vendor Diligence Framework
- Ask which model, whose, and in what region — specifically.
- Get the no-training commitment in contract, covering evaluation and review.
- Require a per-tenant disable switch for every model feature.
- Tier diligence by decision impact, not vendor size.
- Secure logging access to inputs and outputs.
- Demand notification of model changes, and expect resistance.
- Map the full provider chain behind the vendor.
- Re-examine existing vendors; the features arrived after you signed.
The Regional Angle
The first issue is the residency question, which regional diligence usually asks about storage and almost never about inference. A vendor can hold your data in a Gulf region data centre entirely correctly and route every model call to a processing location on another continent, because the model endpoint was a separate architectural decision made by a different team. For organisations under Saudi, Emirati or Qatari data protection regimes — and particularly for regulated financial entities with explicit hosting conditions — that distinction is the whole compliance question. Add the inference location as a named item in the diligence pack, get it in writing, and re-ask it at renewal, because vendors change model providers more often than they change hosting. The second concerns a structural feature of regional procurement: much enterprise software here is bought through a local reseller or implementation partner rather than directly from the vendor. Those intermediaries frequently cannot answer any of the seven questions, because they did not build the product and have no channel to the people who did. Worse, the contract is often with the partner, which means the commitments you negotiate bind an entity that cannot deliver them. Insist on either a direct addendum with the principal vendor covering the model terms, or a written confirmation from the vendor that the partner is authorised to give them. This is the single most common gap in regional vendor files. The third is about sector concentration and the questions regulators here are beginning to ask. A large share of significant regional enterprises are banks, insurers, telecommunications operators, healthcare providers and government-linked entities, all operating under supervisory frameworks that treat outsourcing and technology risk as board-level matters with named accountability. Supervisors in the Gulf are already asking institutions to identify where automated decision-making affects customers, and the honest answer for most is that nobody has enumerated it, because the features arrived inside existing products. Build that inventory now — which of your suppliers' products contain a model that touches a customer outcome — because it is the first thing a supervisor will request and it takes weeks rather than days to assemble.
The objection worth taking seriously
The strongest objection is that this makes an already sclerotic process worse. Vendor diligence in most organisations is a bottleneck that delays useful purchases by months, the questionnaires are answered by sales engineers copying boilerplate, and nobody reads the responses after the file is closed. Adding seven questions to a document nobody reads produces no risk reduction and real delay, and the honest alternative is to accept that model features are now a general characteristic of software, apply your existing standards, and stop pretending a questionnaire ever prevented anything. The critique of questionnaire theatre is accurate and widely deserved. The reason to persist is that two of these questions are not questionnaire questions at all — they are procurement decisions with immediate operational consequences. Whether you can disable the feature per tenant and whether you can log its inputs and outputs determine what you are able to do after something goes wrong, and both must be settled before signature because neither can be added later. If the full set is too heavy for your process, drop five of them. Keep the disable switch and the logging access, put them in the contract, and apply them only where the output affects a person or a payment. That is two questions on a small subset of purchases, which no honest account can call a bottleneck.
Common Questions
Do we need to re-assess existing vendors?
Yes, at least for the ones whose products now include model features you did not evaluate. That is most of them, which is why tiering by decision impact matters.
Will vendors accept a no-training clause?
Most enterprise vendors now will, because competitors offer it. The harder negotiations are change notification and any liability for output.
What if the vendor cannot say where inference runs?
Treat that as the answer. A vendor without that information does not control its own data flows, whatever the hosting page says.
What should we expect over the next twelve months?
Expect model features to appear in essentially every enterprise product renewal, mostly enabled by default. Expect standard diligence frameworks and industry questionnaires to publish artificial intelligence modules during this year and next. Expect Gulf supervisors to ask regulated entities to inventory automated decision-making. And expect the first regional enforcement interest to concern inference location rather than training.
AI Vendor Diligence Framework — we replace the boilerplate section with the few questions that change what you can do after something goes wrong.