John Daley, CEO en medeoprichter van HelmGuard – interviewreeks

John Daley is CEO en medeoprichter van HelmGuard. Eerder werkte hij acht jaar bij Palantir, waar hij samen leiding gaf aan het juridische team en de wereldwijde omzetfunctie. Zijn ervaring met de groei van grote ondernemingen, juridische risico’s en de inzet van AI vormt de basis voor zijn aanpak om governance te verankeren in de systemen waarop organisaties draaien.

HelmGuard ontwikkelt een AI-platform voor beveiliging, governance, risicobeheer en compliance. Het platform koppelt interne gegevens aan gegevens van derden, zet gespecialiseerde agents in om bewijs te verzamelen en controles te beoordelen, en ondersteunt menselijke beoordeling met bronverwijzingen en auditsporen. De werkzaamheden omvatten het beheer van risico’s van derden, interne compliance en de waarborging van AI-agents die binnen ondernemingen actief zijn.

Bij Palantir gaf je samen leiding aan het juridische team en de wereldwijde omzetfunctie, waardoor je direct zicht had op de spanning tussen groei en risico. Wat heeft die ervaring je geleerd over de tekortkomingen van traditionele governance, en hoe heeft die bijgedragen aan je besluit om HelmGuard mede op te richten?

Doordat ik zowel op juridisch als op commercieel gebied werkte, stond ik midden in de spanning die je beschrijft. De belangrijkste les die ik daaruit trok, is dat governance die te ver afstaat van de uitvoering op beide fronten tekortschiet. Ze belemmert de bedrijfsvoering en beheerst de risico’s vaak evenmin.

Een deel van het probleem is dat governance vaak meer waarde hecht aan grondigheid en diepgang dan aan snelheid. Beleid wordt opgesteld, in commissies beoordeeld en achteraf gehandhaafd met audits en vragenlijsten. Tegen de tijd dat de governancefunctie een oordeel heeft gevormd, heeft het risico zich meestal al op de een of andere manier in de organisatie genesteld.

HelmGuard is ontstaan vanuit de overtuiging dat governance opnieuw moet worden opgebouwd als infrastructuur, en niet als afdeling. De opkomst van AI-agents maakt dat urgent, omdat steeds meer werk nu door agents en tussen agents onderling wordt uitgevoerd, op een manier die traditionele benaderingen niet kunnen bijbenen.

Wat verandert er fundamenteel aan de risicoblootstelling van een financiële instelling wanneer die overstapt van AI die acties aanbeveelt naar agents die ze kunnen uitvoeren? Welke risico’s onderschatten banken en fintechbedrijven volgens jou momenteel?

De fundamentele verandering is dat de mens niet langer de bottleneck is. Bij een aanbevelingssysteem staat iemand tussen de uitvoer van het model en de buitenwereld. Bij een agent is het model de handelende partij en kan de mens hooguit achteraf beoordelen wat er al is gebeurd. In de praktijk is zelfs dat lastig, gezien de snelheid, omvang en reikwijdte van wat agents doen.

Ook neemt het risico toe naarmate een uitvoering langer duurt. Uit ons eigen onderzoek blijkt dat de kans dat een agent van zijn opdracht afwijkt groter wordt wanneer een uitvoering langer duurt en meer toolaanroepen omvat. Nu de mogelijkheden zich zo snel ontwikkelen en de productiviteitswinst binnen handbereik ligt, zal de druk om meer taken over te dragen aan agents die langdurig actief zijn enorm zijn. Instellingen die nog maar net beginnen te experimenteren, beseffen nog niet dat hiervoor een waarborgingsmechanisme nodig is dat specifiek op agents is toegesneden.

Wat banken en fintechbedrijven onderschatten? Ik zou drie dingen noemen. Ten eerste is de legitieme toegang van de agent het aanvalsoppervlak, niet een of andere kwetsbaarheid in het model. Ten tweede zegt toezicht op basis van samenvattingen — waarbij de agent alleen meldt dat de taak is voltooid — vrijwel niets over wat de agent daadwerkelijk heeft gedaan. Ten derde vormt de toeleveringsketen achter een agent, met de modelaanbieder, de leverancier van de orkestratiesoftware en de toolintegraties, een risico van vierde partijen. De meeste organisaties zijn niet in staat die keten doeltreffend in kaart te brengen, en standaardprogramma’s voor het beheer van risico’s van derden (TPRM) kunnen dit onmogelijk bijbenen.

