Most organisations are asking AI vendors the wrong questions. They are asking about features, pricing, and integration. They are not asking about data residency, training opt-outs, audit rights, and incident notification. By the time those questions become urgent, the contract is signed and the data is already flowing.
Enterprise procurement processes for software have matured significantly over the past decade. Security questionnaires, data processing agreements, penetration test evidence, and ISO 27001 certificates are now standard requirements for most enterprise software vendors. AI procurement has not kept pace. The questions being asked of AI vendors frequently do not reflect the specific and material risks that AI tools introduce, and the answers being accepted are often not adequate to those risks.
This piece sets out what a thorough AI vendor assessment should cover, why each element matters, and what acceptable answers look like. It is intended as a practical guide for procurement teams, security functions, and legal teams who are being asked to assess AI vendors and need a framework that goes beyond the standard software questionnaire.
Why Standard Vendor Assessment Falls Short for AI
A standard enterprise software vendor assessment focuses on questions that are relevant to any software system: security certifications, penetration testing, vulnerability management, business continuity, data centre security, and subprocessor arrangements. These questions remain relevant for AI vendors. They are not sufficient.
AI tools introduce a category of risk that does not arise with conventional software: the risk that data submitted to the AI will be used to train future models, retained beyond the period required for the immediate transaction, processed in jurisdictions that create legal or regulatory exposure, or made accessible to third parties in ways that the standard data processing framework does not contemplate.
There is also the question of model behaviour. Conventional software does what it is configured to do. AI systems produce outputs that are probabilistic, context-dependent, and not fully predictable. The risk that an AI system will produce inaccurate, biased, or harmful outputs, and the question of who is liable when it does, requires specific contractual treatment that standard software agreements do not provide.
Data Processing: The Questions That Matter
The first and most important question for any AI vendor is what happens to the data you submit. The answer needs to be specific, binding, and verifiable. Vague assurances about taking privacy seriously are not acceptable. The following are the specific commitments you need.
Training opt-out. Does the vendor use customer data to train or improve their models? If so, is there an opt-out, and is that opt-out available under standard commercial terms or only under enterprise agreements? The default position of many consumer-grade AI tools is that submitted data may be used for training. This is frequently incompatible with enterprise data protection obligations and must be addressed contractually before deployment.
Retention periods. How long does the vendor retain data submitted to the AI, including prompts, responses, and any intermediate data generated during processing? Retention beyond what is necessary for the immediate transaction requires justification and must be compatible with your own data retention obligations under UK GDPR.
Data residency. Where is data processed and stored? For organisations with data residency requirements, whether arising from regulation, contract, or internal policy, the vendor must be able to commit to processing within specified geographic boundaries. Commitments about where data is stored are not the same as commitments about where data is processed, and both matter.
Subprocessor arrangements. Which third parties does the AI vendor use to provide their service, what data do those subprocessors access, and where are they located? AI services frequently rely on cloud infrastructure, model providers, and specialist processing services that are themselves based in multiple jurisdictions. The full subprocessor chain needs to be disclosed and assessed.
International Transfers: Getting Beyond the Surface Answer
Many AI vendors will tell you their data is stored in UK or European data centres. This is often true and often insufficient. The question of where data is processed is distinct from where it is stored, and the answer to the processing question frequently involves infrastructure in the United States or other jurisdictions that create legal exposure.
US-headquartered AI providers, regardless of where their servers are located, may be subject to US government access demands under legislation such as the CLOUD Act. This is a sovereignty risk that data residency commitments alone do not address. Organisations processing data that is sensitive from a national security, commercial confidentiality, or regulatory perspective need to understand this exposure and assess whether it is acceptable given the nature of the data being processed.
The appropriate contractual mechanism for international transfers from the UK is the International Data Transfer Agreement or, where transfers are to jurisdictions covered by an adequacy decision, reliance on that decision. Vendors should be able to specify which mechanism applies to their processing arrangements and provide the relevant documentation. If they cannot, that is a significant gap.
Audit Rights: The Commitment That Reveals the Vendor
Under UK GDPR, data controllers have the right to audit their data processors to verify compliance with data protection obligations. In practice, most large AI vendors do not offer direct audit rights. They offer third party audit reports, typically SOC 2 Type II or ISO 27001 certificates, as a substitute.
This is often reasonable for large, established vendors with mature security programmes. The question is whether the scope of the available audit evidence covers the specific risks you are seeking to verify. A SOC 2 report that covers the vendor's production infrastructure but does not cover their model training environment, their subprocessor arrangements, or their data deletion processes is providing assurance over a subset of what you need to verify.
For smaller or newer AI vendors that do not yet have mature third party audit evidence, the absence of audit rights is a more significant concern. The willingness of a vendor to engage constructively on audit arrangements, even where direct audit is not commercially practical, is a reasonable indicator of their maturity and transparency. Vendors who are unwilling to discuss audit rights at all warrant caution.
Incident Notification: What the Contract Needs to Say
UK GDPR requires data controllers to notify the ICO of personal data breaches within 72 hours of becoming aware of them. That notification window starts from when the controller becomes aware, which in the case of a breach at a data processor may be significantly later than when the breach actually occurred.
Your contract with an AI vendor acting as a data processor must require them to notify you of any personal data breach without undue delay and in sufficient time for you to meet your own notification obligations. The contract should specify what constitutes a notifiable incident, the information that must be included in the notification, and the channel through which notification will be made.
Beyond personal data breaches, consider whether your contract addresses security incidents that do not involve personal data but could affect the integrity or availability of the AI service, and incidents involving model compromise or manipulation that could affect the reliability of outputs.
Model Behaviour and Liability
AI systems produce outputs that are not fully predictable. They hallucinate. They reflect biases present in their training data. They can be manipulated through prompt injection. They may produce outputs that are factually incorrect, legally problematic, or commercially damaging. Standard software vendor agreements typically exclude liability for consequential loss and cap direct liability at a multiple of annual fees. These limitations were designed for software that does what it is configured to do. They may not be appropriate for AI systems whose outputs are used to inform decisions.
The liability position needs to be considered in the context of how the AI's outputs will be used. Where outputs will be reviewed by a human before acting on them, the standard liability framework may be adequate. Where outputs will be acted on autonomously or with minimal human review, the liability question deserves more careful attention and potentially bespoke contractual treatment.
Regulated organisations should also consider whether the use of AI outputs in their business processes engages any sector-specific requirements around model explainability, auditability, or human oversight that need to be reflected in the vendor contract.
A Practical AI Vendor Assessment Checklist
Data processing: Confirm whether customer data is used for model training and whether a binding opt-out is available. Obtain the data processing agreement and verify it meets UK GDPR processor requirements. Establish retention periods for prompts, responses, and intermediate data.
Data residency and transfers: Establish where data is processed as well as where it is stored. Identify the international transfer mechanism in use. Assess US government access risk for US-headquartered providers. Obtain the full subprocessor list and assess each subprocessor's location and role.
Security assurance: Obtain current ISO 27001 certificate or SOC 2 Type II report. Verify the scope covers the processing activities relevant to your use case. Confirm penetration testing frequency and obtain summary findings. Assess vulnerability management and patch deployment processes.
Audit rights: Establish what audit rights are available under the proposed contract. Obtain and review available third party audit evidence. Identify any gaps between the scope of available evidence and the risks you need to verify.
Incident notification: Confirm contractual notification obligations including timescales and content requirements. Establish the notification channel and escalation path. Verify that the notification obligation covers the categories of incident relevant to your use case.
Liability and model behaviour: Review liability limitations in the context of how outputs will be used. Assess whether sector-specific requirements around model explainability or human oversight need to be addressed contractually. Consider whether bespoke indemnity provisions are appropriate for high-consequence use cases.
The Bottom Line
AI vendor assessment is not a checkbox exercise. It is a substantive due diligence process that requires specific knowledge of the risks AI tools introduce and the contractual mechanisms available to address them. The organisations that get this right are those that involve security, legal, and data protection functions in the procurement process from the outset, not after the commercial decision has been made.
The AI vendor market is moving quickly. Standards are evolving. Regulatory expectations are developing. A vendor assessment approach that was adequate twelve months ago may not be adequate today. Building AI-specific assessment capability is an investment that pays for itself the first time it prevents a poorly assessed vendor from processing your most sensitive data under inadequate contractual protections.
If you are procuring AI tools and want to ensure your vendor assessment process is fit for purpose, or if you have existing AI vendor relationships that have not been assessed to this standard and want to understand your current exposure, we can help.
