OPERATIONAL FRAMEWORKS

The Deployment Accountability Map

Three tiers. One deployment. A map of who owns what - and the gap the deploying organization cannot delegate away.

The gap between provider accountability and deploying organization accountability is where most enterprises are currently exposed. The provider documents what the platform can do. Nobody documents what the organization decided it was permitted to do, and who made that decision.

v1.0 · April 2026Sougata Roy, sougataroy.com

Free to read and cite with attribution to Sougata Roy and sougataroy.com. Do not republish, rebrand, or claim authorship of any framework, term, or model as your own.

Explore all frameworks

The Accountability Cascade

v1.0

Accountability flows downward3 items

Tier 1

The AI Provider

The AI provider is the organization that built and maintains the...

Tier 2

The Control Infrastructure

The control infrastructure is the governance and management layer...

Tier 3

The Deploying Organization

The deploying organization is your organization - the entity that...

Version 1.0 - Published April 2026

The accountability gap

Approval says the deployment may proceed. Accountability says who answers for the outcome.

The Deployment Accountability Map exists because organizations often treat vendor capability, platform controls, and business responsibility as one blended ownership question. They are separate tiers, and the gaps between them become visible after an incident.

Use this section to separate the act of approving deployment from the obligation to answer for what the deployed system does.

Why this framework exists

When an AI system produces a harmful output, the natural organizational response is to look toward the vendor. The vendor's terms of service have already answered that question. The answer is almost always no. This is the Accountability Assumption in practice: the implicit organizational belief that accountability for an AI agent's decisions resides with the team that built it, the vendor that supplied it, or the platform that hosts it - rather than with the business owner who authorized its deployment.

AI providers disclaim liability for outputs used in consequential decisions. The governance infrastructure through which agents are deployed provides visibility, audit trails, and policy enforcement, but it does not make the organizational decisions about what an agent is authorized to do. The deploying organization makes those decisions. The problem is that most organizations have not recorded what those decisions were, who made them, or on what authority they acted.

Governance question

When an AI agent makes a consequential decision that causes harm, which tier of your accountability structure is responsible for that outcome, and can your organization demonstrate that assignment was made before the harm occurred?

Editorial governance illustration showing provider capability, platform controls, deploying organization authorization, and the accountability gap around a consequential decision. — Accountability gap
Approval permits deployment. Accountability owns the outcome.
The map separates provider capability, platform controls, and organizational authorization so the unresolved outcome does not remain ownerless.

The map

Three tiers. One accountability landing point.

When things go right, credit flows upward through the tiers. When things go wrong, accountability does not cascade - it lands. It lands on the deploying organization, because the decision to deploy was theirs. The provider's disclaimers do not change that. The platform's audit logs do not substitute for the authorization record the organization failed to create.

Read the map from provider to platform to deploying organization. The unresolved gap at each tier lands on the organization unless it has been formally assigned.

Editorial three-tier deployment accountability map showing provider, control infrastructure, and deploying organization boundaries. — Three-tier map
Every tier has a boundary. The outcome lands at the bottom.
Providers publish capability, infrastructure enforces configured controls, and the deploying organization owns intent, decisions, and results.

01Tier 1

The AI Provider

The AI provider is the organization that built and maintains the underlying model, the platform infrastructure, or the agent-building tooling that the deploying organization uses.

Named role or artifact

Before deploying any AI system, review the provider's terms of service specifically for liability disclaimers on outputs. Document what the provider is contractually accountable for. The gap between that documentation and what your organization is accountable for is the minimum scope of your organizational governance work. That gap is always larger than organizations expect when they review the terms of service carefully for the first time.

02Tier 2

The Control Infrastructure

The control infrastructure is the governance and management layer through which the deploying organization configures, monitors, and operates its AI agents. In a Microsoft-first enterprise, this is Microsoft Entra Agent ID for identity, Microsoft Purview for audit and data governance, and Copilot Studio or Microsoft Foundry for agent configuration.

Named role or artifact

For each deployed agent, document what controls the platform enforces by default and what controls require explicit organizational configuration. The line between what the platform handles automatically and what requires a deliberate organizational decision is where most governance gaps live.

03Tier 3

The Deploying Organization

The deploying organization is your organization - the entity that decided to deploy AI agents in its environment and accepted the business outcomes those agents produce.

Named role or artifact

For each deployed agent, identify the decisions your organization has made about scope, access, permitted actions, and accountability that the vendor and platform do not make for you. Document what you have decided and what you have not yet decided. The undecided items are your deployment accountability gap.