Een agent kan legitieme toegang hebben tot een betalingssysteem en toch een ongepaste transactie initiëren. Hoe kunnen financiële instellingen onderscheid maken tussen wat een agent technisch gezien mag doen en waartoe de agent in een bepaalde zakelijke context bevoegd is?

Een machtiging is een eigenschap van de inloggegevens, terwijl autorisatie afhankelijk is van de context. Met traditioneel identiteits- en toegangsbeheer kun je nagaan of deze identiteit deze API mag aanroepen. Het kan je niet vertellen of deze identiteit vandaag, om deze reden, deze betaling aan deze tegenpartij zou moeten uitvoeren.

Mensen overbruggen die kloof met oordeelsvermogen, controles en kennis van de organisatie. Agents beschikken alleen over de context die je ze meegeeft, dus die moet expliciet worden aangeleverd. Ook moeten de controles zelf opnieuw worden doordacht voor een nieuw soort medewerker dat binnen de onderneming opereert.

In de praktijk betekent dit dat er een laag tussen de intentie van de agent en het registratiesysteem komt. Die laag bevat het eigen gegevensmodel van de organisatie, met bekende en vertrouwde entiteiten, goedgekeurde tegenpartijen, limieten en informatie over wie voor wie wat mag doen. In productie wordt elke actie aan dat model getoetst, met dezelfde snelheid als waarmee de agents werken.

Een intuïtieve manier om hierover na te denken, is de volgende toets toe te passen: kun je in één zin uitleggen om welke zakelijke reden deze agent deze specifieke actie mocht uitvoeren? Als het antwoord is dat de agent toegang had, gaat het om een machtiging, niet om autorisatie.

Neem een agent die de factuur van een leverancier leest en een betaling kan initiëren. Hoe zou u die workflow beschermen tegen kwaadwillige instructies die in het document zijn opgenomen, en waar zou u controles vereisen die de agent zelf niet kan omzeilen?

Ik zou beginnen met elk document dat de agent leest als niet-vertrouwde invoer te behandelen, net als een bijlage bij een e-mail. De factuur bevat gegevens die moeten worden uitgelezen, geen instructies die moeten worden opgevolgd. Dat moet expliciet in de opdracht van de agent staan.

Vervolgens moeten lezen en handelen van elkaar gescheiden zijn: de agent die de factuur uitleest, mag niet degene zijn die over de betalingsgegevens beschikt. Het uitlezen levert een gestructureerd voorstel op met de tegenpartij, het bedrag en de referentie. In een afzonderlijke stap wordt dat voorstel getoetst aan het beleid en goedgekeurd voordat er iets gebeurt.

Tot slot moet de handeling worden getoetst aan wat de instelling al weet, en niet aan wat het document beweert. Is deze leverancier bij ons bekend? Zijn dit de bankgegevens die we al van deze leverancier hebben? Valt het bedrag binnen het contract en komt de timing overeen met eerdere betalingen? Promptinjectie kan veranderen wat er in een document staat, maar niet de eigen gegevens van de instelling. Die gegevens kunnen de handelingen van een agent op dezelfde manier sturen als die van een persoon, mits de agent de betreffende context krijgt.

Sommige controles moeten buiten het bereik van de agent blijven. Wijzigingen van een tegenpartij of diens bankgegevens moeten via een apart kanaal worden bevestigd, betalingslimieten moeten op een lager niveau dan dat van de agent worden afgedwongen, nieuwe begunstigden moeten worden geblokkeerd en voor alles wat afwijkt van het gebruikelijke patroon moet een mens goedkeuring geven.

Het onderliggende principe is dat een prompt blokkeren niet hetzelfde is als een agent aansturen. Een goede verdediging vereist een fundamentele herziening van wat een onderneming met agents inhoudt, in plaats van simpelweg automatisering toe te passen op bestaande workflows.

