Waarom IT-beslissers AI-agents wantrouwen (2026): wat dat oplost
Door Mike van BeaumondAI Engineer · company brain & automatiseringgepubliceerd op
8 min leestijd
Direct antwoord: Het wantrouwen van IT-beslissers in AI-agents is rationeel, niet overdreven. Het probleem is vrijwel nooit het model. Het probleem is het ontbreken van structuur rond hoe het model wordt ingezet, en daar kun je concreet iets aan veranderen.
Reality check: als jij als CTO of IT-directeur twijfelt of je Claude Code breed moet uitrollen in je development team, sta je niet alleen. Onderzoek van Salesforce en Deloitte onder ruim duizend IT-beslissers laat zien dat 86 procent denkt dat AI-agents meer problemen veroorzaken dan ze oplossen.
Dat cijfer wordt vaak gelezen als reden om te wachten. Dat is de verkeerde conclusie. Het wantrouwen is niet paranoïde, het is gebaseerd op reële patronen die inmiddels goed gedocumenteerd zijn.
De vraag is niet of het risico bestaat. De vraag is wat het verschil maakt tussen een organisatie die er last van krijgt en een organisatie die het voorkomt.
Welke cijfers onderbouwen dit wantrouwen?
Voor je dit artikel afdoet als doemdenken: hier zijn de cijfers waarop het wantrouwen is gebaseerd, niet als reden om te stoppen maar om te begrijpen waar de echte risico's zitten.
86% van de IT-beslissers binnen enterprise-organisaties denkt dat AI-agents meer problemen veroorzaken dan ze oplossen. Dezelfde organisaties gebruiken gemiddeld al 12 AI-agents en verwachten dat dit aantal naar 20 stijgt in 2027, vaak zonder centrale regie.
Bron: Salesforce en Deloitte, onderzoek onder 1.050 IT-beslissers.
45% van AI-gegenereerde code bevat een kwetsbaarheid uit de OWASP Top 10, de meest gebruikte industriestandaard voor applicatiebeveiliging. Bij Java-code ligt dat percentage boven de 70 procent.
Bron: Veracode, benchmark over 100+ taalmodellen en 80 taken.
46% van de developers zegt de output van AI-tools actief te wantrouwen, een stijging vanuit 31 procent een jaar eerder. Slechts 33 procent vertrouwt de output wel.
Bron: Stack Overflow Developer Survey 2025.
19% trager werkten ervaren developers met AI-tooling in een gecontroleerde studie, terwijl ze zelf vooraf een snelheidswinst van 24 procent hadden voorspeld. De perceptie van versnelling en de werkelijkheid liepen uiteen.
Bron: METR, gerandomiseerd onderzoek onder ervaren developers, juli 2025.
Quick Take: Deze cijfers zijn geen argument tegen Claude Code. Ze zijn het argument tegen het zonder structuur inzetten van AI-coding, wat een ander besluit is.
Wat gaat er werkelijk mis (en wat niet)?
Twee recente incidenten illustreren waar het risico echt zit. Een kwetsbaarheid met de naam CamoLeak, met een ernstscore van 9,6 op 10, maakte het mogelijk om via Copilot Chat stilletjes geheimen en broncode te onttrekken uit private GitHub-repositories.
Bij een grote organisatie veroorzaakte een AI-coding-mandaat twee productie-incidenten, waaronder een uitval van dertien uur in een kritiek systeem. Wat deze incidenten gemeen hebben, is niet een zwak taalmodel.
Het is de afwezigheid van de controlelaag die normaal gesproken nieuwe code beoordeelt voordat hij productie raakt. Zelfs Anthropic zelf erkende in een postmortem van april 2026 dat een regressie voorbij meerdere menselijke en geautomatiseerde reviews glipte.
Dat is geen reclame voor nalatigheid, het is het bewijs dat dit een serieus, oplosbaar proces-probleem is en geen reden om AI-coding te vermijden. Hoe je dat proces concreet inricht voor reviews, lees je in de checklist voor code review op AI-gegenereerde code.
Waarom werkt 'AI-agents verbieden' niet?
Een voor de hand liggende reactie op deze cijfers is terughoudendheid: wachten tot het volwassener is, of het verbieden tot er duidelijke kaders zijn. Onderzoek naar deze reactie laat zien dat dit zelden werkt.
- Een algeheel verbod werkt averechts. Developers gebruiken AI-tools dan ongeautoriseerd, zonder enige zichtbaarheid voor het management. Je verliest dan precies de controle die je dacht te krijgen.
- 83 procent van de organisaties gebruikt AI-agents al in vrijwel elk team. Het is geen toekomstige vraag meer of je dit gaat inzetten. De vraag is of het gecontroleerd gebeurt of organisch en ongestructureerd.
- Concurrenten die het wel goed inrichten, trekken een voorsprong. Branche-onderzoek wijst op een groeiend verschil tussen organisaties met een duidelijk kader voor AI-agents en organisaties die experimenteren zonder structuur.
Quick Take: Niet kiezen is ook kiezen. Zonder kader krijg je adoptie zonder regie, en precies dat patroon zit achter het 86 procent-cijfer.
Wat verandert er concreet met een gestructureerde aanpak?
Het verschil tussen een organisatie die in de probleemgroep van 86 procent valt en een organisatie die er wel waarde uit haalt, zit in vier concrete elementen. Hieronder per element wat de situatie is zonder structuur, en wat een training daaraan verandert.
Iedereen experimenteert individueel, niemand weet wie wat heeft geautoriseerd of waarom. Met structuur: één afgesproken werkwijze per team, vastgelegd in een gedeelde CLAUDE.md, met expliciete grenzen voor wat wel en niet autonoom mag.
AI-gegenereerde code krijgt dezelfde of mindere review dan menselijke code, omdat de tests 'toch al zijn gecheckt'. Met structuur: een vooraf afgesproken risicoclassificatie per taak, met een zwaardere reviewstandaard voor security-gevoelige code dan voor interne tooling.
Het management hoort pas over problemen als ze zich al hebben voorgedaan in productie. Met structuur: een vast evaluatiemoment na een afgebakende pilotperiode, met meetbare criteria voor snelheid en kwaliteit, in plaats van adoptie zonder ijkpunt.
Elke developer beslist zelf welke taken aan Claude Code worden gedelegeerd. Met structuur: een teamafspraak over welk type taken geschikt zijn voor delegatie en welke altijd door een developer worden gedaan.
Quick Take: Een training verandert niet de techniek. Het verandert de structuur eromheen, en dat is precies waar het verschil zit tussen de 86 procent die risico ziet en de organisaties die er waarde uit halen.
Wat neemt een training niet weg?
Eerlijkheid hierbij hoort er ook bij. Een training is geen wondermiddel, en het is goed om vooraf scherp te hebben wat hij wel en niet doet.
- Risico naar nul brengen is niet realistisch. Geen enkele structuur elimineert elk risico volledig. Het doel is risico beheersbaar maken, niet onmogelijk.
- Een training is geen vervanging voor security-expertise. Voor organisaties met strenge compliance-eisen blijft een aparte security-review van de AI-coding-workflow aan te raden naast de training.
- Het wantrouwen van developers verdwijnt niet in één dag. Vertrouwen bouwt op door consistente, voorspelbare resultaten, niet door een eenmalige sessie.
Wil je weten waar het meestal misgaat in de invoering zelf?
Mijn take
De 86 procent die AI-agents als risico ziet, heeft gelijk over het probleem en ongelijk over de conclusie. Het probleem is reëel. De conclusie dat je daarom moet wachten, is dat niet.
De organisaties die nu een gestructureerde aanpak inrichten, lopen straks voor op de organisaties die nog twijfelen. Wil je weten waar jouw team nu staat? Plan een gesprek over Claude Code voor jouw development team.
Bronnen: Salesforce en Deloitte (IT-beslissersonderzoek), Veracode-benchmark, Stack Overflow Developer Survey 2025, METR-onderzoek juli 2025.
Herkenbaar? Laten we praten.
In 30 minuten kijken we samen met welke afdeling je brein begint. Vrijblijvend.
Veelgestelde vragen
Ja, voor een deel. De onderliggende cijfers over kwetsbaarheden en kwaliteitsproblemen in AI-gegenereerde code zijn reëel en goed gedocumenteerd. Het wantrouwen is een terechte reactie op een proces-probleem, niet op de technologie zelf.
Nee. Een training richt de structuur, de afspraken en de werkwijze in die het risico beheersbaar maken. Voor organisaties met strenge compliance-eisen blijft een aanvullende security-audit van de workflow verstandig.
Nee. Wachten verkleint het risico niet. 83 procent van de organisaties gebruikt AI-agents al breed, vaak ongestructureerd. Een gecontroleerde, kleinschalige invoering nu is minder risicovol dan een organische, ongestructureerde invoering die toch al plaatsvindt.
Begin met een afgebakende pilot met één team en één duidelijk gedefinieerde taak, leg vooraf vast wie de output reviewt en plan een evaluatie na een vaste periode. Dat is exact de opzet die we voor jouw team meegeven.