Dhivya Nagasubramanian, VP för AI-omvandling och innovation – Intervjuserie

Dhivya Nagasubramanian är VP för AI-omvandling och innovation på en stor amerikansk finansiell institution, där hon leder design, distribution och styrning av produktionsagenter för artificiell intelligens. Hon är författare till Agentic AI för ingenjörer (Apress/Springer Nature), en praktisk guide för att bygga autonoma AI-system som kan lita på i produktion. Sedan dess release har boken registrerat mer än 6 000 institutionella tillgångar på SpringerLink, innehav i över 260 bibliotek världen över och antagande på universitet. Hon är en USPTO-beviljad patentinnehavare inom tillämpad maskinlärning. Hennes forskningsintressen inkluderar att bygga applikationer som är resistenta mot adversariala fängelseattacker och bidra till bredare industriella ansträngningar för att utveckla bättre modeller för multikulturell säkerhet och säkerhet. Hon är en eftertraktad experttalare och panelist på flera bransch- och akademiska konferenser.

Er karriär har utvecklats från företagskonsult och data scientist till att leda AI-omvandling inom finansiella tjänster. Hur har dessa erfarenheter format Agentic AI för ingenjörer, och vilken återkommande klyfta mellan AI-forskning och företagsdistribution övertygade er om att den här boken behövde skrivas?

Jag började 2008 med att bygga system för portföljredovisning och prestandamätning för bankplattformar. Ett av dessa projekt var en GIPS-kompatibel motor för beräkning av tidsviktade avkastningar, som finanseinstitutioner i mer än 80 länder slutligen använde. Detta arbete lärde mig en läxa som har format hela min karriär. I reglerad finans är den farligaste felet ett felaktigt nummer som ser rätt ut. Ett subtilt felaktigt beräkning får förtroende, rapporteras och ageras på i år, eftersom ingenting verkar vara trasigt.

Jag såg samma mönster igen senare. Jag fann en strukturell klyfta i Markov-modellen för en allmänt använd marknadsattribueringsmodell. Ramverket användes av hundratusentals användare, och felet hade överlevt i år för en enda anledning: utdata såg rimliga ut. När jag flyttade in i AI-omvandling inom finansiella tjänster, såg jag agenter upprepa detta mönster med mycket högre insatser. En agent producerar inte bara ett felaktigt resultat. Den tar också åtgärder baserat på det.

Klyftan som övertygade mig om att skriva boken är att forskning och företagsdistribution bryr sig om olika saker. Forskning mäter förmåga på benchmark. Företag beror på hur ett system beter sig under tvetydighet, förändrade data och adversarial tryck. De flesta skrifter om agenter slutar vid demo-stadiet. Jag skrev Agentic AI för ingenjörer för ingenjören som måste sätta sitt namn på ett system som kommer att köras med begränsad tillsyn inom en reglerad institution.

Boken beskriver övergången från automation till autonomi som en ny ingenjörsmässig mentalitet. Vad skiljer egentligen en autonom AI-agent från en sofistikerad automatiserad arbetsflöde, och var är organisationer mest benägna att förväxla de två?

Jag ger team en enkel test. Kan du lista alla vägar systemet kan ta innan du kör det? Om ja, har du automation. Det kan vara mycket sofistikerad automation med en språkmodell inuti, men det är fortfarande automation. Om systemet bryter ned mål, väljer verktyg och bestämmer ordningen på åtgärder vid körning baserat på sammanhang som du inte skrev, har du autonomi. Skillnaden har ingenting att göra med vilken modell du använder. Det handlar om var besluten fattas.

Organisationer förväxlar de två i båda riktningarna, men bara en riktning är dyrt. Att kalla en skriptad LLM-arbetsflöde för agentic är mest ett marknadsföringsproblem. Det dyra misstaget är det omvända. Team distribuerar genuint autonomt beslutsfattande under styrning som designades för deterministisk automation. Deras test antar återupprepningsbarhet. Deras övervakning antar kända felmönster. Deras revisionslogg antar att det finns en spårbar regel bakom varje åtgärd. Inga av dessa antaganden gäller för en agent.

Det är den mentalitetsförändring jag argumenterar för i boken. Med automation är den viktigaste frågan om systemet utfördes korrekt. Med autonomi blir frågan om systemet fattade rätt beslut. Att svara på det kräver annan instrumentering, annorlunda utvärderingsmetoder och en annan nivå av försiktighet.

Många agenter presterar imponerande i demonstrationer men kämpar när de utsätts för riktiga användare, förändrade data och oförutsägbara verktyg. Vilka komponenter bör anses vara obligatoriska i en produktionsklar agentarkitektur?

