Is RPA dood? De rol van klassieke automatisering naast AI-agents

Elke maandagochtend haalt iemand op de binnendienst een rapport uit uw ERP, kopieert de gegevens naar een spreadsheet en stuurt die door naar drie collega's. Dat is een RPA-taak. Zo is hij ook ooit ingericht: stap voor stap, veld voor veld, screenshot voor screenshot. De robot doet het al twee jaar, foutloos, elke maandag om 06:15. Tot vorige maand, toen het ERP een update kreeg en het scherm net iets anders opbouwde. Sindsdien doet de robot niets meer, en niemand weet precies waarom.

Dit is geen uitzonderlijke situatie. Het is hoe RPA-projecten in het MKB eindigen. Niet met een grote knal, maar met een stille crash die weken onopgemerkt blijft. De vraag is dan niet of RPA slecht is. De vraag is: waarvoor is het goed, en waar loopt het op zijn grenzen?

RPA doet precies wat u zegt, nooit meer en nooit minder

Robotic Process Automation is op zijn best een betrouwbare koerier. U beschrijft de route, stap voor stap, en de robot rijdt die route elke keer opnieuw. Dat is geen tekortkoming, dat is de definitie. RPA mist redeneerruimte. Als het scherm verandert, als een veld leeg is, als een uitzonderingsgeval zich aandient, stopt de robot of gaat hij op de verkeerde weg verder.

Voor processen die letterlijk identiek zijn bij elke uitvoering werkt dat prima. Denk aan het ophalen van een bestand, het invullen van een vast formulier met vaste velden, of het doorsturen van een melding op een vast tijdstip. Stabiel systeem, stabiel scherm, stabiele invoer. Dan is RPA goedkoop en effectief.

Zodra er variatie in zit, betaalt u de prijs. Klantmails zijn nooit identiek. Inkoopfacturen hebben tien verschillende opmaakvormen. Orderregels bevatten soms een opmerking, soms een bijlage, soms een afwijkende leverterm. Precies op die punten breekt klassieke RPA af, en begint het onderhoud dat mensen meer kost dan het bespaart.

Een AI-agent kan variatie aan, maar heeft andere voorwaarden

Een AI-agent werkt anders. Hij leest een inkoopfactuur ongeacht de lay-out, trekt de relevante velden eruit, vergelijkt ze met de inkooporder in uw ERP en legt het resultaat klaar voor uw medewerker. Klopt alles? Dan fiatteringsknop. Klopt er iets niet? Dan een signaal met de reden. Bij factuurverwerking automatiseren is dat precies de werkwijze: de agent doet het controlewerk, de mens beslist.

Maar een agent stelt wel andere eisen. Hij heeft context nodig: toegang tot de goede systemen, duidelijke regels over wat hij mag concluderen en wat hij moet escaleren, en een mens die de output goedkeurt voordat er iets verstuurd of geboekt wordt. Autonome acties zonder menselijke tussenkomst zijn geen onderdeel van hoe wij agents bouwen. Elke uitgaande actie gaat langs goedkeuring.

Wat betreft gegevensverwerking: opslag en verwerking vindt plaats in Frankfurt, taalmodelcalls lopen via Anthropic in de VS. Beide zijn opgenomen in de sub-verwerkerslijst met een transfer impact assessment. Dat is iets om te weten als u processen met persoonsgegevens wil automatiseren.

RPA en agents sluiten elkaar niet uit

De vraag "RPA of agent?" is in de praktijk zelden een óf-vraag. De meeste bedrijven die al RPA hebben draaien, kunnen die robots laten staan voor de taken waarvoor ze goed werken. Het is geen verplichting om alles opnieuw te bouwen. De vraag is eerder: wat doet de robot nu, en welk deel daarvan is kwetsbaar voor variatie of uitzonderingen?

Een handige scheiding in de praktijk: laat de robot doen wat pixel-perfect, herhaalbaar en stabiel is. Laat de agent doen wat redeneren, lezen of beslissen vereist. In een orderverwerkingsproces kan dat betekenen dat een agent de bestelmail uitleest en interpreteert, en dat een bestaande RPA-stap daarna de orderregel in het ERP aanmaakt. Die combinatie werkt. U hoeft niet te kiezen.

