Key takeaways
- Standard vendor due diligence was designed for a supply chain that shipped static software. It verifies that a supplier is solvent, insured and certified, and says nothing about what a model was trained on or how it changes after you sign.
- Under Article 25(4) of the EU AI Act, diligence on an AI supplier is a legal duty, not a best practice. A written agreement with the supplier must specify the information, capabilities and technical access you need to meet your own obligations.
- Article 25(1) contains the trap most buyers miss. Rebranding a bought system, substantially modifying it, or repurposing it into a high-risk use makes you its provider, with the full obligation set that follows.
ISO/IEC 42001A.10.3 andNIST AI RMFGOVERN 6.1 both require active supplier management. Accountability for the outcome stays with you whatever the contract says.- The right trigger to repeat a review is a model version change, not a contract anniversary.
What vendor due diligence covers today
Ask any of the platforms ranking for this topic what belongs in a review and you get a consistent answer. Vendor due diligence is the pre-contract process of verifying that a third party can be trusted with a business function, and the canonical checklist runs to six or seven categories: legal and corporate structure, beneficial ownership, financial stability, security and privacy attestations such as SOC 2 or ISO/IEC 27001, operational resilience and business continuity, and regulatory screening for sanctions, litigation and adverse media. Mature programmes tier suppliers by criticality first, so a payroll processor gets a deeper review than a stationery supplier, then gather evidence, score it against a risk appetite, and set a re-review cadence at onboarding. None of that is wrong. It is a genuinely good process, refined over two decades of outsourcing, and it remains the foundation of any AI governance programme. The problem is narrower and more specific: every category in that list describes the company you are buying from. Not one of them describes the model you are buying.
Vendor due diligence versus commercial due diligence
The two terms get confused often enough to be worth separating. Commercial due diligence assesses whether a target’s market, customers and revenue justify a valuation, and it is usually run by a buyer in a transaction. Vendor due diligence assesses whether a supplier can deliver a service without creating unacceptable risk for you. Confusingly, in mergers and acquisitions the same phrase describes a report a seller commissions on itself to speed up a sale. Throughout this guide the term means the supplier-risk sense: you are the buyer, and the supplier is shipping you an AI system.
Why the standard checklist breaks on an AI vendor
A SOC 2 Type II report is an auditor’s opinion that a company operated stated controls over a period. It tells you the building is locked, access is reviewed and backups are tested. It does not tell you what data trained the model, whether that data was licensed, whether the model was evaluated for the population you serve, or what happened to its behaviour in last month’s release. Those are different questions about a different object, and the standard questionnaire does not ask them. Four properties of AI suppliers break the traditional review. The product is non-deterministic. Conventional software returns the same output for the same input, so testing once establishes behaviour. A model may not. Evidence that a system performed acceptably during a pilot is weaker evidence than the same result from a deterministic tool, and a review designed around one-time acceptance testing quietly overstates what it has proven. The product changes without a contract change. Suppliers retrain, swap base models and adjust system prompts continuously. A model that passed your review in March may behave materially differently in June, with no amendment, no notice and no new attestation. Traditional procurement has no event for this, because traditional software shipped versioned releases on a roadmap you could see. The chain runs deeper than your register. Your supplier is often a thin application over somebody else’s foundation model, which may itself be served by a third infrastructure provider. Nth-party exposure is not new, but in AI the sub-supplier determines the behaviour of the thing you bought, not merely its uptime. Most vendor registers stop at the counterparty. Disclosure meets a trade-secret wall. NIST observes that suppliers routinely decline to disclose training-data composition, architecture or evaluation results on commercial-confidentiality grounds, and that GOVERN 6.1, the third-party control, is among the most frequent failure points in independent audits. That refusal is a finding in itself, and a review that treats “supplier declined to answer” as a blank rather than a risk rating is not doing its job. There is a fifth problem that sits outside the questionnaire entirely. Suppliers increasingly add AI features to tools you already bought, which means AI enters the organisation through a renewal rather than a procurement. This is the vendor-shaped face of shadow AI, and no amount of pre-contract rigour catches it if nothing re-opens the file.
The legal duty most buyers miss: EU AI Act Article 25
Most articles on this topic present supplier scrutiny as prudent risk management. For a large set of European deployments it is now a legal requirement with a named article, and that changes both the urgency and the evidence you need to retain.
The written agreement requirement
Article 25(4) provides that the provider of a high-risk AI system and any third party supplying an AI system, tools, services, components or processes used or integrated into it shall, by written agreement, specify the information, capabilities, technical access and other assistance needed to comply with the Regulation, based on the generally acknowledged state of the art. Read that as a procurement instruction. If you build or place on the market a high-risk system and any part of it comes from outside, the supporting information flow has to be written into a contract. An informal assurance from a solutions engineer does not satisfy it, and neither does a completed questionnaire sitting in a shared drive. The obligation is to have agreed, in writing, what the supplier will tell you and what access they will grant, before you need it.
When the buyer becomes the provider
Article 25(1) is the provision that turns a procurement decision into a compliance liability. A distributor, importer, deployer or other third party is treated as the provider of a high-risk system, and assumes the provider obligations in Article 16, in three circumstances: where it puts its name or trademark on a high-risk system already on the market, where it makes a substantial modification to such a system, or where it modifies the intended purpose of a system that was not high-risk so that it becomes high-risk. Each limb describes something organisations do routinely without thinking of it as a regulatory act. White-labelling a bought system under your own brand is limb (a). Fine-tuning on your own data far enough to fall outside the original conformity assessment is limb (b). Taking a general screening tool and pointing it at recruitment decisions is limb (c). Article 3(23) defines substantial modification as a change not foreseen or planned in the provider’s initial conformity assessment, as a result of which compliance with the Chapter III Section 2 requirements is affected, or which modifies the intended purpose. For general-purpose models, Commission guidance offers an indicative quantitative marker: fine-tuning that uses more than roughly one third of the original training compute points toward a downstream party assuming provider obligations for the modified model. See our guide to general-purpose AI for how those upstream duties interact with your own. The practical point for a review is that “are we planning to modify this?” belongs on the questionnaire, and the answer determines which obligation set you are buying into. Academic work on agentic systems, including AI Agents Under EU Law, notes that runtime behavioural drift sits uneasily against the Article 3(23) boundary, since a system that changes its own behaviour after deployment may cross a line that the drafters imagined a human would cross deliberately.
What the original provider owes you
The duty is not one-directional. Article 25(2) requires the initial provider to cooperate closely with any new provider, making available the necessary information and the reasonably expected technical access and assistance so the new provider can meet its obligations, particularly on conformity assessment. If your supplier’s contract disclaims all such cooperation, that clause is in tension with the Regulation, and it is a reasonable thing to raise in negotiation rather than accept as boilerplate. The EU AI Act operator’s guide sets out how the provider and deployer roles divide more generally.
What ISO 42001, NIST AI RMF and DORA require of vendor due diligence
Three frameworks converge on supplier management from different directions, and an assessment that satisfies all three is defensible in most jurisdictions.
ISO/IEC 42001: accountability does not transfer
Annex A control A.10 governs third-party and customer relationships. A.10.2 requires roles and responsibilities to be allocated clearly across every external party in the AI system lifecycle, including data providers, model developers, platform vendors and integrators, so no obligation falls into a gap between two organisations that each assumed the other held it. A.10.3 requires active management of AI suppliers, so that procured models, datasets and components align with your responsible-AI objectives, evidenced through supplier assessments and contract clauses on transparency and bias. The principle underneath both controls matters more than either: accountability does not transfer. You remain answerable for the outcome even when a supplier caused it. Our ISO 42001 explainer covers how Annex A fits the wider management system.
NIST AI RMF: the control that fails audits
GOVERN 6 addresses risks arising from third-party software, data and supply chain. GOVERN 6.1 extends your governance to supplier models, third-party APIs, pre-trained datasets and open-source components, and is explicit that legal exposure for intellectual property infringement, copyrighted training data and privacy violations embedded in a third-party model stays with the organisation deploying it. GOVERN 6.2 requires contingency processes for third-party failure, including fallbacks and decommissioning triggers. The NIST AI RMF guide maps the full function set.
DORA: the register and the mandatory clauses
Financial entities carry a further layer. Under DORA, applicable since 17 January 2025, Articles 28 to 30 require a register of information covering every ICT third-party contractual arrangement, distinguishing those supporting critical or important functions. Article 30 prescribes clauses that must appear in those contracts, including service description and performance levels, data location, notification of changes, audit rights, incident notification, business continuity and termination rights. AI and large-language-model suppliers can fall within scope as ICT third-party service providers, and in November 2025 the European Supervisory Authorities designated the first nineteen critical ICT third-party service providers, a list dominated by the cloud platforms on which most AI services run.
The 12 AI questions to add to your vendor due diligence questionnaire
These sit alongside your existing security, financial and continuity sections rather than replacing them. For each, the useful part is the evidence, not the answer. The structure below follows the domain split used in the openly licensed AI Vendor Security and Safety Assessment Guide by Dennis Ah-king, which is built to fold into an existing third-party risk process.
Provenance and data
1. What data was the model trained on, and under what licence? Look for a documented data statement naming sources and licensing basis. “Publicly available data” is not an answer. 2. Does our data train your models, by default or by option? Look for a contractual commitment, not a settings screenshot. Establish whether the default changes on renewal. 3. Which sub-processors and model suppliers sit behind this service? Look for a named list with a change-notification commitment. If the supplier resells a foundation model, you need the upstream provider’s terms too.
Model behaviour and change
4. What evaluations were run, on which populations, with what results? Look for evaluation reports with disaggregated results. Aggregate accuracy hides the failure modes that create legal exposure. 5. How will you notify us of a model version change, and how far in advance? Look for a notice period and a defined channel. This is the single most valuable answer on the list. 6. How do you detect and report performance drift after deployment? Look for monitoring you can see, ideally a metric you receive rather than one they watch. 7. What is the system’s intended purpose as you have assessed it? Look for a written statement. Your planned use sitting outside it is the fastest route to inheriting provider obligations.
Chain and dependency
8. Is this system classified as high-risk under the EU AI Act, and on what basis? Look for a reasoned classification. Disagreement here is a finding worth escalating before signature. 9. If we fine-tune or rebrand, what changes in the allocation of responsibility? Look for an answer that engages with Article 25. Suppliers that have not considered it are telling you something. 10. What technical documentation will you provide, and will it be kept current? Look for a commitment mapped to what you owe your own regulator. Our guide to AI system documentation sets out the baseline.
Evidence and exit
11. What audit rights do we have, and do they extend to your model supplier? Look for rights that survive the sub-processor boundary, since that is where behaviour is actually determined. 12. On termination, what happens to our data, fine-tuned weights and embeddings? Look for a deletion commitment covering derived artefacts, not just the source records. Where a supplier declines to answer, record the refusal, rate the residual risk and route it to whoever owns the risk acceptance. A declined question is a result.
Contract clauses that carry the obligation
Answers on a questionnaire bind nobody. The clauses that convert them into obligations are the ones AI contracts most often lack, because a general software agreement was not drafted for a non-deterministic product. Practitioner guidance for lawyers negotiating with AI suppliers consistently identifies the same set: restrictions on training use of customer data, ownership and licensing of model output, notification and approval rights on model changes, sub-processor and model-supplier consent, audit rights that reach the upstream provider, obligations on bias testing and remediation, performance standards adapted to probabilistic output, and termination provisions that unwind fine-tuned weights and embeddings rather than only stored records. Two are worth singling out. Unilateral modification clauses, standard in software agreements, are much more consequential when the thing being modified is the model itself. And liability caps set at twelve months of fees were calibrated for outages, not for a discrimination finding arising from a model you did not build. Broader context on where these fit sits in our AI compliance guide.
Re-diligence: the triggers that should restart the review
Most programmes re-review suppliers annually, or when the contract renews. For AI suppliers that cadence is misaligned with the risk, because the object under review changes on the supplier’s release schedule rather than your procurement calendar. Replace or supplement the calendar with event triggers:
- A model version change, or a change of underlying foundation model
- A new sub-processor or model supplier entering the chain
- A capability expansion, particularly one granting the system new actions or tool access
- A change to the stated intended purpose, by either party
- Any decision on your side to fine-tune, rebrand or repurpose, which engages Article 25(1)
- A reportable incident, whether at the supplier or in your own deployment
- Measured drift crossing a threshold you defined at onboarding
The last two connect this process to controls you may already run. Compliance monitoring supplies the drift signal, and AI incident reporting supplies the incident one. Wiring supplier review to those feeds, rather than to a date, is what makes the programme responsive to how AI suppliers actually behave.
FAQ
What is the difference between CDD and VDD? Customer due diligence is an anti-money-laundering process: verifying a customer’s identity, beneficial ownership and sanctions status before onboarding them, driven by financial-crime regulation. Vendor due diligence runs in the opposite direction, assessing a supplier you are about to depend on. The two share screening techniques and often the same data providers, which is why the acronyms get mixed up, but they answer different questions for different regulators. What is the difference between vendor due diligence and commercial due diligence? Commercial due diligence tests whether a business is worth what a buyer is paying, examining market position, customer concentration and revenue quality, and it belongs to a transaction. Vendor due diligence tests whether a supplier can deliver without importing unacceptable risk into your operations, and it belongs to procurement and third-party risk management. In mergers and acquisitions, confusingly, vendor due diligence can also mean a report a seller commissions on itself. Does a SOC 2 report cover an AI vendor adequately? No. A SOC 2 report is an opinion on whether stated controls operated over a period, covering matters such as access management, change control and monitoring. It is worth having and says nothing about training-data provenance, evaluation results, bias testing or model change management. Treat it as necessary and not sufficient, and add the model-specific questions separately. When does buying an AI system make us its provider? Under Article 25(1) of the EU AI Act, in three situations: you put your name or trademark on a high-risk system already placed on the market, you make a substantial modification to one, or you change the intended purpose of a system so that it becomes high-risk. Any of these transfers the Article 16 provider obligations to you, including the quality management system, technical documentation and conformity assessment. How often should vendor due diligence be repeated for an AI supplier? Keep an annual baseline for continuity and financial checks, and add event triggers for anything model-related. A model version change, a new sub-processor, a capability expansion, an incident or measured drift should each reopen the file regardless of when the last review happened. Reviewing a supplier on a calendar alone means assessing a system that may no longer be the one you assessed. What if a vendor refuses to disclose training data? Record the refusal as a finding rather than an unanswered question, and rate the residual risk accordingly. NIST treats non-disclosure on trade-secret grounds as a recognised feature of this market, not an anomaly. You can often reach an acceptable position through alternatives: a contractual indemnity for intellectual property and privacy claims arising from training data, a third-party attestation, or a narrower warranty about licensing basis rather than full disclosure.
Conclusion
The category has a good process. Two decades of third-party risk management produced a review that reliably establishes whether a supplier will still exist next year and whether its office network is defensible. What it was never designed to do is describe a model: where its training data came from, how it behaves for the people you serve, and what changed in it last week. Article 25(4) has already made that gap a legal one for high-risk deployments in Europe, and ISO/IEC 42001 and NIST AI RMF reach the same conclusion through governance rather than statute. The remedy is not a new programme. It is twelve more questions, a handful of clauses that make the answers binding, and a trigger that fires on a model version change instead of a date. If you want to see where supplier evidence sits in a wider control set, start with our AI risk management guide.