Dhivya Nagasubramanian, VP van AI-transformatie en innovatie – Interviewreeks

Dhivya Nagasubramanian is VP van AI-transformatie en innovatie bij een grote Amerikaanse financiële instelling, waar zij de ontwikkeling, implementatie en governance van productie-agentic AI-systemen leidt. Zij is de auteur van Agentic AI for Engineers (Apress/Springer Nature), een praktische gids voor het bouwen van autonome AI-systemen die in productie kunnen worden vertrouwd. Sinds de publicatie van het boek zijn er meer dan 6.000 institutionele toegangen tot SpringerLink, holdings in meer dan 260 bibliotheken wereldwijd en adoptie in universiteiten. Zij is een door het USPTO verleend octrooihouder in toegepaste machine learning. Haar onderzoeksinteresses omvatten het ontwikkelen van toepassingen die bestand zijn tegen adversarial jailbreak-aanvallen en het bijdragen aan bredere industrie-inspanningen om betere modellen te ontwikkelen voor multicultere veiligheid en beveiliging. Zij is een gewilde expert en panellid op meerdere industrie- en academische conferenties.

Uw carrière is geëvolueerd van enterprise consulting en data science naar het leiden van AI-transformatie binnen financiële dienstverlening. Hoe hebben die ervaringen Agentic AI for Engineers gevormd, en welke terugkerende kloof tussen AI-onderzoek en enterprise-implementatie overtuigde u ervan dat dit boek moest worden geschreven?

Ik begon in 2008 met het bouwen van portfolio-accounting- en prestatie-metingssystemen voor bankplatforms. Een van die projecten was een GIPS-compliant engine voor het berekenen van time-weighted returns, die uiteindelijk door financiële instellingen in meer dan 80 landen werd gebruikt. Dat werk leerde me een les die mijn hele carrière heeft gevormd. In gereguleerde financiën is de gevaarlijkste fout een verkeerd nummer dat er goed uitziet. Een subtiel onjuiste berekening wordt vertrouwd, gerapporteerd en jarenlang gehandhaafd, omdat niets kapot lijkt.

Ik zag hetzelfde patroon later weer. Ik vond een structurele kloof in het Markov-model van een breed gebruikt marketing-attributiemodel. Het kader werd gebruikt door honderdduizenden gebruikers, en de fout had jarenlang standgehouden om één reden: de uitvoer zag er redelijk uit. Toen ik me verplaatste naar AI-transformatie in financiële dienstverlening, zag ik agentic systemen hetzelfde patroon herhalen met veel hogere inzet. Een agent produceert niet alleen een onjuist resultaat. Het neemt actie op basis daarvan.

De kloof die me overtuigde om het boek te schrijven, is dat onderzoek en enterprise-implementatie om verschillende dingen geven. Onderzoek meet capaciteit op basis van benchmarks. Bedrijven zijn afhankelijk van hoe een systeem zich gedraagt onder ambiguïteit, veranderende gegevens en adversarial druk. De meeste schrijvers over agents stoppen bij de demo-fase. Ik schreef Agentic AI for Engineers voor de ingenieur die zijn naam op een systeem moet zetten dat met beperkte supervisie binnen een gereguleerde instelling zal draaien.

Het boek beschrijft de overgang van automatisering naar autonomie als een nieuwe engineeringsmentaliteit. Wat onderscheidt een autonome AI-agent echt van een geavanceerde geautomatiseerde workflow, en waar zijn organisaties het meest geneigd om de twee te verwarren?

Ik geef teams een eenvoudige test. Kun je elke pad die het systeem kan nemen opnoemen voordat je het uitvoert? Als ja, heb je automatisering. Het kan geavanceerde automatisering zijn met een taalmodel erin, maar het is nog steeds automatisering. Als het systeem doelen afbreekt, tools kiest en de volgorde van acties op runtime bepaalt op basis van context die je niet hebt geschreven, heb je autonomie. Het verschil heeft niets te maken met welk model je gebruikt. Het komt neer op waar de beslissingen worden genomen.

