The AI Supply Chain: How to Audit Your AI Dependencies Before They Audit You

Every company deploying artificial intelligence operates a supply chain. The chain is often invisible until something breaks or prices change. Most companies do not have a map of it.

The supply chain looks like this: your product depends on a foundation model from OpenAI, Anthropic, Google, or Mistral. That model runs on cloud infrastructure from AWS, Azure, or Google Cloud. Your data comes from internal sources, third-party data providers, or user-generated input. Fine-tuning, evaluation, and monitoring tools come from a dozen specialised vendors. Feature engineering and data pipelines run on open-source libraries maintained by volunteers or corporate sponsors.

When I led technology at IG Group during our transition from £300 million to £2.7 billion market capitalisation, we had an exhaustive vendor management practice. We mapped every dependency, stress-tested every critical path, and maintained redundancy for anything that could take down the platform. I have not seen a single AI-forward company apply that same discipline to their AI supply chain.

The result is exposure. Single-vendor dependency on foundation models. Pricing risk from cloud providers. Model deprecation by vendors. Data provenance issues. Regulatory exposure from undocumented third-party data sources.

This is not paranoia. It is prudence.

The Supply Chain Layers

An AI supply chain has five distinct layers. Understanding and auditing each layer is non-negotiable.

Layer 1: Foundation Models

Every AI product depends on a foundation model — a large language model, multimodal model, or specialised model trained on massive datasets. The options are:

Closed, proprietary models: OpenAI (GPT-4, o1), Anthropic (Claude), Google (Gemini), Meta (Llama 2/3), Mistral.

Open-source models: Llama (Meta), Phi (Microsoft), Mixtral (Mistral), StarCoder (BigCode).

Custom fine-tuned models: Models you have trained or fine-tuned yourself on your own data.

The risk profile differs dramatically:

Proprietary models. You do not control the model. The provider controls versioning, pricing, capabilities, and availability. OpenAI has deprecated models (e.g., GPT-3.5-turbo-0301) with short notice. They have changed pricing significantly (GPT-4 cost dropped 90% in two years). They have disabled APIs (e.g., code-davinci-002). This is not malice — it is the normal operating model of AI providers. But it creates supply chain risk for you.

Open-source models. You have access to the weights and can run the model on your own infrastructure. But open-source introduces a different risk: you are dependent on the maintenance community. If the project is abandoned or the maintainer loses interest, you may inherit maintenance burden. You also assume all the infrastructure and fine-tuning costs that the commercial provider was absorbing.

Custom fine-tuned models. You own the model and the data. But you have assumed the full operational burden: training infrastructure, ongoing retraining, model governance, performance monitoring. This is only appropriate if you have sufficient scale and specialisation to justify it.

Layer 2: Cloud Infrastructure

Your foundation model (or custom model) runs on cloud infrastructure. AWS, Azure, Google Cloud, or your own servers.

The risks are straightforward:

Pricing volatility. Cloud providers change pricing regularly, and large AI workloads are expensive. GPU costs vary by region, instance type, and spare capacity. Spot pricing is cheaper but can be interrupted. If your product margin depends on specific GPU pricing, you have supply chain risk.

Capacity constraints. During periods of high AI demand, GPU capacity is rationed. You may not be able to scale your inference or fine-tuning because capacity is unavailable. This has already happened to multiple AI-native companies in 2024-2025.

Vendor lock-in. Once you have optimised your code for a specific cloud provider, switching is expensive. Moving a production workload from AWS to Azure requires re-engineering, re-testing, and risk management. Most companies will not do it unless forced.

Regulatory exposure. If your cloud provider faces regulatory action, your service can be disrupted. This is real — Sanctions on Russian entities resulted in AWS and Azure blocking accounts in Russia. Similar geopolitical events could affect your service.

Layer 3: Data Sources

Your AI system learns from or operates on data. The sources matter enormously:

Internal data. Data generated by your own operations. You own it. But you must ensure it is representative, bias-free, and legally clean (no embedded PII, no copyrighted content, no third-party data misclassified as your own).

Licensed third-party data. Data purchased from vendors (market data, financial data, web crawl data). You must audit the license terms: Can you train models on it? Can you retain the trained models after the license expires? What are the attribution requirements?

Public data. Freely available data used for model training. Web crawls, GitHub code, Wikipedia, academic datasets. The legal status of using this for training remains in flux (ongoing litigation about copyright infringement by foundation model creators). You have exposure if your trained model is found to have retained copyrighted material.

User-generated data. Data provided by your customers as input to your AI system. You own the output (the model predictions), but you should not retain the input without consent. This is a GDPR and privacy concern that many companies mishandle.

A responsible data audit should answer:

• What is the origin of every dataset used in training or fine-tuning?
• What are the license terms and any restrictions on use?
• What is our legal exposure if the data has copyright or privacy issues?
• How would we know if a trained model has embedded copyrighted material?

Layer 4: Fine-Tuning, Evaluation, and Monitoring Tools

Beyond the base model and infrastructure, you depend on specialised tools:

Fine-tuning platforms: Weights and Biases, Hugging Face, Lambda Labs. These provide infrastructure and UIs for tuning models on your data.

Evaluation and monitoring: Prompt evaluation tools (LangSmith, Arize, WhyLabs), function calling frameworks (Pydantic, Instructor), model monitoring (Whylabs).

Observability and costs: MLflow, DataDog, custom logging. These tell you what your models are doing and what they cost.

