Een AI-agent krijgt op maandag de opdracht om een proces af te handelen. Op dinsdag werkt de leverancier zijn API bij. Op donderdag verandert een bronbestand van structuur. Op zaterdag verloopt een token. Op woensdag van de tweede week ontdekt iemand dat de agent al dagenlang keurig de verkeerde kant op werkt.
Dat is geen theoretisch probleem. Het is de logische consequentie van een systeem dat niet één antwoord genereert, maar zelfstandig acties uitvoert over een langere periode. Toch behandelen organisaties zo’n agent vaak als een geautomatiseerd script met een slimme interface. De proef is succesvol, de demo ziet er overtuigend uit en dus mag het ding productie in.
De hoofdstelling is ongemakkelijk eenvoudig: een AI-agent die veertien dagen blijft draaien, is geen eenmalige automatisering maar een langdurige beheerverantwoordelijkheid. De looptijd verandert de aard van het risico. Niet omdat veertien dagen een magische grens is, maar omdat iedere extra dag meer afhankelijkheden, meer context en meer mogelijkheden voor afwijkend gedrag introduceert.
Een agent stopt niet wanneer de demo klaar is
Een klassieke automatisering voert meestal een vooraf gedefinieerde handeling uit. De invoer is bekend, de stappen zijn grotendeels vastgelegd en de uitkomst valt binnen een beperkt aantal scenario’s. Dat maakt beheer niet vanzelf eenvoudig, maar wel overzichtelijker. Bij een agent verschuift het zwaartepunt. De agent interpreteert, kiest vervolgstappen, gebruikt hulpmiddelen en kan op basis van nieuwe informatie zijn koers aanpassen.
Daarmee ontstaat een systeem dat niet alleen een technische configuratie heeft, maar ook een lopende toestand. Welke opdracht is actief? Welke aannames heeft de agent uit eerdere acties afgeleid? Welke bestanden, berichten, API’s en accounts heeft hij gebruikt? Welke acties staan nog open? Wie heeft tussentijds de randvoorwaarden aangepast?
Een agent is dus niet alleen software die draait. Het is software die zich in een omgeving beweegt. En die omgeving blijft tijdens die veertien dagen gewoon veranderen. Mensen wijzigen toegangsrechten. Leveranciers passen interfaces aan. Data wordt verwijderd of gecorrigeerd. Bedrijfsregels veranderen. Een agent die gisteren verantwoord handelde, kan vandaag dezelfde opdracht uitvoeren met een andere betekenis.
Veertien dagen is geen runtime, maar levensduur
In veel organisaties wordt de looptijd gezien als een technische parameter. Een taak duurt twee minuten, een workflow drie uur en een agent veertien dagen. Alsof alleen de rekentijd toeneemt. In werkelijkheid neemt vooral de bestuurlijke levensduur toe.
Bij een kort proces kun je de invoer en uitvoer relatief gemakkelijk vergelijken. Bij een langdurige agent moet je ook de tussenliggende geschiedenis kunnen reconstrueren. Niet alleen wat het systeem heeft gedaan, maar waarom het op dat moment over die informatie beschikte, welke instructie gold, welke toestemming actief was en welke alternatieven het niet heeft gekozen.
Dat vraagt om versiebeheer van opdrachten, inzicht in gebruikte modellen en hulpmiddelen, registratie van wijzigingen en een reproduceerbare audit trail. Niet om een mooi dashboard met een groene status, maar om antwoorden op vragen die pas tijdens een incident relevant lijken. Wanneer is de afwijking begonnen? Welke gegevens waren toen beschikbaar? Wie had de bevoegdheid om het proces te stoppen? Welke andere systemen zijn beïnvloed?
Wie dat niet kan beantwoorden, beheert geen agent. Die kijkt ernaar en hoopt dat het goedgaat. Dat is geen operationeel model, maar uitgesteld ongemak.
De meeste risico’s zitten tussen twee acties in
De discussie over AI-agents blijft vaak hangen bij de vraag of de agent wel of niet mag schrijven naar een systeem. Dat is belangrijk, maar onvoldoende. Het echte risico ontstaat tussen twee acties in. Een agent kan eerst informatie ophalen, daarna een conclusie trekken, vervolgens een andere bron raadplegen en tenslotte een wijziging uitvoeren. Iedere stap beïnvloedt de volgende.
Een beperkte bevoegdheid per afzonderlijke actie kan daardoor alsnog leiden tot een ongewenste uitkomst. Een agent hoeft geen volledige beheerder te zijn om schade te veroorzaken. Een combinatie van lezen, interpreteren, doorgeven en uitvoeren kan al genoeg zijn. Daarom verschuift de relevante beveiligingsvraag van “welke toegang heeft de agent?” naar “welke keten van acties kan deze agent zelfstandig vormen?”
Dat sluit aan bij de logica van Zero Trust voor AI-agents, waarbij niet alleen de identiteit of sessie, maar iedere actie opnieuw ter discussie staat. Bij een agent met een levensduur van veertien dagen is dat geen theoretische verfijning. Tijd maakt tijdelijke toegang permanent genoeg om gevaarlijk te worden. Een token dat voor een eenmalige handeling bedoeld was, krijgt ineens een langdurige rol. Een uitzondering die maandag acceptabel leek, blijft tot ver na het oorspronkelijke doel actief.
Monitoring is niet hetzelfde als beheer
Veel organisaties beantwoorden dit probleem met monitoring. Ze meten CPU-gebruik, foutpercentages, API-latentie en het aantal uitgevoerde taken. Nuttig, maar onvoldoende. Een agent kan technisch gezond zijn en toch beleidsmatig ontsporen. Hij kan zonder fouten verouderde data verwerken, te veel berichten versturen of binnen de formele bevoegdheid een proces uitvoeren dat niemand meer bedoelde.
Beheer betekent daarom ook dat iemand actief kan ingrijpen. Er moet een eigenaar zijn die niet alleen verantwoordelijk is voor de technische beschikbaarheid, maar ook voor de opdracht, de toegestane handelingsruimte en de gevolgen van afwijkend gedrag. Die eigenaar moet de agent kunnen pauzeren, terugzetten naar een bekende toestand en gecontroleerd opnieuw laten starten.
Daar hoort een werkbare noodstop bij. Niet een knop die alleen de interface verbergt, maar een mechanisme dat lopende acties begrenst, nieuwe acties voorkomt en duidelijk maakt wat al is uitgevoerd. Ook moet duidelijk zijn wat er gebeurt met half afgeronde transacties. Een agent die midden in een proces wordt gestopt, laat mogelijk een organisatie achter met gedeeltelijk verwerkte gegevens en onduidelijke verplichtingen.
Wie alleen dashboards bouwt, automatiseert vooral het kijken. Dat is nog geen controle.
Eigenaarschap verdwijnt niet door autonomie
De verleiding is groot om de agent verantwoordelijk te maken voor zijn eigen beslissingen. Dat klinkt modern en is organisatorisch vooral gemakkelijk. De agent heeft immers de keuze gemaakt. De ontwikkelaar heeft alleen de techniek geleverd. De proceseigenaar had niet verwacht dat het systeem dit scenario zou tegenkomen. De leverancier beheert het model. Iedereen heeft een verklaring en niemand heeft verantwoordelijkheid.
Autonomie verandert de verdeling van werk, niet de verdeling van aansprakelijkheid of bestuurlijke verantwoordelijkheid. Voor iedere langdurige agent moet daarom vooraf duidelijk zijn wie de opdracht mag wijzigen, wie de toegangsrechten beheert, wie uitzonderingen beoordeelt en wie besluit dat de agent moet stoppen. Dat zijn verschillende rollen, ook als ze in een kleinere organisatie bij één persoon liggen.
Daarbij hoort een expliciete einddatum. Een agent die veertien dagen mag draaien, moet niet stilzwijgend blijven bestaan omdat niemand het stopmoment heeft ingebouwd. Verlenging moet een bewuste beslissing zijn, net als het opnieuw beoordelen van de gegevens, bevoegdheden en afhankelijkheden. Anders wordt tijdelijke automatisering een permanent proces met een vergeten eigenaar.
De kosten zitten niet alleen in tokens
De financiële discussie over agents gaat vaak over modelgebruik en infrastructuur. Dat zijn zichtbare kosten. De minder zichtbare kosten ontstaan door toezicht, herstel, controle en het reconstrueren van beslissingen. Hoe langer een agent draait, hoe meer context iemand moet kunnen begrijpen wanneer het misgaat. Die tijd hoort in de businesscase, ook als niemand hem graag begroot.
Een langdurige agent vereist bovendien operationele afspraken over wijzigingen in gekoppelde systemen. Als een leverancier een API verandert, een autorisatiebeleid aanscherpt of een datadefinitie aanpast, moet ergens worden vastgesteld of de agent nog veilig kan doorgaan. Dat raakt direct aan de bredere afhankelijkheden die organisaties vaak pas zien wanneer een leverancier of platform niet meer doet wat was aangenomen. De grootste cyberafhankelijkheid staat meestal niet in je risicoregister, juist omdat de afhankelijkheid zich niet als één component gedraagt, maar als een keten van aannames.
De juiste vraag is dus niet of een agent goedkoper is dan een medewerker. De juiste vraag is welke nieuwe beheertaak de organisatie zichzelf geeft. Soms is dat een goede keuze. Soms is een korter, eenvoudiger proces verstandiger, ook als het minder indrukwekkend klinkt.
Wat is dan de echte IT-realiteit?
Een AI-agent is geen medewerker zonder salaris, geen script met een betere tekstinterface en geen proces dat na de implementatie vanzelf beheersbaar blijft. Zodra hij zelfstandig meerdere dagen acties uitvoert, wordt hij onderdeel van de operationele werkelijkheid. Zijn toestand, bevoegdheden, afhankelijkheden en beslissingen moeten beheerd worden zolang hij actief is.
Dat betekent niet dat iedere agent voortdurend door een mens moet worden goedgekeurd. Wel betekent het dat menselijke verantwoordelijkheid niet mag verdwijnen achter het woord autonomie. De mate van toezicht kan verschillen per risico, maar eigenaarschap, begrenzing, logging, ingrijpen en beëindiging zijn geen luxe voor volwassen organisaties.
De fout is niet dat organisaties agents inzetten. De fout is dat ze de looptijd verwarren met gemak. Een agent die veertien dagen zelfstandig werkt, heeft geen langere demo nodig, maar veertien dagen beheer. En als niemand dat beheer wil organiseren, is de agent niet autonoom, maar onbeheerd.
Ontdek meer van IT realiteit
Abonneer je om de nieuwste berichten naar je e-mail te laten verzenden.
