AI Model Supply Chain: Weights, Adapters & Provenance

The AI model supply chain is everything between a model being trained and it running in your environment: weights, serialisation format, adapters, tokeniser, runtime and registry. Each is a third-party artefact that executes inside your infrastructure — and the questions you would ask of any other dependency mostly go unasked of a model file.

A model is a dependency

No engineering team would pull an unpinned package from an unverified mirror into production and shrug at the version. The same team will download a multi-gigabyte weights file from a hosting site, load it, and never record which revision it was.

The difference is familiarity, not risk. The package has a version, a registry, a lockfile and a rollback path. The model frequently has none of those.

Loading is code execution

Weights are data. The loader is not. Some serialisation formats permit arbitrary code to run during deserialisation, which makes "download and load a model" equivalent to running a script from the internet with your service account.

Prefer formats designed to be loaded without executing anything.
Verify checksums against the publisher, not against the mirror you used.
Load unfamiliar artefacts somewhere that cannot reach anything that matters.

A model bill of materials

Record	Why, concretely
Base model and exact version	"Which model answered this in March" needs an answer.
Every adapter or fine-tune, and its author	The provenance chain is only as good as its weakest link.
Tokeniser version	A mismatched tokeniser degrades output in ways that look like model drift.
Runtime and quantisation settings	The same weights behave differently across runtimes and precisions.
Checksum of the deployed artefact	Proves what is running is what was approved.

The first time a regulator, a customer or your own incident review asks why an output changed, "the model was updated" is not an answer. The bill of materials is what turns it into one.

Pin, and keep the previous one

Treat a model version like any other deployable: pinned, promoted through environments, and reversible. Keeping the prior version loadable is the part teams skip, and it is the part that matters at two in the morning when the new one is behaving oddly and nobody can say why.

Evaluating an open-weight model

Licence first. It decides whether the rest of the exercise is worth doing. Some permit commercial use with conditions, some restrict by scale, some restrict by use case.
Provenance second. Who published it, can the artefact be verified, is there a version history, is there anyone to tell you about a problem.
Your evaluation set third. Not a public leaderboard. A model that tops a benchmark and fails your own cases is not a candidate.

When someone else fine-tunes it

A vendor-tuned model lengthens the chain and makes it harder to verify: you now depend on a base model, on training data you cannot inspect, and on a process you cannot audit.

That can be a perfectly reasonable trade. It should be a recorded decision with a named owner, taken deliberately — not something the organisation discovers it made while working out what went wrong.

Frequently Asked Questions

What is the AI model supply chain?

Everything between a model being trained and it running in your environment: the weights themselves, the format they are serialised in, any adapters or fine-tunes applied, the tokeniser, the runtime, and the registry the files came through. Each is a third-party artefact that executes inside your infrastructure, and each is a link where something can be substituted.

Are model weights a security risk?

A weights file is data, but the code that loads it is not. Some serialisation formats permit arbitrary code execution during deserialisation, which turns downloading a model into running someone else\\u2019s code. Prefer formats designed to be loaded without executing, and verify checksums against the publisher, not the mirror you fetched from.

What is a model bill of materials?

The AI equivalent of an SBOM: the base model and its version, every adapter or fine-tune applied and who produced it, the tokeniser, the runtime version, and the checksum of what is actually deployed. Without it, "which model answered this question in March" has no answer, which matters the first time an output has to be explained.

How do you evaluate an open-weight model for production?

Licence first, because that decides whether the rest of the exercise matters. Then provenance: who published it, can the artefact be verified, is there a version history. Then evaluation against your own task instead of a public leaderboard. A model that tops a benchmark and fails your evaluation set is not a candidate, whatever the benchmark says.

What changes when a model is fine-tuned by a vendor?

The provenance chain lengthens and gets harder to verify. You now depend on the base model, the fine-tuning data you cannot inspect, and the vendor\\u2019s process. That may be entirely acceptable — but it should be a recorded decision with a named owner, not something discovered during an incident.