Dhivya Nagasubramanian, VP for AI-transformation og innovation – Interviewserie

Dhivya Nagasubramanian er VP for AI-transformation og innovation i en større amerikansk finansinstitution, hvor hun leder design, implementering og styring af produktions-agentic AI-systemer. Hun er forfatter til Agentic AI for Engineers (Apress/Springer Nature), en praktisk guide til at bygge autonome AI-systemer, der kan betrodes i produktion. Siden udgivelsen har bogen haft over 6.000 institutionelle adgang til SpringerLink, ejes af over 260 biblioteker verden over og er blevet anvendt på tværs af universiteter. Hun er indehaver af et USPTO-godkendt patent i anvendt maskinlæring. Hendes forskningsinteresser omfatter udvikling af applikationer, der er resistente over for fjendtlige angreb, og bidrage til bredere industriel anstrengelser for at udvikle bedre modeller for multikulturel sikkerhed og sikkerhed. Hun er en eftertragtet eksperttaler og paneldeltager på tværs af multiple industriel og akademiske konferencer.

Dit karriere er gået fra enterprise-rådgivning og datavidenskab til at lede AI-transformation inden for finansservice. Hvordan har disse oplevelser formet Agentic AI for Engineers, og hvilken tilbagevendende kløft mellem AI-forskning og enterprise-udrulning overbeviste dig om, at denne bog skulle skrives?

Jeg startede i 2008 med at bygge portefølje-regnskabs- og performance-målingsystemer til bankplatforme. Et af disse projekter var en GIPS-kompatibel motor til beregning af time-vægtede afkast, som finansinstitutioner i over 80 lande senere brugte. Det arbejde lærte mig en lektie, der har formet hele min karriere. I regulering af finans, er den farligste fejl en forkert tal, der ser rigtig ud. En subtilt forkert beregning bliver betroet, rapporteret og brugt i år, fordi intet ser forkert ud.

Jeg så det samme mønster igen senere. Jeg fandt en strukturel kløft i Markov-modellen af en bredt brugt markedsførings-attributionsmodel. Rammen blev brugt af hundredtusinder af brugere, og fejlen havde overlevet i år, fordi udgangspunkterne så rimelige ud. Da jeg gik over til AI-transformation i finansservice, så jeg agentic systemer gentage dette mønster med langt højere indsats. En agent producerer ikke bare et forkert resultat. Den tager handling baseret på det.

Kløften, der overbeviste mig om at skrive bogen, er, at forskning og enterprise-udrulning bekymrer sig om forskellige ting. Forskning måler evne på benchmarks. Virksomheder afhænger af, hvordan et system opfører sig under usikkerhed, ændrende data og fjendtlig pres. De fleste skrifter om agenter stopper ved demo-stadiet. Jeg skrev Agentic AI for Engineers til ingeniøren, der skal sætte sit navn på et system, der skal køre med begrænset overvågning inden for en regulering institution.

Bogen beskriver skiftet fra automatisering til autonomi som en ny ingeniør-mindset. Hvad adskiller virkelig en autonom AI-agent fra en sofistikeret automatiseret arbejdsgang, og hvor er organisationer mest sandsynligt at forvirre de to?

Jeg giver holdene en simpel test. Kan du liste alle stier, systemet kan tage, før du kører det? Hvis ja, har du automatisering. Det kan være meget sofistikeret automatisering med en sprogmodel inde i det, men det er stadig automatisering. Hvis systemet bryder ned mål, vælger værktøjer og beslutter rækkefølgen af handlinger på kørselstidspunktet baseret på kontekst, du ikke har skrevet, har du autonomi. Forskellen har intet at gøre med, hvilken model du bruger. Det kommer ned til, hvor beslutningerne tages.

Organisationer forvirrer de to i begge retninger, men kun én retning er dyrekøbt. At kalde en skrevet LLM-arbejdsgang agentic er mest et markedsføringsproblem. Den dyre fejl er det omvendte. Hold udruller ægte autonome beslutningsprocesser under styring, der var designet til deterministisk automatisering. Deres test antager gentagelighed. Deres overvågning antager kendte fejlmodeller. Deres revisionsspor antager, at der er en sporbar regel bag hver handling. Ingen af disse antagelser holder for en agent.

Det er mindset-skiftet, jeg argumenterer for i bogen. Med automatisering er det primære spørgsmål, om systemet udførte korrekt. Med autonomi bliver spørgsmålet, om systemet besluttede korrekt. At svare på det kræver anden instrumentation, anden evaluering og en anden niveau af forsigtighed.

Mange agentic AI-systemer performer imponerende i demonstrationer, men kæmper, når de udsættes for virkelige brugere, ændrende data og uforudsigelige værktøjer. Hvilke komponenter bør være obligatoriske i en produktionsklar agent-arkitektur?

