How should organisations govern AI use when responsibility is split across security, legal, HR, and compliance?

Why This Matters for Security Teams

When AI use is split across security, legal, HR, and compliance, the biggest failure is not disagreement on policy, but the absence of a single decision path that can actually act. Security may understand technical risk, legal may define data-use boundaries, HR may shape acceptable-use rules, and compliance may record obligations, yet none of those functions should operate as a parallel veto chain. Current guidance suggests governance must be operational, not ceremonial, which is consistent with the accountability focus in NIST Cybersecurity Framework 2.0 and the risk-management framing in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. For AI systems that can access tools, secrets, and production data, unclear ownership creates a direct control gap, especially when exceptions need to be approved quickly and logged consistently. In practice, many security teams encounter fragmented AI governance only after an unsupported model, a shadow workflow, or an overbroad exception has already reached production.

How It Works in Practice

The practical answer is to build one enforced governance workflow with named control ownership, rather than a committee that merely reviews issues. One function should own the policy engine, the exception register, and the final approval path, while other functions supply bounded input. That owner should be able to approve, reject, or time-limit use cases, and every decision should be traceable to an accountable record. For agentic AI, that path should also cover workload identity, JIT credentials, ephemeral secrets, and request-time authorisation rather than static role grants.

In operational terms, this means:

• Defining who can classify an AI use case by risk, data sensitivity, and business purpose.
• Separating advisory review from decision authority, so legal or HR can flag concerns without becoming a de facto control bottleneck.
• Using policy-as-code for repeatable enforcement, so access and exception handling are evaluated consistently at runtime.
• Tracking approvals, expiry dates, and revocations in one register that audit can inspect end to end.

This aligns with the governance emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, especially where AI tools or agents need short-lived access to data and systems, and it fits the control logic expected by NIST Cybersecurity Framework 2.0. For deeper context on how identity misuse and exposed secrets amplify AI risk, the Top 10 NHI Issues resource is useful. These controls tend to break down when organisations centralise the paperwork but leave approval and enforcement inside separate departments.

Common Variations and Edge Cases

Tighter governance often increases review time and administrative overhead, so organisations must balance speed against control without letting “shared ownership” become diluted ownership. Best practice is evolving for AI-specific oversight, and there is no universal standard that says every function must sign off on every use case. A more workable model is tiered authority: low-risk internal use can follow a fast path, while anything involving customer data, regulated data, autonomous agents, or secrets requires stricter approval and expiry controls.

Edge cases appear when AI is embedded in an HR workflow, a legal review assistant, or a security operations agent. In those settings, the business owner may initiate the use case, but the control owner must still be able to block unsafe tool access, excessive retention, or unapproved data flows. If the system can act autonomously, intent-based authorisation becomes more important than static RBAC, because the question is not just who started the task, but what the AI is trying to do at that moment. The DeepSeek breach is a reminder that exposed secrets and weak governance can scale quickly once AI systems are connected to live environments. Practitioners should also treat NIST Cybersecurity Framework 2.0 as the baseline for accountability, then layer AI-specific controls on top rather than inventing separate, disconnected rules.

Related resources from NHI Mgmt Group

• How should security teams govern AI use when the same model creates different risk in different contexts?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• How should security teams govern API keys used for generative AI access?