Waarom projecten met agentische AI worden geannuleerd en wat een pilot van acht weken goed aanpakt

Een klant vraagt om terugbetaling en de agent vindt de bestelling in het CRM, controleert het retourbeleid en stelt binnen een minuut een antwoord op. Vervolgens loopt de agent vast, omdat de terugbetaling moet worden goedgekeurd in een financieel systeem waarmee de agent nooit is verbonden en het adres van de klant in twee databases niet overeenkomt. Dit soort tekortkomingen komt in een demo zelden aan het licht, maar bepaalt wel hoeveel het kost om een agent te gebruiken en of iemand hem kan vertrouwen. Het grotere risico van agentische AI zit dus in het bedrijf waarin de agent wordt ingezet, niet in het model.

Gartner verwacht dat tegen eind 2027 meer dan 40% van de projecten met agentische AI wordt geannuleerd. De organisatie wijst daarbij op stijgende kosten, onduidelijke bedrijfswaarde en gebrekkige risicobeheersing. Wie de voorspelling goed leest, ziet dat het gaat om de manier waarop deze projecten worden goedgekeurd op basis van een demo, zonder goed zicht op wat het werk nu kost of wie verantwoordelijk is voor het resultaat.

De vraag die ik elk leidinggevend team zou voorleggen, is of het bedrijf deze agent dagelijks het werk kan laten doen tegen kosten en met een risiconiveau waarmee het kan leven. Om die vraag te beantwoorden, moet je goed kijken naar wat ik het werk na automatisering noem: alles wat mensen nog moeten doen nadat de agent zijn deel heeft afgerond. Een pilot van acht weken is een praktische manier om dat te meten voordat je besluit tot een volledige uitrol.

De problemen die een agent van het bedrijf meekrijgt

Een agent werkt zelden op zichzelf: zelfs een taak die eenvoudig lijkt, raakt klantgegevens, een paar bedrijfsapplicaties en meestal ook een goedkeuringsstap. Elke koppeling beperkt wat de agent kan zien en doen. Als gegevens niet overeenkomen of niemand precies weet wie goedkeuring moet geven, neemt de agent die onduidelijkheid mee in de taak.

Routinegevallen zijn zelden het probleem; dat zijn de uitzonderingen, want daar lopen de operationele kosten op. En juist die gevallen worden in een demo vermeden. Uit onderzoek van Deloitte uit 2026 blijkt dat slechts 5% van de organisaties de eigen bedrijfsprocessen zeer goed voorbereid vindt op AI-agenten. Dat cijfer zegt meer dan welke benchmark voor modellen ook, omdat het erop wijst dat de AI al klaar is lang voordat de meeste processen dat zijn.

In de businesscase moet ook het werk na automatisering meetellen

Meten hoe snel een agent een resultaat oplevert, is de eenvoudigste manier om de waarde ervan te overschatten. Het belangrijkste cijfer is namelijk hoeveel inspanning de voltooide taak kost. Stel dat een medewerker 20 minuten nodig heeft om een verzoek af te handelen en de agent de eerste versie in twee minuten maakt. Dat lijkt 18 minuten tijdwinst op te leveren, totdat iemand 15 minuten besteedt aan het controleren van het resultaat en het corrigeren van fouten. Drie minuten tijdwinst levert weinig op zodra je de gebruikskosten van de agent aan de andere kant van de balans zet.

Uit de analyse van McKinsey van een virtuele klantenservicemedewerker voor een bank blijkt op grotere schaal hetzelfde patroon: tokens waren goed voor 20–25% van de variabele operationele kosten en menselijk toezicht voor 70–75%. Het grootste deel van de kosten lag dus buiten het model. Zonder een nulmeting voordat iemand code schrijft, kan een pilot veel technische vooruitgang laten zien en toch de investeringscase onbeproefd laten. De verantwoordelijke binnen het bedrijf moet op zijn minst een duidelijk antwoord hebben op elk van deze punten:

• Volume: hoe vaak het proces wordt uitgevoerd en hoeveel mensen eraan werken.
• Doorlooptijd: hoelang de hele taak duurt, inclusief controles en correcties.
• Nauwkeurigheid: hoe vaak er iets misgaat of werk opnieuw moet worden gedaan.
• Kosten per taak: wat het uitvoeren van een taak die vandaag succesvol wordt afgerond, kost.
• Bedrijfsimpact: wat een daadwerkelijke verbetering zou veranderen voor klanten, medewerkers of het bedrijf.

Een agent moet zijn plek in het werkproces verdienen

De invoering van nieuwe technologie wordt meestal onder verandermanagement geschaard, maar naar mijn ervaring wordt die veel eerder bepaald, namelijk door de plek van de agent in het werkproces. Een wereldwijd opererend adviesbureau had agenten ontwikkeld voor ondersteunend werk en compliance. De ondersteuningsagent kon informatie uit verschillende interne systemen ophalen, maar medewerkers moesten een aparte applicatie openen om hem te gebruiken en deden dat meestal niet. Toen hetzelfde werkproces naar het bestaande ondersteuningsplatform werd verplaatst, verscheen de agent in het ticket waaraan medewerkers al werkten. Ook een agent voor compliancescreening werd op die manier ingezet: deze werd ingebouwd in Salesforce en draaide telkens wanneer er een dossier werd aangemaakt.

