Neither team should own the problem alone. AI governance spans privacy, security, risk, legal, and identity controls because the same system can create data exposure, access risk, and regulatory obligations at once. The strongest programmes create a shared operating model with clear accountability for ownership, policy, and remediation.
Why This Matters for Security Teams
AI tools rarely create a single kind of risk. A chatbot, copilot, or internal agent can expose personal data, leak secrets, bypass approval paths, or generate unsafe actions that become a security event. That is why the question is not simply who “owns” AI, but which function can coordinate risk decisions across privacy, security, legal, and identity controls. Current guidance suggests using a shared operating model aligned to the NIST Cybersecurity Framework 2.0, because governance works best when accountability is explicit and controls are mapped to real business use cases.
Security teams tend to focus on access, monitoring, and incident response, while privacy teams focus on lawful processing, minimisation, retention, and user rights. Both views are necessary. If either function works in isolation, AI review becomes a checkbox exercise: privacy approves the data flow without understanding privilege, or security approves the tool without understanding personal data exposure. The right model is not a handoff, but a coordinated control plane with defined decision rights. In practice, many security teams encounter AI governance only after a model has already processed sensitive data or an agent has already triggered an unauthorised action, rather than through intentional design review.
How It Works in Practice
Organisations usually need a tiered workflow. Privacy teams assess whether the AI use case is lawful, proportional, and transparent. Security teams assess whether the system is hardened, monitored, and limited to approved identities, secrets, and data sources. Risk or GRC functions often translate those findings into policy exceptions, control owners, and audit evidence. For higher-risk deployments, the most useful reference point is the control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls, because it treats security and privacy as connected control domains rather than separate silos.
- Define a single intake path for AI use cases, with mandatory review criteria for data type, model access, and business impact.
- Assign control owners for prompts, outputs, retained logs, connected systems, and human approval points.
- Require identity controls for administrators, service accounts, and AI agents that can invoke tools or access records.
- Document when privacy sign-off is required, when security sign-off is required, and when both are mandatory.
- Track exceptions centrally so local teams cannot bypass review by adopting new AI features outside the approved workflow.
For organisations operating under personal data obligations, the EU General Data Protection Regulation (GDPR) is especially relevant because it forces clarity on lawful basis, minimisation, and accountability. Security teams should still own technical enforcement, but they should not decide privacy questions alone. These controls tend to break down when AI is deployed through shadow IT or embedded in business apps because ownership becomes unclear and no one is accountable for the full data path.
Common Variations and Edge Cases
Tighter governance often increases review time and slows experimentation, so organisations have to balance speed against assurance. That tradeoff is real, especially in product teams that want to prototype AI features quickly. Best practice is evolving, but current guidance suggests using risk-based thresholds rather than forcing every use case through the same approval queue.
Low-risk internal drafting tools may only need lightweight privacy screening and security configuration checks. By contrast, tools that handle customer data, internal credentials, regulated records, or autonomous actions should trigger deeper review from both functions. The edge case is agentic AI: once an AI system can take actions, the control question shifts from “what data is it seeing?” to “what is it allowed to do, and under whose identity?” That is where AI governance intersects with identity governance, privileged access, and secrets management.
There is no universal standard for this yet, but the strongest programmes treat privacy as the authority on data rights and disclosure, security as the authority on technical control and adversarial risk, and both as co-owners of lifecycle governance. That model is especially important when vendors change model behaviour, when data residency matters, or when the organisation cannot clearly explain where prompts, outputs, and logs are stored. NIST Cybersecurity Framework 2.0 remains a practical baseline for structuring that shared accountability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | AI governance needs clear oversight and shared accountability. |
| NIST AI RMF | GOVERN | This question is fundamentally about who governs AI risk decisions. |
| NIST SP 800-53 Rev 5 | RA-3 | Risk assessments must cover both privacy and security impacts of AI use. |
Set AI governance roles, escalation paths, and accountability before deployment.
Related resources from NHI Mgmt Group
- How should security teams govern AI coding tools that create non-human identities?
- How should security teams govern AI tools that connect to SaaS data?
- How should security teams govern generative AI tools connected to SaaS apps?
- How should security teams govern AI models that can call tools and access data?