The risk is fragmentation. You depend on multiple vendors, each of which could change pricing, deprecate features, or exit the market. If a critical evaluation tool you depend on is acquired and discontinued, you have a problem.

The defence is documented, reproducible workflows. Your fine-tuning, evaluation, and monitoring should not be locked into proprietary UIs. Use open standards (JSONL for data, standard Python APIs) so you can switch tools if needed.

Layer 5: Open-Source Dependencies

Most AI applications use open-source libraries: PyTorch, TensorFlow, Hugging Face Transformers, LangChain, FAISS, NumPy, and hundreds more.

The risk is maintenance and security:

Maintenance risk: A critical library you depend on is maintained by a volunteer who loses interest and stops updating. Bugs accumulate. Security issues go unfixed. Your codebase becomes increasingly outdated.

Security risk: An open-source dependency has a vulnerability. How quickly do you know? How quickly can you patch? If the vulnerability is in a deeply embedded dependency (a dependency of a dependency), patching is complex.

Deprecation risk: The library you depend on is superseded by a new approach (as happened with TensorFlow when PyTorch became dominant). You may face pressure to migrate to a newer, better-maintained alternative.

The defence is: inventory your dependencies, monitor for security advisories, and maintain upgrade discipline. Do not passively wait for issues to surface.

Building an AI Supply Chain Audit

Here is the framework I recommend for companies 6-12 months from a major AI product launch or PE due diligence.

The AI Supply Chain Audit Checklist

Use this checklist to assess your AI supply chain maturity:

Foundation Model Layer

• Do we use a single foundation model provider or multiple?
• Have we evaluated switching to alternative models? Do we know the migration cost?
• Are we using deprecated model versions? Do we have a versioning strategy?
• What happens to our product if our primary model provider changes pricing 50%?
• Do we have a relationship with an alternative provider (secondary supplier)?

Cloud Infrastructure

• Are we single-cloud or multicloud?
• What is our GPU cost per unit of inference? How has it trended?
• Do we have redundancy for critical workloads?
• Could we migrate to an alternative cloud provider in 30 days? Have we tested it?
• Are we exposed to regional capacity constraints?

Data

• Do we own the data we use for training and fine-tuning?
• What are the license terms for third-party data? Can we retain trained models after license expiry?
• Have we audited data for copyright, privacy, and compliance issues?
• Do we have procedures for detecting if our models have embedded copyrighted material?
• What is our legal exposure if a data source is found to have privacy violations?

Tools and Infrastructure

• What are our critical dependencies in fine-tuning, evaluation, and monitoring?
• For each critical tool, do we have documented, reproducible workflows that could migrate to an alternative?
• Are we locked into proprietary UIs, or do we use open standards?
• What is the cost of replacing our evaluation and monitoring stack?

Open-Source

• Do we have a dependency inventory?
• Which dependencies are maintained by volunteers vs. well-funded projects?
• How do we monitor for security vulnerabilities in our dependencies?
• How quickly can we patch a critical security issue in a deeply embedded dependency?
• Are any of our critical dependencies approaching end-of-life?

What PE Buyers Ask About AI Supply Chain

When private equity conducts due diligence on an AI-enabled company, supply chain risk is an increasingly standard question. Here is what they explore:

The companies that score well on these questions achieve premium valuations because they have de-risked their AI supply chain.

The Strategic Question: Build vs. Buy vs. Partner

The audit process should clarify your build/buy/partner strategy for critical components.

Build (create in-house) when:

• The component is core to your competitive moat
• The cost of building is less than the long-term cost of relying on a vendor
• You have sufficient scale to justify the operational burden

This is rarely appropriate for foundation models (too expensive, too complex). It might be appropriate for fine-tuned models if you have proprietary data and unique training needs.

Buy (use a commercial vendor) when:

• The component is commoditised
• The vendor is well-capitalised and stable
• Switching cost is acceptable if needed

Most foundation model usage falls here. You use OpenAI or Claude API because it is cheaper and lower-risk than building your own.

Partner (maintain a relationship with an alternative) when:

• The component is critical but vendor concentration is unacceptable
• You are willing to trade switching cost for resilience

For critical components, a hybrid approach is often appropriate: primary vendor + backup partnership. You operate with the primary vendor 90% of the time, but maintain the capability to switch to the partner if needed.

Why This Matters for Exit Value

An AI-enabled company that has a documented, audited AI supply chain with identified alternatives and tested mitigations is dramatically more valuable to a buyer than a company whose AI capability is a black box of dependencies.

The buyer looks at your supply chain and asks: "If our new ownership changes the business model or cloud provider, can we actually operate this AI capability, or are we trapped in the current configuration?"

Companies that can answer this question confidently achieve 15-25% higher valuations because the buyer is paying for optionality and resilience, not just current-state capability.

The audit takes weeks. The value creation is measured in millions at exit.

For companies at the intersection of AI strategy and exit readiness, auditing your AI supply chain is not optional. It is one of the highest-return activities available to leadership. Document it. Test it. Fix it. Then use it as a confidence signal in investor conversations and due diligence.

Ivan Gowan is the founder and CEO of Opagio. He spent 15 years as a senior technology leader at IG Group (LSE: IGG), overseeing engineering growth from 12 to 250 during the company's rise from £300m to £2.7bn market capitalisation. He holds an MSc from Edinburgh with research in neural networks (2001).

Further Reading

• What should enterprise SaaS companies disclose about data privacy and security?
• Intangible Asset Glossary — definitions of key terms used in this article