Who should own security decisions for generative AI deployments in the enterprise?

Why Generative AI Security Ownership Cannot Sit in One Team

Generative AI deployments change who can reach data, how prompts and outputs are handled, and how automation is authorised, so ownership has to span security governance, identity, cloud, and the application teams that operate the model-facing workflow. The practical issue is not just policy approval, but who can block a risky integration, review access paths, and decide when a use case is too sensitive to proceed. NIST’s NIST AI 600-1 Generative AI Profile is useful here because it treats GenAI as a governance and risk-management problem, not a purely technical rollout.

In practice, many security teams encounter ownership gaps only after a GenAI use case has already been connected to sensitive systems, rather than through intentional approval design.

What Shared Ownership Looks Like in Practice

Shared ownership does not mean shared ambiguity. It means each function owns a different decision boundary. Security governance should define the approval criteria, acceptable use rules, and exception handling. Identity teams should control who or what can invoke the system, what privileges the model-adjacent services receive, and how access is revoked. Cloud teams should own the environment posture, tenancy separation, logging availability, and service configuration. Platform and application owners should own the business use case, data flow, and the consequences of exposing GenAI features inside an existing product or workflow.

This matters because GenAI often creates new control points that do not fit old application ownership models. A model endpoint might be technically simple, but the surrounding tool calls, retrieval layers, connectors, and human review steps can create a much larger security surface. If ownership is unclear, teams tend to assume someone else is checking data exposure, prompt injection resilience, or over-permissioned service identities. That is where governance breaks down.

• Security governance should set the decision framework for risk acceptance and escalation.
• Identity owners should verify authentication, authorisation, and least-privilege access for users and services.
• Cloud owners should ensure telemetry, segmentation, and environment controls are in place before release.
• Application owners should be accountable for the business workflow, data classification, and user impact.

NIST control guidance is also relevant where GenAI deployment creates concrete control obligations for access, logging, configuration, and monitoring, which is why teams often map these decisions back to a structured control baseline rather than treating them as a one-off architecture debate. The guidance breaks down when organisations try to assign one owner for all risks, because GenAI issues usually span both platform control and business use-case governance.

Where Ownership Models Go Wrong and What Good Governance Looks Like

Tighter governance often slows release, requiring organisations to balance deployment speed against the need to control data, permissions, and model-connected tooling.

One common variation is the “AI centre of excellence owns everything” model. That can help with policy consistency, but it fails if the centre cannot enforce identity controls, cloud guardrails, or application-level remediation. Another weak model is leaving ownership with the product team alone, because the team may understand the feature but not the enterprise risk implications of data reuse, external connectors, or automated actions triggered by model output.

Guidance versus consensus: there is broad agreement that GenAI should not be governed as a simple feature toggle, but there is not full consensus on whether the security owner should sit primarily in central security, cloud security, or a federated operating model. What matters is that the accountable party can make a stop-or-go decision and has authority across the relevant control domains.

For most enterprises, good ownership is visible when the decision path is explicit. If a GenAI deployment can access sensitive data, invoke tools, or affect customer-facing outcomes, the security decision should be jointly owned, with a named accountable leader and documented sign-off from the teams responsible for identity, cloud, and application risk. That structure is most defensible when the deployment crosses trust boundaries, because then the question is no longer “who built the feature” but “who is accountable if the feature widens exposure.”

Practitioner Guidance

What to prioritise: Define one accountable owner for the security decision and separate that from the teams that must contribute controls. Shared input is normal; shared accountability is not. The accountable owner should have authority to pause the deployment if identity, data, or monitoring conditions are not met.

What to verify: Confirm that the owner can answer three questions without escalation: who can access the GenAI workflow, what data it can reach, and what happens if the model or a tool-connected action behaves unexpectedly. If any of those answers live in different silos with no decision path, ownership is not real yet.

Common mistake: Treating GenAI as either a pure technology rollout or a pure policy issue. The security decision is only credible when operational control, governance approval, and application ownership are linked to the same release process.

Practitioner takeaway: The right ownership model is the one that can stop an unsafe GenAI deployment before it creates new access, data, or automation exposure, not the one that merely assigns a department to “be involved.”

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• How should security teams govern API keys used for generative AI access?
• How should security teams handle risks from AI browser extensions?
• Who should own AI agent access decisions in an enterprise IAM programme?