Dhivya Nagasubramanian, viceprezidentka pro AI transformaci a inovace – série rozhovorů

Dhivya Nagasubramanian je VP of AI Transformation and Innovation v jedné z největších amerických finančních institucí, kde vede návrh, nasazení a správu produkčních agentic AI systémů. Je autorkou knihy Agentic AI for Engineers (Apress/Springer Nature), praktického průvodce pro stavbu autonomních AI systémů, které lze důvěřovat v produkci. Od jejího vydání zaznamenala kniha více než 6 000 institucionálních přístupů na SpringerLink, držitelství ve více než 260 knihovnách po celém světě a přijetí na univerzitách. Je držitelkou patentu uděleného Úřadem pro patenty a ochranné známky USA v oblasti aplikovaného strojového učení. Jejími výzkumnými zájmy jsou stavba aplikací, které jsou odolné vůči adversariálním útokům, a přispívání k širším průmyslovým snahám o vývoj lepších modelů pro multikulturní bezpečnost a bezpečnost. Je vyhledávanou odbornicí a panelistkou na několika průmyslových a akademických konferencích.

Vaše kariéra se vyvinula z podnikového poradenství a datové vědy do vedení AI transformace ve finančních službách. Jak tyto zkušenosti utvořily Agentic AI for Engineers, a jaká byla opakující se mezera mezi AI výzkumem a podnikovým nasazením, která vás přesvědčila, že tato kniha potřebuje být napsána?

Začala jsem v roce 2008 budováním systémů pro portfolio účetnictví a měření výkonu pro bankovní platformy. Jedním z těchto projektů byl GIPS-kompatibilní motor pro výpočet časově vážených výnosů, který nakonec použily finanční instituce ve více než 80 zemích. Ta práce mě naučila jednu lekci, která utvořila mou celou kariéru. V regulovaném financování je nebezpečnější selhání špatné číslo, které vypadá správně. Subtilně nesprávný výpočet se důvěřuje, hlásí a používá po několik let, protože nic nezobrazuje chybu.

Viděla jsem stejný vzorec znovu později. Našla jsem strukturální mezeru v Markovově modelu široce používaného marketingového modelu atribuce. Rámec byl použit stovkami tisíc uživatelů a chyba přežila po několik let z jednoho důvodu: výstupy vypadaly rozumně. Když jsem se přesunula do AI transformace ve finančních službách, sledovala jsem agentic systémy, které opakovaly tento vzorec s mnohem vyššími sázkami. Agent neonly produkuje špatný výsledek. Činí akci na základě něj.

Mezera, která mě přesvědčila, že musím napsat knihu, je, že výzkum a podnikové nasazení se zajímají o různé věci. Výzkum měří schopnost na benchmarcích. Podniky závisí na tom, jak se systém chová pod ambiguitou, měnícími se daty a adversariálním tlakem. Nejvíce psaní o agentech zastavuje na demo fázi. Napsala jsem Agentic AI for Engineers pro inženýra, který musí umístit své jméno na systém, který bude běžet s omezeným dohledem uvnitř regulované instituce.

Kniha popisuje posun od automatizace k autonomii jako nový inženýrský mindset. Co skutečně odděluje autonomního AI agenta od sofistikovaného automatizovaného workflow, a kde jsou organizace nejvíce pravděpodobně zaměňují dva?

Dávám týmům jednoduchý test. Můžete-li vyjmenovat každou cestu, kterou systém může vzít předtím, než jej spustíte? Pokud ano, máte automatizaci. Může to být velmi sofistikovaná automatizace s modelem jazyka uvnitř ní, ale je to stále automatizace. Pokud systém rozkládá cíle, vybírá nástroje a rozhoduje o pořadí akcí v době běhu na základě kontextu, který jste nenapsali, máte autonomii. Rozdíl nemá nic společného s modelem, který používáte. Spočívá v tom, kde jsou rozhodnutí učiněna.

