Is there shared responsibility for LLMs?

Before you plan a red-team engagement you need to know whose system you are allowed and expected to test. Cloud security solved a similar problem years ago with the shared responsibility model: the provider secures the platform, the customer secures what they build on it. For LLMs the idea exists in two forms. One is vendor guidance describing who configures and monitors which controls. The other is law, mainly the EU AI Act, which splits obligations between providers of models and the parties that use them. Neither replaces your own testing. Both tell you where your side of the line is.

The vendor model: platform, application, usage

Microsoft’s AI shared responsibility model extends its cloud model to generative AI and stresses that the split varies by whether the AI is consumed as software as a service (SaaS), platform as a service (PaaS) or infrastructure as a service (IaaS). It describes three layers.

• AI platform: the infrastructure that runs the model, the training data and the configuration that changes model behaviour. A safety system at this layer filters harmful inputs and outputs in categories such as hate and jailbreaks.
• AI application: the interface users consume, from a simple front end to systems that ground prompts in extra context through a persistence layer, semantic index or plugins. Its safety system inspects the content sent to the model and the interactions with plugins and data connectors.
• AI usage: how the capability is used. Microsoft says protecting it is similar to protecting any computer system (identity and access, devices, data governance) and adds that acceptable use policies and user education need AI-specific updates.

The Cloud Security Alliance made a similar proposal in July 2023. Its post extends the cloud model to generative AI, with AI service providers on one side and AI service users on the other, and again splits it across IaaS, PaaS and SaaS tiers. That the idea appears in independent proposals is a sign of its usefulness, not of a legal standard. Microsoft states plainly that its article is illustrative governance guidance, “not intended to convey legal conclusions or to modify or contradict the terms of any agreement.”

Agents shift more to you

Microsoft’s separate model for AI agents adds three layers: orchestration, tools and actions, and memory and state. For a SaaS agent Microsoft operates the orchestrator, the model, safety systems and most tool connectors, and you own configuration, data access scoping, identity and usage. For a PaaS agent, where the platform provides runtime, model hosting and safety controls, you own the agent’s instructions, tool selection and permissions, orchestration logic, memory design, identity and authorisation. For an IaaS agent you own nearly everything. Its rule of thumb: “The more autonomy and the broader the tool and permission set that you grant an agent, the more of the responsibility matrix shifts to you.”

The same page lists responsibilities you always retain: your data, the agent’s identity and least privilege, authorisation of actions, human oversight, and acceptable use and governance.

What a PaaS split looks like in practice

The table below applies the sources’ logic to a common case, an organisation using a model through a provider’s API. It is this course’s illustration, not a contract.

Some areas are genuinely shared. Prompt injection is one: a provider can work on the model’s resistance, but only you can limit what an injected instruction could do through tool permissions and data access. Data privacy is another: the provider’s terms decide how it handles data, while you decide what data goes in. Microsoft’s matrix lists customer data as the customer’s responsibility in every deployment model.

The legal form: the EU AI Act

The European Commission’s guidance says obligations for providers of general-purpose AI models began to apply on 2 August 2025. Providers must maintain technical documentation, give information and documentation to downstream providers so they understand the model’s capabilities and limitations, and put in place a copyright policy and a training-content summary. Providers of models with systemic risk must also evaluate the model, including conducting and documenting adversarial testing, report serious incidents to the AI Office, and keep the model and its infrastructure adequately secure. From 2 August 2026 the Commission will enforce the provider obligations, including through fines.

Deployers have their own duties. The Commission’s AI Act page says deployers must ensure human oversight and monitoring, and that providers and deployers report serious incidents and malfunctioning. The high-risk rules were delayed by the AI Omnibus, which entered into force on 27 July 2026: they now apply from 2 December 2027 for systems in listed high-risk areas and from 2 August 2028 for systems built into products.

What to do with this

1. Test your side of the line: instructions, retrieval data, tools, permissions, output handling, logging.
2. Treat the provider’s documentation as evidence about theirs, not as a guarantee about your application.
3. Before adopting a model, read its documentation, its data-handling terms and how it accepts vulnerability reports.