Det ärliga svaret är att produktion behöver allt som en demo låter er hoppa över. En demonstration fungerar för att någon kontrollerade miljön. Produktion tar bort den kontrollen.

I boken beskriver jag en sju-lagers referensarkitektur, men dessa är de komponenter jag anser vara obligatoriska. Verktygsavtal med typerade indata och explicita behörigheter, så att agentens räckvidd begränsas av design snarare än av hopp. Tillståndshantering som överlever avbrott och fel. Strukturerad felhantering med definierade eskalationsvägar. En utvärderingsharnesk som körs kontinuerligt, inte en gång före lansering. Och en revisionslogg som registrerar beslut och resonemanget bakom dem, inte bara åtgärderna som vidtogs.

Komponenten som team hoppar över oftast är runtime-verifiering. Detta är ett lager som kontrollerar varje åtgärd mot agentens uttalade mål och de policys som gäller för det. Standardinfrastruktur berättar för er om ett anrop lyckades. Verifiering frågar om anropet borde ha gjorts över huvud taget. Det bevisar aldrig sitt värde i en demo, för att ingenting behöver fångas. I produktion är det det första du kommer att önska att du hade.

Hur bör utvecklingsteam kombinera dessa element till en kontinuerlig säkerhetsprocess snarare än att behandla säkerhet som en slutgiltig för-lanseringsgranskning?

En slutgranskning vilar på antagandet att systemet du granskade är systemet som kommer att köras. För agenter för artificiell intelligens misslyckas det antagandet på tre sätt. De underliggande modellerna uppdateras. Verktygen och API:erna som agenten är beroende av ändras. Och data och miljön som agenten opererar i förändras kontinuerligt. En engångs säkerhetsgranskning beskriver ett system som inte längre existerar några månader senare.

Kontinuerlig säkerhet innebär att stänga loopen. Beteendeutvärderingar som körs i CI (kontinuerlig integration) på samma sätt som enhetstester, och de blockerar varje ändring av prompt, verktyg och modeller. Runtime-övervakning matar produktionsspår tillbaka till utvärderingsuppsättningarna. Jag beskriver fyra övervakningsmönster i boken, eftersom ingen enskild mönster täcker hela felytan. Varje incident producerar en ny kontroll, på samma sätt som varje bugg borde producera en regressions-test. Och adversarial testning körs på ett regelbundet schema istället för en gång före lansering.

Den organisatoriska sidan är lika viktig som den tekniska sidan. Säkerhet kan inte vara ett separat team som dyker upp i slutet med en checklista. Utvecklarna som bygger agenten bör äga dess utvärderingssviter, dess invariant och dess eskalationsdesign, eftersom de vet bättre än någon annan var systemets omdöme är svagast.

Ni har betonat semantisk övervakning av agentens verktygsanrop. Vad avslöjar semantisk övervakning som konventionella loggar och övervakningsverktyg inte kan, och hur kan det upptäcka när en agent är tekniskt fungerande men följer fel mål?

Konventionell övervakbarhet svarar på en fråga: lyckades anropet? Det täcker statuskoder, scheman, latens och felrater. Det kan inte svara på den viktigaste frågan för agenter, som är om anropet borde ha hänt. Ett verktygsanrop kan vara tekniskt perfekt och fortfarande vara fel åtgärd. Rätt format, giltiga autentiseringsuppgifter, lyckat svar, fel sak att göra.

Semantisk övervakning utvärderar varje åtgärd mot agentens uttalade mål och de policys som gäller för det. I boken beskriver jag detta som att definiera semantiska invarianter över agentens verktygsanrop. Dessa är egenskaper som måste gälla oavsett vilken väg agenten tar. En agent som undersöker en kunds ärende bör aldrig komma åt register utanför det ärendet. En agent bör flagga en diskrepans över en viss tröskel, aldrig lösa den på egen hand. När en invariant bryts, fångar du problemet i ögonblicket av åtgärd istället för i en kvartalsvis granskning.

Detta är också hur du upptäcker målförskjutning, som jag anser är det definierande felet för agenter. Målförskjutning ser ut som en agent som slutför varje steg korrekt enligt loggarna medan den tyst arbetar mot fel mål. Det visas aldrig i en logg, eftersom ingenting misslyckas. Semantisk övervakning behandlar avsikt som något du mäter direkt, och avsikt är där agenter går fel.