Organizace zaměňují dva způsoby, ale pouze jeden směr je drahý. Označování skriptovaného LLM workflow jako agentic je většinou marketingový problém. Nákladná chyba je opačná. Týmy nasazují skutečně autonomní rozhodování pod správou, která byla navržena pro deterministickou automatizaci. Jejich testování předpokládá opakovatelnost. Jejich monitorování předpokládá známé vzorce selhání. Jejich auditní stopa předpokládá stopovatelnou pravidlo za každé akce. Žádné z těchto předpokladů neplatí pro agenta.

To je mindsetová změna, za kterou se zasazuji v knize. S automatizací je hlavní otázka, zda systém vykonával správně. S autonomií se otázka stává, zda systém rozhodl správně. Zodpovězení této otázky vyžaduje jinou instrumentaci, jiné evaluační metody a jinou úroveň opatrnosti.

Mnohé agentic AI systémy fungují impresivně v demonstracích, ale zápasí, když jsou vystaveny skutečným uživatelům, měnícím se datům a nepředvídatelným nástrojům. Jaké komponenty by měly být považovány za povinné v architektuře agenta připraveného pro produkci?

Upřímná odpověď je, že produkce potřebuje všechno, co demo umožňuje přeskočit. Demonstrační verze funguje, protože někdo ovládal prostředí. Produkce odebere tuto kontrolu.

V knize popisuji sedmistupňovou referenční architekturu, ale tyto jsou komponenty, které považuji za povinné. Smluvní nástroje s typovanými vstupy a explicitními oprávněními, aby dosah agenta byl omezen designem, nikoli nadějí. Správa stavu, která přežije přerušení a selhání. Strukturované zpracování selhání s definovanými eskalačními cestami. Evaluační harness, který běží nepřetržitě, nikoli jednou před spuštěním. A auditní stopa, která zaznamenává rozhodnutí a důvody, proč k nim došlo, nikoli pouze akce, které byly provedeny.

Komponenta, kterou týmy nejčastěji přeskočí, je runtime verifikace. Jedná se o vrstvu, která kontroluje každou akci proti stanovenému cíli agenta a politikám, které se na něj vztahují. Standardní infrastruktura vám řekne, zda volání bylo úspěšné. Verifikace se ptá, zda volání mělo být provedeno vůbec. Nikdy neprokáže svou hodnotu v demo verzi, protože nic v demo verzi nepotřebuje být chyceno. V produkci je to první věc, kterou budete chtít mít.

Vaše kniha pokrývá bezpečnost, zarovnání, zpětné vazby, testování, ladění, evaluaci a nasazení. Jak by měly inženýrské týmy kombinovat tyto prvky do kontinuálního procesu zajištění, místo aby považovaly bezpečnost za finální předspušťovací kontrolu?

Konečná kontrola spočívá na předpokladu, že systém, který jste prohlédli, je systémem, který bude běžet. Pro agentic AI tento předpoklad selhává třemi způsoby. Podkladové modely se aktualizují. Nástroje a API, na které agent závisí, se mění. A data a prostředí, ve kterém agent operuje, se neustále mění. Jednorázová bezpečnostní kontrola popisuje systém, který již několik měsíců neexistuje.

Kontinuální zajištění znamená uzavření smyčky. Behaviorální evaluace běží v CI (kontinuální integrace) stejným způsobem jako unit testy a brání každou změnu promptů, nástrojů a modelů. Runtime monitoring krmí produkční stopy zpět do evaluačních sad. Popisuji čtyři monitorovací vzorce v knize, protože žádný jeden vzorec nepokrývá celou plochu selhání. Každá incidence produkuje novou kontrolu, stejným způsobem, jako by každá chyba produkovala regresní test. A adversariální testování běží na pravidelném rozvrhu místo jednou před spuštěním.

