Use this explorer to see who is accountable for each slice of the AI stack, how that maps to the MLOps lifecycle, and what each layer is for. Named accountable parties clarify procurement and vendor boundaries and tie stage-gate evidence to those parties. The SRF complements NIST AI RMF, ISO/IEC 42001, and the EU AI Act.
Three views of one idea: decompose AI accountability by enterprise layer so obligations land on a named owner. Generic risk frameworks do not spell that out for AI-native, multi-vendor stacks.
AI responsibility components mapped to the five layers of the CoSAI AI Shared Responsibility Framework (V1.0). Cells follow the RACI matrices in §A.1.2 – §A.1.5 of the whitepaper: Primary = accountable owner, Shared = responsible / supports, Inherited = not directly involved or inherited from an upstream layer.
Scroll horizontally to see all nine responsibility components. The layer-label column is pinned.
CRISP-ML(Q) / MLOps lifecycle, with each phase tagged to the CoSAI AI SRF layer that holds primary accountability for the controls in that phase. Useful for mapping evidence (per §A.7 of the whitepaper) to lifecycle stage gates. Click a phase to expand.
The CoSAI AI Shared Responsibility Framework (V1.0) is an accountability model: it names who owns each part of the AI stack so obligations from NIST AI RMF, ISO/IEC 42001, the EU AI Act, and your internal control sets can land on one primary party per concern. It works as a governance manual for decomposition: enterprise layers express invariant dependencies while operating models shift who supplies each layer. The outline below summarizes what each layer clarifies; the cards give illustrative AI concerns that become assignable and evidential once you name that owner.
- L1 — Business & Usage. L1 job: set permitted use, risk acceptance, and cascade: permitted AI use, risk acceptance, regulatory posture, and lifecycle governance decisions, so requirements cascade from business intent to the layers below, matching the framework’s “governance from the Business layer.”
- L2 — Information. L2 job: data, provenance, and retrieval boundaries: provenance, rights, training data, answer-time source stores (including RAG knowledge bases), embeddings, and retrieval boundaries, extending information governance to what models actually ingest and emit.
- L3 — Application. L3 job: apps, agents, prompts, and human override: how capability meets users and APIs (surfaces, tools, agents, prompts, validation, and human override), where application developers discharge the controls referenced around prompt injection and guardrails in the framework.
- L4 — Platform. L4 job: platform runtime, tenancy, and monitoring: serving, tenancy, isolation, quotas, monitoring, and operational hardening at scale, including containing blast radius across tenants as in the framework’s layered incident example.
- L5 — Model provider. L5 job: model artifact and supply chain: training provenance, the shipped model, cards and transparency, third-party and fine-tuned change, so model builders and vendors have a clear lane alongside NIST/ISO what to achieve.