No One Owns the Fallout When an AI Agent Fails

Eight in ten executives across Europe and the Middle East say an AI incident reached their board or C-suite in the past year. Ask those same executives who answers when an AI agent causes the next one, and no single role collects more than 17 percent of the votes.

That split comes from an IBM study released October 14, 2026, which surveyed 3,221 executives through Censuswide at organizations with 1,000 or more employees in the UK, France, Germany, Italy, Spain, the Netherlands, Saudi Arabia and the UAE. Fieldwork ran September 14 to 24, 2026. The 80 percent incident figure earned the headline. The more useful finding for a CISO or Chief Compliance Officer sits deeper in the report, in the answers about who is accountable when agents go wrong.

Call it the ownerless incident. The board has formally assigned AI risk to someone, the agents keep touching sensitive data, and when something breaks the accountability chain scatters across eight different answers. That is a governance problem, and it is also an evidence problem, because a regulator who asks who authorized an agent to read a record wants a name and a log, not a committee. Kiteworks secure data exchange exists for that second half of the question, and this post explains how the two halves connect.

Key Takeaways

1. The incident count is no longer the news.

Eighty percent of surveyed executives say an AI incident reached their board or C-suite in the past year, so the open question is what leadership can prove about its response.

2. Ownership is fragmented where it counts.

Board-level AI responsibility is nearly universal, yet no single role is named by more than 17 percent when an AI agent produces an adverse outcome.

3. Informal escalation is an audit exposure.

More than a third of incidents that reached leaders did so informally, which leaves a Chief Compliance Officer without a record of what was decided and when.

4. Contracts are not controls.

Most organizations govern vendor AI with clauses and audit rights, while only a small minority monitor third-party AI continuously or require independent assurance.

5. The data obligations did not move.

The EU AI Act timeline shifted, but GDPR security and breach-notification duties and NIS 2 reporting duties still apply to agent access today.

Eight in Ten Boards Have Already Seen an AI Incident

Start with the number nobody can wave away. According to the IBM report, The New Realities of AI Governance, 80 percent of surveyed executives say an AI-related incident reached their board or C-suite within the past year. This is no longer a hypothetical risk on a heat map. It is a recurring agenda item.

What happened next is more revealing than the incident count. Of the organizations where an incident reached senior leaders, 43 percent say it was formally reviewed at that level, while 37 percent say it was communicated informally. Read that again. More than a third of the time, an AI incident traveled to the top of the organization by hallway conversation instead of through a governance process.

An informal escalation leaves no record that survives scrutiny. When a supervisory authority asks how leadership learned about the incident, what it decided, and when, “we talked about it” is not an answer a Chief Compliance Officer can put in front of a regulator. The formal review is the control. The informal mention is the exposure.

The consequences the report lists are just as concrete. Among organizations where an incident reached senior leaders, 40 percent cite a change to AI governance policy as a primary outcome, 38 percent a change to investment or deployment plans, 37 percent the engagement of external advisers, and 35 percent that regulators were notified. Treat those as directional. They come from a vendor-commissioned survey of self-reporting executives, and they cover eight markets rather than the world.

Even so, the regulator figure deserves a second look, because it is the one number in this list that a supervisory authority could verify from its own files. More than a third of organizations that escalated an incident also ended up talking to a regulator. For the people who own audit readiness, that moves the evidence question from “someday” to “this quarter.”

Board Ownership Exists but Agent Accountability Does Not

On paper, the picture looks tidy. The IBM survey found that 98 percent of respondents have formally assigned board-level responsibility for AI risk, and 26 percent have a dedicated board-level AI committee. Governance structures are in place almost everywhere.

Now ask the harder question. When an AI agent produces an adverse outcome, who is accountable? The CIO or CTO was the most common single answer at 17 percent, and no role was named by more than 17 percent. Shared C-suite accountability drew 14.5 percent, the chief risk or chief compliance officer 14 percent, a chief AI officer 13 percent, the deploying team 11 percent, the AI vendor 10 percent, a business-line leader 10 percent, and the CEO 9 percent.

That is not a disagreement about org charts. It is the absence of one. A board committee can own a risk category, but an incident needs a person who can explain what the agent touched, under whose authority, and under which policy. Eight different answers, none of them a majority, tells you most organizations have not made that assignment yet.

