Eight in ten executives at large European and Gulf organisations say an AI-related incident reached their board or senior leadership in the past year. That is the headline of a survey IBM published on 15 October. The more useful numbers are further down.
Who ran it and who paid
IBM commissioned the research and the polling firm Censuswide carried it out. IBM sells AI products and services, so it has an interest in the subject. That does not make the figures wrong. It means they should be read as one company’s evidence, not as neutral measurement.
The sample was 3,221 executives, including C-level, at organisations with 1,000 or more employees. They were in the UK, France, Germany, Italy, Spain, the Netherlands, Saudi Arabia and the UAE. Fieldwork ran from 14 to 24 September 2026.
Those details set the limits. The survey says nothing about small businesses and nothing about Asia. It covers large organisations in eight countries.
What counts as an incident
The release gives examples rather than a definition: an agent failure, a data exposure, an AI-driven decision error or an AI security breach. It does not say how serious an event had to be, or how an executive decided that one had “reached” the board.
That matters for how to read 80%. A single awkward email chain to a director could count. So could a serious breach. The number tells you that AI problems now travel upward, not how bad they were.
Two numbers worth more than the headline
Among organisations where an incident reached the top, 40% said they changed their AI governance policy or framework in response. Put the other way, a majority did not. An event serious enough to be escalated did not, for most, lead to new rules.
The second comes from firms that wanted to deploy AI faster than their governance allowed. Of those, 56% pressed ahead within agreed risk limits. A third (33%) delayed until governance was ready.
Neither figure is a verdict. Pressing ahead within limits may be sensible, and waiting may be cautious or merely slow. The survey does not say which group did better.
What IBM’s executive said
Ana Paula Assis, who chairs IBM’s business in Europe, the Middle East, Africa and Asia-Pacific, framed the finding as a shift. She said the debate has moved from adoption to governance and accountability, and that governance needs “clear ownership when things go wrong”.
That second phrase is the practical one. It describes a person, not a policy document.
Why a manager outside a large company should care
You may work in a team of twelve, not a corporation of twelve thousand. The survey does not describe your firm. It describes where the pressure is heading.
Large organisations are the customers, suppliers and regulators of smaller ones. If their boards are now asking who owns each AI use and who is told when it fails, they will ask the same of the businesses they buy from. Expect it in tender forms, supplier questionnaires and contract clauses.
More directly, the pattern in the 40% is common at any size. Something goes wrong, people are annoyed, and nothing is written down. Six months later the same thing happens again.
What the survey leaves out
IBM’s release does not say how many of the 80% were minor and how many were serious. It does not say whether the 40% who changed policy were the firms with the worst incidents. It gives no margin of error, no breakdown by country for the headline figure, and no independent check.
Those gaps are normal for a press release. They are also reasons to treat the figures as a signal, not a measurement. The direction is credible. The exact size is not established.
A second caution concerns the word “agent”. The release links the findings to AI agents, meaning tools that take actions and not only answer questions. If your team uses AI only to draft and summarise, the risks are narrower. They are not absent, as the example below shows.
A small-team version of the same problem
Imagine a customer-facing team that uses an AI assistant to draft replies. One week a draft quotes the wrong refund period and a customer complains. The manager apologises, fixes that case and moves on.
Nobody records what happened. Nobody asks whether the same prompt will produce the same error for the next customer. Nobody is named as responsible for checking.
That is the small version of an incident that reaches the board and leads to no change. The cost is low the first time, and it rises with each repeat.
What to do this month
Decide what counts as an incident. Write one sentence defining it for your team. A wrong answer sent to a customer is one. A confidential file pasted into a public tool is one. Keep it short enough that people remember it.
Name who hears about it. Pick one person for the team to tell, and make telling them easy. The aim is that problems reach someone with authority, early, without a blame process.
Keep a one-page log. Date, what happened, what was done, and whether a rule changed. After a quarter, read it. If a pattern shows, you have your policy, written by experience.
Settle the speed question in advance. The 56% and 33% were deciding case by case. Agree in advance when your team goes ahead, and when it waits for a check. That is easier to do before the pressure arrives.
An incident reaching the top is no longer unusual. What a team does next is the part that varies, and it does not require a board to start.
Source: IBM press release of 15 October 2026 on research conducted by Censuswide on behalf of IBM, 3,221 executives at organisations of 1,000 or more employees in eight countries, fieldwork 14 to 24 September 2026. Figures are IBM’s.