Den ærlige besked er, at produktion kræver alt, hvad en demo lader dig springe over. En demonstration virker, fordi nogen kontrollerede miljøet. Produktion tager den kontrol væk.

I bogen beskriver jeg en syv-lags reference-arkitektur, men disse er de komponenter, jeg betragter som obligatoriske. Værktøjskontrakter med typiserede indgange og eksplisitte tilladelser, så agentens rækkevidde er begrænset af design snarere end af håb. Tilstandsstyring, der overlever afbrydelser og fejl. Struktureret fejlhåndtering med definerede eskalationsveje. En evalueringssæt, der kører kontinuerligt, ikke kun én gang før lancering. Og en revisionsspor, der optager beslutninger og den begrundelse bag dem, ikke kun handlingerne, der er udført.

Komponenten, hold springer over mest, er runtime-verificering. Dette er et lag, der checker hver handling mod agentens erklærede mål og de politikker, der gælder for det. Standard-infrastruktur fortæller dig, om et opkald lykkedes. Verificering spørger, om opkaldet skulle være lavet overhovedet. Det beviser aldrig sin værdi i en demo, fordi intet behøver at blive fanget. I produktion er det det første, du vil ønske, du havde.

Din bog dækker sikkerhed, alignment, feedback-løkker, test, fejlfinding, evaluering og udrulning. Hvordan skal ingeniørhold kombinerer disse elementer i en kontinuerlig sikkerhedsproces i stedet for at behandle sikkerhed som en sidste forlanserings-gennemgang?

En sidste gennemgang hviler på antagelsen, at systemet, du gennemgik, er systemet, der vil køre. For agentic AI fejler den antagelse på tre måder. De underliggende modeller bliver opdateret. Værktøjerne og API’erne, agenten afhænger af, ændrer sig. Og data og miljø, agenten opererer i, ændrer sig også. En enkelt sikkerheds-gennemgang beskriver et system, der ikke længere eksisterer få måneder senere.

Kontinuerlig sikkerhed betyder at lukke cirklen. Adfærds-evalueringer kører i CI (kontinuerlig integration) på samme måde som enhedstests, og de blokerer hver ændring til prompts, værktøjer og modeller. Runtime-overvågning føder produktionsspor tilbage til evalueringssættene. Jeg beskriver fire overvågningsmønstre i bogen, fordi intet enkelt mønster dækker det fulde fejlsurface. Hver enkelt incident producerer en ny check, på samme måde som hver enkelt fejl skal producere en regressionstest. Og fjendtlig test kører på en fast skema i stedet for kun én gang før lancering.

Den organisatoriske side er lige så vigtig som den tekniske side. Sikkerhed kan ikke være et separat hold, der viser sig ved slutningen med en checkliste. Ingeniørerne, der bygger agenten, skal eje dens evalueringssæt, dens invariant og dens eskalationsdesign, fordi de ved bedst, hvor systemets dømmekraft er svagest.

Du har understreget semantisk overvågning af agent-værktøjskald. Hvad afslører semantisk overvågning, som konventionelle logs og overvågningsværktøjer ikke kan, og hvordan kan det opdage, når en agent er teknisk fungerende, men forfølger det forkerte mål?

Konventionel overvågning svarer på ét spørgsmål: lykkedes opkaldet? Det dækker statuskoder, skemaer, latency og fejlhastigheder. Det kan ikke svare på det spørgsmål, der betyder mest for agenter, som er, om opkaldet skulle ske. Et værktøjskald kan være teknisk perfekt og stadig være den forkerte handling. Rigtig format, gyldige legitimationsoplysninger, succesfuld respons, forkert ting at gøre.

Semantisk overvågning evaluerer hver handling mod agentens erklærede mål og de politikker, der gælder for det. I bogen beskriver jeg dette som at definere semantiske invarianter over agent-værktøjskald. Disse er egenskaber, der skal gælde uanset, hvilken vej agenten tager. En agent, der forsker i en kundes sag, skal aldrig få adgang til optegnelser uden for den sag. En agent skal markere en afvigelse over en bestemt grænse, aldrig løse det selv. Når en invariant bliver overtrådt, fanger du problemet på handlingens tidspunkt i stedet for i en kvartalsvis revision.

Dette er også, hvordan du opdager mål-drift, som jeg betragter som den definerende fejl for agentic systemer. Mål-drift ligner en agent, der gennemfører hver trin korrekt ifølge loggene, mens den stille arbejder mod det forkerte mål. Det viser sig aldrig i en log, fordi intet fejler. Semantisk overvågning behandler hensigt som noget, du måler direkte, og hensigt er, hvor agenter går galt.

