Why IT Decision-Makers Distrust AI Agents (2026): And How to Solve It
By Mike van BeaumondAI Engineer · company brain & automationpublished on
8 min read
Direct answer: IT decision-makers' distrust of AI agents is rational, not exaggerated. The problem is almost never the model itself. The problem is the lack of structure around how the model is deployed, and there is something concrete you can do about it.
Reality check: if you, as a CTO or IT director, are hesitant to roll out Claude Code widely within your development team, you're not alone. Research by Salesforce and Deloitte among over a thousand IT decision-makers shows that 86 percent believe AI agents cause more problems than they solve.
This number is often interpreted as a reason to wait. That's the wrong conclusion. The distrust isn't paranoia; it's based on real patterns that are now well-documented.
The question isn’t whether the risk exists. The question is what differentiates an organization that suffers from it from one that prevents it.
What figures support this distrust?
Before you dismiss this article as doom-mongering: here are the figures on which the distrust is based, not as a reason to stop, but to understand where the real risks lie.
86% of IT decision-makers within enterprise organizations believe that AI agents cause more problems than they solve. These same organizations already use an average of 12 AI agents and expect this number to rise to 20 by 2027, often without central oversight.
Source: Salesforce and Deloitte, survey of 1,050 IT decision-makers.
45% of AI-generated code contains an OWASP Top 10 vulnerability, the most widely used industry standard for application security. For Java code, that percentage is above 70 percent.
Source: Veracode, benchmark across 100+ language models and 80 tasks.
46% of developers say they actively distrust the output of AI tools, an increase from 31 percent a year earlier. Only 33 percent trust the output.
Source: Stack Overflow Developer Survey 2025.
19% slower was recorded for experienced developers using AI tooling in a controlled study, while they had predicted a 24 percent speed gain beforehand. The perception of acceleration and the reality diverged.
Source: METR, randomized study among experienced developers, July 2025.
Quick Take: These figures are not an argument against Claude Code. They are an argument against deploying AI coding without structure, which is a different decision.
What actually goes wrong (and what doesn't)?
Two recent incidents illustrate where the risk truly lies. A vulnerability called CamoLeak, with a severity score of 9.6 out of 10, made it possible to quietly extract secrets and source code from private GitHub repositories via Copilot Chat.
In a large organization, an AI-coding mandate caused two production incidents, including a thirteen-hour outage in a critical system. What these incidents have in common is not a weak language model.
It's the absence of the control layer that normally reviews new code before it hits production. Even Anthropic itself acknowledged in an April 2026 post-mortem that a regression slipped past multiple human and automated reviews.
That's not an endorsement of negligence; it's proof that this is a serious, solvable process problem and no reason to avoid AI coding. How to concretely set up this process for reviews can be found in the checklist for code review on AI-generated code.
Why doesn't 'banning AI agents' work?
An obvious reaction to these figures is caution: waiting until it's more mature, or banning it until clear frameworks are in place. Research into this reaction shows that this rarely works.
- An outright ban is counterproductive. Developers will then use AI tools without authorization, with no visibility for management. You lose precisely the control you thought you were gaining.
- 83 percent of organizations already use AI agents in almost every team. It's no longer a future question of whether you'll implement this. The question is whether it happensControlled or organically and unstructured.
- Competitors who implement it well gain an advantage. Industry research points to a growing gap between organizations with a clear framework for AI agents and organizations experimenting without structure.
Quick Take: Not choosing is also a choice. Without a framework, you get adoption without direction, and that precise pattern is behind the 86 percent figure.
What specifically changes with a structured approach?
The difference between an organization falling into the 86 percent problem group and an organization deriving value from it lies in four concrete elements. Below, for each element, is the situation without structure, and what a training changes about it.
Everyone experiments individually, nobody knows who authorized what or why. With structure: one agreed-upon working method per team, documented in a shared CLAUDE.md, with explicit boundaries for what is and isn't allowed autonomously.
AI-generated code receives the same or less review than human code, because the tests 'have already been checked anyway'. With structure: a pre-agreed risk classification per task, with a stricter review standard for security-sensitive code than for internal tooling.
Management only hears about problems after they have already occurred in production. With structure: a fixed evaluation moment after a delimited pilot period, with measurable criteria for speed and quality, instead of adoption without a benchmark.
Every developer decides for themselves which tasks are delegated to Claude Code. With structure: a team agreement on which types of tasks are suitable for delegation and which are always done by a developer.
Quick Take: A training doesn't change the technology. It changes the structure around it, and that's precisely where the difference lies between the 86 percent who see risk and the organizations that derive value from it.
What doesn't a training remove?
Honesty is also part of this. A training is not a miracle cure, and it's good to be clear in advance about what it does and doesn't do.
- Bringing risk to zero is unrealistic. No structure completely eliminates every risk. The goal is to make risk manageable, not impossible.
- A training is not a substitute for security expertise. For organizations with strict compliance requirements, a separate security review of the AI-coding workflow is still recommended in addition to the training.
- Developers' distrust won't disappear in one day. Trust is built through consistent, predictable results, not through a single session.
Want to know where things usually go wrong in the implementation itself?
My take
The 86 percent who see AI agents as a risk are right about the problem and wrong about the conclusion. The problem is real. The conclusion that you should therefore wait is not.
Organizations that establish a structured approach now will be ahead of those still hesitating. Want to know where your team stands today? Schedule a call about Claude Code for your development team.
Sources: Salesforce and Deloitte (IT decision-maker survey), Veracode benchmark, Stack Overflow Developer Survey 2025, METR research July 2025.
Sound familiar? Let's talk.
In 30 minutes we look together at which team your brain starts with. No obligation.
Frequently asked questions
Yes, in part. The underlying figures on vulnerabilities and quality issues in AI-generated code are real and well-documented. Distrust is a fair reaction to a process problem, not to the technology itself.
No. A training establishes the structure, agreements, and working methods that make the risk manageable. For organizations with strict compliance requirements, an additional security audit of the workflow remains wise.
No. Waiting does not reduce the risk. 83 percent of organizations already use AI agents widely, often unstructured. A controlled, small-scale implementation now is less risky than an organic, unstructured implementation that is already happening.
Start with a clearly defined pilot with one team and one specific task, pre-determine who reviews the output, and schedule an evaluation after a fixed period. That's precisely the setup we provide for your team.