När en agent möter tvetydiga instruktioner, motsägelsefulla policys, otillgängliga verktyg eller otillräcklig tillförlitlighet, vad bör strukturerad felhantering se ut? Hur kan utvecklare säkerställa att systemet pausar, eskalerar eller återhämtar sig istället för att improvisera?

Problemet att utforma mot är att de flesta agenter har bara ett sätt att slutföra en uppgift, vilket är att producera ett svar. När instruktioner är tvetydiga eller policys motsäger varandra, improviserar agenten. Inte för att modellen är vårdslös, utan för att improvisera är den enda beteendet som arkitekturen tillåter. Strukturerad felhantering innebär att ge systemet bättre alternativ och göra dem lättare att nå än ett uppfunnet svar.

I praktiken innebär det att vägran och eskalering designas och testas med samma omsorg som framgång. Jag rekommenderar att definiera typerade feltilstånd: tvetydig instruktion, motsägelsefull policy, otillgängligt verktyg, otillräcklig tillförlitlighet. Var och en av dem motsvarar ett specifikt beteende. Ställ en förtydligande fråga. Överför till en människa med fullständig sammanhang bifogad. Gå till skrivskyddad drift. Försök igen inom snävare gränser. Eller stoppa. Tillförlitlighetströsklar bör matcha risken för den specifika åtgärden. Tröskeln för att skriva en intern sammanfattning och tröskeln för att röra en kundkonto bör aldrig vara samma nummer.

Två metoder gör detta verkligt. Först, designa eskalationsvägen innan den lyckade vägen. Om en människa kommer att ta emot överföringen, bestäm vilket sammanhang de får och vilken auktoritet de har innan du skriver den första prompten. För det andra, testa fel på samma sätt som du testar funktioner. Mata in tvetydiga instruktioner. Inaktivera verktyg i staging. Mata agenten med motsägelsefulla policys. Ett system som aldrig har övat på att misslyckas kommer att agera utan vägledning första gången det händer i produktion.

Finansiella institutioner måste balansera experiment med strikta krav kring sekretess, granskbarhet, modellrisk och regelefterlevnad. Var bör mänskligt godkännande förbli obligatoriskt, och var kan agenter säkert ges större operativ autonomi?

Min regel är att mänskligt godkännande bör förbli obligatoriskt för varje åtgärd som är irreversibel, som flyttar pengar eller påverkar en patients utfall, som involverar kundkommunikation med regulatorisk vikt, som matar regulatorisk rapportering eller som ändrar agentens egna verktyg, policys eller behörigheter. Agenter kan säkert ta på sig mer autonomi i läs- och resonemangsarbete: forskning, återvinning, dokumentanalys, triage, utkast och försoningar som flaggar diskrepanser för mänsklig granskning istället för att lösa dem.

Det vanliga misstaget är att kräva mänskligt godkännande vid varje steg. Det gör inte systemet säkrare. Det återskapar den manuella processen med extra steg och tränar granskare att stämpla. Godkännanden hör hemma vid riktiga beslutsfattandepunkter. Det bör finnas få av dem, och var och en bör bemannas av någon med verklig auktoritet att säga nej.

Den andra principen är att autonomi bör tjänas in snarare än beviljas. Börja smalt. Utöka när systemet visar sig under övervakning. Behåll bevisen. I modellrisktermer bör er kontrollmiljö låta er visa en regulator inte bara vad agenten gjorde, utan varför ni var berättigade att ge det den nivån av oberoende. Den posten är den riktiga licensen att operera.

Genom ert arbete med artificiell intelligens-säkerhets- och standarder hjälper ni till att definiera regler för system vars förmågor fortsätter att förändras. Vilka säkerhetsåtgärder kan realistiskt standardiseras idag, och vilka områden förblir för beroende av sammanhang, bransch eller användningsfall?

De säkerhetsåtgärder vi kan standardisera idag är strukturella. De kräver att vissa kontroller existerar, dokumenteras och kan inspekteras. Dokumenterad kapacitet och behörighetsgränser för autonoma system. Definierad mänsklig tillsyn och eskalationsmekanismer. Incidentdetektering och rapporteringskrav. Utvärderingsmetoder och beviskrav. Tydligt ansvar över hela systemlivscykeln, så att när något går fel, är svaret på vem som är ansvarig aldrig bara AI. Dessa kan standardiseras eftersom de berör om kontrollerna existerar och hur bra de är, inte de specifika värdena de tar.

