Enterprise AI Governance Best Practices

What the AI Supply Chain Is

The AI an enterprise uses is rarely made by the party that sells it.

Behind a vendor sits a model it may not have built, trained on data it did not gather, assembled from components it did not write, and served on infrastructure it does not own. Each of those is a link in a supply chain that reaches back well beyond the enterprise’s direct relationship.

This chapter governs that upstream chain. The direct vendor relationship, including due diligence, contracts, data use, and vendor accountability, is governed elsewhere in this document and is not repeated here.

The distinction is not only one of distance. Vendor governance works through direct relationship and contract, which the enterprise does not have with the parties upstream of its vendor. Supply-chain governance must therefore work through different means, including provenance, transparency, and the accountability it requires of the vendors it can reach, and it is treated as a separate discipline for that reason rather than folded into vendor governance.

What remains, and what this chapter addresses, is everything the enterprise depends on but did not choose and cannot see: the origins of the models, the data behind them, the components within them, and the providers behind the provider.

Know the Provenance of the Models You Use

A model is not a neutral tool. It carries the properties of whatever it was built and trained on.

The enterprise should seek to know, for the models it depends on, where each came from, what it was derived from, and in general terms what it was trained on. This is model provenance, and it is the difference between using a model and understanding what one has taken on by using it.

Provenance matters because it travels with the model. Legal encumbrance on training data, undisclosed sources, embedded bias, and licensing conditions all pass to the enterprise that uses the model, whether or not they are visible in how it performs.

Where provenance cannot be established, that absence is itself governable information. A model of unknown origin is not the same as a model of acceptable origin, and the enterprise should record which it is holding rather than assume the more comfortable answer.

Govern the Providers Behind Your Provider

A direct vendor commonly depends on others: a model supplier, a hosting provider, a data source, or another service woven into what it delivers.

These are the enterprise’s fourth-party dependencies. The enterprise does not contract with them, cannot govern them directly, and often does not know they exist, yet their failure or compromise can still reach it through the vendor in between.

The enterprise should seek to understand, for its significant AI dependencies, what critical parties sit behind the direct vendor. A dependency the enterprise cannot name is one it cannot plan for, and concentration hidden one layer down is still concentration.

Because these parties cannot be governed by contract, they should be governed by knowledge and by expectation of the direct vendor: the enterprise should require its vendors to stand accountable for their own supply chains rather than treating the boundary of the contract as the boundary of the risk.

Govern Open and Reused Components

Much AI is assembled rather than built, drawing on openly available models, pre-trained components, and shared libraries.

These components carry their own provenance, their own licensing conditions, and their own maintenance status, and they enter the enterprise through routes that a vendor contract does not cover.

The enterprise should treat reused AI components as governed elements of its supply chain, understanding where they came from, under what terms they may be used, and whether they are actively maintained.

An abandoned component is a particular risk. A model or library that is no longer maintained does not announce that it has been left behind, and an enterprise depending on it can inherit unpatched weaknesses long after the wider community has moved on.

Recognize Supply-Chain-Specific Risks

Some AI risks originate upstream and arrive through the supply chain rather than in the enterprise’s own use.

A model can be compromised before the enterprise ever receives it, through poisoned training data or tampering during its construction. A component can carry a weakness introduced far upstream. A sub-provider can fail in a way that cascades down through the vendor to the enterprise.

These risks share a common feature: they are present before the enterprise begins to use the AI, and they cannot be detected by watching only the enterprise’s own operation of it.

The enterprise should account for upstream origin as a distinct source of risk in its AI risk governance, so that a threat introduced before the point of use is not assumed away simply because it did not originate at the point of use.

Require Transparency You Cannot Contract For

The enterprise cannot sign a contract with most of its AI supply chain. It can still require transparency about it.

The enterprise should make supply-chain visibility an expectation of the vendors it does contract with: that they disclose the material origins of what they provide, identify the critical parties they depend on, and inform the enterprise when those change.

Transparency should be treated as a governable attribute of a vendor relationship. A vendor that cannot or will not describe its own supply chain is disclosing something meaningful about the risk of depending on it.

What the enterprise learns this way should be recorded where its AI governance can use it, connected to the use cases, agents, and vendor relationships the supply chain sits behind, rather than held as informal knowledge that leaves when a person does.

Connect the Supply Chain to Governed Inventories

Supply-chain knowledge is only useful to governance if it is attached to the things the enterprise already governs.

Model provenance, upstream dependencies, and component origins should connect to the AI Use Cases, AI Agents, AI Models, and vendor relationships they support, so that the enterprise can see not only what it uses but what its use depends upon.

This connection is what allows the enterprise to answer, when an upstream problem emerges, which of its use cases and agents are affected. A supply-chain risk that cannot be traced to the things it touches cannot be responded to quickly, and upstream problems rarely leave much time.

Governance Questions the AI Supply Chain Should Answer

For the AI Supply Chain, governance should answer what exists, who owns it, what is affected, which risks, obligations, controls, evidence, incidents, changes, and gaps require action.