Why do AI systems make shared responsibility harder than cloud security did?

Why This Matters for Security Teams

Cloud security taught many organisations to separate control responsibilities across infrastructure, platform, and application layers. AI systems complicate that model because one business outcome can depend on prompts, model weights, retrieval sources, orchestration logic, tools, and human approval steps at the same time. That means risk cannot be assigned cleanly to a single layer or team. Security leaders need ownership models that map to runtime behaviour, not just procurement or hosting boundaries.

This matters because accountability gaps tend to appear exactly where AI is most dynamic: during inference, tool use, and iterative prompt changes. Traditional control ownership still matters, but it is no longer sufficient on its own. Guidance such as the NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for control design, yet AI systems require a clearer statement of who owns model behaviour, data lineage, and output approval across the full lifecycle. In practice, many security teams encounter this only after an AI workflow has already exposed data, produced unsafe output, or taken an unauthorised action through a connected tool.

How It Works in Practice

Shared responsibility becomes harder in AI because the control path is distributed across more components than in a typical cloud stack. A cloud service often has relatively stable responsibility splits. An AI system can add an external model provider, an internal orchestration layer, a retrieval pipeline, policy filters, and one or more agents that can act on behalf of a user or service account. Each layer can introduce risk, and each layer may be managed by a different party.

Security teams should define responsibility by function and runtime decision point. That means deciding who owns prompt governance, who approves training and fine tuning data, who monitors output quality, and who can permit tool execution. It also means making line-of-business owners accountable for business use, while platform teams own technical guardrails and logging. Current guidance suggests that the most reliable model is one where ownership is documented per control, per data flow, and per action boundary.

• Map the AI workflow from input to output, then assign a named owner to each handoff.
• Separate model provider obligations from internal obligations for data quality, policy enforcement, and incident response.
• Log prompts, retrieval sources, tool calls, and final outputs where privacy and legal constraints allow.
• Review whether agent permissions exceed the minimum required for the task, especially when connected to production tools.

Frameworks such as the CSA Cloud Controls Matrix help with cloud control baselines, but AI requires an added layer of governance for model provenance, prompt injection resistance, and output validation. These controls tend to break down when AI systems are embedded into fast-moving product teams because ownership changes faster than the control documentation.

Common Variations and Edge Cases

Tighter AI governance often increases delivery overhead, requiring organisations to balance speed against review depth. That tradeoff is real, especially where teams want rapid experimentation or delegated agent action. Best practice is evolving, and there is no universal standard for exactly how to split responsibility between the model supplier, the platform owner, and the business owner.

Hybrid deployments create the hardest cases. For example, an enterprise may host its own retrieval data but consume a third-party foundation model, or it may fine tune an external model and then connect it to internal tools. In those environments, responsibility is often shared across contract, architecture, and operations, so security teams should use the control language in ISO/IEC 27001:2022 Information Security Management to anchor ownership, evidence, and review discipline. For agentic workflows, that should extend to explicit approval boundaries and emergency stop conditions.

The main exception is low-risk, read-only AI use with no access to internal systems or sensitive data. Even then, output validation and data handling rules still matter, but the shared responsibility model is simpler. The model becomes much less manageable once AI can write, trigger, retrieve, or approve actions across business systems.

Related resources from NHI Mgmt Group

• Why do AI systems make NHI risk harder to control?
• Why do agentic AI systems make NHI risk harder to manage?
• Why do AI systems make least privilege harder to enforce?
• Why do standing privileges make AI agent security harder?