Vad vi inte kan standardisera ännu är inställningarna själva. Specifika förtroendetrösklar, skadetaxonomier och lämpliga autonomnivåer beror starkt på sammanhang. Den acceptabla fel toleransen för en marknadsinnehållsagent och för ett system som rör kliniska eller finansiella beslut är inte två punkter på samma skala. De tillhör olika regimer, formade av domänen, jurisdiktionen och vem som lider skada när något misslyckas.

Finansiella kontroller är en användbar modell här. Revisionskrav är globalt standardiserade, men materialitet bedöms alltid i sammanhang. Standarder som respekterar den uppdelningen tenderar att antas. Standarder som försöker diktera sammanhangsberoende värden tenderar att ignoreras, och en säkerhetsstandard som ingen följer skyddar ingen.

Er senaste forskning har utforskat multikulturell och adversarial robusthet i AI-säkerhetsutvärdering. Vilka typer av modellfel är troligen att missas av västerländska eller globalt genomsnittliga benchmark, och hur bör företag utvärdera system som avses för multikulturell distribution?

Att bara titta på genomsnittliga benchmark kan missa de fel som är viktigast. En modell kan posta en stark övergripande säkerhetspoäng medan den misslyckas illa för ett specifikt språk, dialekt eller kulturellt sammanhang, eftersom dessa fel försvinner i genomsnittet. Västerländsk utvärdering lägger till en annan blind fläck. Det missar skador som är kulturellt specifika, såsom idiom, gester och religiösa eller regionala sammanhang där samma utdata är ofarligt i en kultur och skadligt i en annan. Det testar också under-translitterering, kodväxling och icke-västerländska namn och enheter. Det finns också en adversarial vinkel. Angripare riktar sig inte mot er genomsnittliga prestanda. De hittar er svagaste skiva, och för de flesta modeller är den svagaste skivan ett språk med låg resurs eller ett kulturellt sammanhang som inte utvärderats tillräckligt.

Detta är vad som drog mig in i att bidra till multikulturell AI-säkerhetsbenchmarkforskning. Den grundläggande upptäckten är enkel. Att bedöma säkerhet över kulturer kräver utvärderingsdata och mänsklig bedömning som hämtas från dessa kulturer. Du kan inte bedöma skada från utsidan av sammanhanget i vilket den inträffar.

För företag föreslår jag tre regler. Utvärdera varje segment ni betjänar, och acceptera aldrig ett genomsnitt som bevis. Bygg utvärderingsuppsättningar från er faktiska kundpopulationer. Kör adversarial testning på de språk era kunder använder. Om ni betjänar kunder i 40 länder och utvärderar endast på engelska, har ni mätt er system för någon annans distribution.

Ni har också en beviljad USA-patent i tillämpad AI. Vilket problem försökte ni lösa, vad lärde processen er om att omvandla AI-forskning till praktisk innovation, och vilken olöst agentic AI-utmaning är ni mest intresserade av att ta itu med nästa?

Patentet som nyligen godkändes behandlar ett skalförhållnings- och konsekvensproblem i finansiella tjänster – konventionell kvalitetsgranskning är manuell, så mänskliga granskare kan bara sampla en bråkdel av anrop, och deras bedömningar varierar från person till person. Min metod dirigerar varje kvalitets- och efterlevnadsfråga till metoden som är bäst lämpad att svara på den, med varje beslut loggat och spårbar för granskning.

Du kan se samma teman jag har beskrivit under hela den här intervjun. Dirigera varje uppgift till det minst kraftfulla verktyget som kan göra det bra. Håll människor i loopen där omdöme är viktigt. Och gör varje automatiserat beslut spårbar, eftersom i en reglerad institution är ett svar utan bevis inte ett svar.

Det som patentprocessen lärde mig är att disciplinen ligger i detaljerna. Du kan inte patentera en vag idé. Du måste visa exakt vad din metod gör annorlunda, och exakt var den tillämpas. Den tvingade precisionen gjorde det underliggande arbetet bättre.

Den olösta utmaningen jag bryr mig mest om nu är runtime-verifiering för multi-agentsystem. Att definiera semantiska invarianter för en enskild agent är hanterbart. Jag vet, för vi gör det i produktion. När agenter delegerar arbete till andra agenter blir beteendet emergent, och felen flyttar in i handoffen. En instruktion tolkas lite annorlunda vid varje steg. En policy gäller för en agent men inte för den agent som rekryteras. Att verifiera interaktionen mellan agenter, inte bara deras åtgärder, är där jag förväntar mig att nästa generation av tysta fel kommer att dyka upp. Det är det problem jag vill arbeta med nästa.

Tack för den underbara intervjun, läsare kan också beställa hennes bok Agentic AI för ingenjörer.