Organizační strana má tolik co dočinění s technickou stranou. Bezpečnost nemůže být samostatným týmem, který se objeví na konci s kontrolním seznamem. Inženýři, kteří staví agenta, by měli vlastnit jeho evaluační sady, jeho invarianty a jeho eskalační návrh, protože znají lépe než kdokoli jiný, kde je systémova úsudku nej slabší.

Vy jste zdůraznili semantické monitorování agentních nástrojových volání. Co odhaluje semantické monitorování, co konvenční logy a nástroje pro pozorovatelnost nemohou, a jak může detekovat, zda je agent technicky funkční, ale sleduje špatný cíl?

Konvenční pozorovatelnost odpovídá na jednu otázku: zda volání bylo úspěšné. Pokrývá stavové kódy, schémata, latenci a míru chyb. Nemůže odpovědět na otázku, která je pro agenty nejdůležitější, zda volání mělo nastat. Nástrojové volání může být technicky perfektní a přesto být špatnou akcí. Správný formát, platná pověření, úspěšná odpověď, špatná věc udělat.

Semantické monitorování vyhodnocuje každou akci proti stanovenému cíli agenta a politikám, které se na něj vztahují. V knize popisuji toto jako definici semantických invariantů nad agentními nástrojovými voláními. Tyto jsou vlastnosti, které musí platit bez ohledu na cestu, kterou agent vezme. Agent, který zkoumá jeden zákaznický případ, by nikdy neměl přistupovat k záznamům mimo tento případ. Agent by měl označit nesrovnalost nad určitou hranicí, nikdy ji sám nevyřešit. Když je invariant porušen, chytíte problém v okamžiku akce místo v čtvrtletní auditorské kontrole.

To je také způsob, jak detekovat drift cíle, který považuji za definující selhání agentic systémů. Drift cíle vypadá jako agent, který dokončí každou akci správně podle logů, zatímco tiše pracuje na špatném cíli. Nikdy se neobjeví v logu, protože nic se nezdařilo. Semantické monitorování zachází s úmyslem jako s něčím, co se měří přímo, a úmysl je tam, kde agenci selhávají.

Když agent narazí na nejednoznačné instrukce, konfliktní politiky, nedostupné nástroje nebo nedostatečnou důvěru, co by mělo vypadat strukturované zpracování selhání? Jak mohou vývojáři zajistit, aby systém pozastavil, eskaloval nebo se zotavil místo improvizace?

Problém, proti kterému je třeba navrhnout, je, že většina agentů má pouze jednu cestu, jak ukončit úkol, a to je vyprodukovat odpověď. Když jsou instrukce nejednoznačné nebo politiky jsou v konfliktu, agent improvizuje. Ne proto, že model je bezohledný, ale protože improvizace je jediné chování, které architektura umožňuje. Strukturované zpracování selhání znamená dát systému lepší možnosti a učinit je snazšími než vymyšlená odpověď.

V praxi to znamená, že odmítnutí a eskalace jsou navrženy a testovány se stejnou péčí jako úspěch. Doporučuji definovat typované stavy selhání: nejednoznačné instrukce, konfliktní politika, nedostupný nástroj, nedostatečná důvěra. Každý z nich mapuje na specifické chování. Zeptejte se na objasňující otázku. Předejte lidem s plným kontextem. Přepněte na pouze čtecí operaci. Opakujte v rámci užších limitů. Nebo zastavte. Prahové hodnoty důvěry by měly odpovídat riziku konkrétní akce. Práh pro vypracování interního souhrnu a práh pro dotyk zákaznického účtu by nikdy neměly být stejným číslem.

Dvě postupy dělají to skutečným. První je navrhnout eskalační cestu před šťastnou cestou. Pokud člověk bude převzít převod, rozhodněte, jaký kontext získá a jakou autoritu má, než napíšete první prompt. Druhý je testovat selhání způsobem, jako byste testovali funkce. Vložte nejednoznačné instrukce. Zakažte nástroje ve stagingu. Krmte agenta konfliktními politikami. Systém, který se nikdy neučil selhat, bude jednat bez vedení poprvé, když se to stane v produkci.

