It should be shared, with security setting control requirements, IAM managing identities and permissions, and the business owning approved use cases and risk acceptance. AI governance fails when it is treated as a side project because the controls span multiple teams. Clear ownership, access review and change control are the minimum coordination points.
Why This Matters for Security Teams
ai governance is not a single control domain, and that is why ownership disputes create real risk. Security teams usually define the control baseline, IAM teams operationalise identity, credential, and access enforcement, and business leaders decide which AI use cases are acceptable and how much residual risk can be tolerated. That split is consistent with the governance expectations reflected in the NIST Cybersecurity Framework 2.0 and the broader accountability model in the NIST AI Risk Management Framework.
Practitioners often get this wrong by treating AI governance as either a pure policy exercise or a pure technical control problem. In practice, model access, prompt handling, data retention, third-party integration, and human approval all intersect. If one function owns the whole topic without the others, gaps appear quickly: security may miss business context, IAM may miss model-specific risks, and business owners may approve use cases without understanding operational constraints. In practice, many security teams encounter AI governance only after an unreviewed use case has already been put into production.
How It Works in Practice
A workable operating model assigns different decisions to different owners. Security should set minimum requirements for data protection, logging, monitoring, vulnerability management, and third-party assurance. IAM should control who can access models, prompts, APIs, service accounts, and downstream systems, with review of high-risk privileges and non-human credentials. The business should own use-case approval, process impact, and risk acceptance because it is closest to the operational consequence of failure.
For AI-specific programmes, governance should also reflect model and usage risk. The NIST AI 600-1 Generative AI Profile is useful where teams need to translate general AI risk principles into GenAI controls such as output review, abuse prevention, and prompt handling. Where AI is integrated into security operations or decision support, the NIST Cyber AI Profile (IR 8596) helps teams think about cyber-specific use, trust boundaries, and monitoring.
- Define a named governance owner for policy, but split implementation across security, IAM, and the business.
- Map each AI use case to required controls, data classes, and approval authority before deployment.
- Use IAM to enforce least privilege for users, service accounts, agents, and tool connections.
- Require change control for prompts, models, connectors, and retrieval sources when they affect outputs or risk.
- Review logging, escalation, and incident response so AI events can be investigated like other security events.
The control pattern is strongest when documented in policy and reinforced through review cycles, access recertification, and exception handling aligned to NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when AI is embedded in fast-moving product teams with no formal release gate, because governance then depends on informal approval instead of enforced workflow.
Common Variations and Edge Cases
Tighter AI governance often increases approval overhead, so organisations have to balance speed against assurance. That tradeoff becomes sharper when teams want to experiment with GenAI, external APIs, or agentic workflows, because useful systems may change too quickly for a heavy committee process. Current guidance suggests risk-based governance rather than one-size-fits-all approval, but there is no universal standard for this yet.
One common edge case is the split between central policy and federated delivery. Central security and IAM teams may own the framework, while product or operational teams run the actual AI service under delegated controls. That can work, but only if the business accepts explicit accountability for each use case and exceptions are time-bound. Another edge case is regulated deployment. The EU AI Act and the ISO/IEC 42001:2023 AI Management System Standard both point toward structured governance, but they do not remove the need for clear internal ownership. The practical question is not who writes the policy, but who can stop a risky use case, who can approve exceptions, and who is accountable when the AI behaviour changes after deployment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0, NIST SP 800-63 and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Sets the risk governance model for AI accountability and lifecycle oversight. | |
| NIST CSF 2.0 | GV.OV | Governance outcomes fit the need for clear oversight and responsibility. |
| NIST SP 800-63 | Identity assurance matters where users or agents access AI systems and data. | |
| OWASP Agentic AI Top 10 | Agentic AI introduces prompt, tool, and autonomy risks that need governance. | |
| NIST AI 600-1 | GenAI-specific profile helps translate governance into operational controls. |
Apply identity assurance and session controls before granting access to AI tools and workflows.
