Who is actually accountable? Building a real authority chain for agentic AI

A named owner is not the same thing as accountability.

Ask most organizations who is accountable for a particular agentic AI system, and they can usually point to a name in a RACI chart, a model-risk inventory, or a deployment sign-off. Ask who had the power to prevent a particular harmful outcome before it occurred, however, and the answer is often much less clear.

That gap — between a name on a document and a person with meaningful authority to intervene — is where accountability fails.

This is the fourth article in our AI Governance Gap series. The first argued that governance is becoming a condition of market access in high-stakes sectors. The second showed why governance frameworks built around identifiable human decisions struggle with agentic systems. The third introduced reversibility as the principle that should determine how much control a system requires, and when that control must occur.

This article addresses the practical question left open by those arguments: when accountability needs to move upstream, who is actually waiting there to exercise it?

Moving a sign-off earlier in a workflow is not, by itself, a control; it only becomes a control when the person or function providing that sign-off has the information, authority, time, and obligation to act.

In practice, accountability for an agentic system involves more than accepting responsibility after an incident. It includes three connected burdens:

• ownership: accepting responsibility for the system’s intended outcomes and harmful effects;

• stewardship: setting and maintaining its scope, controls, permissions, and acceptable performance boundaries; and

• gatekeeping, meaning deciding whether, where, and by whom it may be used (including when it must be restricted, suspended, or withdrawn).

These obligations are owed not only to the organization deploying the system, but also to the people affected by its actions and to the regulators who oversee its use.

The named-owner illusion

Many governance programs already include an “owner” field; it is completed during model review, added to a system inventory, and occasionally revisited when an audit, incident, or regulatory request makes it necessary. That is better than having no ownership at all, but it is not enough.

In practice, a model’s metadata in an AI/data science platform often identifies the technical practitioner who initiated development. That data scientist can explain data preparation, architecture, and testing choices. But recorded technical authorship does not answer fundamental operational questions: What use case does this model serve? Why are we pursuing it? Who monitors its live execution, and who has the formal mandate to pull the plug if it acts outside policy?

A name on a platform tells you whom to contact; it does not establish what that person owns, what they can decide, or when responsibility passes to someone else.

That distinction matters most when an agentic system affects an individual: a customer denied credit, a patient directed down an inappropriate care pathway, a job applicant deprioritized, or a supplier wrongly excluded. In those cases, “the system made the decision” or “the process included a human review step” will not satisfy an affected person, a regulator, an auditor, or a court.

To move beyond this illusion, governance cannot live as a static field in a spreadsheet. Orchestration tools like Dataiku Govern replace passive ownership with dynamic governance blueprints, actively mapping out decision rights, gatekeeping approvals, and enforcement mechanisms across the entire system lifecycle.

Agentic systems require an authority chain, not a single owner

Traditional accountability models assume a relatively short distance between decision and decision-maker: a person receives the relevant facts, makes a choice, and can explain that choice afterward. Agentic systems stretch and obfuscate that distance. A foundation model provider trains the base model; an internal technical team configures data access and tools; a product owner defines the objective; a data scientist engineers the prompts; a governance committee approves the broad use case; and an operations team monitors production against an executive’s stated risk appetite.

None of these people may have made the individual decision an affected person experiences, and yet all may have shaped the conditions that made that decision possible.

The answer is not to pretend that one person personally authored every agentic output, but instead establish an explicit authority chain: a clear account of who designed the system’s boundaries, who approved its use, who supervises it in production, who can stop it, and who ultimately answers for the risk.

Authority vs. accountability

Authority and accountability are separate but related concepts: Authority is the power to decide and act. Accountability is the obligation to answer for decisions, actions, or outcomes within a defined remit.

For example, a compliance lead may have the authority to determine whether an agentic system meets regulatory requirements and block deployment if it fails. They are accountable for that determination. After deployment, an operations team may be accountable for monitoring runtime behavior and escalating anomalies, while retaining the authority to pause the system pending formal review.

The goal is not to proliferate names on a document, but to eliminate unowned handoffs. There is no AgentOps without a formalized authority chain.

Five links in a real authority chain

Depending on the organization and use case, one person may hold more than one role, or responsibilities may sit with functional teams rather than individuals. What matters is that every link is active, defined, and connected to the next.

1. Design authority

Design authority allocates responsibility across the choices that define a system’s purpose, scope, and permitted actions.

The authority to determine what the system is built to do - and what it is allowed to do within a business process - sits with the business or process owner. This includes defining the objective, acceptable outcomes, limits of autonomy, and required human escalation triggers.

Technical teams (data scientists and engineers) are responsible for implementing those boundaries within system architecture: instruction sets, model selection, fine-tuning, data access, tool configurations, permissions, and guardrail thresholds.