Accountability dimensions

What each tier owns, and what it does not.

Each tier has a different accountability boundary. The map is useful only when the boundary is written plainly enough that a post-incident review can test it.

Use these dimensions to identify where the accountability chain broke: provider, control infrastructure, or deploying organization.

Editorial governance triptych showing provider, control, and enterprise boundary tests with owns and does not own columns. — Boundary test
Accountability requires knowing what each tier does not own
The boundary test makes the enterprise action visible: document the gap, assign ownership, and stop treating assumptions as evidence.

Tier 1

The AI Provider

The AI provider is the organization that built and maintains the underlying model, the platform infrastructure, or the agent-building tooling that the deploying organization uses.

Read this tier as a boundary test: what is owned here, what is explicitly not owned here, and what the enterprise must document next.

What this tier owns

The provider is responsible for the behavior of its model within published specifications and documented limitations, platform security and availability within the terms of the service agreement, disclosure of known limitations and appropriate use cases, and compliance with applicable laws in the jurisdictions where the service operates.

What this tier does not own

Configuration or tasks.

Enterprise action

Tier 2

The Control Infrastructure

Read this tier as a boundary test: what is owned here, what is explicitly not owned here, and what the enterprise must document next.

What this tier owns

The control infrastructure is accountable for identity management and verification, data boundary enforcement through sensitivity labels and access controls, audit log production and retention, and platform-level security configuration. It is not accountable for organizational intent or business decisions - it enforces the boundaries the organization configures, it does not determine what those boundaries should be.

What this tier does not own

Organizational intent or business decisions.

Enterprise action

Tier 3

The Deploying Organization

The deploying organization is your organization - the entity that decided to deploy AI agents in its environment and accepted the business outcomes those agents produce.

Read this tier as a boundary test: what is owned here, what is explicitly not owned here, and what the enterprise must document next.

What this tier owns

The deploying organization is accountable for the decision to deploy, the definition of authorized scope and prohibited actions, the assignment of a named Consequence Owner, the design of human review checkpoints, and the governance documentation that demonstrates those decisions were made before deployment. Vendor disclaimers do not transfer this accountability. Platform audit logs do not substitute for authorization records. The organization that deploys owns the outcomes.

What this tier does not own

Vendor controls do not relieve the deploying organization of liability.

Enterprise action

Governing scenario

Before the Agent Goes Live: The Pre-Deployment Accountability Review

GOVERNANCE DEBT BEGINS THE MOMENT THIS CHECKLIST IS SKIPPED.

Use this scenario when reviewing a post-incident report: if the pre-deployment accountability review was skipped, the accountability gap began before the incident.

The failure pattern

Ethyca's 2026 governance analysis names the consequence directly: when ownership of an AI system's behavior is distributed without structure, liability does not concentrate - it spreads. And when regulators or courts come looking, they do not accept 'that was another team's responsibility' as a defense.

How to apply it

Step 1 is mapping the provider tier for each deployed system. For each AI system the organization operates, identify the provider and review the terms of service. Document what the provider is contractually accountable for and what they explicitly disclaim. Pay specific attention to disclaimers on outputs used in consequential decisions. This documentation is the baseline against which the organizational governance scope is defined.

Editorial governance checklist showing provider terms reviewed, platform controls verified, scope documented, owner assigned, review checkpoints, and signed authorization before go-live. — Pre-deployment review
Governance debt begins when the review is skipped
The review turns provider terms, platform controls, authorized scope, owner assignment, and human checkpoints into deployment evidence.

Primary sources

The research basis for the map.

The page grounds the accountability map in external analysis of AI governance ownership and the operational split between provider, platform, and deploying organization.

Use these references when the accountability finding needs support outside the internal incident report.

Editorial governance illustration showing a completed accountability map with provider record, control record, organization record, governance artifacts, and audit-ready answer. — Completed map
The answer belongs in the map, not in memory
A completed map shows tier responsibilities, the deployment gap, named ownership, authorized scope, review checkpoints, and retained evidence.

ethyca.com/guides/ai-governance

Source: Ethyca, "AI Governance: Framework, Compliance and Operational Guide 2026," February 2026.

View source

Connected frameworks

Where accountability becomes a record.

The map names which tier owns what. These adjacent frameworks turn that ownership into authorization records, operating controls, and chain-level governance.

Use these cards when the post-incident finding points to missing authorization, missing controls, or multi-agent delegation.

Connected framework