Shared Responsibility Model for Generative AI

What Shared Responsibility Means in Generative AI

The shared responsibility model for generative AI separates provider duties from deployer duties. The provider secures the model service, infrastructure and platform layer, while the organisation using the service remains accountable for data sent to it, who can access it, what it is used for and how outputs are approved, monitored and governed.

That split matters because provider terms do not transfer enterprise accountability. The organisation still has to decide which users may prompt the system, what information is acceptable to submit, whether sensitive data may enter the workflow and how model outputs are allowed to influence decisions, records or downstream actions.

What the Provider Secures

The provider side usually covers the hosted model, underlying cloud service, platform availability, patching, service hardening and baseline security of the AI offering itself. In practical terms, this is the “security of the service” layer, where the customer relies on the provider’s controls for the core system, but not for business use decisions.

This boundary is easy to misunderstand because a managed AI service can feel turnkey. Even when the provider offers strong technical safeguards, the deployer still inherits risk from how the service is configured, whether retention settings are acceptable and whether the organisation has placed the right policy controls around its use.

What the Deploying Organisation Must Govern

The deploying organisation controls the human and business side of the model’s use: acceptable inputs, access approvals, role-based use, data classification, prompt hygiene, logging, monitoring and the business processes that consume AI output. That includes deciding whether staff may use public prompts, confidential records or regulated data with the service.

It also includes the consequences of model output. If a generated answer is used to draft a customer communication, support a financial decision or influence code or policy, the organisation owns the review standard and the approval path. Shared responsibility therefore extends beyond security teams into the business function that actually operationalises the tool.

Why the Model Changes AI Governance

Generative AI introduces a wider trust boundary than many classic SaaS tools because the output is probabilistic, context-sensitive and easy to over-trust. Organisations need a clear governance model for input restrictions, output review, human oversight and usage monitoring, especially where employees may treat AI like an internal decision engine rather than an assistant.

The most important practical point is that responsibility follows control. If the enterprise chooses the use case, the data, the audience and the downstream action, it also owns the risk of misuse, leakage and bad decisions, even when the provider hosts the model.

Security Implications of the Shared Boundary

Shared responsibility in generative AI creates exposure when the enterprise assumes the provider will handle policy, privacy or appropriateness decisions. The model can only be made safe for a business when provider controls and deployer controls are aligned around identity, data handling, monitoring and approval.

That means the organisation must treat AI use as part of its security operating model, not as a standalone vendor feature. The question is not only whether the service is secure, but whether the enterprise has bounded what people can send to it and what they can do with what comes back.

Risk and Threat Considerations

Shared responsibility becomes risky when organisations assume the provider has absorbed the full burden of AI misuse, prompt leakage or unsafe output use. The main exposure is not just service compromise, but enterprise-side data disclosure, unauthorised use and poor reliance on generated content.

Failure mechanism: Users submit sensitive information to a model, outputs are accepted without review, or the organisation lacks monitoring over who is using the service and for what purpose. That failure can occur even when the provider is operating the platform correctly.

Impact: Confidential data can leave the organisation, business decisions can be influenced by unvetted output, and governance gaps can turn a well-managed AI service into an enterprise risk.

Practitioner Guidance

Why practitioners should care: Treat the shared responsibility model as an operating boundary, not a legal disclaimer. The deployer must define what data may be used, who may use the service and what level of review is required before outputs affect real-world action.

Governance implication: Ownership should sit with the business function that deploys the model, with security, privacy and risk teams setting the policy guardrails around access, logging, retention and approved use cases.

Practitioner takeaway: If the organisation controls the prompt, the data and the downstream decision, it owns the risk, even when the AI service itself is provider-managed.

Related resources from NHI Mgmt Group

• Guide: Shared Responsibility Models Guide
• AI Agent Shared Responsibility Model
• Why do AI agents complicate shared-responsibility models?
• Why do generative and agentic AI create problems for traditional model risk management?
• Why do shared API keys create the wrong trust model for AI agents?