HelmGuard gebruikt AI-agents om toezicht te houden op andere agents. Hoe stelt u vast dat het toezichtsysteem fouten herkent die de onderliggende agent over het hoofd ziet, en welke waarborgen moeten onafhankelijk zijn van beide?

Het voordeel van de toezichthouder is niet dat die slimmer is dan de agent waarop hij toezicht houdt, maar dat hij over andere informatie beschikt en een andere taak heeft. Hij ziet het volledige logboek in plaats van alleen de samenvatting, beschikt over de controles en het risicoprofiel van de organisatie en probeert de taak niet zelf uit te voeren. Hij heeft dus geen reden om een sluiproute goed te praten.

We stellen op dezelfde manier vast of de toezichthouder fouten opvangt die de agent mist als bij elke andere controle: door hem te testen op bekende fouten. We reconstrueren handelingen aan de hand van logboeken, vergelijken ze met de vastgelegde opdracht en controles en meten hoe goed afwijkingen worden opgespoord in reeksen met bekende labels.

Onafhankelijkheid is cruciaal, net zoals financiële instellingen het risicobeheer van de eerste, tweede en derde lijn van elkaar hebben gescheiden. De toezichtslaag moet waar mogelijk op andere modellen draaien dan de agent, alleen-leestoegang hebben tot de systemen waarop de agent handelt en nooit de inloggegevens van de agent delen. Zo kan het ontwerp rekening houden met onderling samenhangende fouten en blijft het doel en toepassingsgebied van de controle- en verificatielaag beperkt.

Sommige waarborgen moeten onafhankelijk zijn van beide, zoals deterministische limieten en functiescheiding die op systeemniveau worden afgedwongen, onveranderlijke logboeken die geen van beide agents kan aanpassen, noodstop- en isolatiemechanismen die niet afhangen van het oordeel van een van beide modellen, en periodieke menselijke beoordeling van de resultaten van de verificatielaag.

AI-eigen waarborging is noodzakelijk, want alleen iets dat werkt volgens de werkwijze van de agent, met dezelfde snelheid en op basis van dezelfde gegevens, kan het tempo bijhouden. Maar die waarborging moet wel zijn verankerd in dezelfde organisatiestructuur en hetzelfde nalevings- en risicokader die organisaties in de loop van jaren hebben ontwikkeld.

Kunt u uitleggen hoe HelmGuard het schriftelijke beleid van een bank zou omzetten in een controle die wordt toegepast terwijl een agent actief is? Wat gebeurt er bijvoorbeeld wanneer een betaling waarvoor verder toestemming is, in strijd is met een interne beperking?

De eerste stap is het beleid om te zetten in toetsbare voorwaarden. Zo wordt een regel als ‘voor betalingen van meer dan $50.000 aan nieuwe leveranciers is goedkeuring van de tweede lijn vereist’ opgesplitst in voorwaarden die automatisch kunnen worden gecontroleerd, zoals de status van de tegenpartij, het bedrag en de goedkeuringsstatus. Vervolgens worden die voorwaarden gekoppeld aan het gegevensmodel van de instelling.

De tweede stap is die voorwaarden op te nemen in de opdracht waarbinnen de agent werkt. De toezichtslaag toetst elke voorgestelde handeling eraan. Neem uw voorbeeld: een agent stelt een betaling voor die binnen zijn bevoegdheden en binnen het contract met de leverancier valt, maar de instelling heeft de leverancier geblokkeerd in afwachting van een nieuwe zorgvuldigheidscontrole. Het systeem staat de handeling toe, maar het beleid verbiedt die. De toezichtslaag signaleert het conflict, onderbreekt de handeling, legt de redenering vast en stuurt de zaak, met het bijbehorende bewijs, door naar de aangewezen goedkeurder.

Daarna kan een van drie dingen gebeuren; alle drie worden vastgelegd. De goedkeurder maakt de blokkade met opgave van een reden ongedaan, de beperking blijft van kracht en de agent krijgt te horen waarom, of het beleid blijkt onjuist en wordt aangepast. Die laatste terugkoppeling voorkomt dat het schriftelijke beleid en de controles in de praktijk uit elkaar gaan lopen.

