De opkomst van agentische ontwikkeltools, die AI-agenten de voorbereiding van codewijzigingen toevertrouwen, stelt de vraag naar de controleerbaarheid van workflows. In gereguleerde sectoren is het niet langer voldoende te weten wie een wijziging heeft goedgekeurd: men moet de context, controles en beslissingen die eraan ten grondslag liggen kunnen reconstrueren.
Binnen een grote financiële instelling die een agent in haar ontwikkelworkflow gebruikt, stelde het interne audit- en compliance-team een specifieke vraag. Voor een merge request (een verzoek om code samen te voegen) die door een agent was geopend om een afhankelijkheid van een betalingsservice bij te werken, kon men aangeven wie deze had goedgekeurd, welke invoergegevens en prompts de agent had gebruikt, welke beleidscontroles waren geëvalueerd en hoe deze taak te reproduceren of ongedaan te maken? Het team had geen antwoord. Het leveringssysteem beschouwde het werk van de agent niet als een afgebakende en controleerbare transactie.
Een diff die door de CI (de continue integratie, die code automatisch test) is gevalideerd en goedgekeurd, bewijst dat een wijziging heeft plaatsgevonden. Het bewijst echter niet de context die door de agent is gebruikt, de beleidsbeslissingen die zijn geëvalueerd vóór het aanmaken van de merge request, noch de mogelijkheid om het resultaat bij een latere uitvoering te reproduceren. In gereguleerde omgevingen zijn het ‘hoe’ en ‘waarom’ echter essentieel. Deze situatie doet zich voor op alle platforms en in DevSecOps-organisaties: het budget voor agentische tools wordt binnen enkele weken goedgekeurd, terwijl dat voor uitvoeringsregistraties, identiteitskoppeling en replay-tools nooit verschijnt of wordt behandeld als een simpele compliancekost.
Vier terugkerende uitzonderingen
Zodra agenten merge requests openen in een gereguleerde CI/CD-omgeving, duiken vier soorten compliance-uitzonderingen op. De eerste is de ontbrekende herkomst: niemand kan zeggen welke gegevens de agent heeft gebruikt, of het nu gaat om specificaties, opgehaalde context, toolaanroepen of de status van de repository. De tweede is de onzekere identiteitstoewijzing, aangezien de agent handelde onder een gedeeld servicetoken, zonder aangewezen menselijk verantwoordelijke. De derde is een niet-reconstrueerbare beslissingsketen, waarbij de redenering slechts tijdelijk is vastgelegd. De vierde is de niet-afgebakende terugdraaiing: aangezien de wijzigingen van de agent gekoppeld zijn, wordt elke terugdraaiactie handmatig werk door commits en repositories heen.
Achteraf reconstructie bestaat uit het onderzoeken van gesprekslogs, gedeeltelijke CI-outputs en nog beschikbare agenttraces. In de meeste organisaties houdt niemand het aantal uren bij dat wekelijks aan deze taak wordt besteed, wat verklaart waarom de kosten ervan onzichtbaar blijven. De bron stelt een eenvoudige test voor: is een team in staat om binnen een uur een bewijsdossier te produceren met de taakspecificaties, de repositorystatus, de geëvalueerde controles en de menselijke verantwoordelijke voor de actie?
« Eerst leveren » en zijn beperkingen
De strategie « Eerst leveren, daarna beheren » kan werken wanneer agenten beperkt blijven tot afgebakende gebieden, zoals het genereren van tests, kleine refactorings of het bijwerken van documentatie, met een grondige menselijke review. Ze breekt echter af wanneer teams zich eraan onttrekken, promptbibliotheken zich vermenigvuldigen met inconsistente logging en gedeelde tokens toewijzing op portfolioniveau onmogelijk maken. Het artikel citeert ook het geval van een groot bedrijf dat een workflowfundament wilde bouwen voordat het agenten uitrolde: het platformproject strekte zich uit over meerdere kwartalen, en de teams omzeilden het uiteindelijk.
Het artikel benadrukt dat « de concurrentiedruk snelheid beloont, terwijl toezichthouders de reconstructiecapaciteit belonen ». Het beschrijft de kosten van deze kloof: ontbrekende bewijzen ontdekt tijdens een controle, wekenlange herstelwerkzaamheden en een impactradius die bij elke slecht geregistreerde agentactie groter wordt. Het citeert in dit verband Crédit Agricole CIB, dat volgens de tekst een levering leidt waarbij duizenden ontwikkelaars verspreid over tientallen landen op één DevSecOps-platform werken, een vereiste om agentisch werk te kunnen controleren.
Werk benoemen en meten
De bron beveelt aan deze klus te behandelen als een volwaardig product, genaamd ‘Geregistreerde uitvoering voor agentische CI/CD’, met middelen die platformengineering, security, audit en ontwikkelaarservaring samenbrengen. De deliverables omvatten een registratieschema dat invoergegevens, outputs, toolaanroepen en modelversie vastlegt, een identiteitskoppeling die elke actie aan een menselijke verantwoordelijke verbindt, logs van beleidsbeslissingen, evenals replay- en terugdraaimechanismen. De monitoring kan steunen op de diepte van de uitzonderingswachtrij, de mediane tijd om bewijzen te verkrijgen, het slagingspercentage van replays en het heropeningspercentage van uitzonderingen.
Als er slechts één stap gezet moet worden, adviseert de tekst te beginnen met de meest risicovolle gevallen, zoals afhankelijkheidswijzigingen, Infrastructure as Code-aanpassingen en beveiligingsconfiguratie. De laatste voorgestelde test bestaat uit het vragen aan een team om een door een agent geschreven, samengevoegde wijziging netjes ongedaan te maken, uitsluitend op basis van geregistreerde artefacten.