Organisaties verwarren de twee in beide richtingen, maar alleen één richting is duur. Een geautomatiseerde LLM-workflow agentic noemen is voornamelijk een marketingprobleem. De kostbare fout is het omgekeerde. Teams implementeren echt autonome besluitvorming onder governance die was ontworpen voor deterministische automatisering. Hun testen gaan ervan uit dat herhaalbaarheid aanwezig is. Hun monitoring gaat ervan uit dat bekende foutpatronen aanwezig zijn. Hun audit-trail gaat ervan uit dat er een traceerbare regel achter elke actie zit. Geen van die aannamen is waar voor een agent.

Dat is de mentaliteitsverandering waar ik in het boek voor pleit. Met automatisering is de belangrijkste vraag of het systeem correct is uitgevoerd. Met autonomie wordt de vraag of het systeem correct heeft besloten. Het beantwoorden van die vraag vereist andere instrumentatie, andere evaluatiemethoden en een ander niveau van voorzichtigheid.

Veel agentic AI-systemen presteren indrukwekkend in demonstraties, maar worstelen wanneer ze worden blootgesteld aan echte gebruikers, veranderende gegevens en onvoorspelbare tools. Welke componenten moeten in een productieklare agentarchitectuur verplicht worden overwogen?

Het eerlijke antwoord is dat productie alles nodig heeft wat een demo laat overslaan. Een demonstratie werkt omdat iemand de omgeving controleerde. Productie neemt die controle weg.

In het boek beschrijf ik een zevenlaags referentie-architectuur, maar deze zijn de componenten die ik verplicht acht. Tool-contracten met getypeerde invoer en expliciete machtigingen, zodat de reikwijdte van de agent per ontwerp wordt beperkt en niet per hoop. Statusbeheer dat interrupties en fouten overleeft. Gestructureerd foutafhandeling met gedefinieerde escalatiepaden. Een evaluatieharnas dat continu draait, niet één keer voor de lancering. En een audit-trail die beslissingen en de redenering erachter registreert, niet alleen de acties die zijn ondernomen.

De component die teams het vaakst overslaan, is runtime-verificatie. Dit is een laag die elke actie controleert tegen de gestelde doelstelling van de agent en de beleidsregels die van toepassing zijn. Standaardinfrastructuur vertelt je of een oproep is geslaagd. Verificatie vraagt of de oproep überhaupt had moeten worden gedaan. Het bewijst zijn waarde nooit in een demo, omdat niets in een demo hoeft te worden gevangen. In productie is het het eerste waar je naar verlangt.

Uw boek behandelt veiligheid, alignering, feedback-lussen, testen, debuggen, evaluatie en implementatie. Hoe kunnen engineersteams deze elementen combineren in een continu proces van waarborging in plaats van veiligheid te behandelen als een laatste voorlanceringbeoordeling?

Een laatste beoordeling rust op de aanname dat het systeem dat u beoordeelt het systeem is dat zal draaien. Voor agentic AI faalt die aanname op drie manieren. De onderliggende modellen worden bijgewerkt. De tools en API’s waarop de agent afhankelijk is, veranderen. En de gegevens en omgeving waarin de agent opereert, blijven veranderen. Een eenmalige veiligheidsbeoordeling beschrijft een systeem dat een paar maanden later niet meer bestaat.

Continue waarborging betekent het sluiten van de lus. Gedragsbeoordelingen worden in CI (continue integratie) uitgevoerd op dezelfde manier als eenheidsbeoordelingen, en ze blokkeren elke wijziging in prompts, tools en modellen. Runtime-monitoring voedt productietracés terug naar de evaluatiesets. Ik beschrijf vier monitorpatronen in het boek, omdat geen enkel patroon het volledige foutoppervlak dekt. Elk incident produceert een nieuwe controle, op dezelfde manier waarop elke bug een regressietest zou moeten produceren. En adversarial testen worden op een regelmatig schema uitgevoerd in plaats van één keer voor de lancering.

De organisatorische kant is even belangrijk als de technische kant. Veiligheid kan geen apart team zijn dat aan het einde met een controlelijst verschijnt. De ingenieurs die de agent bouwen, moeten de evaluatiesuites, de invarianten en het escalatie-ontwerp van de agent bezitten, omdat ze beter dan wie ook weten waar het oordeel van het systeem het zwakst is.