This split deserves the caution any survey deserves. One 2026 IBM-commissioned survey of executives in eight markets is not a settled industry fact about who owns AI security. Surveys that ask different respondents in different regions have put the CIO, the CTO, and the CISO each in the lead seat. The durable finding is the fragmentation itself.

Here is the whole game. Accountability that lives only at the committee level does not produce evidence. Evidence comes from the data layer, where a named human authorizer, an agent identity, a policy decision, and a log entry meet. If that chain exists, the question of who answers has a factual basis. If it does not, the organization is arguing about blame while the regulator’s clock keeps running.

The CISO usually inherits this vacuum whether or not the title appears in anyone’s answer. The security leader is the executive the board turns to when the incident is real, which makes the missing chain a personal problem as well as an institutional one.

Governance Designed for People Is Now Scaling to Agents

Agents are already in production in a meaningful share of these organizations. IBM reports that 35 percent run agentic AI in production, and 75 percent expect agents to act without human approval of every action by 2027. At the same time, only 37 percent say their governance is designed to scale with agentic deployment, while another 45 percent say it could cope but needs strengthening.

Put those figures side by side and the shape of the problem appears. Deployment has a calendar. Governance has an intention. The report adds that 56 percent continue deploying within agreed risk limits while their governance adapts, and a third delay deployment until governance is ready. The majority is building the plane in flight.

Governance lag is the right name for it. It is the interval between the day an agent starts touching regulated data and the day the controls that govern it are evidence-quality. Every day inside that interval produces access events that cannot be reconstructed later.

One clarification matters for how this gets written up internally. “Without human approval of every action” describes delegation, not independence. A human authorizes the workflow, a policy bounds what the agent may touch, and the log records both. Agents join people as a second class of identity under one governance model. They do not replace the human accountability chain, and a program that treats them as autonomous actors outside it has already misread the assignment.

This is also where the cost of waiting shows up. Retrofitting identity, policy, and logging onto agents that are already in production means reconstructing history that was never captured. Building the controls into the data layer first means every agent interaction is governed from its first request. AI data governance done early is cheaper than forensic reconstruction done late.

Split Accountability Needs One Evidence Chain

If accountability is split, the evidence chain must be single. That is the design principle that resolves the vacuum without waiting for the org chart to settle.

Start with the authorizer. Every agent workflow should trace to a named person who delegated it, in the same way a human user’s access traces to their account. Where the identity of the agent is linked to the identity of the delegating human, the question of who answers has a factual answer regardless of which executive title ends up owning AI risk.

Next comes policy. Role-based rules decide what a person in a job may see, but an agent acts across tasks, and a role-only model grants too much or too little. Attribute-based access control evaluates the agent’s profile, the sensitivity of the data, the context of the request, and the operation requested. An agent allowed to read a folder is not automatically allowed to download it.

Then comes the record. A tamper-evident audit trail that captures who authorized the agent, what data it touched, under which policy, and when turns an incident from an investigation into a report. The difference matters in practice. Regulators run on days, and an evidence package that takes weeks to assemble is a finding waiting to happen.

Kiteworks Compliant AI governs agent access at the data layer along exactly those lines. It verifies agent identity and links it to the human authorizer, evaluates each request against attribute-based policy, applies FIPS 140-3 validated encryption, and writes tamper-evident audit records. The Kiteworks Secure MCP Server brings the same model to AI clients such as Claude and Copilot, where each request inherits the user’s existing permissions through OAuth 2.0 and is logged in the same audit trail that covers email, file sharing, and managed file transfer. One audit trail across channels is the point. Five tools produce five audit gaps.

The Vendor Blind Spot Is the Audit Blind Spot

The accountability problem does not stop at the corporate boundary. The IBM survey found that 54 percent of executives acknowledge gaps in governance coverage for AI used by key vendors and supply-chain partners.

The controls organizations reach for tell the story. Contractual provisions lead at 43 percent and audit rights follow at 39 percent, while continuous monitoring of third-party AI risk sits at 21 percent and independent assurance or certification at 13 percent. Paper controls dominate and observed controls trail far behind.

A clause is a promise. A log is a fact. When a partner’s agent touches your regulated data, the contract says what should have happened and only your own records say what did. That asymmetry is the vendor blind spot, and it becomes an audit blind spot the first time an examiner asks for the access history of data that left your environment.

