On the first Monday after an AI agent goes wrong, there is always a meeting. It is well attended, well intentioned and almost entirely devoted to a single question that should have been settled months earlier. Whose agent was it?
Operations says it belongs to the product team. The product team says it is a finance workflow. Finance points at legal, because legal signed the contract. Legal points at the vendor, because the vendor wrote the logic. The vendor, when it joins the call, is warm, apologetic and quietly precise: the contract assigns responsibility to the customer’s designated owner. Somebody opens the register of agents. The designated owner is a name that nobody in the room recognises, because the person left the company in the spring.
This scene is not a joke, and it is no longer hypothetical. In September, IBM and Censuswide surveyed 3,221 senior executives across eight EMEA markets. 80% said an AI-related incident had reached their board or C-suite in the past year. IBM defined an incident broadly: an agent failure, a data exposure, an AI-driven decision error or an AI security breach. Four in five senior leaders have already sat through some version of that Monday meeting.
Then the survey asked the question that matters. Who owns the outcome when an AI agent goes wrong? The most popular answer was the CIO or CTO. It attracted 17%. There was no consensus on legal liability either: 20% favoured sharing it between deployer and vendor, 19% said a regulatory framework that does not yet adequately exist should decide, and 14% placed it with the vendor.
Read those numbers as a single sentence. Most large organisations have had an AI incident, and most cannot say who is responsible for the next one. They have built the machine, switched it on and forgotten to write a name on the door.
The question nobody put on the project plan
Every agent deployment has a business case, a vendor, a security review, a pilot and a launch date. Almost none has a person whose job it is to answer for what the agent does once it is live. It is the one line missing from an otherwise meticulous plan, and it is missing for a reason: asking for it slows the launch.
IBM’s survey makes the incentive visible. When governance lags behind deployment, 56% of executives keep deploying within agreed risk limits. Only 33% pause until governance catches up. Speed is rewarded and the delay is blamed on whoever caused it. The person who points out that nobody owns the agent becomes the person who is holding up the launch.
So the box on the org chart stays empty, and the agents multiply. 35% of those executives already run agentic AI in production. 75% expect agents to have some level of autonomy over decisions by 2027. Meanwhile only 37% have a formal, board-reviewed estimate of the financial risk from their governance gaps. A board cannot govern a risk it has never priced.
This edition is about that empty box. Who ought to be in it, why nobody wants to be, and what happens to the people who end up there by accident.
The long history of someone to blame
The idea that an organisation answers for the actions of those working on its behalf is old. Employment law has long held that an employer is responsible for what an employee does in the course of the job. Ships have captains, aircraft have a pilot in command, and hospitals have a named consultant on every patient record. These are not just administrative conventions. They are answers to the question that every complex system eventually has to face: when something breaks, where does the account stop?
Automation has repeatedly strained that arrangement. When a machine takes over part of the work, responsibility does not move with it. It stays with the human who is nominally in charge, even as their real control shrinks. The pilot is still responsible for an aircraft that spends most of its flight on autopilot. The operator is still responsible for a plant whose control room has been automated. The more capable the system becomes, the less the person responsible can actually do, and the more the arrangement relies on that person being a convenient place to put the blame.
The researcher Madeleine Clare Elish gave this pattern a name. In a 2019 paper in Engaging Science, Technology, and Society, she described the moral crumple zone: a situation where responsibility for an automated system’s actions is misattributed to a human actor who had limited control over it. The metaphor comes from car design. A crumple zone is the part of a vehicle engineered to absorb the force of a crash so that the passenger compartment survives. In a moral crumple zone, the human absorbs the impact so that the system, and the institution behind it, keeps its integrity.
The AI debate has moved from adoption to governance and accountability.
Ana Paula Assis, Chair of IBM EMEA and APAC, on the findings of the company’s September 2026 executive survey.
Assis is right, and the shift matters more than the sentence suggests. For three years, the argument inside organisations was about whether to adopt. Governance was a compliance exercise, something to be written down and filed. Agents change that, because an agent acts. It sends the email, approves the refund, changes the record, calls the API. A tool you consult leaves the decision with you. An agent takes the decision and tells you afterwards, if it tells you at all.
The mechanism: how an owner becomes a scapegoat
Nobody sets out to build a moral crumple zone. They emerge from three ordinary decisions, each reasonable on its own.
The first is that deployment is decentralised. A marketing team connects an agent to the customer database. A finance analyst gives an assistant access to the invoicing system. A developer gives a coding agent standing credentials. None of these decisions goes through a central approval, because the tools are cheap, the benefits are immediate and nobody wants to wait six weeks for a review.
Workato and Censuswide surveyed 1,001 US IT decision-makers at VP level or above in May. 62% agreed that most of the AI agents in use at their organisation were not formally approved by IT. 63% said their IT team knows less about AI agents than other employees do. These are the people responsible for the technology estate, telling us that the estate has grown without them.
The second decision is that accountability follows the org chart, not the architecture. When something breaks, the organisation asks whose function it falls under. The answer is nearly always technology, because technology is the function that is nominally responsible for systems. The same survey found that 74% of those leaders expect IT leadership to be blamed if an agent breaks policy, exposes data or harms a customer. That is more than twice the share who expect the blame to fall on the AI vendor.
Put the two findings together. IT did not approve most of the agents. IT knows less about them than the people using them. And IT expects to take the blame. That is the moral crumple zone in a single page of survey data: accountability without approval rights, blame without a veto.
The third decision is that the contract assigns the risk downhill. Vendors, understandably, limit their liability. The customer’s designated owner carries the operational risk, and the customer carries the legal risk. By the time an incident occurs, the chain of responsibility runs from a model provider through a platform vendor through an integration partner to one nervous person in a company who clicked “accept” on the terms.
The consequences for that person are not abstract. 23% of the same IT leaders expect to be removed or to resign after a major AI-caused incident. 36% expect their organisation to try to handle a major incident quietly, without disclosure. A role with that profile does not attract volunteers. It attracts people who did not see it coming, and people with no choice.
What gets lost when nobody owns the agent
An empty owner box does not just create a blame problem after an incident. It quietly damages the organisation before one.
Early warning disappears. An owned system has someone who reads its logs, notices the strange behaviour and raises a hand. An unowned system produces the same warnings and delivers them to nobody. The most unsettling detail in many incident reviews is not that the signals were missing. It is that they were there, in an inbox no one was reading.
Learning does not happen. OneTrust and Sapio Research surveyed 1,200 senior decision-makers in eight markets in June and July. 86% had experienced at least one AI-related incident in the past year. Yet only 5% said coordination and accountability are clear across the AI lifecycle. An incident that belongs to no one cannot be investigated properly, because there is nobody whose job it is to change the system afterwards. The organisation experiences a crisis, issues a statement and returns to the previous arrangement.
Authority drifts away from responsibility. Where an owner exists on paper but cannot approve, change or stop the agent, the arrangement is ceremonial. The name on the register is a name to blame, not a person who can act. This is the gap between a decision-maker and a designated owner, and it is the gap the moral crumple zone lives in.
Responsibility cannot be outsourced to the machine. In 2024, a tribunal in British Columbia dealt with a customer who had been given wrong information about a bereavement fare by Air Canada’s website chatbot. The airline argued that the chatbot was a separate legal entity responsible for its own actions. The tribunal did not accept it, ruling that the airline remained responsible for all the information on its website, whether it came from a static page or a chatbot. The decision concerned a small claim, but the principle is not small. A company cannot create an agent and then disown it when it speaks.
Five archetypes of the empty box
Organisations fill the owner role in recognisable ways. Most are wrong, and each fails differently.
The Named Scapegoat. A single person, usually in IT or security, whose name is on the register. They did not choose the agent, cannot veto it and cannot always see it. Their title implies authority; their actual power is the ability to be fired. The Named Scapegoat is the human crumple zone in its purest form, and the organisation treats the arrangement as a successful governance structure until the first incident.
The Committee Ghost. A governance committee that meets monthly, reviews a slide deck and issues guidance. Everyone is responsible, so no one is. The committee can recommend, but it cannot stop a deployment on a Tuesday afternoon, and it has no one to dismiss when the guidance is ignored. When an incident occurs, the minutes show that it was discussed. They do not show who acted.
The Vendor Shield. The organisation assumes the AI supplier carries the risk, and sometimes writes it into the strategy deck. The contract usually says otherwise. The 74% figure from Workato is a useful corrective: IT leaders expect to be blamed at more than twice the rate they expect the vendor to be. Even those who buy from a vendor know the buck does not stop there.
The Absentee Signatory. The person who signed off on the agent months ago and has since moved teams, left the company or forgotten. The register still carries their name, and so do the credentials the agent runs under. The agent continues to operate with the authority of someone who is no longer there. It is the most dangerous archetype precisely because it looks fine on paper.
The Quiet Owner. The rare good case. A named person with authority over scope, access and shutdown, who reads the logs, holds a review date and has a direct line to the executive who will answer for the loss. The Quiet Owner is boring in the best sense: no one notices them until the agent misbehaves, at which point the incident is contained in hours rather than weeks. They are also the hardest to hire, because the role requires technical judgement, organisational authority and a willingness to say no to a launch date.
The uncomfortable truths
1. Ownership without authority is not ownership. It is a liability transfer. If the person named on the register cannot approve, change or stop the agent, the register is a list of people to blame. The test is simple: ask the owner whether they could switch the agent off today without asking permission. If the answer is no, you have a scapegoat, not an owner.
2. The pressure to adopt is not neutral. It is created by executives, repeated by consultants and enforced by peers. Only 37% of EMEA organisations have a board-reviewed estimate of the financial risk, yet 87% of the leaders OneTrust surveyed encourage agent use. A culture that encourages adoption without pricing the risk is not brave. It is borrowing against someone else’s career.
3. Regulators are coming for the name on the door. On 1 October, Senators Josh Hawley and Chris Murphy introduced the AI Agent Accountability Act. As described, it would create criminal and civil liability under the Computer Fraud and Abuse Act for operators who knowingly run an agent that recklessly causes hacking damage or loss, and for developers who fail to put reasonable safeguards in place. It is a proposal, not law, and at the time of writing its text had not been published, so definitions such as “operator” may change. But the direction of travel is unmistakable. The people who run agents are about to be treated as the people who answer for them.
4. “Nobody told me” will not be a defence. The 36% of IT leaders who expect their company to handle a major incident quietly are describing a world in which the first sign of an incident is concealment. Concealment is not a governance model. It is a delay before a larger disclosure, and it exposes the owner twice: once for the incident and once for the silence.
5. An agent without an owner is not autonomous. It is abandoned. We use the word autonomy as if it were a feature. Autonomy is what we grant to someone who can be held to account. A system that nobody can be held to account for is not autonomous. It is an orphan with a root password.
What to do about it
The fix is not complicated. It is just unglamorous, which is why it has not happened. Here is what it looks like by role.
If you are early in your career. You may be offered the agent. A team will need someone to “look after” a new workflow, and the junior person with the energy and the technical curiosity is the obvious candidate. Before you accept, ask three questions. What can this agent do, in plain language? What can I do to stop it, today, without asking anyone? And who do I report to if it goes wrong? If you cannot get clear answers, you are being offered a crumple zone with a nice title. Decline politely, or ask for the authority first. The people who can answer these questions clearly will be among the most valuable in any organisation over the next five years, because they are the ones who make agents safe to use.
If you are a manager building a team. Treat agent ownership as a real role, not an extra line on an existing job description. It needs time in the week, access to logs, the power to pause a deployment and a route to the executive who will answer to the board. When you hire, look for people who can describe how an agent fails, not only what it can do. Ask candidates for a time they stopped something that was working because they did not trust it. And protect the person who raises the incident. If the first thing that happens to them is a difficult conversation with their line manager, you will not hear about the second incident until it is on the front page.
If you run a function or a business. Start with a register of every agent in use. Each entry needs a named owner, a written scope, an access list, a kill switch, a review date and a designated deputy for when the owner is absent or moves on. Review the register against your joiners, movers and leavers list every quarter, because the Absentee Signatory is created by departures, not by decisions. Then give the owner the authority that matches the name. In practice, that means the right to approve, to change and to stop. If they cannot do all three, someone senior has not delegated, they have deflected.
If you sit on a board. Ask for a number. IBM found that only 37% of organisations have a board-reviewed quantification of financial risk from AI governance gaps. If your board has never seen a loss estimate for an agent failure, it is not governing the risk, it is hoping. Ask who owns the most consequential agent in the organisation, what they can stop and whether they would tell you about an incident. Then ask the question 98% of the IBM sample say they have answered: who holds board-level responsibility for AI risk? Naming a director is easy. Asking what that director has actually reviewed is the part that tests the arrangement.
The name on the door
It would be easy to read this edition as an argument for slowing down. It is not. The Workato leaders were explicit that none of them wanted to slow the business. What they wanted was to know what the agents were doing, to be able to audit and reverse their actions, and to know who is accountable. 29% named that last point as a top priority. They are not asking for permission to stop. They are asking for a name on the door.
The irony is that ownership is what makes speed possible. A pilot can fly faster in a system with a clear captain, a checklist and a flight recorder. An organisation can deploy more agents, more boldly, once it knows who is watching each one, what that person can do and where they go when things break. Trust in automation has never come from the absence of human responsibility. It has come from the presence of it.
So the next time someone proposes a new agent, do not begin with the business case. Begin with a short, awkward conversation. Whose name goes beside this? What can they switch off? What will they tell the board when it fails? If the room goes quiet, you have found the work.
Because the Monday meeting is coming. The only choice you still have is whether, when it starts, someone in the room already knows the answer to the question on the first slide.