How do we govern our AI supply chain and manage upstream model dependencies?

The AI supply chain extends further upstream than most teams initially realize. For a typical production AI system, the supply chain includes: the foundation model (with its training data, safety fine-tuning, and ongoing updates); any fine-tuning or retrieval datasets added by the organization; the inference infrastructure (cloud compute, model serving layer); the AI APIs or SDKs used to invoke the model; and the AI-enabled development tools used to build and test the system — including coding assistants, testing tools, and evaluation frameworks.

Each layer of this chain introduces distinct risk types. Foundation model risks include training data contamination, undisclosed capability changes, and safety regression in model updates. Dataset risks include license violations in training data, personal data ingested without consent, and adversarially injected data in retrieval stores. Infrastructure risks include standard cloud supply chain concerns amplified by the sensitivity of model weights and inference inputs. Development tool risks include the possibility that AI coding assistants have introduced vulnerable or license-encumbered code.

Mapping the supply chain before assessing it is essential. Many organizations discover during the mapping process that they have AI dependencies they were unaware of: vendor software that has silently added AI features, AI tools used by individual developers that touch production code, and foundation model providers with their own upstream dependencies that are not publicly documented.

Concentration risk — the degree to which production AI systems depend on a single provider, model, or dataset — is one of the most consequential supply chain risk factors and one of the least frequently assessed. An organization whose three most business-critical AI systems all depend on the same foundation model provider, with no tested fallback, has a concentration risk that could affect business continuity if that provider experiences an outage, regulatory action, or safety incident.

Assess substitutability for each Critical dependency: if this dependency failed or became unavailable tomorrow, what would the organization do? Could it switch to an alternative provider within 24 hours, 7 days, 30 days, or not at all? For dependencies with low substitutability and high concentration, consider maintaining a secondary option in a tested state, even if it is not in active use.

Document concentration risk explicitly in the supply chain map. Present it to the AI governance committee as a standing risk item. Organizations with high concentration in a single provider should disclose this as a material dependency in governance reporting.

AI supply chain governance should be integrated with, not parallel to, the organization's existing software supply chain security program. The software supply chain security program already covers dependency management, SBOM generation, vulnerability scanning, and third-party code review. AI supply chain governance adds model provenance, training data lineage, and capability change monitoring to this existing framework.

The integration point is procurement: every new AI component should go through the same supply chain review as other software dependencies, with an AI-specific layer added. Model cards and training data documentation should be treated as equivalents to SBOMs. Model weight integrity verification should be integrated into artifact management alongside binary signing and checksum verification.

Where AI supply chain risks are not covered by existing software supply chain processes — particularly around training data provenance and capability change monitoring — build AI-specific processes and document them as extensions to the existing framework, not as separate programs. Consolidation reduces organizational complexity and improves the likelihood that supply chain controls are consistently applied.