Who is accountable for AI output? The person who ran the agent.
Every AI failure I have investigated had a human who pushed the button. Automation is a delivery mechanism, not a transfer of responsibility.
The shipper, not the model.
Every AI failure I have investigated had a human who pushed the button.
That is the entire thesis. The rest of this piece is the work of holding to it when the room would prefer a softer answer.
The pattern is consistent enough that I have stopped treating it as anecdote. A pipeline writes a customer-facing summary that contains a number nobody can source. A code-generation agent ships a function that quietly degrades a production query. An internal assistant drafts a policy clause that contradicts a contract clause two screens away. Each of those is reported, internally, as a model problem. None of them are. In every case there is a person who reviewed the output, or skipped reviewing it, and approved the flow that put it in front of a user, a customer, or a delivery deadline. That person is the accountable party. The model is the instrument. The shipper is the actor.
When I say "AI failure," I mean a workflow that produced output a reasonable person inside the organization would not have endorsed had they read it. Not a bug in the model. Not a latent training defect. A discrete operational event with a date, a system, an output, and a chain of approvals that ended with a human deciding the output was good enough to leave the building. Every one of those investigations terminates at the same place: a named individual or a named role that owned the run.
The point I want to land here, before anything else: the engineer who built an automated agent pipeline does not get to step away from what the pipeline ships. Automation is a delivery mechanism, not a transfer of responsibility. If you wrote the agent, scheduled the agent, and let the agent push code into a repository, the code the agent pushed is yours. The fact that you were not at the keyboard when it ran is exactly the point of having built the agent. Authorship of the automation is authorship of the output.
This is unwelcome news in two directions. It is unwelcome to the operator, because it forecloses the most comfortable explanation, which is that the model misbehaved and the model is a thing outside their control. It is also unwelcome to the executive sponsor, because it forecloses the second-most comfortable explanation, which is that the vendor failed and the vendor is a thing outside their company. Both explanations have one feature in common. They locate the failure somewhere the organization is not required to act.
The accountable party is the person who released the AI-touched output, or the named role that authorized the workflow to release it. Everything that follows is a consequence of that sentence.
Vendor obligations are real and do not transfer your accountability.
The most common objection at this point, usually from procurement, is that the vendor has obligations too. They do. The objection is correct on its face and irrelevant on substance.
Two layers exist, and they are not substitutes for each other. The first layer is vendor obligation. The model vendor is on the hook for product defects, security incidents in their infrastructure, breaches of their service contract, and whatever performance claims they made when you signed the agreement. That layer is real, it is enforceable, and your contracts team negotiated it for a reason. The second layer is operator accountability. That is the obligation your organization holds for the use you put the system to inside your environment, with your data, against your customers, in your decision flow. Vendor obligation does not collapse into operator accountability. They are two different surfaces. A vendor can be entirely in compliance with their contract while your deployment of their system produces an output that fails your customer, your delivery commitment, or your board.
The reason this confuses senior people is that the two layers look adjacent on a contract page. They are not adjacent in cause. The model vendor controls model behavior in aggregate. You control the decision to put that model behavior in front of a specific user, on a specific workflow, with a specific oversight regime, or with none. The first determines what the model can do. The second determines what your organization does with it. The line between those is the line between vendor obligation and your accountability.
I have watched leadership teams treat a vendor's SOC 2 report as if it were a substitute for an internal review process. It is not. The report tells you the vendor runs their controls. It tells you nothing about what your team did with the output the vendor's system produced this morning. The same applies to model evaluation scores, alignment documentation, and red-team disclosures. They constrain the instrument. They do not run the workflow. The workflow is run by your people, under your operating model, with your authority. The contract your side of that line needs is the AI security policy that makes the safe path explicit.
The clean way to hold both layers in mind is this. If the model produces a defect at the population level, meaning a systemic bias, a security regression, or a behavior outside the contracted spec, that is vendor terrain. If a specific output reached a specific customer or decision because your process let it, that is your terrain. Most of the failures I have investigated were the second kind. None of them were resolved by reading the vendor's terms more carefully.
Accountability laundering: the three evasions.
When an AI-touched workflow produces an output that the organization cannot defend, three sentences tend to appear in the post-mortem. I have come to read them as a single phenomenon, accountability laundering, and I have come to name each one out loud, because the only way to stop them is to make their function legible.
The first is "the model hallucinated." This sentence redirects responsibility away from the reviewer. It locates the failure inside the model's stochastic behavior, which is presented as a force of nature, and it suspends the question of why no human caught the output before it left the building. The model's behavior is not a force of nature. It is a known property of the instrument, and the reviewer's job is to know it. A hallucination that ships is a review failure, not a model failure.
The second is "the prompt was off." This sentence redirects responsibility away from the workflow designer. It locates the failure inside a single textual artifact, usually written by an individual, and it suspends the question of why the workflow tolerated a single point of failure at the prompt layer in the first place. Production-grade AI workflows do not depend on the rhetorical skill of whichever engineer happened to write the prompt that morning. They have guardrails, retrieval boundaries, validators, and review steps designed by someone whose job is to keep individual prompt variance from reaching the customer. If a single off prompt could produce a bad output, the workflow was already broken before the prompt.
The third is "the system did it." This sentence redirects responsibility away from the sponsoring executive. It treats the AI workflow as an autonomous agent that arrived from outside the organization, with its own intentions, and locates the failure in something opaque and ownerless. The system did not appear. Someone funded it, someone approved it, someone signed off on the production deployment, and someone owns the operating decision to keep it running. Each of those is a named role. The system did not do it. The org did, through those roles.
What these three sentences share is a grammatical move. Each one converts a human decision into an agent-of-its-own and assigns the failure there. That is what laundering is: moving a thing through an opaque process so that on the far side, nobody can be asked to answer for it. Once you can see the move, you cannot un-see it, and you cannot say any of the three sentences in front of an executive who has read this piece without the room noticing.
There is a fourth sentence I almost added, "we need better governance," but it does not belong on the list, because it is not a redirect. It is the right answer arriving without an owner. The cure for laundering is not more governance language. It is a named accountable role.
The operating-model implication: every AI-touched workflow needs a named accountable role.
For every AI-touched workflow inside the organization, there must be a named accountable role. Not a committee, not a working group, not a shared inbox. A named role, held by a named person, with three specific authorities attached to it. The workflows that test this rule first are the shadow-AI workflows that dominate the real incident log.
The first authority is review. The role can require, before any AI-generated output leaves the workflow, that the output be inspected against a defined standard for that workflow. The standard is written down. The role decides whether the output meets it. Review is not the same as the engineer who built the pipeline glancing at a sample once a week. Review is a structural step in the flow, owned by a role with the authority to halt the flow.
The second authority is sign-off. The role can release a class of output for use, for a given customer segment, decision context, or downstream system, and can refuse to release it. Sign-off is consequential. The signer accepts that if the output produces an organizational harm, they will be asked to explain the release decision. They cannot point at the model. The model is not in the room with the customer. The signer is.
The third authority is remediation. When an AI-generated output produces a harm, whether a misled customer, a contract conflict, a missed commitment, or a delivery defect, the role owns the path to making it right. That includes communicating internally, withdrawing the output, correcting the workflow, and deciding whether the workflow continues, pauses, or is rebuilt. Remediation is not the same as raising a Jira ticket against the model. Jira does not call the customer.
These three authorities, taken together, are what makes a role accountable in any meaningful sense. Anything less is decoration. I have watched organizations write down "the AI Council is accountable for AI output" and consider the matter resolved. The council may own policy, but it cannot be the accountable actor for a specific output. When a workflow fails, the question has to land on a named person with release authority. Only an individual can. The test for whether your org has installed accountability is whether you can walk into the room and name the person, by name, who will be asked when a specific AI workflow produces a specific bad output. If the answer is a function name, a department, or a forum, the workflow is unowned.
Where the role sits, by workflow
The role rotates by workflow. The structure does not. A short, deliberately incomplete map of how that rotation actually lands inside a delivery org:
- AI-generated code shipped through an agent pipeline - accountability sits with the engineer who built and runs the pipeline. The agent is the engineer's instrument. The fact that the engineer was not at the keyboard when the agent committed the function does not transfer the function back to the agent. If the function lands in production and breaks the query, the pipeline owner is the first person the team asks, alongside whatever reviewers, code owners, or release owners approved that path to production. "The agent did it" is the developer-flavored version of "the system did it."
- AI-assisted code review or PR triage - accountability sits with the reviewer who approved the merge, not with the agent that summarized the diff. The agent compressed the diff for the reviewer's convenience. The reviewer is still the named approver in the version-control history. If the merged change is wrong, the merge approval is what the team examines.
- AI-generated draft documents - policies, proposals, contract language, BRS, PRD, ticket descriptions - accountability sits with the PM, BA, or product owner who released the draft into the workflow. The AI produced a candidate. A human said yes to the candidate and forwarded it. The forwarder owns the forwarded artifact, the same way they would have owned a draft written by a junior they delegated to.
- AI-generated customer-facing summaries, replies, or content - accountability sits with the role that put the output in front of the customer. For a support reply, that is the support agent or team lead. For a marketing summary, that is the marketer who approved the publication. The customer does not care that the first draft came from a model. The customer received a piece of communication from the company.
- AI-touched analytics, dashboards, or board-pack contributions - accountability sits with the analyst or head of function whose name appears on the page. AI is allowed to draft the chart commentary. The function head is the one called when the chart commentary turns out to be wrong in front of the executive team.
- AI-assisted internal communications drafted by the user themselves - accountability sits, embarrassingly and correctly, with the sender. Drafting an internal note with an assistant and then sending it without reading it carefully is a category of operator failure that the existing org chart already covers. The assistant is a typewriter. The sender signs the memo.
The pattern repeats across every workflow I have audited. Review, sign-off, remediation, a named individual. Authorship of the workflow is authorship of the output. The fact that part of the workflow was performed by software does not move the authorship.
The objection I hear from C-level leadership is that this does not scale. It does. What does not scale is the alternative, which is letting AI-touched workflows multiply without owners and then assigning blame retroactively when one of them fails. The retroactive model is not cheaper. The cost of an unowned failure, paid to customers, to the board, to your delivery commitments and your own credibility, is far higher than the cost of running a competent review-and-sign-off step on the front end. The unowned model only looks cheaper, because the cost is paid in events that have not happened yet. The accountable model pays the cost continuously and visibly, and as a result the org keeps its standing.
One note on tooling. I am not naming review tools, sign-off platforms, or remediation runbooks in this piece, because the tooling is downstream of the role design. The most common failure I have seen is organizations that buy a review tool before they have decided who, in their org, has the authority to halt a workflow. The tool then becomes another surface where outputs pile up and nobody acts. The order is: name the role, attach the authorities, then choose the instrument. Reversing that order is how organizations end up with expensive dashboards and no decisions.
Org-design close.
If your AI workflow has no named accountable role, your organization is silently betting that nothing will go wrong.
That bet has a payoff curve. Most days it pays out. Most outputs are unremarkable, most customers do not notice, most internal flows produce text that nobody reads carefully. On those days the bet looks like efficiency, and the people who pointed out the missing role look like obstructionists. The bet pays out until the day it does not, and on that day the cost of the missing role becomes legible to everyone at once: the customer, the board, the team, the executives who funded the workflow, the engineers who built it. The cost is not the failure itself. The cost is the fact that nobody in the org has the standing to answer for it.
That is not a strategy. That is a posture. A strategy has a stated cost and a defended decision behind it. A posture has neither. A posture is what an organization has when nobody has thought through the question hard enough to take a position on it.
The work of converting the posture into a strategy is operating-model work. It is the same work I do every time an AI capability moves from experiment to production. Pick the workflow. Name the role. Attach review, sign-off, and remediation authority to it. Write down what the role can refuse and what it must release. Tell the rest of the organization who that person is. Repeat the exercise for the next workflow. Do not skip workflows because they look low-stakes. Every workflow I have investigated retroactively was considered low-stakes the day before it failed.
Accountability is not a layer you bolt on top of an AI deployment. It is the spine of the deployment. A workflow with a named accountable role is an AI deployment. A workflow without one is a posture wearing the costume of a deployment. The two look the same on a slide. They are not the same when something goes wrong.
The person who ran the agent is the accountable party. Decide who that person is, in your organization, for each workflow, before the question is forced on you by an event you would rather not be remembered for.
