The accountability gap
When a vendor-hosted AI system causes harm, who exactly is accountable?
NIST AI RMF defines what governance outcomes to achieve. ISO/IEC 42001 defines how to manage AI within your organization. EU AI Act defines which regulatory obligations apply by risk tier. None specifies who holds the accountability token when a RAG pipeline returns biased output, an agentic workflow takes an unauthorized action, or a foundation model produces a harmful response inside a SaaS product you didn't build. The CoSAI AI SRF answers that question — systematically, for every operating model and every layer of the stack.
At a glance
| Framework | Primary question answered | Focus area | Multi-party accountability? |
|---|---|---|---|
| NIST AI RMF AI 100-1 · NIST · 2023 | What governance outcomes should be achieved? | Risk identification & response | Not addressed |
| ISO/IEC 42001 AI Management System · ISO · 2023 | How should an organization manage AI within its boundary? | Management system & certification | Single-org assumed |
| EU AI Act Regulation (EU) 2024/1689 · In force 2024–2026 | Which regulatory obligations apply by AI risk tier? | Regulatory risk tiers & compliance | Regulatory only |
| CSA AICM AI Controls Matrix v1.0.3 · CSA · 2024 | Which controls apply across 18 AI security domains? | Control catalogue & crosswalks | Broad tiers only |
| MITRE ATLAS Adversarial Threat Landscape for AI · MITRE · Living | What adversarial attacks target AI systems (AML.Txxxx)? | Threat taxonomy & TTPs | Threat taxonomy only |
| COSAiS / NISTIR 8605A SP 800-53 Overlay for AI · NIST · Pre-draft 2026 | Which SP 800-53 controls require tailoring for AI systems? | Federal control overlays & lifecycle | Federal/single-org |
| NTIA AI Accountability Report Policy Report & Recommendations · NTIA · March 2024 | What policies should hold AI actors answerable to external stakeholders? | Federal accountability policy & call to action | Calls for it |
| CoSAI AI SRF Shared Responsibility Framework · CoSAI / OASIS · V1.0 | Who is accountable for each control, in which deployment model? | Layered accountability & RACI | Core purpose |
Framework deep dives
What it does well
Defines what governance outcomes to achieve — Govern, Map, Measure, Manage — across the full AI lifecycle. Widely adopted, vendor-neutral, and paired with a rich Playbook of suggested actions.
Where it stops short
Assumes a single organization owns the AI system end-to-end. It does not address how accountability is split when a model provider, platform provider, and customer each control different parts of the stack.
What it does well
Provides a certifiable management system structure (analogous to ISO 27001 for security) covering policy, risk assessment, incident handling, and continual improvement. Gives enterprises a recognized audit basis.
Where it stops short
The standard is written for a single organization managing AI within its own boundary. Supply chain and vendor accountability — particularly for hosted models and API-based AI services — are left to interpretation.
What it does well
Defines which regulatory obligations apply by AI risk tier — prohibited, high-risk, limited, minimal — and adds GPAI rules for foundation models. The first legally binding AI regulation globally, with enforcement that escalates through 2025–2026.
Where it stops short
The Act assigns legal liability at the entity level (provider vs. deployer) but provides no operational model for how those obligations are discharged across platform layers, especially in complex agent chains where multiple providers each contribute a piece.
What it does well
243 controls across 18 domains with ownership tiers (MP/OSP/AP) and crosswalks to EU AI Act, ISO 42001, NIST AI 600-1, and BSI AI C4. The broadest AI control catalogue available, with LLM lifecycle phase mapping.
Where it stops short
Ownership tiers (Model Provider / Orchestration Service Provider / AI Practitioner) are fixed labels, not parameterized by operating model. A control marked "OSP" looks the same whether you're using a managed API, building on a foundation model, or running a self-hosted agent.
What it does well
The definitive catalogue of adversarial techniques targeting AI systems — prompt injection, model inversion, training data poisoning, and more — with AML.Txxxx technique IDs and real-world incident case studies.
Where it stops short
ATLAS is purely descriptive. It tells you what attacks exist and how they work, but not who in a vendor/customer deployment is responsible for detecting, preventing, or responding to each technique.
What it does well
Provides precise SP 800-53 control tailoring for AI systems across four lifecycle phases (Training / Deployment / Maintenance / Continuous) and cross-references MITRE ATLAS adversarial technique IDs. The highest-fidelity federal AI control guidance available.
Where it stops short
Designed for federal systems and single-organization ownership. It doesn't address how SP 800-53 controls are split when commercial AI services (AI-SaaS, AI-PaaS) are in the stack, which is the dominant pattern in most non-federal deployments.
What it does well
The first major US federal policy document to formally call on industry to develop AI accountability mechanisms — audits, assessments, certifications — that allow external stakeholders to verify AI systems are trustworthy. Defines accountability as requiring that AI actors face consequences when they are not trustworthy, and calls on government and industry to build the ecosystem that makes those consequences real.
Where it stops short
A policy call-to-action, not an implementable framework. It does not specify how responsibility is allocated across model providers, platforms, and deployers in a multi-vendor AI stack — the operational prerequisite for any audit or assessment program to function.
A note on terminology
NTIA defines accountability as answerability to external parties plus enforceable consequences. SRF uses accountability to mean operational assignment — who is responsible for which activity across which layer. These are complementary definitions at different levels: SRF establishes the assignment; regulation (EU AI Act) and liability law supply the consequences.
What SRF adds that no other framework provides
Every responsibility in SRF has exactly one accountable party. No shared ambiguity, no RACI rows where three parties are marked Accountable and nobody actually owns it.
The same activity — say, input guardrails — is the provider's responsibility in AI-SaaS and the customer's in IaaS. SRF makes that shift explicit for every layer and every model.
SRF includes Agent-PaaS as a distinct operating model with its own accountability matrix — the first framework to directly address agentic and multi-agent responsibility boundaries.
SRF accountability assignments translate directly into contract clauses, vendor questionnaires, and SLA language — reducing negotiation cycles between customers and AI providers.
SRF is not a new control set. It's an accountability layer that sits above existing frameworks — you keep your NIST, ISO, or AICM controls and add the "who owns this" dimension SRF provides.
Produced under the OASIS Open standards process by the Coalition for Secure AI (CoSAI), with members spanning hyperscalers, model providers, and enterprise security vendors. No single vendor's interests shape the accountability model.
Use the Responsibility Mapper to generate a RACI for your operating model, or explore how SRF's five layers apply to your AI stack.