Model Provenance: Third-Party AI Model Risk as a Board-Level Control

A board that asks “which AI vendor do we use” is asking the easy version of a much harder question: what is actually inside the model that vendor is running, where did its training data come from, and what happens to the answer the board relies on if that provenance turns out to be murkier than the vendor’s marketing suggested.

Model provenance — where a model’s weights, training data, and fine-tuning history actually come from, and how confidently that chain can be verified — is treated, in most vendor relationships, as a black box nobody asks about. That’s a reasonable default for low-stakes applications and a genuine board-level risk gap for anything materially influencing a regulated decision, because a vendor’s own uncertainty about their model’s provenance becomes the deploying organisation’s uncertainty the moment the model is put into production.

Why provenance is a board question, not just a technical one

Three specific provenance risks carry real board-level consequence. Training data contamination — a model trained partly on data the vendor didn’t have clear rights to use, or on data containing embedded bias nobody screened for, creates downstream legal and reputational exposure for every organisation deploying that model, regardless of how carefully the deploying organisation itself behaved. Undisclosed fine-tuning — a vendor quietly fine-tuning a base model on data from other customers, intentionally or through careless data pipeline design, creates a genuine confidentiality risk that has nothing to do with how the deploying organisation itself handles data. Supply chain opacity — a model marketed under one vendor’s name that is, underneath, a repackaged or lightly modified version of a third party’s model, with the actual underlying provenance obscured by branding, which matters enormously if that underlying third party is later found to have a genuine problem.

What genuine provenance diligence actually asks

A board-level provenance review doesn’t require deep technical expertise to run — it requires a specific set of questions asked consistently, the same discipline as the vendor evaluation questions I’ve written about generally, applied to the specific risks AI models carry that traditional software doesn’t. What is the base model, specifically, and who actually trained it — not “our proprietary AI,” a genuine answer. What data was it trained or fine-tuned on, and what rights did the vendor have to that data. Has the model, or its provider, been independently audited for bias, security, or data lineage, and by whom. What happens, contractually, if a provenance problem surfaces after deployment — who bears the remediation cost and the reputational exposure.

Vendors confident in their own provenance answer these specifically. Vendors relying on marketing language — “enterprise-grade,” “responsibly trained,” “industry-leading” — without specific, checkable substance behind those phrases are telling a board something important through the vagueness itself, the same diagnostic signal I’ve written about for vendor evaluation more broadly: composure and specificity under a hard question reveal more than the answer’s content alone.

What one review actually found

A healthcare-adjacent firm running a provenance review on its customer-support AI vendor asked, plainly, whether the underlying model had ever been fine-tuned on other customers’ support data. The vendor’s first answer was a confident “no, your data stays isolated.” A follow-up question about the base model’s original training data provenance produced a considerably less confident answer, revealing the base model itself had been licensed from a third party the vendor had never independently audited. Nothing about the deployment was necessarily unsafe. But the firm’s original assumption — that provenance diligence stopped at its direct vendor — had been wrong, and the second layer down was where the actual uncertainty lived.

Why this matters more as AI supply chains get longer

The provenance question compounds as AI deployments increasingly chain multiple providers together — a foundation model from one vendor, fine-tuned by a second, deployed through a third’s platform, each layer adding genuine value and genuine opacity simultaneously. A board’s risk exposure runs through every layer of that chain, whether or not the board has ever heard the names of the vendors two steps removed from the one they actually contracted with.

None of this argues for treating every AI vendor with suspicion — most provenance chains, honestly examined, turn out to be reasonably clean. It argues for actually examining them, once, deliberately, rather than assuming cleanliness because the vendor’s homepage uses reassuring language.

Running a genuine model-provenance review against an organisation’s current AI vendor relationships — the specific questions a marketing page won’t answer — is exactly the kind of due-diligence work a technology control assessment is built to perform.

The board that asks these questions once, deliberately, is in a categorically stronger position than the board that only discovers the answers after something has already gone wrong with a model it never actually understood.

Provenance risk is a genuine reason to avoid deep coupling to a single provider in the first place — see model-agnostic architecture.

None of this needs to happen at the pace of a full audit cycle. A focused provenance review against an organisation’s two or three most consequential AI vendor relationships can happen in days, and it’s the kind of work that ages well — done once, revisited annually, rather than left undone until an incident forces the question.