Who should own model provenance and template governance in AI programmes?

Ownership should sit with the teams responsible for AI security, supply chain assurance, and platform governance, with clear sign-off before any model is promoted. If no one owns artefact integrity, poisoned templates can enter production through ordinary model refresh processes without a decision point.

Why This Matters for Security Teams

Model provenance and template governance are not paperwork exercises; they are the control point that determines whether an AI programme can trust what it is deploying. When ownership is vague, a template, prompt pack, or model artefact can be refreshed, copied, or promoted without anyone checking integrity, lineage, or approval status. That creates a quiet supply chain problem inside the AI stack itself.

This is especially important because AI systems often pull from shared libraries, inherited templates, and external model artefacts that change faster than traditional release processes. NHI Management Group’s research on the Top 10 NHI Issues shows that weak lifecycle control consistently becomes an attack path when artefacts are reused without review. The governance lesson aligns with NIST Cybersecurity Framework 2.0: identify, protect, and verify the assets before they are relied on in production.

In practice, many security teams encounter poisoned templates only after an ordinary refresh has already moved the bad artefact into a live workflow.

How It Works in Practice

Ownership should sit with the teams that can enforce security and release discipline across the full artefact path: AI security, supply chain assurance, and platform governance. That means one group is accountable for provenance checks, another for promotion controls, and a third for operational enforcement in the runtime platform. Best practice is evolving, but there should be a clear sign-off step before any model, prompt template, or agent template is promoted.

A practical governance model usually includes four controls. First, every artefact needs a recorded source, version, hash, and approval state. Second, template changes should be treated like software changes, with review, testing, and rollback. Third, promotion should require a named approver who is not the author of the artefact. Fourth, monitoring should detect drift between the approved baseline and what is actually running.

That approach is consistent with the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which frames identity and lifecycle control as inseparable, and with the NIST view that governance must connect policy to operational enforcement. Where teams need a broader risk lens, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful for auditability and evidence collection.

• Use provenance metadata for every model and template artefact.
• Require approval before promotion, not after deployment.
• Keep change logs, hashes, and rollback paths under governance control.
• Separate authoring, review, and release responsibilities.

These controls tend to break down in fast-moving MLOps and agentic AI environments because automated refresh pipelines often bypass manual approval points unless they are explicitly designed into the release flow.

Common Variations and Edge Cases

Tighter provenance control often increases release overhead, requiring organisations to balance deployment speed against integrity assurance. That tradeoff is real, especially when data science teams want rapid iteration and platform teams want a stable, auditable release process. There is no universal standard for this yet, but the direction of travel is clear: ownership must be explicit, and the approval path must be visible.

In smaller programmes, a single control owner may cover both provenance and template governance, but that only works if duties are still separated in the workflow. In regulated or high-risk environments, governance is often split so that AI security validates artefact trust, supply chain assurance checks upstream sources, and platform governance enforces promotion rules. For emerging risks such as template poisoning or compromised shared prompt packs, DeepSeek breach is a reminder that trusted artefacts can become attack vectors when validation is weak.

The useful test is simple: if no specific team can block a bad artefact, then no one truly owns the control. That gap is where governance becomes performative instead of operational.

Related resources from NHI Mgmt Group

• Who should own AI identity governance in an organisation?
• Who should own governance when humans, services, and AI agents all access the same resources?
• Who should own AI identity governance in an enterprise IAM programme?
• Who should own governance for AI-assisted developer access: IAM, engineering, or platform teams?