For European organizations the exposure is codified. The NIS 2 Directive requires covered entities to manage supply chain security as part of their cybersecurity risk-management measures, and its management-body provisions put responsibility for approving and overseeing those measures on leadership. The practical reading is that third-party risk management must produce evidence of what partners and their agents did with your data, not just a signed questionnaire. A mature vendor risk management program asks for access logs and policy decisions, then verifies they exist before a regulator does.

The gap also has a cost that rarely shows up in a risk register. When a vendor’s agent touches your data and the log lives only in the vendor’s system, your ability to answer a regulator depends on how quickly the vendor responds, and on whether the vendor’s retention period matches yours. Neither is something a clause can guarantee at the speed a 72-hour clock demands.

The AI Act Moved, but the Data Obligations Did Not

Some executives will read the news about the EU AI Act timeline as relief. The AI Omnibus, as summarized by the Future of Privacy Forum, moved the application date for the Act’s Annex III high-risk requirements from August 2, 2026 to December 2, 2027, and for Annex I systems from August 2, 2027 to August 2, 2028. Parliament adopted the text on June 16, 2026, the Council on June 29, 2026, and it was published in the Official Journal on July 24, 2026.

Treat that as a schedule change for one regulation, not a pause on governance. IBM found that 41 percent of EU executives in its sample are accelerating governance investment ahead of the high-risk obligations, which suggests many have read the delay correctly. They are using the extra time to build, not to wait.

The reason is simple. Regulators regulate data, not models. The GDPR applies to personal data whether a person or a software agent processes it, and its security-of-processing duty under Article 32 and its 72-hour breach notification duty under Article 33 do not depend on the AI Act’s calendar. NIS 2 adds its own reporting clock, with an early warning within 24 hours and a fuller notification within 72 hours of a significant incident. None of those obligations contains an exemption for agents.

So the practical question for a Chief Compliance Officer or a Data Protection Officer is unchanged. If an agent reads personal data at two in the morning and something goes wrong, can the organization show who authorized the access, what the agent saw, and what policy allowed it, inside a regulator’s timeline? A DPO who cannot answer that question is exposed on the GDPR today, regardless of what the AI Act says about 2027.

What a CISO and CCO Can Do Before the Next Board Meeting

Stop asking which executive should own AI. Start asking whether each agent workflow has an owner, a policy, and a log. Those are three things you can verify this month, and they hold up no matter how the executive question resolves.

First, assign a named human authorizer to every agent workflow that touches regulated data, and record that assignment where the identity system and the audit trail can both see it. A board committee owning “AI risk” does not substitute for a person owning “this agent’s access.” When the IBM respondents split eight ways on accountability, the missing piece was usually this one.

Second, run an evidence drill. Pick one agent workflow and ask the team to produce, within hours, the full access record for a sample of its actions, including who authorized the agent, which data it touched, and which policy permitted it. If the answer takes weeks, you have measured your evidence gap, and you have a number to bring to the board that the board will understand.

Third, formalize incident escalation. The 37 percent of incidents that reached leaders informally should reach them through a documented review that records what was decided and when. A written record of leadership’s response is itself evidence, and it is cheap.

Fourth, move vendor AI from contract language to observed controls. Ask partners for logs and policy decisions for any agent that touches your data, and write the right to receive them into the agreement. Continuous monitoring at 21 percent is the number to beat.

Fifth, enforce data minimization at the operation level. An agent that receives only the data its task requires produces a smaller incident when something fails and a simpler story when a supervisory authority asks.

IBM’s own framing is worth keeping on the wall. In the release, Ana Paula Assis, IBM’s chair for EMEA and APAC, said that governance “can no longer be treated as a compliance exercise.” The corollary for the people who sign the audit response is plain. Governance that cannot produce evidence on demand is still a compliance exercise, no matter how it is labeled.

To learn more about producing evidence-quality records of AI agent access to regulated data, schedule a custom demo today.

Additional Resources

• Blog Post
  Zero‑Trust Strategies for Affordable AI Privacy Protection
• Blog Post
  How 77% of Organizations Are Failing at AI Data Security
• eBook
  AI Governance Gap: Why 91% of Small Companies Are Playing Russian Roulette with Data Security in 2025
• Blog Post
  There’s No “–dangerously-skip-permissions” for Your Data
• Blog Post
  Regulators Are Done Asking Whether You Have an AI Policy. They Want Proof It Works.