Financiële instellingen voeren al uitgebreide due diligence uit naar leveranciers. Wat moet er veranderen wanneer een leverancier het model, de tools of de machtigingen van een agent na de eerste beoordeling kan aanpassen, waardoor mogelijk ook het gedrag van die agent binnen de systemen van de instelling verandert?

Bij due diligence op één bepaald moment gaat men ervan uit dat wat is beoordeeld ook daadwerkelijk in gebruik wordt genomen. Bij een agent gaat die aanname niet meer op zodra de leverancier het onderliggende model vervangt, een tool toevoegt of de machtigingen uitbreidt. Daarom is een andere aanpak nodig, met meer aandacht voor het gedrag van de agent.

Contractueel moeten instellingen als minimumeis stellen dat ze op de hoogte worden gebracht van wezenlijke wijzigingen in de modelversie, de set tools en de reikwijdte van de machtigingen. Ook moeten ze vooraf bepalen wat als wezenlijk geldt.

Maar belangrijker nog: operationeel moeten ze zelf doorlopend bewijs verzamelen, waargenomen gedrag vergelijken met verwacht gedrag, afwijkingen in de gaten houden en de mogelijkheid behouden om de uitgangssituatie opnieuw vast te stellen. Als de leverancier de agent kan aanpassen, moet je kunnen zien dát die is aangepast.

Met agents komt ook een keten van onderleveranciers mee, van de modelaanbieder en de hostinglaag tot elke toolintegratie. Dat brengt risico’s van vierde partijen met zich mee, en de meeste programma’s voor het beheer van risico’s van derden zijn niet ingericht om die goed in kaart te brengen.

Hier komen de twee onderdelen van ons platform samen. Risicobeheer van derden laat zien wie de leverancier is en waartoe die zich heeft verbonden; waarborging van agents laat zien wat diens software daadwerkelijk in jouw omgeving doet. Due diligence moet beide omvatten.

Welk bewijs heeft een instelling nodig om, nadat een agent financieel verlies heeft veroorzaakt, de besluitvorming te reconstrueren en vast te stellen wie verantwoordelijk is binnen het bedrijfsteam, bij de softwareleverancier en bij de modelaanbieder? Waar ziet u de grootste tekortkomingen in de manier waarop dat bewijs momenteel wordt vastgelegd?

Je hebt het volledige spoor van de uitvoering nodig: elke invoer, toolaanroep, tussenliggende redeneerstap en uitvoer, plus het mandaat waaronder de agent op dat moment werkte, de toen geldende beleids- en controle-instellingen, het gebruikte model en de versie ervan, en de configuratie die de leverancier had uitgerold. Daarbovenop heb je de menselijke tussenkomsten nodig: wie wat heeft goedgekeurd, wanneer en op basis van welk bewijs.

De verantwoordelijkheid is grofweg over drie partijen verdeeld, maar wij denken dat het lastig zal zijn om de modelaanbieder een groot deel ervan toe te wijzen. Het bedrijfsteam moet verantwoordelijk zijn voor het mandaat en de goedkeuringen; de softwareleverancier voor de configuratie en tools van de agent en voor het wijzigingsbeheer. Met deze indeling kun je beginnen verantwoordelijkheden toe te wijzen, als je kunt aantonen op welk niveau de fout is ontstaan.

De grootste tekortkoming op dit moment is dat toezicht vaak beperkt blijft tot samenvattingen. Als in het uitvoeringsverslag staat: ‘taak succesvol voltooid’, blijft de handeling die het verlies heeft veroorzaakt onzichtbaar totdat het geld verdwenen is. De reconstructie wordt dan forensisch onderzoek. Wat nodig is, is een bewijsspoor dat vanaf het begin is ontworpen om verantwoordelijkheid vast te stellen: onveranderlijk, gekoppeld aan het mandaat en de controles, en onafhankelijk van zowel de agent als diens leverancier. Dat spoor moet voortdurend worden bewaakt door gespecialiseerde agents, die problemen snel aan het licht brengen wanneer beoordeling nodig is.

