We have a governance problem in AI, and it is not the one most people are talking about.

The industry conversation focuses on model safety, bias, and hallucinations. These matter. But the more immediate and under-addressed risk is structural: when something goes wrong in an AI-powered system, no one has clearly defined who is responsible for what. Every layer points to the next. The model company says the product company configured it wrong. The product company says the enterprise deployed it incorrectly. The enterprise says the implementation team made undocumented changes. And the auditor is left looking at a system that four parties touched, with no clear accountability at any seam.

The profession has begun to recognize this. In September 2025, ISACA published a thoughtful piece applying the Cloud Shared Responsibility Model to AI, mapping obligations across model providers, AI platforms, and end users, drawing on the EU AI Act’s role definitions. It is a valuable starting point, and the direction is right.

But I think we need to go further, specifically on two dimensions that the current conversation has not yet addressed.

The first is a fourth layer. The existing frameworks stop at the enterprise as the end user. In practice, the team that actually implements an AI workflow, the developers, the integration engineers, the vibe coders shipping features at speed, operates as a distinct accountability layer with its own risk profile. Collapsing them into “the enterprise” obscures where some of the most consequential decisions are actually being made.

The second, and more important, is audit evidence. Defining who is responsible for what is necessary but not sufficient. What is missing is a mechanism for proving it, the kind of structured, verifiable, third-party attestation that SOC 1 and SOC 2 brought to cloud computing. Without that, AI governance remains a policy exercise. With it, it becomes something auditors, procurement teams, and regulators can actually act on.

We have solved this problem before. In the SaaS world, the Shared Responsibility Model, formalized through SOC 1 and SOC 2 reporting standards, established a practical answer: you control it, you own it, you document it. Sub-service organizations have defined boundaries. Controls are mapped to layers. Audit evidence is required at each handoff. It is not perfect, but it created a common language between providers, customers, and auditors that made enterprise SaaS governable at scale.

The AI supply chain needs the same architecture, with the same expectation of proof.

A Four-Layer Responsibility Framework

I propose thinking about AI accountability across four distinct layers, each with its own control obligations:

Layer 1：AI Model Companies (Anthropic, OpenAI, Google DeepMind) Responsible for: model behavior, training data governance, safety alignment, known capability disclosures, and vulnerability response. This is analogous to the infrastructure provider in a SaaS stack. They set the floor. They should be required to produce something equivalent to a SOC 2 Type II report covering their model development and deployment controls.

Layer 2：AI Product Companies (those building applications on top of foundation models) Responsible for: prompt design, output filtering, integration security, use-case scoping, and how they represent model capabilities to downstream buyers. When a product company embeds a model into a workflow, they are making configuration decisions that carry real risk. Those decisions need to be documented and auditable.

Layer 3： AI-Using Enterprises Responsible for: deployment configuration, access controls, data inputs, human oversight mechanisms, and incident response readiness. This is where most current AI governance frameworks focus, and rightly so. But enterprises cannot govern what they do not understand about the layers above them. They need standardized disclosures from Layers 1 and 2 to make informed decisions.

Layer 4： AI Implementation Teams Responsible for: specific workflow design, validation of outputs, change management, and ongoing monitoring. This is where vibe coding and shadow AI create the most immediate risk, technical decisions made without security review, at speed, by people who may not understand the implications of what they are building on top of.

Why This Matters for Auditors，Cybersecurity and GRC Professionals

The current state is that AI risk assessments are largely qualitative, inconsistent, and incomplete. Organizations are filling out questionnaires based on frameworks that were not designed for agentic AI systems acting as users, generating their own audit trails, and making decisions at machine speed.

A layered responsibility model changes the audit question from “does your organization have an AI policy?” to “what controls exist at each layer of your AI supply chain, who is responsible for them, and what evidence do you have?” That is a question auditors know how to answer, if the framework exists to support it.

It also changes procurement. Right now, enterprises buy AI products without any standardized way to assess the security posture of the model underneath. A SOC-equivalent reporting standard for AI would give procurement and vendor risk teams something concrete to evaluate, the same way SOC 2 Type II reports transformed cloud vendor assessments a decade ago.

The Window to Get This Right

The analogy to early SaaS is instructive not just for the solution, but for the timeline. The SaaS Shared Responsibility Model was largely reactive, it crystallized after incidents made the gaps undeniable. We have an opportunity to be proactive with AI, but that window is narrowing. Agentic AI is already inside enterprise environments. OpenClaw-style tools are already operating with elevated privileges on corporate networks. The first significant incidents attributable to ungoverned AI supply chains are likely eighteen to twenty-four months away.

The profession has both the tools and the credibility to shape how this gets defined. The broader GRC, Cybersecurity community helped build the frameworks that made cloud computing governable. The same work needs to happen now, for AI, before the incidents write the standards for us.

The post The AI Shared Responsibility Gap: Why We Need a SOC-Style Framework for the AI Supply Chain appeared first on Chasing Polaris – Wickey's blog.

*** This is a Security Bloggers Network syndicated blog from Chasing Polaris - Wickey's blog authored by Wickey Wang. Read the original post at: https://wickey.substack.com/p/ai-shared-responsibility-gap-why-we-need-soc-style-wickey-7ahfc