Welke taken vertrouw je een AI-agent zelfstandig toe, en welke absoluut niet? Tot nu toe was dat vooral onderbuik. Nu is er voor het eerst een cijfer op geplakt. MIT Technology Review Insights ondervroeg samen met Microsoft 300 technische besluitvormers uit twaalf sectoren en vier wereldregio's, van startups tot bedrijven van boven de tien miljard dollar, en liet ze 101 concrete agent-taken scoren op een vertrouwensschaal van 0 tot 100. De uitkomst tekent een scherpe grens: een agent wordt vertrouwd waar zijn werk meetbaar en terug te draaien is, en gewantrouwd zodra hij een levend systeem in mag.
Het gemiddelde vertrouwen bleef steken op 64 van de 100, en van de 101 onderzochte taken haalden er maar 30 een score boven de 70. Dat is de eerste nuance die ertoe doet: ondanks alle demo's van "autonome" software zit het brede vertrouwen nog lang niet op automatische piloot. De tweede nuance is waar dat vertrouwen wel en niet zit, en die grens is verrassend consistent.
Code schrijven en rapporteren: daar mag de agent los
Bovenaan de lijst staan taken met een gemeenschappelijke noemer: de uitkomst is direct te controleren en een misser kost je hooguit een weggegooid concept. Automatische rapportgeneratie scoort met 84 het hoogst, gevolgd door het schrijven van boilerplate-code voor nieuwe features (82,5). Ook het bewaken van datakwaliteit (82), het monitoren van realtime datastromen (81) en het bijhouden van verlopende certificaten (81,5) staan hoog. Precies de klussen waar je als bedrijf meteen ziet of de agent het goed deed.
Dat is geen toeval, laat het onderzoek zien. Bij gegenereerde code kunnen teams simpelweg meten hoeveel ervan daadwerkelijk in de hoofdcodebase belandt; die ene merge-ratio vertelt of het werk de kwaliteitslat haalt. Vertrouwen ontstaat waar de feedback snel, meetbaar en goedkoop is.

Live infrastructuur: daar stopt het vertrouwen abrupt
Aan de onderkant staan de taken waar een fout geen concept is maar een onomkeerbaar feit. Het configureren en oplossen van een service mesh scoort met 37,5 het laagst, gevolgd door het testen van disaster recovery (43) en het plannen van databasemigraties (44,5). Dit zijn stuk voor stuk ingrepen in draaiende infrastructuur, waar de agent organisatiekennis mist en waar een verkeerde stap productie plat kan leggen.
| Meeste vertrouwen | Minste vertrouwen |
|---|---|
| Rapportgeneratie (84) | Service mesh-configuratie (37,5) |
| Boilerplate-code (82,5) | Disaster-recovery-tests (43) |
| Datakwaliteit bewaken (82) | Databasemigratie plannen (44,5) |
Het patroon is dus niet "eenvoudig versus moeilijk". Het is omkeerbaar versus onomkeerbaar, en meetbaar versus contextafhankelijk. Een agent die code voorstelt kun je laten reviewen; een agent die een schema-migratie draait op je productiedatabase geeft je geen tweede kans.
De grens is niet modelkracht, maar bedrijfscontext
De belangrijkste conclusie van de onderzoekers zit in het waarom. Het lagere vertrouwen bij de complexe taken komt niet door een tekort aan rauwe modelcapaciteit, maar door een gebrek aan bedrijfscontext dat aan de agent wordt meegegeven. Een model dat je codebase niet kent, je afhankelijkheden niet overziet en je uitzonderingen niet snapt, is niet te vertrouwen met een ingreep die precies die kennis vereist. Meer rekenkracht lost dat niet op.
Dat sluit naadloos aan op wat organisaties zelf als rem inbouwen. 59 procent van de respondenten houdt bewust een mens in de lus, en 53 procent zet in op meer observability en monitoring om grip te houden. Vertrouwen wordt met andere woorden per taak verdiend, niet in één keer verleend. "Als we agents ontwerpen om binnen dezelfde operationele grenzen, identiteitssystemen en governance-modellen te werken die teams al gebruiken, gaan ze zich gedragen als de systemen die organisaties al vertrouwen", zegt Jeremy Winter van Microsoft in de toelichting bij het onderzoek.
Die scheidslijn ken je terug uit de praktijk. Het is dezelfde vraag als waar je een agent in je ERP laat lezen en signaleren, en waar je hem laat boeken in het systeem van record: een verkeerd concept gooi je weg, een verkeerde btw-boeking is een feit in je administratie. Onderzoeksbureau Gartner verwacht niet voor niets dat ruim veertig procent van de agentic-AI-projecten voor eind 2027 sneuvelt, en de projecten die overleven zijn zelden die met het slimste model.
Wat dit betekent voor jouw bedrijf
Dit onderzoek is bruikbare munitie als je je eigen agent-beleid vastlegt, juist omdat het de grens niet op onderbuik maar op data zet. De les is niet "agents zijn nog niet zover", maar "trek de grens op omkeerbaarheid". Laat een agent autonoom lezen, signaleren, rapporteren en code voorstellen, want daar is de uitkomst controleerbaar en een fout goedkoop. Zet een menselijke goedkeuring op alles wat een live systeem verandert, hoe verleidelijk de demo ook is.
En dat leg je niet achteraf vast. Het zijn vijf governance-afspraken die je vastlegt voordat je agents de productie in stuurt: welke taken de agent zelf mag, vanaf welke drempel hij escaleert, hoe je elke actie logt, hoe je hem in één keer stilzet en wie de mens is die tekent voor de output. Wie dat vooraf regelt, kan de agent stap voor stap meer ruimte geven met bewijs in de hand, precies zoals je een nieuwe medewerker met tekenbevoegdheid ook niet op dag één een blanco volmacht geeft. Het onderzoek levert je nu het cijfermatige startpunt: begin bij de taken die boven de 70 scoren, en behandel alles onder die grens als iets wat een mens eerst goedkeurt. Vertrouwen in een agent is geen aanname die je vooraf doet, maar iets wat je per taak opbouwt.
Veelgestelde vragen
Waar laat jij je agents los?
Ik help je die grens concreet trekken: van meedenken over welke taken een agent zelf mag doen tot het bouwen, koppelen en automatiseren van een oplossing die veilig binnen je eigen systemen blijft, self-hosted waar dat kan.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