U hebt de overgang van Palantir van een niet-beursgenoteerd bedrijf naar een beursgenoteerde onderneming meegemaakt. Welk bewijs moeten beleggers vragen wanneer ze bedrijven beoordelen waarvan de groei afhankelijk is van autonome AI, om goed bestuur te kunnen onderscheiden van geruststellende verklaringen?

Omdat ik de overgang van Palantir van een niet-beursgenoteerd naar een beursgenoteerd bedrijf heb meegemaakt, weet ik dat bedrijven bij hun toelichtingen vaak geruststellende taal gebruiken over hun bestuurspraktijken: ze verwijzen naar ingevoerde raamwerken, gepubliceerde principes en opgerichte commissies. Beleggers moeten dat als een basisvereiste beschouwen en in plaats daarvan vragen naar bewijs uit de dagelijkse praktijk.

Een paar specifieke vragen zijn het stellen waard.

Welk deel van de acties van agents wordt op actieniveau gecontroleerd in plaats van alleen aan de hand van samenvattingen?

Hoe hoog is het gemeten afwijkingspercentage en hoe heeft dat zich ontwikkeld?

Hoeveel incidenten zijn er geweest, hoe snel werden die ontdekt en gebeurde dat dankzij de ingebouwde controles of door toeval?

Wie kan een agent stilleggen, hoe snel kan dat en is die bevoegdheid onafhankelijk van het team dat de agent heeft gebouwd? Als het antwoord neerkomt op iemand die iets opmerkt, is dat geen controle.

Kijk tot slot, en misschien enigszins tegenintuïtief, of er bewijs is dat het bedrijf fouten heeft gemaakt en kan uitleggen hoe het daarop heeft gereageerd. Een bedrijf dat geen enkel incident met agents meldt, gebruikt óf geen agents op grote schaal, óf kijkt niet goed.

Wat zou u ervan overtuigen dat een financiële instelling klaar is om de bevoegdheden van een agent uit te breiden: van een beperkte pilot naar het verplaatsen van klanttegoeden of het uitvoeren van transacties? Welke meetbare resultaten moeten meer autonomie rechtvaardigen, en welke moeten juist aanleiding geven om die in te perken?

Ik zou een aanhoudende periode willen zien waarin elke handeling van de agent op actieniveau aan het mandaat is getoetst, met een laag, stabiel en goed begrepen afwijkingspercentage.

Aan de meetbare kant zou ik kijken naar een afwijkingspercentage onder een afgesproken drempel, gemeten over een betekenisvol aantal uitvoeringen; of elke afwijking die zich voordeed door de controlelaag is onderschept voordat die het registratiesysteem bereikte; of de detectie- en indammingstijd in minuten in plaats van dagen wordt gemeten; en of ten minste één echte bijna-misser nauwkeurig kan worden gereconstrueerd om aan te tonen dat het bewijsspoor daadwerkelijk werkt.

De bevoegdheden moeten stapsgewijs worden uitgebreid, niet met grote sprongen. Eerst een ruimere reikwijdte en pas daarna hogere limieten; eerst lees- en schrijfrechten en pas daarna onbewaakt werken; eerst interne middelen en pas daarna klantmiddelen. Voor elke stap moet een eigen uitgangswaarde worden vastgesteld.

Redenen om de autonomie terug te schroeven zijn onder meer elke afwijking die het registratiesysteem heeft bereikt, een stijgend afwijkingspercentage na een wijziging van een model of tool, een wijziging van leverancier waarvan de instelling niet vooraf op de hoogte was, een hiaat in het controlespoor of een toenemend percentage menselijke ingrepen. Dat laatste betekent meestal dat het mandaat zelf niet klopt.

Het leidende principe is dat autonomie moet worden verdiend en kan worden ingetrokken, precies zoals bij een nieuwe medewerker. De instelling moet in beide gevallen het bewijs kunnen laten zien.

Hartelijk dank voor het geweldige interview. Lezers die willen ontdekken hoe doorlopende waarborging, onafhankelijke controles en bewijs op actieniveau het AI-toezicht in de financiële dienstverlening kunnen ondersteunen, kunnen terecht bij HelmGuard.