What should an AI vendor due diligence questionnaire ask beyond standard security questions?

Why standard security questions miss AI vendor risk

A normal supplier questionnaire is still necessary. You still need to ask about access controls, encryption, incident response, penetration testing, business continuity and subprocessors.

But those questions do not tell you enough about an AI vendor. An AI tool can fail even when the hosting environment is secure. It can produce a confident but wrong answer, expose sensitive context through a weak prompt flow, change behaviour after a model update, or use your data in ways your policy would not allow.

So the better question is not whether to replace your security questionnaire. It is what to add to it.

The extra questions should cover model, data, testing and accountability

An AI vendor due diligence questionnaire should ask for evidence across six areas: model identity, training and customer data use, output quality, adversarial security, privacy and residency, and governance ownership. The goal is to make the vendor explain how the AI system behaves in practice, rather than only checking whether their cloud controls look tidy on paper.

For regulated or professional services firms, this matters because the customer still owns the outcome. If an AI-assisted workflow affects client advice, financial reporting, customer communications, claims handling or internal decisions, you need a defensible record of why the vendor was approved and what controls remain inside your organisation.

Map your AI vendor risks before approval

1. Model identity and change control

Start by asking what model or models power the product. Do not accept a vague answer such as "we use an LLM". Ask for the model name, provider, version, feature mapping and whether different parts of the product use different models.

Then ask how model changes are managed. A vendor should be able to explain how often models are updated, what counts as a material change, how customers are notified, and whether you can test a change before it affects a live workflow.

• Which model powers each AI feature?
• Is the model proprietary, open source, or provided by a third party?
• Can the vendor give notice before a material model change?
• Is there a model card or equivalent technical summary?

2. Training data, customer data and IP position

AI vendor review needs a direct answer on data use. Ask whether your prompts, uploaded files, outputs, feedback or usage logs are used to train or fine-tune any model. If the answer is yes, ask whether you can opt out contractually and technically.

You should also ask what data was used to train or fine-tune the system. The vendor may not disclose every detail, but they should be able to describe the categories of data, licensing position, use of customer interactions, treatment of personal data and approach to copyright or text-and-data mining restrictions.

• Are customer prompts and outputs retained, and for how long?
• Are they used for model training, product improvement, evaluation or support?
• What opt-out rights are available in the contract and product settings?
• What IP indemnity is offered if AI outputs create a rights dispute?

3. Performance evidence and human review

A vendor's accuracy claim is not enough. Ask how performance was tested, what datasets were used, whether the test cases match your use case, and how the vendor measures wrong or unsupported outputs.

This is especially important where the system drafts professional work, summarises records, extracts data, supports decisions or touches customer communications. The vendor should explain where human review is expected, what confidence signals are available, and what failure patterns are known.

• What benchmarks or internal evaluations support the claimed performance?
• Were tests run on domain-specific examples similar to your use case?
• How are hallucinations, omissions and unsupported claims measured?
• What human approval step is recommended before relying on outputs?

4. Prompt injection and AI-specific security

Standard application security testing does not fully cover AI systems. Ask whether the vendor has tested for prompt injection, data exfiltration through retrieval, malicious file inputs, model extraction, data poisoning and unsafe tool use.

If the product connects to email, documents, CRMs, finance systems or case management tools, this question becomes more important. The issue goes beyond whether someone can log in. A hostile input may make the AI take instructions from the wrong place.

• Has the system had AI-specific red-team testing?
• How does it separate user instructions from system instructions and retrieved content?
• What monitoring detects abnormal model behaviour or output drift?
• How are AI-specific vulnerabilities reported and remediated?

5. Data residency, retention and subprocessors

AI systems often move data through more services than buyers expect. A document may pass from your application into a model endpoint, logging layer, evaluation tool, support system and cloud storage region.

Ask where inference happens, which subprocessors receive AI-related data, what is logged, how long logs are retained, and how deletion requests are handled. For UK and EU firms, this should line up with your data protection assessment, client confidentiality rules and contractual commitments.

• Which cloud regions and model endpoints process prompts and context?
• Which subprocessors handle AI inputs, outputs, embeddings or logs?
• Can customer data be deleted from prompts, logs and evaluation datasets?
• Are encryption keys customer-managed or vendor-managed?

6. Governance evidence and contractual commitments

The vendor should be able to show how AI risk is owned internally. Ask for governance documents, risk assessments, incident procedures, audit reports, model cards, DPIAs where relevant and any alignment with standards such as ISO/IEC 42001.

For financial services, insurance, legal and accountancy use cases, connect this back to your own obligations. You may need evidence for Consumer Duty, SM&CR accountability, client confidentiality, privilege, data protection, audit trail and quality review. Vendor answers should make those checks easier, not push them back to your team as guesswork.

Set up a practical AI governance operating model

How to score the answers

Do not treat the questionnaire as a box-ticking exercise. Score each answer against three tests:

• Clarity: did the vendor answer the question directly?
• Evidence: did they provide documents, settings, reports or contractual terms?
• Fit: does their control match the sensitivity of your intended use case?

Red flags include vague claims of proprietary secrecy, no training data explanation, no opt-out from customer data training, generic benchmark claims, no AI-specific testing, unclear subprocessors and refusal to give meaningful incident notification commitments.

A practical approval checklist

Before approving an AI vendor, your internal record should show:

• the intended use case and data categories;
• the vendor's model and subprocessors;
• how prompts, files and outputs are retained or used;
• the main output risks and human review controls;
• the contractual position on training, confidentiality, IP and incidents;
• the named internal owner for ongoing monitoring.

That is enough to turn vendor due diligence from a one-off procurement form into a control your team can revisit when the vendor changes its model, terms or product behaviour.

Build the approval workflow for AI tools

Conclusion

Your AI vendor questionnaire should still include standard security questions, but it cannot stop there. The important additions are about how the model works, what data it uses, how outputs are tested, what happens when the model changes, and who is accountable when the system fails.

If the vendor can answer those questions with evidence, you have a stronger basis for approval. If they cannot, the risk has not disappeared. It has simply moved from the vendor's sales process into your operating model.