Ask most vendors selling you an "AI-powered" tool who built the model underneath it, and watch how long it takes them to answer. Not because they're hiding something necessarily, but because a lot of them genuinely don't have a clean answer. They licensed a foundation model from OpenAI or Anthropic or Google, wrapped it in a product interface, maybe fine-tuned it on some data of unclear provenance, and shipped it. Your due diligence checklist was built for the last generation of software vendors: can they store your data securely, do they have a SOC 2 report, what's their uptime. None of that tells you what you actually need to know about an AI vendor, which is: how many hands touched this system before it reached you, and what did each of them get wrong.
I've come to think of this as the value chain problem. Every AI system your company adopts is not one vendor's product. It's a stack of components, sourced from different organizations, each with its own failure modes, and your contract is usually with the party at the very top of that stack, the one furthest from where the actual risk sits.
What The AI Value Chain Actually Looks Like
Regulation (EU) 2024/1689 — the EU AI Act — uses "value chain" as a formal term for a reason. Article 25 assigns different obligations to providers, distributors, importers, deployers, and "other third parties" precisely because a single AI system typically involves all of them, and liability doesn't stop at whoever sold you the license.
In practice, a typical enterprise AI deployment stacks up like this:
- Data layer. Whoever sourced, labeled, or licensed the training and fine-tuning data. This might be the foundation model provider, might be a data broker, might be your own vendor scraping public sources.
- Foundation model layer. The organization that trained the base model — OpenAI, Anthropic, Google, Meta, Mistral, or an open-weight model your vendor downloaded from Hugging Face.
- Fine-tuning / adaptation layer. Whoever adjusted the base model for a specific task, often the vendor itself, sometimes a subcontractor.
- Orchestration layer. The retrieval system, vector database, prompt chain, and agentic tool-calling logic that sits around the model.
- Application layer. The interface and workflow your employees actually touch.
- Deployment layer. You. The organization putting the output into a business decision.
Your vendor almost always sits at the application layer, sometimes touching orchestration, rarely owning the foundation model itself. When something goes wrong, a biased output, a hallucinated citation, a data leak, the question "whose fault is this" runs straight up that stack, and most vendor contracts stop it at layer five with a liability cap that would embarrass a copier lease.
Component Integration Risk, Defined
Component integration risk is what happens when the failure isn't in any single layer but in how the layers were stitched together. NIST's AI Risk Management Framework (NIST AI RMF 1.0, January 2023) addresses exactly this under its Govern function: category GOVERN 6.1 calls for "policies and procedures... that address AI risks associated with third-party entities," and GOVERN 6.2 calls for contingency processes for third-party failures specifically because the framework's authors recognized that most organizational AI risk doesn't originate in-house.
Here's a concrete version of the problem. A vendor fine-tunes a foundation model on your industry's documents to build a compliance assistant. The foundation model provider updates the base model, quietly, as providers do. Your vendor's fine-tuning was calibrated against the old model's behavior. The new base model responds differently to the same fine-tuning weights, and nobody tests the combination again before it reaches your employees, because from the vendor's side nothing "changed" — they didn't touch their layer. This is not a hypothetical. It is the standard failure mode of any system built on API access to a model you don't control, and it's why "the vendor didn't change anything" is not the same claim as "the system didn't change."
A related pattern: retrieval-augmented generation systems pull from a vector database your vendor manages, but the embedding model that indexed your documents is a separate third-party component from the generation model that writes the answer. If the vendor swaps the embedding model to cut costs, without re-indexing, retrieval quality degrades in ways that look like the generation model got worse, when the actual fault sits one layer down, in a component the vendor may not have disclosed as separate at all.
The system's face is not the system. What your employees see is a chat window; what actually produced the answer is four or five components from four or five organizations, and the failure could have originated in any of them.
The Due Diligence Framework: Four Questions Per Layer
I run vendor evaluations against four questions at every layer of the stack, not just the top one.
Who owns this component, and can they be named? Not "we use best-in-class models" — which model, which version, which provider. If a vendor won't name their foundation model provider, that's not a trade secret concern, it's a red flag, because the disclosure obligation flows to them under Article 53 of the EU AI Act (in force since 2 August 2025) if their upstream provider is a general-purpose AI model provider under the Act's definition.
What changes without notice, and how would you know? Foundation model providers version and retrain continuously. Ask the vendor directly: if your model provider ships a new version, do you re-test before it reaches customers, and would we be notified? Get this in writing, not verbally, because a verbal assurance doesn't survive a contract renewal.
What data trained or fine-tuned each component, and where did it come from? This is where model cards matter — the standardized disclosure format proposed in the 2019 paper "Model Cards for Model Reporting" (Mitchell et al.) and now published by most major foundation model providers. If your vendor's fine-tuning data isn't documented anywhere, including internally, you're accepting an unquantified risk on data provenance, copyright exposure, and bias.
Who is liable, and at what layer does the liability actually attach? Read the indemnification clause against the value chain, not against the vendor relationship. A liability cap of your annual contract value is meaningless if the actual harm originates three layers down in a foundation model neither party controls.
A Comparison: Software Vendor DD vs. AI Vendor DD
The checklist your procurement team already runs isn't wrong, it's just incomplete. Here's where the two diverge:
| Diligence Area | Traditional Software Vendor | AI Vendor (Value Chain Aware) |
|---|---|---|
| Uptime / availability | SLA against the vendor's own infrastructure | SLA meaningless if foundation model provider has an outage; ask about upstream dependency |
| Data handling | Where is data stored, who can access it | Where is data stored AND was it used for training/fine-tuning anywhere upstream |
| Change management | Vendor's own release notes | Vendor's release notes plus foundation model provider's model changelog — two independent change streams |
| Liability | Capped at contract value, vendor-only | Must trace to the layer where the failure actually originated; ask who indemnifies for upstream model behavior |
| Compliance certification | SOC 2 Type II | SOC 2 Type II plus ISO/IEC 42001:2023 (or a documented AI risk management process) at every layer that touches your data |
| Audit rights | Access to vendor's security documentation | Access to vendor's subcontractor/component list, not just their own controls |
| Documentation | User manual, API docs | Model card or equivalent disclosure for each foundation and fine-tuned model in the stack |
What To Ask For In Writing
Three documents I request before any AI vendor contract moves forward, and I've never had a legitimate vendor refuse to at least discuss all three.
First, a component inventory: every model, every data source, every third-party API the vendor's product depends on, updated at each contract renewal. This doesn't need to be exhaustive engineering documentation, it needs to name the organizations whose failures become your failures.
Second, a change notification commitment: a defined process for telling you when an upstream component changes materially, not just when the vendor's own interface changes. ISO/IEC 42001:2023, the AI management system standard, builds this expectation into its Annex A controls on third-party and customer relationships, and a vendor that's pursued or is pursuing certification will already have this documented, because the standard requires it as a condition of certification, not as a courtesy.
Third, incident history for the specific components in use, not just the vendor's own product. If the foundation model provider has had a documented incident, an outage, a safety issue, a discovered bias pattern, ask whether and how it affected your vendor's product. A vendor that tracks this proactively is managing the value chain. A vendor that's never thought about it is passing that risk to you without either of you knowing it.
Why This Matters More Now Than It Did Two Years Ago
The vendor landscape has consolidated around a handful of foundation model providers, which sounds like it should simplify due diligence, fewer upstream sources to track, but it's actually concentrated the risk instead of distributing it. When three or four foundation models sit underneath a large share of the "AI-powered" tools on the market, a single upstream incident, a training data lawsuit, a safety issue, a sudden policy change from one provider, ripples through dozens of downstream vendors simultaneously. Your due diligence on Vendor A is not independent of your due diligence on Vendor B if they share the same foundation model underneath. That's a portfolio-level risk, not a per-vendor one, and most procurement processes still evaluate vendors one contract at a time.
I'd rather a client discover this during an assessment than after a deployment, because the fix is cheap before signature and expensive after. If you're building or refreshing an AI vendor evaluation process, our AI readiness assessment walks through exactly this kind of value-chain mapping before a single contract gets signed, and if you're further along and trying to sequence AI governance work against a framework like NIST's, the practical sequencing guide we published on implementing the NIST AI RMF at a mid-sized company covers where vendor risk fits into a broader program.
FAQ
What is the "AI value chain" and why does it matter for vendor due diligence?
The AI value chain is the full set of organizations and components that produce an AI system's output: the data source, the foundation model provider, the fine-tuning party, the orchestration layer, and the application vendor you actually contract with. Article 25 of the EU AI Act (Regulation (EU) 2024/1689) formally assigns different obligations to providers, importers, distributors, and deployers along this chain, which means liability and compliance responsibility don't stop at your immediate vendor.
What is component integration risk in AI systems?
Component integration risk is the risk created not by any single component failing but by how components interact, for example when a foundation model provider updates a model and a vendor's fine-tuning, calibrated against the prior version, produces different behavior without either party changing anything on their own end. It's a distinct risk category from a straightforward vendor outage or bug.
What documents should I request from an AI vendor before signing a contract?
A component inventory naming every model and data source the product depends on, a change-notification commitment for upstream model updates, and incident history covering the specific upstream components in use, not just the vendor's own product history. Model cards, where available, are the standard disclosure format for individual model details.
Does ISO/IEC 42001 certification substitute for vendor due diligence?
No, but it's strong evidence the vendor has a documented process you can audit. ISO/IEC 42001:2023's Annex A includes controls specifically addressing third-party and customer relationships, so a certified vendor should already have the component inventory and change-management documentation you'd otherwise have to request from scratch. Certification tells you a process exists; due diligence confirms it's actually being followed for your specific deployment.
How does the EU AI Act affect due diligence on AI vendors outside the EU?
If a vendor's product touches EU users or markets, or if their upstream foundation model provider qualifies as a general-purpose AI model provider under the Act, obligations under Article 53 (documentation and disclosure requirements, in force since 2 August 2025) can apply regardless of where your company is headquartered. US and other non-EU companies evaluating AI vendors with any EU exposure should ask directly whether the vendor or its upstream providers have assessed their Article 53 obligations.
Last updated: 2026-09-13
Jared Clark
AI Strategy Consultant, AI Strategies Consulting
Jared Clark is the founder of AI Strategies Consulting, helping organizations design and implement practical AI systems that integrate with existing operations.