Aan de agenten zelf veranderde niets; alleen hun plek in het werkproces veranderde. Medewerkers hadden al een reden om een ticket te openen of een dossier aan te maken, dus door op dat moment beschikbaar te zijn, werd er niets extra’s van hen gevraagd. De plaatsing is daarom zowel een architectuurbeslissing als een keuze die de invoering beïnvloedt. De agent heeft context nodig op de plek waar het werk wordt gedaan en de uitvoer moet naar de volgende stap kunnen doorstromen, zonder dat iemand die handmatig hoeft over te zetten.

Autonomie verandert de veiligheidsafweging

Een agent die alleen informatie kan lezen, brengt één soort risico met zich mee; een agent die gegevens kan wijzigen of klanten kan e-mailen, brengt een heel ander risico met zich mee. De beveiligingsmaatregelen moeten daarom aansluiten op wat de agent daadwerkelijk mag doen. Overmatige machtigingen en het lekken van gevoelige gegevens zijn bekende risico’s, maar promptinjectie verdient de meeste aandacht: instructies die verborgen zitten in een document of e-mail dat de agent tijdens de uitvoering van een volkomen legitieme taak oppikt.

De richtlijnen van Gartner van mei 2026 voor governance van agenten verdelen autonomie in vier niveaus. Dat biedt een praktische manier om te bepalen hoe strikt de beheersmaatregelen moeten zijn:

1. Observeren: de agent haalt informatie op en signaleert patronen, met alleen-lezen toegang.
2. Adviseren: de agent doet een aanbeveling, waarna een medewerker de beslissing neemt.
3. Handelen na goedkeuring: de agent bereidt een actie voor of start die, maar een persoon moet toestemming geven voordat de actie wordt uitgevoerd.
4. Autonoom handelen: de agent voert goedgekeurde acties zelfstandig uit binnen vastgestelde grenzen, met monitoring en escalatie bij uitzonderingen.

Op elk niveau heeft een agent een eigen identiteit nodig, toegangsrechten die beperkt zijn tot zijn taak en een registratie van elke actie die hij uitvoert. Organisaties hebben ook regels nodig voor de omgang met en bewaring van gegevens, duidelijkheid over welke gegevens bij externe modelaanbieders terechtkomen, en iemand die bevoegd is de agent stil te leggen en zijn toegang in te trekken zodra er iets niet in de haak lijkt.

Al deze beheersmaatregelen brengen doorlopende kosten met zich mee: ruimere toegangsrechten, extra monitoring en frequente goedkeuringen tellen na verloop van tijd allemaal op. Het juiste autonomieniveau is daarom niet alleen een beveiligingskwestie, maar ook een economische afweging. Het ligt op het punt waar de agent een waardevol resultaat oplevert tegen een risico dat het bedrijf aanvaardbaar vindt.

Kies een proces dat de inzet van een agent rechtvaardigt

Veel teams beginnen bij de technologie en zoeken daar vervolgens een probleem bij. Een beter vertrekpunt is een proces waarvan de kosten of vertragingen al duidelijk zijn voor de mensen die het uitvoeren.

Een wereldwijd bedrijf dat experts aan klanten koppelt en waarmee we hebben samengewerkt, paste precies in dat beeld: het team koppelde aanvragen voor enquêtes aan experts aan de hand van drie systemen die niet met elkaar communiceerden. Voor elke match controleerden medewerkers handmatig de profielen, eerdere deelname en naleving van de regels. We bouwden een agent die semantisch zoeken combineerde met die deelnamegeschiedenis en de nalevingsregels. In productie daalde het aantal meldingen over onjuiste matches met 80%, steeg de nauwkeurigheid van de koppelingen met 40% en kreeg het team 22% van zijn capaciteit terug.

Het project slaagde omdat het probleem duidelijk afgebakend was: informatie stond verspreid, gegevens moesten handmatig worden samengevoegd en de kwaliteit van de matches kon voor en na de invoering worden gemeten. Die duidelijkheid helpt ook bepalen of een proces überhaupt een agent nodig heeft. Werk dat door vaste regels wordt gestuurd, is meestal goedkoper uit te voeren met traditionele automatisering. Voor werk dat vooral bestaat uit informatie vinden en samenvatten, volstaat vaak een AI-assistent. De extra kosten en risico’s van agenten zijn het waard wanneer het werk vraagt om context te lezen, een keuze te maken uit toegestane acties en meerdere stappen aan elkaar te koppelen om een resultaat te bereiken.

Een pilot van acht weken met duidelijke beslismomenten

De hele pilot draait om één commerciële vraag: kan deze agent het proces voldoende verbeteren om inzet op grote schaal te rechtvaardigen? Acht weken bieden genoeg ruimte om de zakelijke rechtvaardiging, de technologie en het vermogen van de organisatie om te beheren wat ze bouwt, te toetsen.

