If an agent in your company made a bad call tomorrow and you could not name the one person who answers for it, this is for you. Most UAE executives in IBM's new study could not agree on that name either, and most of them have already had an AI incident reach the top.
What did IBM find in the UAE?
That AI incidents are already reaching leadership, and that nobody agrees who owns them. IBM published the UAE results of its AI governance study on 15 October 2026. Censuswide surveyed 206 UAE executives at organisations with 1,000 or more employees, between 14 and 24 September, as part of 3,221 across eight countries.
Three in four (75%) said an AI-related incident reached board or C-suite attention in the past 12 months. IBM's list of incidents includes an agent failure, data exposure, an AI-driven decision error or an AI security breach. Among those who had one escalate, 49% changed their AI governance policy and 40% changed their AI investment or deployment plans.
Then IBM asked who answers when an autonomous agent causes a bad outcome. There was no consensus.
Most commonly cited owner of adverse outcomes from autonomous AI agents, UAE, % of respondents
IBM's release gives only the top three. The other answers are not broken out for the UAE. Across all eight countries the split is wider still: no single role is named by more than 17%, and the top answer there is the CIO or CTO.
The direction of travel makes the gap matter more each quarter. 38% of UAE respondents already run agentic AI in production in one or more functions, 13% across the whole business. 78% expect agents to have some decision autonomy by 2027. And 41% say their governance is designed to scale with agents.
Why doesn't board oversight answer who owns an agent?
Because a board owns risk appetite, not an agent. IBM found AI risk formally governed at board level in nearly all UAE organisations it surveyed, and the accountability question still splits three ways. A committee can approve a policy. It cannot read last week's refunds, notice that an agent started skipping a check, and switch it off at 9pm on a Thursday.
IBM's report says this itself. Its fifth priority for governing autonomous AI reads: "agents should be overseen by a professional who understands each agent's scope and can intervene if anything goes astray." It adds that ultimate accountability may sit higher, so lines of responsibility should roll up from that first-line oversight to executive leadership.
That gives three layers, and each one has a different job.
The top three UAE answers all name the middle layer; none of them is the bottom one. A Chief Risk Officer can be the right accountable executive. But a CRO with forty agents across sales, service and finance is not the person who notices one of them misbehaving. That is the agent manager's job. IBM did not ask whether that role exists, so check it in your own organisation: if nobody can name the agent manager for each agent, the bottom layer is empty.
UAE law already has a version of the bottom layer for some systems. For personal data processed in the DIFC, Regulation 10 requires a system used commercially for high-risk processing to have an Autonomous Systems Officer appointed by the deployer or operator. Regulation 10.3.4 also deems the deployer to act as a controller for what the system does with personal data. It is a DIFC rule, not a federal one, and whether your use is high-risk is a legal call. The idea is the same: a named human, not a committee. We covered the rule in more detail in AI agent kill switch: the UAE gap.
What does a named agent manager actually do?
Five things, and they fit on one page per agent. This is our method, not an IBM template. We write it before an agent goes live, and the owner signs it.
- 01Owner and deputy. One named person, not a team or a committee, and one deputy who can act with the same rights when the owner is away. Both are people who work in the process the agent serves.
- 02Scope. Which systems the agent reads, which it writes to, and which decisions it may take on its own. Anything not on the list it may not do. Writes change records and send messages, so the write list is the one to argue about, but a read of customer personal data is still processing under data protection law and belongs on the card too.
- 03Hand-off point. The line where the agent must stop and pass to a person: an amount, a customer type, a missing document, a low-confidence answer. IBM's EMEA respondents rank defined thresholds for human escalation among the top capabilities they will need as agents get more autonomy.
- 04Weekly review. The owner, or someone they name, reads a sample of what the agent did and every case it handed off. A wrong pattern caught on a Tuesday is a fix. The same pattern caught by a customer is an incident.
- 05Stop order and reporting line. Which lever stops the agent first, who can pull it, when it was last tested, and which executive gets the incident report. The executive is the middle layer; the owner is the one who acts.
Take a reply agent on a property brokerage's WhatsApp number that answers portal leads and books viewings in the CRM. Its owner is the sales operations manager, with the senior team lead as deputy. It reads listings and lead records and writes viewing bookings and notes. It hands to a person when a buyer asks about price, payment plans or anything legal, and when a lead asks twice for a human. The owner reads twenty conversations every Monday. If it books a viewing for a unit that is off the market, the owner pauses it on that number and the sales director gets the report. This is an illustrative example, not a client.
Writing the card is where the real arguments surface. Two teams claim the agent, or neither does. The write list turns out to be longer than anyone agreed. That argument belongs before go-live, not after the first incident.
How does the card become a control?
A signed page is a promise. Each line on the card needs something in the systems that holds it, or it fails on the first busy day. This is how we map the card to controls; the exact setting depends on your platforms.
The identity line does most of the work. If three agents share one integration user, the audit log cannot say which of them changed a record, and revoking that user stops all three. One identity per agent makes the owner card checkable. The front door can be an API gateway such as our Flex Gateway setup or the control layer we describe in the control plane. Our founder taught this at Dreamforce 2026 in the breakout "Agent Fabric: See, Control, and Govern Every Agent" (session notes).
What does the owner need to be able to stop?
Everything the agent can touch, from one place. IBM asked UAE executives what they expect to need to manage agents making decisions at each step by 2027. 36% named the ability to immediately halt agent activity across the enterprise, alongside vendor liability frameworks (37%) and cross-jurisdictional governance structures (36%).
An owner who cannot stop the agent only has a title. The stop itself is rarely one button: it is pausing the agent, cutting its logins, cutting the connectors it calls and closing the channel it answers in. We set out those four levers and a timed drill in AI agent kill switch: the UAE gap, so we will not repeat them here.
What the owner card adds is who pulls the lever, and the deputy who pulls it when the owner is on a flight. Give both the permissions in advance. Test them in a sandbox, and write the time on the card.
Agents your vendors run belong on the list too. Nearly half (49%) of UAE respondents admit gaps in how their governance covers AI used by vendors, technology partners and suppliers, and only 29% monitor third-party AI risk continuously. If a supplier's agent writes to your CRM, it needs an owner on your side.
What do these numbers not tell you?
Less than the headline suggests. This is a survey of what executives say, not an audit of what happened, and IBM sells AI governance software and services, so weigh the framing. The UAE base is 206 people at large organisations with 1,000 or more staff. A smaller company may have one agent and one obvious owner.
"An AI-related incident reached the board" covers a wide range, from a data exposure to a decision error, and the release does not say how serious each one was. IBM gives only the top three UAE answers on accountability, so we do not know how many said "nobody" or "not decided". And some of the figures we compare differ in wording: the UAE release says "immediately halt agent activity", the eight-country report says "pause agent activity" (29%). Read the direction, not the decimals.
The direction is consistent. Agents are moving into production faster than the organisations running them have decided who looks after each one.
What would we do first?
List the agents you run today, including the ones a team switched on inside a vendor's product, and write one owner card for the agent closest to customers or money. At Mindcat, our method for a first agent is "Spec, shadow, gate": write down what it may touch, watch it work alongside a person, then gate every write behind a named owner. The owner card is the first page of that spec.
After go-live, the owner stays on your side. Our Run plan supports them: for agents, we read a sample of transcripts and hand-offs every week and fix what went wrong, and the monthly note says what changed. The owner decides; we do the work. Our own access goes on the card like anyone else's: who on our side, what they can read, and until when.
This is not for a team with no agent touching a real system yet. Name an owner for the process first; our Implement Around Your Process work starts there.
If you have agents live and no owner card for each, the written assessment is free. You get the list of agents we find, a draft owner card for each, and the lines no control holds yet. When there is an agent to build, the first build week is a fixed AED/SAR 14,900, credited in full if you sign the build within 60 days.