U hebt de nadruk gelegd op semantische monitoring van agent-tooloproepen. Wat onthult semantische monitoring dat conventionele logboeken en observatie-instrumenten niet kunnen, en hoe kan het detecteren wanneer een agent technisch functioneert maar het verkeerde doel nastreeft?

Conventionele observatie beantwoordt één vraag: is de oproep geslaagd? Het dekt statuscodes, schema’s, latentie en foutpercentages. Het kan de vraag niet beantwoorden die voor agents het meest telt, namelijk of de oproep had moeten gebeuren. Een tool-oproep kan technisch perfect zijn en nog steeds de verkeerde actie zijn. Juist formaat, geldige referenties, succesvol antwoord, verkeerde ding om te doen.

Semantische monitoring beoordeelt elke actie tegen de gestelde doelstelling van de agent en de beleidsregels die van toepassing zijn. In het boek beschrijf ik dit als het definiëren van semantische invarianten voor agent-tooloproepen. Dit zijn eigenschappen die ongeacht welk pad de agent neemt, moeten gelden. Een agent die één klantgeval onderzoekt, mag nooit toegang krijgen tot records buiten dat geval. Een agent moet een afwijking boven een bepaalde drempel markeren, nooit zelf oplossen. Wanneer een invariantie wordt geschonden, vang je het probleem op het moment van actie in plaats van in een kwartaalbeoordeling.

Dit is ook hoe je doelverschuiving detecteert, die ik beschouw als de definitieve fout van agentic systemen. Doelverschuiving ziet eruit als een agent die elke stap correct voltooit volgens de logboeken, maar stilzwijgend naar het verkeerde doel werkt. Het verschijnt nooit in een logboek, omdat niets faalt. Semantische monitoring behandelt intentie als iets dat rechtstreeks wordt gemeten, en intentie is waar agents fout gaan.

Wanneer een agent onduidelijke instructies, conflicterende beleidsregels, onbeschikbare tools of onvoldoende vertrouwen tegenkomt, wat zou gestructureerde foutafhandeling moeten omvatten? Hoe kunnen ontwikkelaars ervoor zorgen dat het systeem pauzeert, escaleert of herstelt in plaats van te improviseren?

Het probleem waar je tegen moet ontwerpen, is dat de meeste agents slechts één manier hebben om een taak te beëindigen, namelijk een antwoord produceren. Wanneer instructies onduidelijk zijn of beleidsregels conflicteren, improviseert de agent. Niet omdat het model roekeloos is, maar omdat improviseren het enige gedrag is dat de architectuur toestaat. Gestructureerde foutafhandeling betekent het systeem betere opties geven en ervoor zorgen dat ze gemakkelijker toegankelijk zijn dan een verzonnen antwoord.

In de praktijk betekent dit dat weigeren en escaleren met dezelfde zorg worden ontworpen en getest als succes. Ik raad aan om getypeerde foutstaten te definiëren: onduidelijke instructie, conflicterend beleid, onbeschikbare tool, onvoldoende vertrouwen. Elk daarvan kaart naar een specifiek gedrag. Vraag een verhelderende vraag. Geef over aan een mens met volledige context eraan vastgemaakt. Ga naar alleen-lezen-bewerking. Herstart binnen strakkere limieten. Of stop. Vertrouwensdrempels moeten overeenkomen met het risico van de specifieke actie. De lat voor het opstellen van een intern samenvatting en de lat voor het aanraken van een klantaccount mogen nooit hetzelfde nummer zijn.

Twee praktijken maken dit echt. Ten eerste, ontwerp het escalatiepad voordat je het happy pad ontwerpt. Als een mens de overdracht krijgt, beslis dan wat de context is die ze krijgen en welke autoriteit ze hebben voordat je de eerste prompt schrijft. Ten tweede, test fouten op dezelfde manier als functies. Injecteer onduidelijke instructies. Schakel tools uit in staging. Voer de agent conflicterende beleidsregels. Een systeem dat nooit heeft geoefend om te falen, zal zonder leiding handelen de eerste keer dat het in productie gebeurt.

