Who should own governance when an AI platform is self-hosted?

Why This Matters for Security Teams

Self-hosted AI platforms are not just another application stack. The operating organisation inherits the full blast radius: identity governance, patching, data handling, backups, caching, observability, and incident response. That is why ownership cannot sit only with a vendor relationship or a shared services team. The governance model has to match the operational reality, or control gaps appear between procurement, security, and platform engineering.

This is especially important because AI platforms concentrate sensitive data and privileged integrations. NHIMG research on the McKinsey AI platform breach and the DeepSeek breach shows how quickly exposure can cascade when platform ownership, credentials, and operational controls are not aligned. The NIST Cybersecurity Framework 2.0 remains useful here because it forces organisations to assign governance, protect assets, and maintain response responsibilities explicitly rather than assume they exist by default.

In practice, many security teams discover that “self-hosted” really means “self-owned” only after a patch delay, misconfigured access path, or exposed secret has already created an incident.

How It Works in Practice

For self-hosted AI platforms, governance should be split into clear ownership layers. The business owner defines use case risk and acceptable data use. The platform owner, usually infrastructure or platform engineering, runs the environment, applies patches, maintains availability, and owns incident response tasks. Security owns policy, control design, and continuous assurance. Identity and access should be treated as a shared control plane, not an afterthought, because credentials, service accounts, API keys, and model access paths are often what determine real-world exposure.

That means the operating organisation should define who approves changes, who rotates secrets, who monitors privileged access, and who can disable the platform during a security event. Current guidance suggests mapping these responsibilities to existing governance structures rather than inventing a parallel AI committee with no operational authority. NHIMG’s Top 10 NHI Issues is useful here because self-hosted AI often introduces the same failure modes seen in other non-human identities: overprivileged service accounts, missed rotation, and unclear ownership. The Lifecycle Processes for Managing NHIs guidance reinforces that lifecycle control only works when provisioning, review, and retirement are assigned to a named operator.

• Define one accountable owner for uptime, patching, and rollback.
• Assign security policy ownership separately from operational execution.
• Require named ownership for service identities, tokens, and admin paths.
• Document who can approve model, prompt, and toolchain changes.
• Test incident handoff before production go-live, not after.

These controls tend to break down in hybrid environments where the model is self-hosted but logging, identity, or data storage still depend on a third-party control plane because responsibility becomes split across systems with different support boundaries.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance accountability against speed of delivery. That tradeoff is real, especially when platform teams want autonomy and security teams want control gates.

There is no universal standard for this yet, but best practice is evolving toward clear operating ownership plus independent policy oversight. In regulated environments, the platform owner may be the infrastructure team, while the data owner remains with the business function and the risk owner sits with security or compliance. For shared or federated deployments, the safest approach is a RACI model that explicitly names who patches, who approves access, who monitors secrets, and who responds to incidents. The Regulatory and Audit Perspectives section is useful when auditors ask for evidence that ownership is not implied. NIST’s Cybersecurity Framework 2.0 supports this by requiring clear governance and communication paths across the stack.

Edge cases appear when a provider manages the model while the buyer self-hosts the application layer, or when an internal platform is exposed to multiple business units with different data classifications. In those cases, governance should follow the component that can actually change risk, not the team that merely receives the ticket. Organisations that miss this usually end up with security exceptions owned by everyone and fixed by no one.

Related resources from NHI Mgmt Group

• What is the difference between self-hosted and managed MCP governance?
• Who should own AI instruction file governance?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?