An AI vendor due diligence checklist for enterprise control: intended use, data handling, security, model oversight, contract terms and ongoing assurance.
Topics: AI Governance, Vendor Risk, EU AI Act, Due Diligence, Privacy Operations
An AI supplier can enter the business through a single team purchase, then quickly become embedded in customer service, HR, marketing, software development or decision-making. That is why an AI vendor due diligence checklist must establish more than whether the supplier has a security certificate or an acceptable privacy notice. It must show what the AI system does, what data it uses, who is accountable, and whether the organisation can maintain control once the service is live.
For privacy, legal, risk and security leaders, the goal is a repeatable approval process that produces evidence. The process should support proportionate decisions: a low-risk productivity tool does not warrant the same scrutiny as an AI system that influences recruitment, credit, healthcare, access to services or other consequential outcomes. But neither should be approved on the basis of a sales demonstration.
Start with the intended use, not the vendor questionnaire
The most useful due diligence begins inside the organisation. Before sending questions to a vendor, define the proposed use case in operational terms. Identify the business owner, users, affected individuals, decision points, data categories, integrations and jurisdictions involved. Clarify whether the AI produces suggestions for human review, automates an action, or materially influences a decision.
This distinction changes the control requirements. A generative AI assistant used to draft internal communications may present confidentiality and intellectual property risks. A system used to rank job applicants brings stronger fairness, transparency, human oversight and legal considerations. A vendor cannot provide a meaningful answer about suitability without understanding the intended deployment.
Record this information in an AI system registry from the outset. The registry should connect the use case to its owner, vendor, processing activities, risk classification and assessment history. For organisations operating in or serving the EU, it also provides a practical foundation for assessing obligations under the EU AI Act, including whether the intended use could fall within a prohibited, high-risk or transparency-related category.
AI vendor due diligence checklist: the control areas
A checklist should be structured around the evidence needed to make and defend an approval decision. The following areas create a practical baseline for most enterprise AI procurements.
1. Supplier identity, governance and accountability
Establish who is actually providing the service. This can be less straightforward than it appears where a familiar software provider layers third-party models, cloud infrastructure, annotation services or specialist data providers into its offering.
Confirm the contracting entity, corporate location, hosting locations, material subcontractors and the parties that process data or provide model functionality. Ask who owns security, privacy, AI governance, incident response and customer support. A supplier should be able to identify accountable roles and explain how concerns about model performance, harmful outputs or customer data are escalated.
Also assess financial and operational resilience. A service that supports a critical process needs credible continuity arrangements, support commitments and a clear position on what happens to data, configurations and records when the contract ends.
2. Data flows and privacy controls
Map the data journey rather than accepting broad statements that data is “protected”. Determine what information enters the system through prompts, uploads, APIs, connectors, telemetry and user feedback. Identify whether the supplier receives personal data, special category data, confidential business information, source code or regulated records.
The key questions are practical. Is customer data used to train, fine-tune or evaluate a shared model? Is this disabled by default, contractually prohibited, or merely configurable? How long are prompts, outputs and logs retained? Can the organisation set retention periods, delete records and retrieve evidence of deletion? Where are data transfers made, and what transfer safeguards apply?
The answers should feed directly into the organisation's ROPA and, where processing is likely to create a high risk to individuals, its DPIA. If the proposed use relies on legitimate interests, the assessment should also connect to a documented Legitimate Interest Assessment rather than treating procurement as a separate exercise.
3. Security architecture and access management
AI services often widen the attack surface because they connect to internal knowledge bases, collaboration platforms and production systems. Assess the service as an operational component, not as an isolated web application.
Review identity and access controls, including single sign-on, multi-factor authentication, role-based permissions, privileged access and user provisioning. Establish whether the organisation can restrict access to approved teams, prevent unmanaged accounts and remove access promptly when staff change roles.
Ask how the supplier protects data in transit and at rest, separates customer environments, manages vulnerabilities and monitors for suspicious activity. Evidence may include relevant certifications, test summaries, security policies, incident procedures and independent assurance reports. Documents matter, but they do not replace questions about the specific deployment. A secure platform can still be poorly configured or given excessive access to internal systems.
4. Model behaviour, testing and human oversight
A vendor should be able to explain the model or models used, their intended capabilities and known limitations. This does not always mean full disclosure of proprietary model details. It does mean providing enough information for the organisation to understand reliability constraints, expected failure modes, content safeguards and the basis for material outputs.
Evaluate how the supplier tests accuracy, bias, harmful content, prompt injection, data leakage and resilience against misuse. Where the system makes recommendations about people, ask how performance is measured across relevant groups and under realistic operating conditions. Generic benchmark claims are rarely enough.
Human oversight must be designed into the business process. Define who reviews outputs, when escalation is required, which actions cannot be automated and how users can challenge or correct an outcome. The appropriate level of review depends on impact. High-volume, low-consequence tasks may use sampling and exception handling; consequential decisions need stronger review and documented accountability.
5. Legal terms, audit rights and change control
The contract must reflect the actual service. Confirm the controller-processor allocation where personal data is involved, and ensure the data processing agreement covers instructions, confidentiality, security, sub-processors, international transfers, assistance with rights requests and breach notification.
For AI-specific risk, address ownership and permitted use of inputs and outputs, training restrictions, intellectual property claims, confidentiality, indemnities where appropriate, and the supplier's duty to notify the customer of material service changes. Model substitutions, new sub-processors, altered data retention, expanded training uses or a changed hosting region can alter the original risk assessment.
Audit rights should be realistic. Not every customer will gain on-site access to a global vendor's facilities, but the organisation should have defined access to relevant assurance information, incident reports, remediation evidence and a route to investigate material concerns. The contract should also establish exit assistance, deletion requirements and the format for returning customer data.
6. Incident response and ongoing assurance
Due diligence is not complete at signature. AI systems change frequently, usage expands and vendors update models, terms and data practices. Assign an internal service owner who is responsible for confirming that the approved use remains the actual use.
Set review triggers rather than relying only on annual reassessments. Triggers should include a new integration, use of new data categories, a material model update, a security event, a substantiated complaint, unexpected output behaviour or a move into a higher-impact decision process. These events may require an updated DPIA, contract review, AI risk classification or security assessment.
The organisation also needs a clear route for reporting issues. Users should know how to report harmful, inaccurate or confidential outputs, while security and privacy teams need a coordinated process for supplier incidents. Link this process to breach and incident management so that investigation, notifications, decisions and evidence are handled in one controlled workflow.
Turn the checklist into an approval decision
A questionnaire without a decision model creates delay and inconsistent outcomes. Define approval states such as approved, approved with conditions, pending remediation or rejected. Conditions may include disabling training on customer data, limiting the use case, introducing human review, completing a DPIA, or obtaining a contractual amendment before launch.
Risk acceptance should be explicit. The business owner can explain the value of the use case, but privacy, security, legal and risk stakeholders need clear authority to set conditions or prevent deployment where controls are insufficient. Document who approved the decision, the evidence considered, the residual risks and the date for review.
For organisations managing a growing vendor estate, this is where a unified governance system becomes valuable. Privacy360 can connect vendor assessments with AI system records, DPIAs, ROPA entries, contract reviews and incident evidence, avoiding the gaps created when each team maintains a separate spreadsheet or mailbox.
The best due diligence process does not treat AI procurement as a one-time compliance hurdle. It gives the organisation a controlled way to adopt useful technology while retaining visibility over data, decisions, suppliers and change. That discipline makes faster approvals possible because the evidence, ownership and escalation path are already in place.