Finanční instituce musí vyvážit experimentování se striktními požadavky na ochranu soukromí, auditovatelnost, modelové riziko a soulad s předpisy. Kde by mělo zůstat lidské schválení povinné, a kde mohou agenti bezpečně získat větší provozní autonomii?

Mé pravidlo je, že lidské schválení by mělo zůstat povinné pro jakoukoli akci, která je nezvratná, která pohybuje penězi nebo ovlivňuje výsledek pacienta, která zahrnuje zákaznické komunikace nesoucí regulační váhu, která krmí regulační reporting, nebo která mění agentovy vlastní nástroje, politiky nebo oprávnění. Agenti mohou bezpečně převzít více autonomie v čtení a rozumění: výzkum, vyhledávání, analýza dokumentů, triáž, vypracování a smíření, které označí nesrovnalosti pro lidskou kontrolu místo jejich řešení.

Obvyklá chyba je vyžadovat lidské schválení na každém kroku. To systém nezabezpečuje. Opakuje se manuální proces s extra kroky a cvičí recenzenty, aby gumovali. Schválení patří na skutečné rozhodovací body. Měly by být jich málo a každý by měl být obsazen někým s skutečnou autoritou říci ne.

Dalším principem je, že autonomie by měla být získána, nikoli udělena. Začněte úzce. Rozšiřte, jakmile se systém prokáže pod monitorováním. Uchovejte důkazy. Z hlediska modelového rizika by vaše kontrolní prostředí mělo umožnit vám ukázat regulátorovi nejen to, co agent udělal, ale proč jste byli oprávněni mu udělit tuto úroveň nezávislosti. Tato záznam je skutečná licence k provozu.

Přes svou práci na umělých inteligentních zárukách a standardech pomáháte definovat pravidla pro systémy, jejichž schopnosti pokračují v změně. Které záruky lze realisticky standardizovat dnes, a které oblasti zůstávají příliš závislé na kontextu, odvětví nebo použití?

Záruky, které můžeme standardizovat dnes, jsou strukturální. Vyžadují, aby certain kontroly existovaly, byly zdokumentovány a mohly být inspektovány. Zdokumentované hranice schopností a oprávnění pro autonomní systémy. Definované lidské dohledy a eskalační mechanismy. Povinnosti detekce incidentů a hlášení. Evaluační metody a požadavky na důkazy. Čisté účetnictví napříč systémem životního cyklu, aby když něco jde špatně, odpověď na otázku, kdo je zodpovědný, nebyla nikdy pouze AI. Tyto lze standardizovat, protože se týkají existence a kvality kontrol, nikoli konkrétních hodnot, které berou.

Co zatím nemůžeme standardizovat, jsou samotné nastavení. Konkrétní prahové hodnoty důvěry, taxonomie škod, a vhodné úrovně autonomie závisí silně na kontextu. Přijatelná tolerance selhání pro marketingového agenta a pro systém, který se dotýká klinických nebo finančních rozhodnutí, nejsou dva body na stejné škále. Patří do různých režimů, tvarovaných doménou, jurisdikcí a tím, kdo nese škodu, když něco selže.

Finanční kontroly jsou užitečným modelem zde. Auditní požadavky jsou standardizovány globálně, ale materialita je vždy posuzována v kontextu. Standardy, které respektují tento rozdělení, tendují k tomu, aby byly přijaty. Standardy, které se snaží diktovat kontextově závislé hodnoty, tendují k tomu, aby byly ignorovány, a bezpečnostní standard, který nikdo nedodržuje, nezajišťuje nikoho.

Vaše nedávný výzkum prozkoumal multikulturní a adversariální odolnost v AI bezpečnostní evaluaci. Jaké druhy modelových selhání jsou pravděpodobně ztraceny WESTERN-centrickými nebo globálně průměrnými benchmárkami, a jak by měly podniky vyhodnocovat systémy určené pro multikulturní nasazení?