Når en agent møder tvetydige instruktioner, modstridende politikker, utilgængelige værktøjer eller utilstrækkelig tillid, hvad skal struktureret fejlhåndtering se ud? Hvordan kan udviklere sikre, at systemet pauser, eskalerer eller genopretter i stedet for at improvisere?

Problemet at designe imod er, at de fleste agenter kun har én måde at afslutte en opgave på, som er at producere et svar. Når instruktioner er tvetydige eller politikker modstrider hinanden, improviserer agenten. Ikke fordi modellen er uforsigtig, men fordi improvisering er den eneste adfærd, arkitekturen tillader. Struktureret fejlhåndtering betyder at give systemet bedre muligheder og gøre dem lettere at nå end et lavet svar.

I praksis betyder det, at afvisning og eskalation er designet og testet med samme omhu som succes. Jeg anbefaler at definere typiserede fejltilstande: tvetydig instruktion, modstridende politik, utilgængeligt værktøj, utilstrækkelig tillid. Hver enkelt af disse tilstande kortlægges til en bestemt adfærd. Stil et afklarende spørgsmål. Overdrag til en menneske med fuld kontekst vedhæftet. Drop til læse-only-operation. Gentag indenfor snævrere grænser. Eller stop. Tillidsniveauer skal matche risikoen for den specifikke handling. Grænsen for at udarbejde en intern sammenfatning og grænsen for at røre en kunde-konto skal aldrig være det samme tal.

To praksisser gør dette til virkelighed. Først designer du eskalationsvejen, før du designer den lykkelige vej. Hvis en menneske skal modtage overdragelsen, beslutter du, hvilken kontekst de får, og hvilken myndighed de har, før du skriver den første prompt. Anden, tester du fejl på samme måde, som du tester funktioner. Indsæt tvetydige instruktioner. Deaktiver værktøjer i staging. Fodrer agenten med modstridende politikker. Et system, der aldrig har øvet fejl, vil handle uden vejledning første gang, det sker i produktion.

Finansinstitutioner må balancere eksperimenter med strenge krav omkring privatliv, revisionsberettigelse, model-risiko og lovmæssig overholdelse. Hvor skal menneskelig godkendelse forblive obligatorisk, og hvor kan agenter sikkert få større operationel autonomi?

Min regel er, at menneskelig godkendelse skal forblive obligatorisk for enhver handling, der er irreversibel, der flytter penge eller påvirker en patients udfald, der involverer kunde-kommunikation med lovmæssig vægt, der føder lovmæssig rapportering, eller der ændrer agentens eget værktøj, politik eller tilladelser. Agenter kan sikkert få større autonomi i læse- og forstå-arbejde: forskning, hentning, dokumentanalyse, triage, udarbejdelse og afstemning, der markerer afvigelser for menneskelig gennemgang i stedet for at løse dem.

Den almindelige fejl er at kræve menneskelig godkendelse ved hver skridt. Det gør ikke systemet sikrere. Det genskaber den manuelle proces med ekstra skridt og træner gennemgangere til at stæmpe. Godkendelser hører til ved rigtige beslutningspunkter. Der skal være få af dem, og hver skal være bemandet med nogen, der har reel myndighed til at sige nej.

Den anden princip er, at autonomi skal være fortjent snarere end tildelt. Start smalt. Udvid, efterhånden som systemet beviser sig under overvågning. Behold beviset. I model-risikobetoninger skal din kontrol-miljø låse dig til at vise en regulator ikke kun, hvad agenten gjorde, men hvorfor du var berettiget til at give det den niveau af uafhængighed. Denne post er den virkelige licens til at operere.

Gennem dit arbejde med kunstig intelligens-sikkerheds- og standarder hjælper du med at definere regler for systemer, hvis evner fortsætter med at ændre sig. Hvilke sikkerhedsforanstaltninger kan realistisk standardiseres i dag, og hvilke områder forbliver for afhængige af kontekst, industri eller brugsområde?

De sikkerhedsforanstaltninger, vi kan standardisere i dag, er strukturelle. De kræver, at bestemte kontroller findes, er dokumenterede og kan inspiceres. Dokumenterede evne- og tilladelsesgrænser for autonome systemer. Definerede menneskelig overvågning og eskalationsmekanismer. Ulykkesdetektion og rapporteringsforpligtelser. Evalueringmetoder og beviskrav. Klare ansvar på tværs af system-livscyklussen, så når noget går galt, er svaret på, hvem der er ansvarlig, aldrig bare AI. Disse kan standardiseres, fordi de vedrører, om kontrollerne findes og hvor gode de er, ikke de specifikke værdier, de tager.

