Dhivya Nagasubramanian, VP for AI-Transformasjon og Innovasjon – Intervju-serie

Dhivya Nagasubramanian er VP for AI-Transformasjon og Innovasjon i en stor amerikansk finansiell institusjon, der hun leder design, utrulling og styring av produksjonsagenter for AI. Hun er forfatter av Agentic AI for Engineers (Apress/Springer Nature), en praktisk guide til å bygge autonome AI-systemer som kan stole på i produksjon. Siden utgivelsen har boken hatt over 6 000 institusjonelle tilganger på SpringerLink, innhold i over 260 biblioteker verden over og adopsjon på universiteter. Hun er en USPTO-godkjent patentholder i anvendt maskinlæring. Hennes forskningsinteresser inkluderer å bygge applikasjoner som er motstandsdyktige mot adversarial jailbreak-angrep og bidra til bredere industrielle bestrebelser for å utvikle bedre modeller for flerkulturell sikkerhet og sikkerhet. Hun er en etterspurt eksperttaler og panelist på flere industri- og akademiske konferanser.

Din karriere har gått fra enterprise-konsulent og data-vitenskap til å lede AI-transformasjon innen finansielle tjenester. Hvordan har disse erfaringene formet Agentic AI for Engineers, og hva var den gjentakende gapet mellom AI-forskning og bedrifts-utrulling som overbeviste deg om at denne boken måtte skrives?

Jeg startet i 2008 med å bygge portefølje-regnskaps- og ytelses-målings-systemer for bankplattformer. Ett av disse prosjektene var en GIPS-kompatibel motor for å beregne tid-vektede avkastninger, som finansielle institusjoner i over 80 land til slutt brukte. Denne arbeidet lærte meg en lek som har formet hele min karriere. I regulert finansiell virksomhet er den farligste feilen en feil som ser riktig ut. En subtilt feil kalkulasjon blir tillitsfull, rapportert og brukt i årevis, fordi ingenting ser ut til å være feil.

Jeg så samme mønster igjen senere. Jeg fant en strukturell gap i Markov-modellen for en vidt brukte markeds-tilskrivningsmodell. Rammen ble brukt av hundre tusener av brukere, og feilen hadde overlevd i årevis fordi utdataene så rimelige ut. Når jeg flyttet inn i AI-transformasjon i finansielle tjenester, så jeg agenter gjenta dette mønsteret med mye høyere innsats. En agent produserer ikke bare en feilaktig resultat. Den tar handling basert på det.

Gapet som overbeviste meg om å skrive boken er at forskning og bedrifts-utrulling bryr seg om forskjellige ting. Forskning måler evne på benchmark. Bedrifter avhenger av hvordan et system oppfører seg under usikkerhet, endring av data og adversarialt press. De fleste skrivinger om agenter stopper ved demo-stadiet. Jeg skrev Agentic AI for Engineers for ingeniøren som må sette navnet sitt på et system som skal kjøre med begrenset overvåking innen en regulert institusjon.

Boken beskriver skiftet fra automatisering til autonomi som en ny ingeniør-målsetning. Hva skiller virkelig en autonom AI-agent fra en sofistikert automatisert arbeidsflyt, og hvor er organisasjoner mest sannsynlig å forveksle de to?

Jeg gir teamene en enkel test. Kan du liste alle stier systemet kan ta før du kjører det? Hvis ja, har du automatisering. Det kan være svært sofistikert automatisering med en språkmodell inne i det, men det er fortsatt automatisering. Hvis systemet bryter ned mål, velger verktøy og bestemmer rekkefølgen av handlinger på kjøretid basert på kontekst du ikke skrev, har du autonomi. Forskjellen har ingenting å gjøre med hvilken modell du bruker. Det kommer ned til hvor beslutningene tas.

Organisasjoner forveksler de to i begge retninger, men bare en retning er dyrekjøpt. Å kalle en skrevet LLM-arbeidsflyt agentic er mest et markedsføringsproblem. Den kostbare feilen er omvendt. Teamene deployer genuint autonome beslutningsprosesser under styring som var designet for deterministisk automatisering. Deres testing antar gjentakelighet. Deres overvåking antar kjente feil-mønster. Deres audit-spor antar at det finnes en sporbar regel bak hver handling. Ingen av disse antagelsene holder for en agent.

Dette er det målsetnings-skiftet jeg argumenterer for i boken. Med automatisering er hovedspørsmålet om systemet utførte korrekt. Med autonomi blir spørsmålet om systemet bestemte korrekt. Å svare på det krever annen instrumentering, annen evaluering-metode og en annen nivå av forsiktighet.

Mange agenter AI-systemer utfører imponerende i demonstrasjoner, men sliter når de blir utsatt for virkelige brukere, endring av data og uforutsigbare verktøy. Hvilke komponenter bør være obligatoriske i en produksjonsklar agent-arkitektur?

