Shared Responsibility for AI Infrastructure: The Layer-by-Layer Model

The shared responsibility model is fifteen years old, cloud-native, and quietly broken for AI: it drew its lines for a world of instances and storage buckets, and AI estates added model weights, training-data custody, and prompt handling — layers the classic model never accounted for, sitting exactly where responsibility questions are hardest. The result is the standard failure: two parties, each certain the other owns the control, discovering otherwise during an incident. This page extends the model properly: six layers, ownership that shifts by deployment model, and the documented matrix that keeps boundaries examined rather than assumed.

Six Layers and Who Owns Each

Responsibility layers from bottom to top — facility, hardware, platform and orchestration, workload and data, model, and application — with the provider typically owning the lower layers and the customer the upper ones, and the AI-specific additions (model behavior, training-data custody, prompt handling) sitting exactly where the classic cloud model never drew lines.

The classic-model ancestry sets the defaults — provider secures the infrastructure, customer secures data, configuration, and access — and the security-model extensions for AI add the layers that ancestry predates: build-versus-consume ownership of the model layer, custody of training data, and handling of prompts as a governed artifact. Industry commentary names the gap directly: applying the fifteen-year-old cloud model to AI systems leaves responsibility undefined precisely where AI concentrates its risk. The six-layer stack above is this page's organization of that extension — the layer names adapt to any estate; the additions being explicit is the entire point.

How Deployment Models Move the Lines

Deployment models move the boundary lines: consuming AI as a service shifts model-layer duties to the vendor while returning configuration and data-governance duties to you; building on raw infrastructure returns every layer above the metal to you; managed and dedicated models consolidate middle layers under contract — the matrix is per-model, and assuming one matrix fits all deployments is the first confusion.

The table's honesty item is that consolidation is not elimination: a dedicated environment consolidating middle layers under one provider — the model this site's private-infrastructure pages cover — still leaves workload, model, and application responsibility with the customer, and the consolidated boundary is documented rather than dissolved. Security-model guidance for AI establishes the pattern the table generalizes: ownership shifts with build-versus-consume, and the shift is per layer, not per contract. Hybrid estates therefore hold multiple matrices simultaneously, one per environment, which is exactly why the single-assumed-matrix habit fails the moment architecture gets interesting.

Documenting Boundaries Before They Bite

The matrix becomes an artifact by documentation: a responsibility map across the AI supply chain naming each layer's owner under each deployment model — the document audits consume, incident response reads at 3 a.m., and vendor conversations correct — because the standard failure of shared responsibility is not disagreement but unexamined agreement, two parties each certain the other owns the control.

• Per environment, not per company: each deployment model in the estate gets its own matrix column — the hybrid estate's document shows all of them side by side.
• Named owners, not "the provider": each control line names who executes it, who verifies it, and who answers when it fails.
• The supply chain extended: standards guidance directs documenting responsibilities across the AI supply chain — subprocessors inherit lines from their customers, and the matrix says which.
• The 3 a.m. test: incident response reads the matrix under pressure — if it cannot answer "whose control, whose escalation" in seconds, it is documentation, not an artifact.

Press coverage of the model's ambiguities documents the stakes — boundary confusion produces security consequences, not just paperwork friction — and the artifact exists precisely because unexamined agreement feels like alignment right up until the incident assigns the control to nobody. For estates extending into dedicated infrastructure, the consolidated-column conversation with providers such as OneSource Cloud's private AI infrastructure is exactly where the matrix earns its keep: which layers consolidate, which remain yours, and what evidence the boundary produces — documented before signature, examined at every renewal.

FAQ

Who is responsible for model security?

It depends on the deployment model — consuming AI as a service places model-layer duties with the vendor under contract, while self-hosting returns them to you entirely — which is why the matrix is drawn per model, and why the question without the model named has no responsible answer.

Is the cloud shared responsibility model enough for AI?

No — the cloud-era model never drew lines for model behavior, training-data custody, or prompt handling, and applying it unextended leaves exactly the AI layers unowned; the extension is not optional bookkeeping but the closing of gaps the classic model predates.

What is the most common responsibility failure?

Unexamined agreement: both parties certain the other owns a control — facility-side assuming patching, customer-side assuming physical security — discovered during the incident neither side owned preventing, which is what the documented matrix exists to prevent.