How should organisations approach AI supplier due diligence?

Organisations buying AI tools and platforms in 2026 are doing so at pace and scale, often without procurement frameworks equipped to handle the specificities and complexities of AI. Evaluating an AI vendor needs to be approached differently from evaluating a software licence. Organisations need to be able to demonstrate that they have considered questions like: Who controls the training data? What happens if the supplier is acquired? How does liability work when the system produces a harmful output? Yet, these AI-relevant questions sit well outside the scope of standard commercial due diligence. 

Instead, organisations need to adopt a structured approach to AI supplier due diligence in order to govern AI responsibly. The risks are already visible across sectors, the regulatory landscape is still developing, and the decisions made at the procurement stage are difficult to unwind later. The frameworks and practical tools to build that approach already exist, but organisations need to apply them now in order to sufficiently protect themselves.   

In this article, we will cover: 

• Why procurement processes designed for traditional software fall short for AI systems
• How categorising AI systems correctly changes the questions organisations need to ask
• How ISO/IEC 42001, NIST RMF, and the EU AI Act provide practical procurement baselines
• Why cross-functional governance must be built into procurement from the start
• What organisations should be asking vendors

Why existing procurement processes fall short 

Most procurement processes were designed for a different kind of technology decision. Evaluating a software licence, a cloud platform, or a managed service involves questions that are broadly understood: what does it cost, what does it do, what are the contractual protections? AI procurement raises a different order of question, and standard due diligence frameworks were not built to answer it. 

When an organisation procures an AI system, it is making decisions about data sovereignty, liability exposure, regulatory compliance, and long-term operational dependency. This applies to dedicated AI tools and to traditional software platforms that have integrated AI features, often without changes to the original contract terms. In 2026, 76% of enterprises are purchasing AI solutions rather than building them internally, up from 53% in 2024. Many are doing so through procurement processes that have not been updated to reflect that shift. 

The gap runs deeper than process. Traditional procurement evaluates performance at the point of purchase. AI systems change over time: models are retrained, capabilities extended, vendor terms revised. An assessment that was accurate at contract signature may not reflect the system six months into deployment, which is one reason why treating AI as a static product creates exposure that only becomes visible later. 

Not all AI procurement is alike 

Procurement teams that apply the same process to every AI acquisition tend to underestimate what they are actually buying. There are at least three distinct categories, and they demand different questions. 

For a dedicated AI-powered product, the focus should fall on use case fit, data sovereignty, and hosting arrangements. The Workday AI-powered applicant tracking system that infringed US age discrimination law shows what happens when use case scrutiny is absent: buyers inherited the compliance consequences of a mismatch they had not identified. 

AI introduced as a feature within an existing platform requires a different kind of attention: identifying and renegotiating contracts that contain no AI-specific clauses. The 2026 changes to GitHub Copilot's training policy caught organisations on lower-tier contracts whose interaction data was used for model training without the protections available to enterprise subscribers. Many had no idea the terms applied to them. 

Procuring a foundation model or platform directly shifts the focus again, towards technical capability, long-term strategic dependency, and 'lock-in' risk. AI systems continuously incorporate data and learning, which makes switching suppliers considerably more complex and costly than the initial contract terms tend to suggest. 

Using established frameworks as a procurement baseline 

Organisations can draw on ISO/IEC 42001 on AI Management Systems, the NIST AI Risk Management Framework, and the EU AI Act as practical footholds to support the development of an AI-ready procurement framework, without treating any one as a complete solution. 

ISO 42001's Clause 8.2 requires organisations to assess and manage risks from procured AI components, services, and products. Annex A.10.3 requires a formal process for evaluating whether supplier practices align with the organisation's responsible AI approach, including risk tiering and ongoing monitoring.  Building a vendor risk tier based on intended use and data sensitivity is a workable way to do this; requiring suppliers to provide documented evidence of their AI governance scope, through third-party certification or a structured self-assessment, gives that tier a documented basis for selection decisions rather than leaving it as an internal judgement call. 

The NIST RMF's GOVERN 6 function addresses third-party AI risk. GOVERN 6.2 specifically requires contingency processes for when third-party arrangements fail or change, which has two direct procurement implications. The first is a standardised vendor questionnaire covering AI risk policies, incident response procedures, and data provenance controls, used to assess whether a supplier clears a minimum governance threshold before contract. The second is contractual fallback terms: what happens if the model degrades, the API fails, or the supplier is acquired? Both should be standard, not optional. 

Under the EU AI Act, buyers have a defined role as 'deployers', and their compliance depends in part on whether suppliers have met their own obligations. For high-risk AI systems,  verifying that a valid conformity assessment exists and requesting copies should be a standard procurement step. There is also a reclassification risk worth assessing early: organisations that customise, white-label, or substantially modify a third-party high-risk AI system may themselves become 'providers' under the Act, taking on conformity assessment and technical documentation obligations. Procurement is the right moment to ask whether the intended use triggers that shift. After deployment, the question is harder to answer and the obligations harder to meet. 

Cross-functional governance from the outset 

Organisations should bring legal, compliance, engineering, risk, and change management into the procurement process from the outset. Each has a stake in whether a system can be deployed safely, and by the time a contract is signed, the decisions that shape most of the governance risk have already been made. 

The costs of upskilling staff, adapting internal processes, and managing organisational transition are frequently treated as implementation concerns to be addressed later. They should be scoped and budgeted at the procurement stage. Organisations should invest in responsible AI training for procurement professionals before the vendor conversation begins, and build cross-functional working into the process as a baseline expectation rather than an occasional input. As the Responsible AI Profession paper published by techUK notes, procurement professionals increasingly need to function as responsible AI professionals in practice, equipped to ask the right questions, interpret the answers, and make informed, evidence-based decisions. Waiting until after contracts are signed to develop that capability is one of the most avoidable ways AI deployments go wrong. 

What to ask vendors 

Effective vendor engagement requires questions that go beyond standard commercial due diligence. Organisations should seek clear answers on where data is stored and processed, and whether the vendor can use organisational data, including prompts and interaction logs, for model training or any secondary purpose. Where the system has agentic capabilities, the boundaries of autonomous action should be clearly mapped. Liability terms in the event of an AI-specific failure, whether that is biased output, hallucination, or autonomous action causing harm, require explicit contractual definition. 

What happens at the end of the contract matters too. Organisations should verify that a documented exit strategy exists, covering data portability, format, and timeline, and that switching supplier does not carry punitive commercial or technical consequences. AI vendor contract terms in this area remain inconsistent, with liability caps structured in ways that shift significant risk onto buyers. Addressing these questions at the procurement stage is considerably more straightforward than trying to resolve them after a problem has occurred. 

What this means for organisations 

Every contract signed with an AI vendor shapes how data is handled, where liability sits, and what an organisation can and cannot do if things go wrong or circumstances change. The organisations managing this well are the ones that have brought legal, compliance, and technical teams into the process early, defined their vendor risk tiers, and built contractual protections that reflect what they are actually buying. 

AI procurement is not yet a mature, industry-certified area of governance practice. The decisions being made now are setting precedents. Your organisation's exposure to AI supply chain risk is, to a significant degree, determined at the point of purchase. 

Trilateral's full report on AI Procurement and supply chain risk sets out a practical framework to get you started.