Den ærlige svaret er at produksjon trenger alt det en demo lar deg hoppe over. En demonstrasjon fungerer fordi noen kontrollerte miljøet. Produksjon tar den kontrollen vekk.

I boken beskriver jeg en syv-lags referanse-arkitektur, men disse er komponentene jeg anser som obligatoriske. Verktøy-kontrakter med typede inndata og eksplisitte tillatelser, så agentens rekkevidde begrenses av design snarere enn av håp. Tilstands-styring som overlever avbrudd og feil. Strukturert feil-håndtering med definerte eskalasjons-veier. En evaluering-ramme som kjører kontinuerlig, ikke bare en gang før lansering. Og en audit-spor som registrerer beslutninger og begrunnelsen bak dem, ikke bare handlinger tatt.

Komponenten teamene hopper over mest ofte er runtime-verifisering. Dette er et lag som sjekker hver handling mot agentens uttalte mål og de retningslinjer som gjelder for det. Standard-infrastruktur forteller deg om en kall lykkes. Verifisering spør om kallet skulle være gjort i det hele tatt. Det beviser aldri sin verdi i en demo, fordi ingenting i en demo trenger å bli fanget. I produksjon er det det første du kommer til å ønske deg.

Boken din dekker sikkerhet, justering, tilbakemeldings-løkker, testing, feil-søking, evaluering og utrulling. Hvordan bør ingeniør-team kombinere disse elementene til en kontinuerlig sikkerhets-prosess i stedet for å behandle sikkerhet som en siste for-utrullings-gjennomgang?

En siste gjennomgang hviler på antagelsen at systemet du gjennomgikk er systemet som skal kjøre. For agenter AI, feiler den antagelsen på tre måter. De underliggende modellene oppdateres. Verktøyene og API-ene agenten avhenger av, endres. Og data og miljøet agenten opererer i, endrer seg kontinuerlig. En engangs sikkerhets-gjennomgang beskriver et system som ikke lenger eksisterer noen måneder senere.

Kontinuerlig sikkerhet betyr å lukke løkken. Atferdsevalueringer kjører i CI (kontinuerlig integrasjon) på samme måte som enhets-tester, og de blokkerer hver endring til promter, verktøy og modeller. Runtime-overvåking matet produksjons-spor tilbake til evaluering-settene. Jeg beskriver fire overvåkings-mønster i boken, fordi ingen enkelt mønster dekker hele feil-overflaten. Hver hendelse produserer en ny sjekk, på samme måte som hver feil skal produsere en regressionstest. Og adversarial testing kjører på en fast skedulering i stedet for bare en gang før lansering.

Den organisatoriske siden betyr like mye som den tekniske siden. Sikkerhet kan ikke være et eget team som dukker opp på slutten med en sjekkeliste. Ingeniørene som bygger agenten skal eie dens evaluering-sett, dens invarianter og dens eskalasjons-design, fordi de vet bedre enn noen andre hvor systemets dømmekraft er svakest.

Du har betonet semantisk overvåking av agent-verktøy-kall. Hva avslører semantisk overvåking som konvensjonelle logger og overvåkings-verktøy ikke kan, og hvordan kan det detektere når en agent er teknisk fungerende, men forfølger det feilaktige målet?

Konvensjonell overvåkning svarer på ett spørsmål: lykkes kallet? Det dekker status-koder, skjema, latency, feil-rater. Det kan ikke svare på spørsmålet som betyr mest for agenter, som er om kallet skulle skje. Et verktøy-kall kan være teknisk perfekt og likevel være feil handling. Riktig format, gyldige legitimasjoner, suksessfult svar, feil ting å gjøre.

Semantisk overvåking evaluerer hver handling mot agentens uttalte mål og de retningslinjer som gjelder for det. I boken beskriver jeg dette som å definere semantiske invarianter over agent-verktøy-kall. Disse er egenskaper som må holde uansett hvilken vei agenten tar. En agent som forsker på en kundes sak skal aldri få tilgang til poster utenfor den saken. En agent bør merke en diskrepans over en viss terskel, aldri løse den på egen hånd. Når en invariant blir brutt, fanger du problemet i øyeblikket handlingen skjer, i stedet for i en kvartalsvis gjennomgang.

Dette er også hvordan du detekterer mål-drift, som jeg anser som den definerte feil for agenter. Mål-drift ser ut som en agent som fullfører hver enkelt steg korrekt ifølge loggene, mens den stille arbeider mot det feilaktige målet. Det viser aldri i en logg, fordi ingenting feiler. Semantisk overvåking behandler intensjon som noe du måler direkte, og intensjon er der agenter går galt.

