Why standard security questions miss AI vendor risk
Add AI-specific questions to the usual security review: which models and suppliers handle the data, whether customer content is used for training or evaluation, how outputs are tested, and what changes the vendor can make without notice.
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.
Keep the existing security questionnaire and add questions about the AI features, data flows and proposed tasks.
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 client advice, financial reporting, customer communications, claims handling or internal decisions, identify the responsibilities retained by your firm and those allocated to the supplier. Record the evidence considered, approval conditions and internal controls. Allocation depends on the use, contract and applicable duties; this checklist does not determine legal liability.
Map your AI vendor risks before approval
1. Model identity and change control
Ask for the model name, provider, version and feature mapping, including whether different features use different models. Where exact identifiers are unavailable or confidential, request an equivalent technical description, supported change-control evidence and any disclosure restrictions. Record what remains unknown and assess whether that uncertainty is acceptable for the proposed use.
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.
Ask what the supplier can evidence about training and fine-tuning data categories, licensing, customer interactions, personal data and copyright or text-and-data mining restrictions. Full training-set provenance may not be available. Document disclosure limits, the evidence offered and any unresolved rights or data-use risk; a questionnaire answer is not a finding that the training data was lawfully obtained.
- 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
Map whether a document passes through model endpoints, logging, evaluation, support or cloud storage, and which supplier controls each stage. Confirm the provider's role for each processing activity; the term sub-processor only fits a processor arrangement.
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.
Ask the firm's responsible reviewers which requirements apply to the proposed financial, insurance, legal or accountancy use. Link supplier questions to those requirements and the evidence needed for the approval decision, rather than treating a generic questionnaire as compliance proof.
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?
Record gaps in model or training-data evidence, customer-data opt-outs, relevant benchmarks, AI-specific testing, supplier roles and incident commitments. Assess each gap against the task and data sensitivity. Missing opt-out or limited disclosure may rule out a confidential-data use without automatically ruling out every separately assessed non-personal public-data task. Do not infer acceptable use from the public-data label alone.
A practical approval checklist
Before approving an AI vendor, your internal record should show:
- the intended use case and data categories;
- the model and supplier-role evidence available, with any identity or disclosure gaps;
- 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.
Assign owners to unresolved items and define which model, term or product changes require reassessment. The six-item record is a starting point; it does not establish that due diligence is sufficient for the intended use.
Build the approval workflow for AI tools
Conclusion
Before approval, reconcile the six questionnaire areas with the intended workflow. Identify any answer that lacks usable evidence, assign a reviewer and record whether the affected use is paused, restricted or ready for the next approval step.
Keep unresolved limitations visible in the approval record. Evidence supports a decision but does not remove the need for internal controls, testing and reassessment.
Need a safer AI route for your firm?
If this article reflects a live decision in your practice, the useful next step is to map the workflows, confidentiality risks, supplier controls and governance gaps before tools spread informally.
