How to run AI supplier due diligence that tests data use, accountability, security and contractual evidence before a vendor is embedded.
Topics: AI Governance, Vendor Risk, Procurement, EU AI Act, Due Diligence
A supplier may present an AI capability as a minor product enhancement, yet it can introduce new data flows, model dependencies, security exposures and accountability gaps across the organisation. AI supplier due diligence gives privacy, legal, security and procurement teams a controlled way to establish what is being bought, what data is involved, and who remains accountable once the service is in use.
For enterprise teams, the challenge is not simply determining whether a supplier has an AI policy. It is translating supplier claims into evidence that supports a defensible decision. That requires a repeatable process linked to procurement, privacy assessment, contract review, risk ownership and ongoing monitoring.
Why conventional vendor reviews are no longer enough
Traditional third-party assessments focus on information security, financial stability, data processing terms and general compliance controls. Those remain necessary. However, AI suppliers can create additional governance questions that do not fit neatly into a standard security questionnaire.
A provider may use customer inputs to improve a model, rely on multiple sub-processors for model hosting and inference, or change model behaviour through updates that do not require a new implementation. A supplier can also offer an apparently low-risk tool while integrating generative features that process confidential business information, employee data or customer communications.
The point is not to treat every AI-enabled supplier as high risk. It is to apply assessment depth proportionately. A tool that creates internal meeting summaries warrants a different review from an AI system that supports recruitment decisions, fraud detection, customer profiling or access to regulated services. The organisation needs clear criteria for making that distinction, rather than relying on the confidence of a product demonstration or a generic assurance statement.
Start AI supplier due diligence before selection is final
The most effective AI supplier due diligence begins before commercial commitments narrow the available options. Once a business unit has selected a provider, configured workflows and announced implementation dates, governance teams are left trying to correct decisions under pressure.
Procurement should trigger an AI review as soon as a supplier identifies AI functionality, processes organisational data through an AI system, or provides outputs that may influence decisions about individuals. A short intake can establish whether the service uses machine learning, generative AI, automated decision-making, biometric processing, third-party foundation models or cross-border data transfers.
This early triage should route the supplier into the right level of review. Low-impact use cases may require a focused AI addendum to the vendor assessment. Higher-impact systems may require a Data Protection Impact Assessment, an AI risk assessment, security validation, legal review and senior risk approval. The process must be clear enough that business teams can follow it without interpreting regulatory thresholds themselves.
Establish the actual AI use case
Supplier descriptions often focus on capability rather than operational context. A meaningful review starts with how the organisation intends to use the service. Ask which teams will use it, whether it will handle personal data or confidential information, what decisions its outputs inform, and whether staff can challenge or override those outputs.
This distinction matters because the same platform can present different risks depending on configuration. A general-purpose AI assistant used for approved internal content may be manageable through access controls and user guidance. The same assistant connected to customer records, HR files or a knowledge base containing sensitive data requires closer control over inputs, permissions, retention and output handling.
The use case should be recorded alongside the supplier record, not retained only in procurement correspondence. That creates a reliable connection between the commercial relationship, the privacy assessment and the organisation’s AI system inventory.
Test claims with evidence, not policy statements
A supplier’s AI principles, trust centre materials and standard contractual terms are useful starting points. They are not sufficient evidence on their own. Due diligence should identify what is contractually committed, what is technically configured, and what remains dependent on the customer’s own controls.
The review should establish whether customer data is used for training, fine-tuning, evaluation or service improvement, and whether opt-out settings are available by default or only on request. It should also clarify where data is processed, how long prompts and outputs are retained, and which sub-processors or model providers participate in the service.
For systems that produce material outputs, teams should understand the supplier’s approach to testing, monitoring and change management. This does not require demanding access to proprietary model weights or source code. It does require evidence that the provider manages known limitations, documents significant changes and has a process for addressing harmful, inaccurate or unreliable outcomes.
A well-designed assessment should cover six control areas:
- data inputs, permitted uses, retention and deletion;
- model and infrastructure dependencies, including sub-processors;
- security controls, access management and incident notification;
- human oversight, output validation and user-level safeguards;
- testing, performance monitoring and material change management; and
- contractual accountability, audit rights and exit arrangements.
The evidence required will vary. An enterprise AI provider handling large volumes of personal data may need to provide detailed assurance materials and contractual commitments. A specialist supplier supporting a limited internal use case may be assessed through a narrower evidence set. Proportionality is not reduced control. It is the discipline of applying the right control to the actual exposure.
Connect supplier review to privacy and AI governance workflows
AI supplier risk becomes difficult to manage when each function holds a separate version of the facts. Procurement may retain the supplier questionnaire, legal may retain redlined data processing terms, security may hold assurance reports, and privacy may maintain a separate assessment. At renewal, no one can easily identify what was approved, under which conditions, or whether the service has changed.
A central operational record should connect the supplier, contract, processing activity, assessment outcome, AI use case and accountable owner. It should also record residual risks, approvals, required actions and review dates. This creates an evidence trail that supports internal challenge, audit preparation and consistent handover when personnel change.
For organisations operating across the EU, UK, APAC and other jurisdictions, the record also needs to reflect the applicable legal basis, international transfer arrangements and local requirements. Where AI processing is likely to result in high risk to individuals, the supplier review should feed directly into the DPIA workflow rather than duplicate the same questions in separate documents. Where legitimate interests are relied upon, the assessment should also align with the organisation’s Legitimate Interest Assessment.
The EU AI Act adds a further operational consideration. Organisations need visibility of which AI systems they use, the role they play in the value chain, their intended purpose and their risk classification. Supplier due diligence is one of the primary sources of that information. If a third-party AI service is not recorded at onboarding, it is unlikely to appear reliably in the AI system registry later.
Contract terms should reflect the operating model
A contract cannot eliminate AI risk, but it can define the supplier’s obligations when the service changes or an incident occurs. Standard data processing terms may not address model training restrictions, AI-specific sub-processors, meaningful notification of material functionality changes, or access to evidence needed for ongoing oversight.
Legal and procurement teams should ensure the agreement matches the approved use case. Where the supplier processes personal data, the DPA should accurately describe the processing and sub-processing arrangements. Where training restrictions are essential, they should be expressed clearly rather than assumed from marketing materials. Contract review should also address the organisation’s ability to suspend data sharing, retrieve data and manage deletion if the service is discontinued.
The appropriate terms depend on supplier leverage, service criticality and available alternatives. A global provider may offer limited negotiation scope, while a specialist vendor may be more flexible. In either case, the decision should record accepted gaps and the compensating controls required internally.
Due diligence is an ongoing control, not an onboarding event
AI services change quickly. A supplier can introduce a new model provider, alter retention settings, enable a new feature or expand the categories of data processed. The original assessment may remain valid, but only if changes are detected and assessed against the approved operating model.
Set review triggers around contract renewal, material product changes, new integrations, security incidents, changes to sub-processors and expanded use cases. Business owners should have a defined responsibility to report changes, while privacy, security and legal teams need a practical route to reassess them without restarting the entire procurement process.
This is where a unified governance environment matters. Privacy360 enables teams to connect vendor and third-party risk assessments with DPIAs, ROPA records, contract review, AI system oversight and evidence collection. Rather than reconstructing the history of a supplier from disconnected files, governance leaders can see the control status, accountable owner and next required action in one operational system.
The objective is not to slow down AI adoption. It is to ensure that each supplier enters the organisation with defined boundaries, verified evidence and accountable ownership - so expansion happens under control rather than through exception management.