Når en agent møter tvetydige instruksjoner, motstridende retningslinjer, utilgjengelige verktøy eller utilstrekkelig tillit, hva bør strukturert feil-håndtering se ut som? Hvordan kan utviklere sikre at systemet pauser, eskalerer eller gjenoppretter i stedet for å improvisere?

Problemets å designe mot er at de fleste agenter bare har én måte å avslutte en oppgave på, som er å produsere et svar. Når instruksjoner er tvetydige eller retningslinjer motstridende, improviserer agenten. Ikke fordi modellen er uforsiktig, men fordi improvisering er den eneste atferd arkitekturen tillater. Strukturert feil-håndtering betyr å gi systemet bedre alternativer og gjøre dem lettere å nå enn et oppdiktet svar.

I praksis betyr det å definere typede feil-tilstander: tvetydig instruks, motstridende retningslinje, utilgjengelig verktøy, utilstrekkelig tillit. Hver enkelt kartlegger til en bestemt atferd. Spør en klargjørende spørsmål. Overfør til en menneske med full kontekst vedlagt. Gå ned til kun-lesing-operasjon. Prøv igjen innenfor strengere grenser. Eller stopp. Tillits-nivå bør matche risikoen for den spesifikke handlingen. Standarden for å lage en intern oppsummering og standarden for å berøre en kunde-konto bør aldri være samme tall.

To praksiser gjør dette reelt. Først, design eskalasjons-veien før den lykkes-veien. Hvis en menneske skal motta overføringen, bestem hva slags kontekst de får og hva slags myndighet de har før du skriver den første promten. Second, test feil på samme måte som du tester funksjoner. Injiser tvetydige instruksjoner. Deaktiver verktøy i staging. Mat agenten motstridende retningslinjer. Et system som aldri har øvet feil, vil handle uten veiledning første gang det skjer i produksjon.

Finansielle institusjoner må balansere eksperimentering med strenge krav rundt personvern, overvåkning, modell-risiko og regulatorisk overholdelse. Hvor bør menneskelig godkjenning forbli obligatorisk, og hvor kan agenter trygt få større operasjonell autonomi?

Min regel er at menneskelig godkjenning bør forbli obligatorisk for enhver handling som er irreversibel, som flytter penger eller påvirker en pasients utfall, som involverer kunde-kommunikasjon som bærer regulatorisk vekt, som matar regulatorisk rapportering, eller som endrer agentens egne verktøy, retningslinjer eller tillatelser. Agenter kan trygt ta på seg mer autonomi i les og forstå-arbeid: forskning, innhenting, dokument-analyse, triage, utkast og sammenstilling som markerer diskrepanser for menneskelig gjennomgang i stedet for å løse dem.

Den vanlige feilen er å kreve menneskelig godkjenning på hvert steg. Det gjør ikke systemet tryggere. Det rekonstruerer det manuelle prosessen med ekstra steg og trener gjennomgangere til å godkjenne uten å se nærmere på. Godkjenninger hører hjemme på virkelige beslutnings-punkter. Det bør være få av dem, og hver bør være bemannet med noen som har faktisk myndighet til å si nei.

Den andre prinsippet er at autonomi bør være fortjent snarere enn gitt. Start smalt. Utvid når systemet beviser seg under overvåking. Behold beviset. I modell-risiko-termer bør kontroll-miljøet ditt la deg vise en regulator ikke bare hva agenten gjorde, men hvorfor du var berettiget til å gi det den niveauet av uavhengighet. Denne rekorden er den virkelige lisensen til å operere.

Gjennom ditt arbeid på kunstig intelligens-sikkerhet og standarder, hjelper du med å definere regler for systemer hvis evner kontinuerlig endres. Hvilke sikkerhets-foranstaltninger kan realistisk standardiseres i dag, og hvilke områder forblir for avhengig av kontekst, bransje eller brukstilfelle?

De sikkerhets-foranstaltningene vi kan standardisere i dag er strukturelle. De krever at visse kontroller eksisterer, er dokumentert og kan inspekteres. Dokumentert evne- og tillatelses-grensene for autonome systemer. Definert menneskelig overvåking og eskalasjons-mekanismer. Hendelse-deteksjon og rapporterings-forpliktelser. Evaluering-metoder og bevis-krav. Tydelig ansvar over hele system-livssyklusen, så når noe går galt, er svaret på hvem som er ansvarlig aldri bare AI-en. Disse kan standardiseres fordi de angår om kontrollene eksisterer og hvordan gode de er, ikke de spesifikke verdiene de tar.

Hva vi ikke kan standardisere ennå er innstillingene selv. Spesifikke tillits-nivåer, skade-taksonomier og passende autonomi-nivåer avhenger sterkt av kontekst. Den akseptable feil-toleransen for en markedsførings-innhold-agent og for et system som berører kliniske eller finansielle beslutninger er ikke to punkter på samme skala. De hører hjemme i forskjellige regimer, formet av domenet, jurisdiksjonen og hvem som bærer skaden når noe feiler.