Hvad vi ikke kan standardisere endnu er indstillingerne selv. Specifikke tillidsniveauer, skadetaxonomier og passende autonominiveauer afhænger stærkt af kontekst. Den accepterede fejl-tolerant for en markedsførings-indhold-agent og for et system, der rører kliniske eller finansielle beslutninger, er ikke to punkter på samme skala. De tilhører forskellige regimer, formet af domænet, jurisdiktionen og hvem, der bærer skaden, når noget fejler.

Finanskontroller er en nyttig model her. Revisionskrav er standardiseret globalt, men materielitet vurderes altid i kontekst. Standarder, der respekterer denne opdeling, har tendens til at blive antaget. Standarder, der forsøger at diktere kontekst-afhængige værdier, har tendens til at blive ignoreret, og en sikkerhedsstandard, som ingen følger, beskytter ingen.

Dit nylige forskning har udforsket multikulturel og fjendtlig robusthed i AI-sikkerheds-evaluering. Hvilke slags model-fejl er sandsynligt at blive overset af vestligt-centrerede eller globalt-gennemsnits-benchmarks, og hvordan skal virksomheder evaluere systemer, der er beregnet til multikulturel udrulning?

At se kun på gennemsnits-benchmarks kan oversætte fejl, der betyder mest. En model kan opnå en stærk samlet sikkerheds-score, mens den fejler slemt for et bestemt sprog, dialekt eller kulturelt kontekst, fordi disse fejl forsvinder i gennemsnittet. Vestligt-centrerede evaluering tilføjer endnu en blind plet. Det overser skader, der er kulturelt specifikke, såsom idiom, gestus og religiøse eller regionale kontekster, hvor samme output er harmløs i en kultur og skadelig i en anden. Det undersøger også for lidt kode-skift, translitteration og ikke-vestlige navne og enheder. Der er en fjendtlig vinkel også. Angribere målretter ikke din gennemsnits-præstation. De finder din svageste skive, og for de fleste modeller er den svageste skive et lav-resurse-sprog eller et under-udværdiget kulturelt kontekst.

Dette er, hvad der trak mig ind i at bidrage til multikulturel AI-sikkerheds-benchmark-forskning. Den grundlæggende opdagelse er ligefrem. At vurdere sikkerhed på tværs af kulturer kræver evalueringdata og menneskelig dømmekraft trukket fra disse kulturer. Du kan ikke vurdere skade fra uden for konteksten, hvor den sker.

Til virksomheder foreslår jeg tre regler. Evaluér hver segment, du betjener, og accepter aldrig et gennemsnit som bevis. Byg evalueringssæt fra dine faktiske kunde-populationer. Kør fjendtlig test i de sprog, dine kunder bruger. Hvis du betjener kunder i fyrre lande og kun evaluerer på engelsk, har du målt dit system til en andens udrulning.

Du er også indehaver af et tildelt United States Patent and Trademark Office-patent i anvendt maskinlæring. Hvilket problem forsøgte du at løse, hvad lærte processen dig om at omdanne AI-forskning til praktisk innovation, og hvilken uløst agentic AI-udfordring er du mest interesseret i at løse næste?

Patentet, der blev godkendt, løser et skala- og konsistens-problem i finansservice-kvalitets-gennemgang – konventionel kalde-gennemgang er manuel, så menneskelige gennemgangere kan kun prøve en brøkdel af opkald, og deres vurderinger varierer fra person til person. Min tilgang router hver kvalitets- og overholdelses-spørgsmål til den metode, der er bedst egnede til at svare på det, med hver beslutning logget og sporbar til revision.

Det, patent-processen lærte mig, er, at disciplinen ligger i detaljerne. Du kan ikke patenterer en vag idé. Du må vise præcis, hvad din metode gør anderledes, og præcis hvor den anvendes. Denne præcision gjorde det underliggende arbejde bedre.

Den uløste udfordring, jeg bekymrer mig mest om nu, er runtime-verificering for multi-agent-systemer. At definere semantiske invarianter for en enkelt agent er håndterbart. Jeg ved, fordi vi gør det i produktion. Når agenter delegerer arbejde til andre agenter, bliver adfærd emergent, og fejlene flytter ind i håndoffene. En instruktion bliver lidt genfortolket på hvert trin. En politik gælder for en agent, men ikke for den agent, den rekrutterer. At verificere interaktionen mellem agenter, ikke kun deres handlinger, er, hvor jeg forventer, den næste generation af stille fejl vil dukke op. Det er problemet, jeg vil arbejde på næste.

Tak for det gode interview, læsere kan også ønske at bestille hendes bog Agentic AI for Engineers.