“De robot rijdt de vaste route. De agent bepaalt welke route het is.”

Waar RPA alsnog de voorkeur verdient

Er zijn situaties waarin een AI-agent meer is dan nodig. Als uw proces volledig vast ligt, nooit uitzonderingen kent en het systeem dat u gebruikt geen API heeft, is een scherm-gebaseerde RPA-robot soms de enige manier om te koppelen. Niet fraai, maar doelmatig. Een agent toevoegen aan zo'n proces voegt weinig toe en maakt het geheel complexer.

Kijk ook naar volume en frequentie. Processen die slechts één keer per maand plaatsvinden en altijd identiek verlopen, zijn niet de plek om een agent te introduceren. De bouwtijd weegt niet op tegen de winst. Zoals ik in het artikel over procesgeschiktheid schrijf: frequentie en regelmatigheid zijn de eerste twee filters voordat u überhaupt nadenkt over welke technologie u inzet.

Waar RPA structureel op vastloopt

De drie meest voorkomende situaties waarin RPA-projecten vastlopen, zijn systeemupdates, uitzonderingsgevallen en veranderende bedrijfsprocessen. Elke keer als het bronscherm of de bronstructuur verandert, moet iemand de robot opnieuw inrichten. Dat kost tijd, en bij veel MKB-bedrijven heeft niemand meer de kennis om dat zelf te doen.

Uitzonderingsgevallen zijn het tweede struikelblok. Een klant plaatst een order met een afwijkend afleveradres. Een leverancier stuurt een creditnota in plaats van een factuur. Een product heeft een andere btw-code dan verwacht. De robot herkent dit niet als een uitzondering en handelt of verkeerd of helemaal niet. Een medewerker ontdekt het pas als de klacht binnenkomt.

Het derde probleem is groei. Uw bedrijf verandert. Producten, klantgroepen, leveranciers, werkwijzen, alle processen bewegen mee. Een robot die is gebouwd op een proces van twee jaar geleden, past zelden nog precies op het proces van vandaag. Een agent kan meegroeien, mits u de regels bijhoudt. Die bijsturing is minder technisch en minder tijdrovend dan een RPA-robot opnieuw in te richten.

Hoe u de keuze maakt zonder technische achtergrond

U hoeft geen technisch specialist te zijn om de juiste keuze te maken. Stel uzelf drie vragen. Is het proces elke keer identiek, of zijn er variaties in de invoer? Is het systeem waarmee de robot werkt stabiel, of worden er regelmatig updates doorgevoerd? Heeft uw team de kennis en tijd om de robot bij te houden als er iets verandert?

Drie keer ja betekent dat RPA een prima keuze kan zijn. Bij één of meer keer nee loont het om te kijken of een agent beter past. De vergelijking tussen beide technologieën staat uitgewerkt op de pagina AI-agent versus RPA, als u dat vergelijk concreet wil zien.

Welk werk kost uw team elke week uren, terwijl het eigenlijk hetzelfde is als de week ervoor? En welk deel van dat werk bevat net genoeg variatie om een robot keer op keer te laten stranden? Dat onderscheid is de sleutel. Niet de technologiekeuze zelf.

Begin met het proces, niet met de tool

De fout die ik het vaakst zie: bedrijven kiezen eerst een technologie en zoeken daarna een toepassing. Dat werkt averechts. Begin bij het proces. Beschrijf wat er nu gebeurt, waar de uitzonderingen zitten, hoe vaak het voorkomt en wie er op dit moment op toeziet. Daarna volgt de keuze voor de tool vanzelf.

Als u wil weten of uw bedrijf klaar is voor een eerste stap, is de AI-readiness check een goed vertrekpunt. Die vragenlijst helpt u bepalen welke processen er rijp voor zijn en welke voorbereiding er nog nodig is.

De concrete eerste stap voor maandag: schrijf drie processen op die nu gedeeltelijk of volledig handmatig lopen. Noteer bij elk proces of de invoer altijd identiek is, of er uitzonderingen zijn en hoe vaak het mis gaat. Die drie beschrijvingen zijn het startpunt voor elke technologiekeuze, of het nu RPA, een agent of iets anders wordt.