Financiële instellingen moeten experimenteren met strikte vereisten rondom privacy, controleerbaarheid, modelrisico en regelgevingsconformiteit in evenwicht brengen. Waar moet menselijke goedkeuring verplicht blijven, en waar kunnen agents veilig meer operationele autonomie krijgen?

Mijn regel is dat menselijke goedkeuring moet blijven voor elke actie die onomkeerbaar is, die geld verplaatst of de uitkomst van een patiënt beïnvloedt, die klantcommunicaties met regelgevingsgewicht omvat, die regelgevingsrapportage voedt of die de tools, beleidsregels of machtigingen van de agent zelf wijzigt. Agents kunnen veilig meer autonomie krijgen in lees- en redeneerwerk: onderzoek, ophalen, documentanalyse, triage, opstellen en reconciliaties die afwijkingen markeren voor menselijke beoordeling in plaats van ze op te lossen.

De gebruikelijke fout is om menselijke goedkeuring te vereisen bij elke stap. Dat maakt het systeem niet veiliger. Het creëert het handmatige proces opnieuw met extra stappen en traint reviewers om te rubberen. Goedkeuringen horen bij echte beslissingspunten. Die moeten er weinig zijn, en elke moet zijn bemand door iemand met echte autoriteit om nee te zeggen.

Het andere principe is dat autonomie moet worden verdiend in plaats van verleend. Begin smal. Breid uit terwijl het systeem zichzelf onder monitoring bewijst. Bewaar het bewijs. In modelrisicoterminologie moet uw controle-omgeving u in staat stellen om een regulator niet alleen te laten zien wat de agent heeft gedaan, maar waarom u gerechtvaardigd was om het die niveau van onafhankelijkheid te geven. Dat record is de echte licentie om te opereren.

Door uw werk aan kunstmatige intelligentie-beveiligings- en standaardisatie-initiatieven, helpt u bij het definiëren van regels voor systemen waarvan de mogelijkheden blijven veranderen. Welke beveiligingsmaatregelen kunnen vandaag realistisch worden gestandaardiseerd, en welke gebieden zijn nog te afhankelijk van context, industrie of gebruiksscenario?

De beveiligingsmaatregelen die we vandaag kunnen standaardiseren, zijn structureel. Ze vereisen dat bepaalde controles bestaan, worden gedocumenteerd en geïnspecteerd kunnen worden. Gedocumenteerde capaciteits- en machtigingsgrenzen voor autonome systemen. Gedefinieerde menselijke toezicht- en escalatiemechanismen. Incidentdetectie- en rapportageverplichtingen. Evaluatiemethoden en bewijsvereisten. Duidelijke aansprakelijkheid in de hele systeemlevenscyclus, zodat wanneer iets misgaat, het antwoord op wie verantwoordelijk is nooit alleen de AI is. Deze kunnen worden gestandaardiseerd omdat ze betrekking hebben op of de controles bestaan en hoe goed ze zijn, niet op de specifieke waarden die ze aannemen.

Wat we nog niet kunnen standaardiseren, zijn de instellingen zelf. Specifieke vertrouwensdrempels, schadecatalogi en passende autonomieniveaus zijn sterk afhankelijk van de context. De aanvaardbare fouttolerantie voor een marketing-inhoudsagent en voor een systeem dat klinische of financiële beslissingen raakt, zijn niet twee punten op dezelfde schaal. Ze behoren tot verschillende regimes, gevormd door het domein, de rechtsgebieden en wie de schade draagt wanneer iets faalt.

Financiële controles zijn een nuttig model hier. Auditvereisten zijn wereldwijd gestandaardiseerd, maar materialiteit wordt altijd in context beoordeeld. Standaarden die die splitsing respecteren, hebben de neiging om te worden aangenomen. Standaarden die proberen contextafhankelijke waarden te dicteren, worden genegeerd, en een veiligheidsstandaard die niemand volgt, beschermt niemand.

Uw recente onderzoek heeft multicultere en adversarial robuustheid in AI-veiligheidsevaluatie onderzocht. Wat voor soort modelfouten zullen waarschijnlijk worden gemist door Westers-centrische of wereldwijd gemiddelde benchmarks, en hoe moeten bedrijven systemen evalueren die zijn bedoeld voor multicultere implementatie?