Finansielle kontroller er en nyttig modell her. Revisjons-krav er standardisert globalt, men materielitet blir alltid dømt i kontekst. Standarder som respekterer den splitten, tenderer til å bli adoptert. Standarder som prøver å diktere kontekst-avhengige verdier, tenderer til å bli ignorert, og en sikkerhets-standard som ingen følger, beskytter ingen.

Ditt nylige forskning har utforsket flerkulturell og adversarial robusthet i AI-sikkerhets-evaluering. Hvilke typer modell-feil er sannsynlig å bli oversett av vestlige-sentriske eller globalt-gjennomsnittlige benchmark, og hvordan bør bedrifter evaluere systemer ment for flerkulturell utrulling?

Å se bare på gjennomsnittlige benchmark kan overse feilene som betyr mest. En modell kan postere en sterk overordnet sikkerhets-score mens den feiler dårlig for et spesifikt språk, dialekt eller kulturell kontekst, fordi disse feilene forsvinner i gjennomsnittet. Vestlige-sentriske evaluering legger til en annen blind-plekk. Det overseer skader som er kulturelt spesifikke, som idiom, gester og religiøse eller regionale kontekster hvor samme utgang er harmløs i en kultur og skadelig i en annen. Det overseer også kode-omskifting, translitterasjon og ikke-vestlige navn og enheter. Det er en adversarial vinkel også. Angripere målretter ikke din gjennomsnittlige ytelse. De finner din svakeste del, og for de fleste modeller er den svakeste delen et lav-resurs-språk eller en under-evaluert kulturell kontekst.

Dette er hva som trakk meg inn i å bidra til flerkulturell AI-sikkerhets-benchmark-forskning. Kjerne-funnene er enkle. Å dømme sikkerhet over kulturer krever evaluering-data og menneskelig dømmekraft trukket fra disse kulturene. Du kan ikke vurdere skade fra utenfor konteksten det skjer i.

For bedrifter foreslår jeg tre regler. Evaluér hver segment du betjener, og aksepter aldri et gjennomsnitt som bevis. Bygg evaluering-sett fra dine faktiske kunde-populasjoner. Kjør adversarial testing på språkene dine kunder bruker. Hvis du betjener kunder i førti land og evaluér bare på engelsk, har du målt systemet ditt for noen andres utrulling.

Du holder også et tildelt United States Patent and Trademark Office-patent i anvendt AI. Hva var problemet du forsøkte å løse, hva lærte prosessen deg om å omdanne AI-forskning til praktisk innovasjon, og hvilket uløst agentic AI-utfordring er du mest interessert i å løse neste?

Patentet som nylig ble godkjent, løser et skala- og konsistens-problem i finansielle tjenester-kvalitets-gjennomgang — konvensjonell kvalitets-gjennomgang er manuell, så menneskelige gjennomgangere kan bare prøve en brøkdel av kallene, og deres vurderinger varierer fra person til person. Min tilnærming ruter hver kvalitets- og overholdelses-spørsmål til metoden best egnet til å svare på det, med hver beslutning logget og sporbar for gjennomgang.

Du kan se samme temaer jeg har beskrevet gjennom hele dette intervjuet. Rute hver oppgave til det minst kraftfulle verktøyet som kan gjøre det bra. Hold mennesker i løkken hvor dømmekraft betyr noe. Og gjør hver automatisert beslutning sporbar, fordi i en regulert institusjon er et svar uten bevis ikke et svar.

Hva patent-prosessen lærte meg, er at disiplinen ligger i detaljene. Du kan ikke patenterer en vag ide. Du må vise eksakt hva din metode gjør annerledes, og eksakt hvor den gjelder. Denne presisjonen gjorde den underliggende arbeidet bedre.

Den uløste utfordringen jeg bryr meg mest om nå, er runtime-verifisering for multi-agent-systemer. Å definere semantiske invarianter for en enkelt agent er håndterbart. Jeg vet, fordi vi gjør det i produksjon. Når agenter delesgerer arbeid til andre agenter, blir atferden emergent, og feilene flytter inn i hånd-overskrittene. En instruksjon blir litt omfortolket på hvert steg. En retningslinje gjelder for en agent, men ikke for agenten den rekrutterer. Å verifisere interaksjonen mellom agenter, ikke bare handlingene til hver enkelt, er der jeg forventer den neste generasjonen av stille feil kommer til å dukke opp. Det er problemet jeg vil jobbe med neste.

Takk for det flotte intervjuet, lesere kan også bestille hennes bok Agentic AI for Engineers.