Model Sourcing

What Model Sourcing Means in Practice

Model sourcing is the control point where an organisation decides which AI model it will trust, approve and operate. It is not just procurement, it is also a governance decision about provenance, licensing, ownership and version control, because those factors shape whether the model can be used safely and consistently inside the target system.

For practitioners, the important distinction is that model sourcing happens before deployment but still affects runtime assurance. A model chosen from an unmanaged source can bring hidden dependency risk, unclear update paths or an unsupported licence position, even if the model itself appears technically sound.

Provenance, Licensing and Approval

Good model sourcing starts with knowing where the model came from and who stands behind it. That includes the original provider, distribution channel, licence terms, and any constraints on commercial use, redistribution, fine-tuning or derivative deployment. If those details are not recorded, the organisation may not be able to prove what it approved later.

The approved artefact matters as much as the model name. A model can exist in multiple variants, checkpoints or packaging formats, and the one that is tested, signed off and deployed must be the one documented in the system record. Without that traceability, teams can drift into using different artefacts while assuming they are operating the same model.

Why Model Sourcing Shapes Security and Operations

Model sourcing affects the trust boundary of the whole AI system. A model sourced from an unreliable channel can undermine supply chain assurance, while an ungoverned update can change behaviour, safety characteristics or dependencies without warning. The issue is not only malicious tampering, but also unmanaged change and poor visibility.

Operationally, sourcing also determines how much control the organisation has over support, rollback, reproducibility and auditability. If the team cannot identify the exact model version in use, it becomes difficult to explain behaviour, compare test results, or recover a stable baseline after an incident or regression.

How Organisations Keep Model Sourcing Under Control

Organisations should treat model sourcing like any other high-value software and supply-chain decision: confirm provenance, document the approved source, record the exact artefact, and align the approval process with security and legal review. That is especially important when the model will be reused across multiple systems or business units.

For a practical control lens, this aligns well with supply-chain integrity and secure configuration practices. A sourcing process should make it obvious which model was selected, why it was selected, and what conditions must be met before a different artefact or provider can replace it. That discipline reduces ambiguity when the model is audited, retrained or retired.

Useful reference points include SLSA for provenance thinking and NIST Cybersecurity Framework 2.0 for governance of supply-chain risk and controlled change.

Risk and Threat Considerations

Model sourcing becomes risky when organisations cannot verify origin, integrity or licence status, or when they assume a model label is enough to establish trust. A compromised, substituted or outdated artefact can introduce behavioural drift, hidden dependencies or insecure defaults into downstream systems.

Failure mechanism: Weak sourcing allows an unverified model, clone or modified artefact to be approved and deployed as if it were trusted, which breaks provenance, change control and reproducibility.

Impact: The result can be supply-chain exposure, unexpected model behaviour, audit gaps, and difficulty proving what was actually deployed when investigating an incident or regression.

Practitioner Guidance

Why practitioners should care: Model sourcing is where trust is established, so the sourcing record should be treated as a security and governance artefact, not just a procurement note. If the organisation cannot answer which model was approved, from where, and under what terms, it does not have a reliable control point.

What to watch for: Watch for model downloads outside approved channels, undocumented substitutions, ambiguous version labels, and reused artefacts that have not been revalidated after upstream changes. Those are common signs that sourcing discipline is weakening.

Practitioner takeaway: Make the model source, licence, version and approved artefact part of the system’s controlled inventory so that deployment, review and rollback all refer to the same trusted object.

Related resources from NHI Mgmt Group

• Why do AI sourcing decisions need to be treated as an operating model issue rather than a build-versus-buy choice?
• What is the Model Context Protocol (MCP) and why does it matter for security?
• What does AI model abuse reveal about the current NHI threat surface?
• Why do attackers often check model availability before trying to generate content?