Alleen naar gemiddelde benchmarks kijken, kan de fouten missen die het meest tellen. Een model kan een sterke algehele veiligheidsscore hebben, terwijl het ernstig faalt voor een specifieke taal, dialect of culturele context, omdat die fouten in het gemiddelde verdwijnen. Westers-centrische evaluatie voegt een andere blind spot toe. Het mist schade die cultureel specifiek is, zoals idiomen, gebaren en religieuze of regionale contexten waarin dezelfde uitvoer onschadelijk is in één cultuur en schadelijk in een andere. Het test ook onvoldoende code-switching, transliteratie en niet-Westerse namen en entiteiten. Er is een adversariaal aspect ook. Aanvallers richten zich niet op uw gemiddelde prestaties. Ze vinden uw zwakste snede, en voor de meeste modellen is die zwakste snede een taal met weinig middelen of een culturele context die onvoldoende is geëvalueerd.

Dit is wat me trok in het bijdragen aan multicultere AI-veiligheidsbenchmarkonderzoek. De belangrijkste bevinding is rechttoe rechtaan. Het beoordelen van veiligheid over culturen heen vereist evaluatiegegevens en menselijke beoordeling getrokken uit die culturen. U kunt schade niet beoordelen van buiten de context waarin het optreedt.

Voor bedrijven stel ik drie regels voor. Evalueer elke segment dat u serveert, en accepteer nooit een gemiddelde als bewijs. Bouw evaluatiesets uit uw daadwerkelijke klantpopulaties. Voer adversarial testen uit in de talen die uw klanten gebruiken. Als u klanten in veertig landen serveert en alleen in het Engels evalueert, hebt u uw systeem gemeten voor iemand anders zijn implementatie.

U bent ook houder van een door het United States Patent and Trademark Office verleend octrooi in toegepaste AI. Welk probleem probeerde u op te lossen, wat leerde het proces u over het omzetten van AI-onderzoek in praktische innovatie, en welk onopgelost agentic AI-uitdaging bent u het meest geïnteresseerd om aan te pakken?

Het octrooi dat onlangs is goedgekeurd, lost een probleem van schaal en consistentie op in financiële dienstverlening kwaliteitsbeoordeling — conventionele oproepbeoordeling is handmatig, dus menselijke beoordelaars kunnen alleen een steekproef van oproepen beoordelen, en hun beoordelingen verschillen van persoon tot persoon. Mijn aanpak routeert elke kwaliteits- en conformiteitsvraag naar de methode die het beste geschikt is om die te beantwoorden, met elke beslissing gelogd en traceerbaar voor audit.

U kunt dezelfde thema’s zien die ik in dit interview heb beschreven. Routeer elke taak naar het minst krachtige instrument dat het goed kan doen. Houd mensen in de lus waar oordeel belangrijk is. En maak elke geautomatiseerde beslissing traceerbaar, omdat in een gereguleerde instelling een antwoord zonder bewijs geen antwoord is.

Wat het octrooiproces me leerde, is dat de discipline in de details zit. U kunt geen vaag idee octrooieren. U moet precies aangeven wat uw methode anders doet, en precies waar het van toepassing is. Die gedwongen precisie maakte het onderliggende werk beter.

De onopgeloste uitdaging waar ik me het meest zorgen over maak, is runtime-verificatie voor multi-agent systemen. Het definiëren van semantische invarianten voor één agent is beheersbaar. Ik weet dat, omdat we het in productie doen. Wanneer agents taken delegeren aan andere agents, wordt gedrag emergent, en verplaatst de fouten naar de handovers. Een instructie wordt een beetje anders geïnterpreteerd bij elke stap. Een beleid is van toepassing op één agent, maar niet op de agent die het werven. Verifying de interactie tussen agents, niet alleen de acties van elk, is waar ik verwacht dat de volgende generatie stille fouten zal verschijnen. Dat is het probleem dat ik het liefst als volgende wil aanpakken.

Bedankt voor het geweldige interview, lezers kunnen ook haar boek Agentic AI for Engineers bestellen.