Week 1–2: bepaal wat beter moet

Leg eerst vast hoe het proces nu verloopt: van het volume en de doorlooptijd tot het foutpercentage, herstelwerk en de kosten. Noteer welke systemen erbij betrokken zijn, wie verantwoordelijk is voor elke fase en voor welke uitzonderingen menselijke tussenkomst nodig is. Laat de proceseigenaar en het technische team vervolgens overeenstemming bereiken over het ene resultaat dat de agent moet verbeteren. Beslismoment: ga verder zodra het probleem, de uitgangssituatie, de verantwoordelijke en de succescriteria duidelijk zijn.

Week 3: bepaal de grenzen van de agent

In deze fase worden de grenzen van de agent vastgesteld, waaronder zijn identiteit, toegangsrechten, gegevenstoegang, goedgekeurde tools en mate van autonomie. Test de agent op promptinjectie, ongeoorloofde toegang, blootstelling van gevoelige gegevens en misbruik van tools. Richt ook logging en incidentrespons in, plus een manier om de agent op te schorten of zijn toegang in te trekken. Beslismoment: ga verder zodra de beheersmaatregelen en interventiestappen daadwerkelijk zijn getest en iedereen weet wat de agent wel en niet mag doen.

Week 4–6: test de omstandigheden waaronder de demo misgaat

Laat de agent nu realistisch werk uitvoeren, met onvolledige dossiers, tegenstrijdige informatie, ongebruikelijke verzoeken en af en toe een systeemstoring. Houd bij hoeveel taken hij voltooit, hoe nauwkeurig hij is en hoeveel correctiewerk mensen moeten doen. Bereken vervolgens wat een succesvol voltooide taak werkelijk kost wanneer ook het modelgebruik, de integraties, monitoring en controle worden meegerekend. Beslismoment: ga over op tests in de praktijk zodra de agent de afgesproken drempelwaarden haalt en het team zowel de gebruikskosten als de manieren waarop de agent fouten maakt begrijpt.

Week 7–8: stel de agent beschikbaar aan echte gebruikers

Stel de agent beschikbaar aan een kleine groep medewerkers voor een afgebakend deel van het echte werk, en houd het oude proces beschikbaar voor alles wat de agent niet aankan. Let erop of mensen de agent daadwerkelijk gebruiken, of hij hun werk verlicht en of ze vertrouwen hebben in de resultaten.

Vergelijk aan het einde de resultaten met de uitgangssituatie uit week één en kijk naar productiviteit, nauwkeurigheid, gebruik, hoe vaak mensen moesten ingrijpen, de totale bedrijfskosten en eventuele resterende beveiligingsrisico’s. Beslis vervolgens of je de inzet opschaalt, specifieke tekortkomingen verhelpt en opnieuw test, of ermee stopt. Ook als een pilot aantoont dat de agent te duur of te onbetrouwbaar is voor de taak, heeft hij zijn nut bewezen: zo voorkom je een veel grotere investering die op giswerk is gebaseerd.

Meet de resultaten en bepaal vervolgens hoeveel autonomie je geeft

Tellen hoeveel taken een agent verwerkt, zegt weinig: een systeem kan duizenden verzoeken afhandelen en medewerkers toch het merendeel ervan laten controleren, corrigeren of afronden. De kosten per succesvol afgeronde taak, bekeken in samenhang met de nauwkeurigheid en het aantal uitzonderingen, geven een veel beter beeld van de vraag of het proces van begin tot eind is verbeterd.

Diezelfde meetgegevens vormen de basis om een agent meer ruimte te geven. Een agent die routineverzoeken binnen de afgesproken grenzen betrouwbaar afhandelt, kan zelfstandig op die verzoeken handelen. Bij een agent die steeds met onduidelijke gevallen te maken krijgt, blijft een medewerker die beslissingen goedkeuren; naarmate er meer bewijs beschikbaar komt, worden de machtigingen opnieuw beoordeeld.

Schaal op wanneer de organisatie de agent kan ondersteunen

Een agent die goed werkt voor één team, zal vroeg of laat ook met andere afdelingen, applicaties en goedkeuringsprocessen te maken krijgen. Om op te schalen zijn duidelijk eigenaarschap, consistente toegangscontroles en een manier om uitzonderingen af te handelen nodig, evenals een budget om de agent actueel te houden wanneer de processen eromheen veranderen.

De onderliggende vraag is hoeveel verantwoordelijkheid de organisatie bereid is over te dragen. Dat besluit moet zijn gebaseerd op bewijs uit het dagelijkse werk, niet op een geslaagde demonstratie. Na acht weken moet de leiding weten wat de agent aankan, wanneer mensen nog moeten ingrijpen en wat het kost om de agent te laten werken. De bedrijven die met agentische AI een voorsprong nemen, zijn de bedrijven die vanaf de eerste week rekening houden met het werk dat na automatisering overblijft en middelen toewijzen aan agents voor de taken die ze daadwerkelijk voltooien.