Four large surveys published in 2026 asked enterprises about AI incidents. Their headline numbers differ, because each one counts a different kind of incident. Read together, they describe the same organisation: AI is in production, incidents are routine, and governance is running behind.
What each survey found
| Survey | Who was asked | Headline finding |
|---|---|---|
| OneTrust, Sep 2026 | 1,200 senior decision-makers in 8 countries | 86% had at least one AI-related incident in the past year |
| DigiCert, Jul 2026 | 1,001 IT and security leaders in the US, UK and Australia | 78% had AI incidents or found AI vulnerabilities |
| Spacelift, Jun 2026 | Infrastructure and platform teams | 93% had AI-caused infrastructure incidents; 19% had the governance foundations the report considers necessary |
| Proofpoint, 2026 | 1,400+ security professionals in 12 countries | About one-third fully prepared to investigate an AI incident that spans several systems |
The finding that matters most
OneTrust asked what organisations did after an incident. The most common response was more employee training (49%). The least common was pausing or slowing deployment (27%).
That is a rational choice for most businesses. Stopping AI work has a visible cost and an invisible benefit. But it means the controls have to work while the system keeps running. Training alone does not do that.
The same survey has two more numbers worth reading together:
- 87% encourage employees to use AI agents, but only 47% have clear governance, oversight and controls for them.
- 28% had two or more incidents where an AI system or agent took an action nobody approved.
Agents are where the gap gets expensive. A chatbot that gives a wrong answer is a quality problem. An agent that sends the email, moves the file or changes the record is an operational incident.
Shadow AI is a symptom of slow approvals
One-third of OneTrust respondents saw staff use unapproved AI because the approved tools or processes were not available quickly enough. In my experience this is the most fixable finding in the whole set.
When an approval takes six weeks, people route around it. When it takes two days for a low-risk use and a proper review for a high-risk one, most people use the front door. The fix is risk tiering at intake, so review effort follows risk.
Three controls that close most of the gap
1. A named owner who can pause the system
Every AI system in production needs one person with written authority to disable it, and a rollback path that has been tested. In NIST AI RMF terms this is GOVERN 2.1 and MANAGE 2.4. It is the cheapest control on this list and the one most often missing.
2. An action boundary for agents
List what each agent may do unattended, what needs human approval, and what it may never do. Log every action against that list. This maps to GOVERN 6.1 for third-party components and to the human oversight requirements in Article 14 of the EU AI Act.
3. An incident process that crosses tools
Proofpoint's finding that only about a third can investigate a cross-system AI incident points to a process gap more than a tooling gap. You need a severity scale with AI-specific examples, a response clock, an owner for each step, and a post-incident review that produces a corrective action. That is MANAGE 4.1 and 4.3.
A quick test: pick your highest-risk AI feature. Can you name the person who can turn it off, how long that takes, and who gets told if it misbehaves? If any answer is "not sure", start there.
How to read survey numbers like these
Vendor surveys are useful for direction and weak for precision. Each company defines "incident" in a way that fits what it sells, and samples lean toward organisations already engaged with the topic. I use them to see which problems are common, then confirm against what I find in an actual evidence review.