2. Deployment authority

Deployment authority sits with whoever approves the system for a specific use case, operating environment, and degree of autonomy.

This is distinct from technical design, because a system may be technically capable of taking an action without being authorized to take that action in a particular context. The deployment decision validates:

• What the system is permitted to do autonomously vs. what demands human sign-off;

• What data, tools, and downstream systems it may access;

• What behavioral thresholds trigger mandatory revalidation, suspension, or retirement; and

• Which enforcement mechanisms ensure these boundaries cannot be bypassed.

3. Operational authority

Operational authority sits with the person or function responsible for the system once live.

They monitor execution health, investigate anomalous behavior, manage incidents, and approve operational exceptions. Crucially, they must hold both the mandate and technical capability to pause, restrict, or decommission the system immediately.

Through centralized control environments like Dataiku Agent Management, operational teams maintain continuous visibility over behavioral stability, risk metrics, and execution health across native deployments or ecosystem tools like Microsoft Copilot, AWS Bedrock, or LangChain. This gives operational owners the single pane of glass needed to enforce risk guardrails the moment an agent breaches acceptable performance boundaries.

4. Third-party dependency authority

Agentic systems rely heavily on external foundation models, APIs, and data integrations. These dependencies materially influence system behavior through silent provider-side updates, changed safety filters, API modifications, or service outages.

This introduces regulatory distance: a model provider may reside outside the governing jurisdiction, yet the deploying enterprise remains strictly accountable to domestic regulators and affected customers for any resulting harm.

For every critical external dependency, organizations must assign explicit authority over:

• Assessing how upstream model modifications affect live behavior;

• Enforcing contractual audit, incident-notification, and change-alert protocols; and

• Deciding when a third-party change requires taking downstream agents offline.

The choice of vendor is not an external procurement matter; it is a core operational link in the authority chain.

5. Executive and legal accountability

The final link is the executive role and legal entity that owns the enterprise risk appetite and answers externally when failure occurs.

This does not require senior leadership to micromanage individual agent transactions. It requires them to prove that the organization instituted deliberate governance: establishing acceptable risk tolerances, defining clear escalation paths, and empowering operational roles to intervene.

When an agent causes financial, legal, or physical harm, executive accountability centers on whether the organization built an adequate operational governance framework for the risk it chose to take on.

The handoff test

The most serious accountability failures often occur not within one role, but between roles. For instance, technical teams may configure an agent’s permissions without adequate safeguards against the real-world consequences of its actions, and business teams may approve a use case without visibility into model limitations. Subsequently, operations teams may monitor the system without authority to stop it, and legal and risk teams may be brought in only after deployment, when the relevant design choices have already been made.

Traditional accountability frameworks, like RACI, remain useful but aren’t enough for agentic systems. They clarify who is nominally responsible or accountable, but they don’t establish decision rights, operational handoffs, evidence/audit trails, and the escalation mechanisms required to govern systems that can act autonomously. For agentic AI, accountability must be designed as a live operational capability, not documented as a static allocation of roles.

Reversibility determines how explicit the chain needs to be

The third article in this series argued that governance intensity should scale with irreversibility. The same is true of the authority chain.

For highly reversible, low-stakes actions, such as internal drafting or recommendations that can be easily changed before any external consequence, responsibility can be relatively distributed. A named system owner, audit logging, periodic review, and post-hoc sampling may be proportionate.

For consequential but recoverable actions, the chain needs stronger operational ownership. The organization should know who receives alerts, who can intervene, what escalation paths apply, and how recovery will be managed.

For actions that are irreversible, rights-affecting, or expensive to reverse, authority must be explicit before execution. Organizations should be able to identify:

• who approved the action class;

• who set the conditions under which the agent may act;

• who can halt or override it;

• who monitors for patterns of harm;

• which executive owns the risk decision; and

• which legal entity answers for the outcome.

The lower the reversibility of an action, the less acceptable it is to reconstruct accountability after the fact from logs, policies, and best guesses.

What boards should ask

The question boards often ask is: Who owns this AI system? That question is necessary, but insufficient in the current landscape.

An organization that can answer these questions before an incident is better protected and has built a genuine operating capability: the ability to deploy agentic systems with accountable autonomy rather than uncontrolled delegation.

Accountability is a design decision

The instinct in many organizations is to assign accountability at the end of the development process: a name added to a document during final review, but that is too late.

A real authority chain must be designed alongside the system itself. The same rigor applied to deciding what an agent can do must be applied to deciding who can constrain it, approve it, supervise it, and stop it.

Accountability is not a clean-up task for after something goes wrong, but rather an architectural decision made before the system is allowed to act.