Dívat se pouze na průměrné benchmárky může ztratit selhání, která jsou nejdůležitější. Model může získat silný celkový bezpečnostní skóre, zatímco špatně selhává pro konkrétní jazyk, dialekt nebo kulturní kontext, protože tato selhání mizí v průměru. WESTERN-centrická evaluace přidává další slepou skvrnu. Chybí škody, které jsou kulturně specifické, jako jsou idiomy, gesta a náboženské nebo regionální kontexty, kde stejný výstup je neškodný v jedné kultuře a škodlivý v jiné. Chybí také testování kódového přepínání, transliterace a nezápadních jmen a entit. Existuje také adversariální úhel. Útočníci neútočí na vaše průměrný výkon. Najdou váš nej slabší řez, a pro většinu modelů je tento řez nižší jazyk nebo kulturní kontext.

To mě přitáhlo k přispívání do multikulturního AI bezpečnostního benchmarkového výzkumu. Základní zjištění je přímé. Posuzování bezpečnosti napříč kulturami vyžaduje evaluační data a lidské úsudky z těchto kultur. Nemůžete posoudit škodu z vnějšku kontextu, ve kterém dochází.

Pro podniky navrhuji tři pravidla. Evaluační každý segment, který obsluhujete, a nikdy nepřijímejte průměr jako důkaz. Sestavte evaluační sady z vašich skutečných zákaznických populací. Spusťte adversariální testování v jazycích, které vaši zákazníci používají. Pokud obsluhujete zákazníky v 40 zemích a evaluační pouze v angličtině, jste měřili váš systém pro někoho jiného.

Vy také držíte udělený patent Úřadem pro patenty a ochranné známky USA v aplikovaném AI. Jaký problém jste se snažili vyřešit, co proces naučil o převodu AI výzkumu na praktickou inovaci, a který nevyřešený agentic AI výzvu jste nejvíce zajímá o řešení další?

Patent, který byl nedávno schválen, řeší problém měřítka a konzistence ve finančních službách kvalitativní kontrola — konvenční kontrola hovorů je manuální, takže lidský recenzent může pouze vzorkovat zlomek hovorů, a jejich hodnocení se liší od osoby k osobě. Můj přístup směruje každou kvalitativní a souladnou otázku k metodě, která je nejlépe přizpůsobena k odpovědi, s každým rozhodnutím zaznamenaným a stopovatelným pro audit.

Můžete vidět stejné téma, které jsem popsal po celou tuto interview. Směrovat každou úlohu k nejméně mocnému nástroji, který ji může udělat dobře. Udržovat lidi v smyčce, kde úsudek záleží. A učinit každou automatizovanou rozhodnutí stopovatelnou, protože v regulované instituci odpověď bez důkazu není odpovědí.

Co proces patentu mě naučil, je, že disciplína je v detailech. Nemůžete patentovat vágní nápad. Musíte ukázat přesně, co vaše metoda dělá jinak, a přesně kde se uplatňuje. Tato vynucená přesnost udělala základní práci lepší.

Neřešený výzva, která mě zajímá nejvíce, je runtime verifikace pro multi-agentní systémy. Definice semantických invariantů pro jeden agent je zvládnutelná. Ví to, protože to děláme v produkci. Když agenti delegují práci na jiné agenty, chování se stává emergentním, a selhání se pohybují do handoffů. Instrukce se mírně změní na každém kroku. Politika se vztahuje na jednoho agenta, ale ne na agenta, kterého najme. Verifikace interakce mezi agenty, ne pouze akcí každého z nich, je tam, kde očekávám, že se objeví další generace tichých selhání. To je problém, na který chci pracovat další.

Děkuji za skvělý rozhovor, čtenáři mohou také objednat její knihu Agentic AI for Engineers.