AI agents can act, delegate and fail, but they can't own the outcome. Who gets paged when an agent inside the building goes wrong?
AI agents can act, delegate, or even fail, but they can't own the outcome. That is still a human's job.
In one of my previous articles, I wrote about killing the spider instead of burning the house down. It is the argument that when an AI agent goes wrong, you contain the blast radius instead of torching the whole system in a panic. That was a technical argument about permissions, sandboxes, and kill switches.
Here is the harder version of that question, and it isn't technical at all. It is organizational.
If the agent is no longer a sandboxed pilot but is actually inside the building, wired into the CRM, the ERP, the ticketing queue, and the codebase, and it does something wrong, who gets paged? Whose name is on the incident report? Who explains it to the board, the regulator, or the customer whose account just got wiped?
Six months into 2026, the honest answer at most companies is that nobody knows yet. And that gap is now big enough that regulators, researchers, and enterprise security teams are all measuring it in real numbers.
Gartner's prediction from last year is playing out roughly on schedule: 40% of enterprise applications are expected to carry task-specific AI agents by the end of 2026, up from under 5% in 2025. That is not incremental adoption. That is an org-wide phase change happening inside a single budget cycle.
Governance simply did not scale at the same rate. A Cloud Security Alliance survey of 418 security and IT professionals, fielded in January 2026 and published in May, found that 82% of enterprises had discovered an AI agent or workflow running in their environment that their own security team didn't even know existed, with 41% finding this more than once. Sixty-five percent had already suffered an AI-agent-related security incident in the past year: 61% resulted in data exposure, 43% in operational disruption, and 35% in direct financial loss.
Forbes ran a piece in April describing the scenario plainly: an agent managing user access accidentally wipes accounts or grants elevated privileges to the wrong people. Within minutes, employees are locked out and sensitive data is exposed. The piece's own framing was blunt: less than half of organizations have a formal governance policy for this at all. The agent acted at machine speed, but the org chart still runs on human speed.
There is one clean signal that companies know this is now a leadership problem: 76% of surveyed organizations report having a Chief AI Officer in 2026, up from 26% a year earlier, according to an IBM Institute for Business Value study of 2,000 CEOs published in May. That is a real structural response.
But a title is not an operating model. Only a small minority of the same organizations believe their AI governance is actually adequate to the risk they are carrying.
Naming an owner for "AI" broadly does not answer the sharper question underneath: who owns this specific agent's specific decision at the exact moment it makes it, not after the postmortem?
That is the distinction a few 2026 governance frameworks are converging on. One useful model, popularized as a "RACI for acting AI systems," makes an explicit rule: an AI agent can be Responsible, Consulted, or Informed on a decision, but it can never be Accountable.
Accountability has to sit with a named human, whether that is a business process owner for the outcome, a product owner for the agent's behavior, an operations owner for monitoring and incident response, or a security owner for what it is allowed to touch. The point isn't bureaucracy for its own sake. It is making sure that when the agent does something wrong, there is a pre-assigned human whose job it was to have seen it coming, rather than a frantic scramble to figure out who should have been looking.
The agent can be Responsible, Consulted, or Informed, but never Accountable. Every production agent needs a named human owner for each role.
It is worth noting that even the people writing the rules haven't fully settled this. The EU AI Act's enforcement powers over general-purpose AI providers go live on August 2, 2026, with fines up to 3% of global turnover or €15 million for documentation and compliance failures. This is a different, lower tier than the 7% ceiling reserved for outright prohibited practices, which is a distinction that gets flattened in a lot of compliance summaries.
At the same time, the EU's "Digital Omnibus" agreement reached in May 2026 pushed the deadline for high-risk system obligations under Annex III back to December 2027, and embedded high-risk systems further still to August 2028.
Read that sequence carefully and it tells us something useful: the obligations on the model providers are tightening now, while the obligations on the companies deploying agents inside their own workflows just got more time. That gap is exactly where the accountability question in this piece lives. The deployer, not just the model vendor, carries the burden for how an agent is configured, scoped, and supervised once it goes live.
Regulators are still negotiating the calendar, but enterprises do not get to wait for them to finish.
The technical version of blast-radius thinking was about scoping what an agent can touch. The organizational version is about scoping who is accountable for what it does touch, and writing that down before the agent acts, not after.
In practice, that means three unglamorous things:
None of that is exciting. However, it is the exact difference between an incident that gets contained in an afternoon and one that becomes the reason your company is named in a regulatory filing next year.
An AI agent's safety ultimately comes down to the governance around it: a verifiable identity, a scoped set of permissions, and a named owner for every action. Get that right, and autonomy is an asset. Skip it, and you won't know who is accountable until something is already broken.
Originally published on LinkedIn.