Dhivya Nagasubramanian, Wiceprezes ds. transformacji i innowacji AI – seria wywiadów

Dhivya Nagasubramanian jest Wiceprezesem ds. transformacji i innowacji AI w dużym amerykańskim instytucie finansowym, gdzie kieruje projektowaniem, wdrożeniem i zarządzaniem systemami AI agentic. Jest autorką książki Agentic AI for Engineers (Apress/Springer Nature), praktycznego przewodnika po budowaniu autonomicznych systemów AI, które mogą być zaufane w produkcji. Od czasu jej wydania książka zanotowała ponad 6 000 dostępów instytucjonalnych na SpringerLink, posiada zbiory w ponad 260 bibliotekach na całym świecie i jest stosowana w uczelniach. Jest posiadaczem patentu przyznanego przez USPTO w dziedzinie stosowanej nauki o maszynach. Jej zainteresowania badawcze obejmują tworzenie aplikacji, które są odporne na ataki jailbreak i przyczyniają się do szerszych wysiłków branży w celu opracowania lepszych modeli bezpieczeństwa i ochrony w wielu kulturach. Jest cenionym ekspertem i panelistą na konferencjach branżowych i akademickich.

Twoja kariera rozwinęła się od doradztwa przedsiębiorstw i nauki o danych do kierowania transformacją AI w usługach finansowych. Jak doświadczenia te ukształtowały Agentic AI for Engineers, i jaki powtarzający się rozdźwięk między badaniami AI a wdrożeniem przedsiębiorstw przekonał Cię, że ta książka musi zostać napisana?

Zacząłem w 2008 roku budową systemów rachunkowości portfela i pomiaru wyników dla platform bankowych. Jednym z tych projektów była silnik zgodny z GIPS do obliczania zwrotów ważonych w czasie, który został wykorzystany przez instytucje finansowe w ponad 80 krajach. Praca ta nauczyła mnie lekcji, która ukształtowała całą moją karierę. W regulowanym finansie najbardziej niebezpieczna awaria to błędna liczba, która wygląda poprawnie. Subtelnie niepoprawne obliczenie jest ufało, raportowane i stosowane przez lata, ponieważ nic nie wydaje się złamanym.

Widziałem ten sam wzorzec ponownie później. Znalazłem strukturalną lukę w modelu Markowa powszechnie używanego modelu atrybucji marketingowej. Ramy były używane przez setki tysięcy użytkowników, a błąd przetrwał przez lata z jednego powodu: dane wyjściowe wyglądały rozsądnie. Kiedy przeniosłem się do transformacji AI w usługach finansowych, obserwowałem, jak systemy agentic powtarzają ten wzorzec z o wiele wyższymi stawkami. Agent nie produkuje tylko błędny wynik. Podejmuje działania na jego podstawie.

Rozdźwięk, który przekonał mnie do napisania książki, polega na tym, że badania i wdrożenie przedsiębiorstw dbają o różne rzeczy. Badania mierzą zdolność na benchmarkach. Przedsiębiorstwa zależą od tego, jak system zachowuje się w niejasności, zmieniających się danych i presji przeciwnika. Większość pisarstwa o agentach kończy się na etapie demo. Napisałam Agentic AI for Engineers dla inżyniera, który musi postawić swoje nazwisko na systemie, który będzie działał z ograniczonym nadzorem w regulowanym instytucie.

Książka opisuje zmianę z automatyzacji na autonomię jako nowy sposób myślenia inżynierskiego. Co prawdziwie oddziela autonomicznego agenta AI od zaawansowanego przepływu pracy zautomatyzowanego, i gdzie organizacje są najbardziej skłonne do pomylenia ich?

Daję zespołom prosty test. Czy możesz wyliczyć każdą ścieżkę, którą system może podjąć przed jego uruchomieniem? Jeśli tak, masz automatyzację. Może to być bardzo zaawansowana automatyzacja z modelem językowym w środku, ale nadal jest to automatyzacja. Jeśli system rozkłada cele, wybiera narzędzia i decyduje o kolejności działań w czasie wykonywania na podstawie kontekstu, którego nie zaprogramowałeś, masz autonomię. Różnica nie ma nic wspólnego z modelem, którego używasz. Chodzi o to, gdzie są podejmowane decyzje.

Organizacje mylą te dwa w obie strony, ale tylko jeden kierunek jest kosztowny. Nazywanie zaprogramowanego przepływu pracy z modelem językowym agentic jest głównie problemem marketingowym. Kosztowny błąd jest odwrotny. Zespoły wdrożenia prawdziwej autonomii podejmowania decyzji pod rządami, które zostały zaprojektowane dla deterministycznej automatyzacji. Ich testowanie zakłada powtarzalność. Ich monitorowanie zakłada znane wzorce awarii. Ich ślad audytowy zakłada ślady przypisane do każdej akcji. Żadne z tych założeń nie dotyczy agenta.

To jest zmiana myślenia, o której argumentuję w książce. Z automatyzacją głównym pytaniem jest, czy system został wykonany poprawnie. Z autonomią pytanie staje się, czy system podjął poprawną decyzję. Odpowiedź na to wymaga innej instrumentacji, innych metod oceny i innego poziomu ostrożności.

Wiele systemów AI agentic działa imponująco w demonstracjach, ale ma trudności, gdy są narażone na prawdziwych użytkowników, zmieniające się dane i nieprzewidywalne narzędzia. Jakie składniki powinny być uważane za obligatoryjne w architekturze agenta gotowego do produkcji?

Szczera odpowiedź brzmi: produkcja potrzebuje wszystkiego, co demo pozwala ominąć. Demonstracja działa, ponieważ ktoś kontrolował środowisko. Produkcja odbiera ten kontrolę.

W książce opisuję siedmiowarstwową architekturę referencyjną, ale te składniki uważam za obligatoryjne. Umowy z narzędziami z wprowadzanymi danymi i jawnymi uprawnieniami, tak aby zasięg agenta był ograniczony projektem, a nie nadzieją. Zarządzanie stanem, które przetrwa przerwy i awarie. Ustrukturyzowane obsługiwanie awarii z określonymi ścieżkami eskalacji. Końcowa ocena, która działa nieprzerwanie, a nie tylko raz przed uruchomieniem. I ślad audytowy, który rejestruje decyzje i powody, dla których zostały podjęte, a nie tylko akcje.

Składnik, który zespoły najczęściej pomijają, to weryfikacja w czasie wykonywania. Jest to warstwa, która sprawdza każdą akcję względem deklarowanego celu agenta i polityk, które mają zastosowanie. Standardowa infrastruktura mówi ci, czy wywołanie powiodło się. Weryfikacja pyta, czy wywołanie powinno zostać wykonane w ogóle. Nigdy nie udowadnia swojej wartości w demo, ponieważ nic w demo nie wymaga pochwycenia. W produkcji jest to pierwsza rzecz, której będziesz żałował, że nie masz.

Twoja książka obejmuje bezpieczeństwo, wyrównanie, pętle sprzężenia zwrotnego, testowanie, debugowanie, ocenę i wdrożenie. Jak zespoły inżynierskie powinny łączyć te elementy w ciągły proces zapewnienia, zamiast traktowania bezpieczeństwa jako ostatecznej przeglądowej recenzji przed uruchomieniem?

Ostateczna recenzja opiera się na założeniu, że system, który został przeglądnięty, jest systemem, który będzie działał. Dla AI agentic to założenie zawodzi na trzy sposoby. Podstawowe modele są aktualizowane. Narzędzia i interfejsy API, od których zależy agent, ulegają zmianie. I dane oraz środowisko, w którym agent działa, ciągle się zmieniają. Jednorazowa recenzja bezpieczeństwa opisuje system, który nie istnieje już kilka miesięcy później.

Ciągłe zapewnienie oznacza zamknięcie pętli. Oceny behawioralne są uruchamiane w CI (ciągłej integracji) w ten sam sposób, co testy jednostkowe, i bramkują każdą zmianę w promptach, narzędziach i modelach. Monitorowanie w czasie wykonywania karmi ślady produkcyjne z powrotem do zestawów oceny. Opisuję cztery wzorce monitorowania w książce, ponieważ żaden wzorzec nie obejmuje pełnej powierzchni awarii. Każdy incydent produkuje nowy test, w ten sam sposób, w jaki każdy błąd powinien wyprodukować test regresji. I testy przeciwnika są uruchamiane na regularnym harmonogramie, zamiast tylko raz przed uruchomieniem.

Strona organizacyjna jest równie ważna, co strona techniczna. Bezpieczeństwo nie może być oddzielnym zespołem, który pojawia się na końcu z checklistą. Inżynierowie, którzy budują agenta, powinni posiadać jego zestawy oceny, niezmienne i projekt eskalacji, ponieważ lepiej niż ktokolwiek inny wiedzą, gdzie osąd systemu jest najbardziej słaby.

Podkreśliłaś monitorowanie semantyczne wywołań narzędzi agenta. Co ujawnia monitorowanie semantyczne, czego nie mogą ujawnić konwencjonalne logi i narzędzia obserwacyjne, i jak może ono wykryć, kiedy agent jest technicznie funkcjonalny, ale dąży do błędnego celu?

Konwencjonalna obserwacyjność odpowiada na jedno pytanie: czy wywołanie powiodło się? Obejmuje to kody stanu, schematy, opóźnienia i wskaźniki błędów. Nie może odpowiedzieć na pytanie, które jest najważniejsze dla agentów, czyli czy wywołanie powinno się wydarzyć. Wywołanie narzędzia może być technicznie idealne i nadal być niewłaściwą akcją. Prawidłowy format, ważne poświadczenia, pomyślna odpowiedź, niewłaściwa rzecz do zrobienia.

Monitorowanie semantyczne ocenia każdą akcję względem deklarowanego celu agenta i polityk, które mają zastosowanie. W książce opisuję to jako definiowanie semantycznych niezmiennych nad wywołaniami narzędzi agenta. Są to właściwości, które muszą być spełnione niezależnie od ścieżki, którą agent podejmuje. Agent badający jeden przypadek klienta nigdy nie powinien uzyskać dostępu do rekordów poza tym przypadkiem. Agent powinien oznaczyć rozbieżność powyżej pewnego progu, nigdy nie rozwiązać jej samodzielnie. Kiedy niezmienna jest naruszona, pochwycasz problem w momencie akcji, zamiast w kwartalnej audycie.

To jest również sposób, w jaki wykrywasz dryf celu, który uważam za definicyjną awarię systemów agentic. Dryf celu wygląda jak agent, który kończy każdy krok poprawnie zgodnie z logami, podczas gdy cicho pracuje nad błędnym celem. Nigdy nie pojawia się w logu, ponieważ nic nie awarii. Monitorowanie semantyczne traktuje intencję jako coś, co mierzy się bezpośrednio, a intencja jest tam, gdzie agenci idą źle.

Kiedy agent napotyka niejasne instrukcje, sprzeczne polityki, niedostępne narzędzia lub niewystarczającą pewność, jaki powinien wyglądać ustrukturyzowany sposób obsługi awarii? Jak deweloperzy mogą upewnić się, że system zatrzymuje się, eskaluje lub odzyskuje, zamiast improwizować?

Problem, przeciwko któremu trzeba zaprojektować, polega na tym, że większość agentów ma tylko jeden sposób zakończenia zadania, który polega na wyprodukowaniu odpowiedzi. Kiedy instrukcje są niejasne lub polityki są sprzeczne, agent improwizuje. Nie dlatego, że model jest lekkomyślny, ale dlatego, że improwizacja jest jedynym zachowaniem, które architektura pozwala. Ustrukturyzowane obsługiwanie awarii oznacza dawanie systemowi lepszych opcji i sprawianie, by były one łatwiejsze do osiągnięcia niż wymyślona odpowiedź.

W praktyce oznacza to, że odmowa i eskalacja są zaprojektowane i przetestowane z taką samą starannością, jak powodzenie. Zalecam definiowanie typowych stanów awarii: niejasne instrukcje, sprzeczne polityki, niedostępne narzędzie, niewystarczająca pewność. Każdy z nich mapuje się na określone zachowanie. Zadaj pytanie wyjaśniające. Przekaż do człowieka z pełnym kontekstem. Przejdź do trybu tylko do odczytu. Ponów w ramach ściślejszych limitów. Albo zatrzymaj. Progi pewności powinny odpowiadać ryzyku konkretnego działania. Pasek dla wersji roboczej wewnętrznej i pasek dla dotknięcia konta klienta nigdy nie powinny być tą samą liczbą.

Dwie praktyki sprawiają, że to staje się realne. Po pierwsze, zaprojektuj ścieżkę eskalacji przed ścieżką szczęśliwą. Jeśli człowiek otrzyma przekaz, zdecyduj, jaki kontekst otrzyma i jaką władzę ma, zanim napiszesz pierwszy prompt. Po drugie, przetestuj awarię w ten sam sposób, w jaki testujesz funkcje. Wstrzyknij niejasne instrukcje. Wyłącz narzędzia w środowisku testowym. Nakarm agent sprzecznymi politykami. System, który nigdy nie ćwiczył awarii, będzie działał bez kierunku pierwszy raz, gdy wystąpi w produkcji.

Instytucje finansowe muszą balansować eksperymenty z surowymi wymogami dotyczącymi prywatności, audytowalności, ryzyka modelu i zgodności z przepisami. Gdzie powinna pozostać obowiązkowa zgoda ludzka, a gdzie agenci mogą bezpiecznie otrzymać większą autonomię operacyjną?

Moja zasada brzmi: zgoda ludzka powinna pozostać obowiązkowa dla każdej akcji, która jest nieodwracalna, która przenosi pieniądze lub wpływa na wynik pacjenta, która obejmuje komunikację z klientem o wadze regulacyjnej, która karmi raportowanie regulacyjne, lub która zmienia narzędzia, polityki lub uprawnienia agenta. Agenci mogą bezpiecznie przyjąć większą autonomię w pracy odczytu i rozumienia: badania, pobieranie dokumentów, analiza dokumentów, triage, tworzenie szkiców i uzgodnienia, które oznaczają rozbieżności do przeglądu ludzkiego, zamiast ich rozwiązywać.

Wspólny błąd polega na wymaganiu zgody ludzkiej na każdym kroku. To nie sprawia, że system jest bezpieczniejszy. Odtwarza proces ręczny z dodatkowymi krokami i szkoli recenzentów, aby potwierdzać. Zgody należą na prawdziwe punkty decyzyjne. Powinno ich być niewiele, a każdy powinien być obsadzony przez kogoś z prawdziwą władzą, aby powiedzieć nie.

Zasada jest taka, że autonomia powinna być zdobyta, a nie przyznana. Zacznij wąsko. Rozszerzaj, gdy system udowadnia się podczas monitorowania. Zachowaj dowody. W terminach ryzyka modelu Twoje środowisko kontroli powinno pozwolić ci pokazać regulatorowi, że nie tylko to, co agent zrobił, ale także dlaczego byłeś uzasadniony, aby dać mu ten poziom niezależności. To nagranie jest prawdziwą licencją na działanie.

Przez swoją pracę nad zabezpieczeniami i standardami sztucznej inteligencji, pomagasz definiować zasady dla systemów, których możliwości ciągle się zmieniają. Jakie zabezpieczenia można realistycznie standaryzować dzisiaj, a które obszary pozostają zbyt zależne od kontekstu, branży lub przypadku użycia?

Zabezpieczenia, które możemy standaryzować dzisiaj, są strukturalne. Wymagają one, aby pewne kontrolki istniały, były udokumentowane i mogły być sprawdzane. Udokumentowane granice zdolności i uprawnień dla autonomicznych systemów. Zdefiniowane mechanizmy nadzoru ludzkiego i eskalacji. Obowiązki wykrywania i raportowania incydentów. Metody oceny i wymagania dowodowe. Wyraźna odpowiedzialność na całym cyklu życia systemu, tak aby gdy coś pójdzie nie tak, odpowiedź na to, kto jest odpowiedzialny, nigdy nie brzmiała tylko „AI”. Mogą być one standaryzowane, ponieważ dotyczą istnienia kontrolki i tego, jak dobrze są one, a nie konkretnych wartości, które przyjmują.

Co nie możemy jeszcze standaryzować, to same ustawienia. Konkretne progi pewności, taksonomie szkód i odpowiednie poziomy autonomii zależą silnie od kontekstu. Akceptowalna tolerancja awarii dla agenta treści marketingowych i systemu, który dotyka decyzji klinicznych lub finansowych, nie są dwoma punktami na tej samej skali. Należą one do różnych reżimów, ukształtowanych przez dziedzinę, jurysdykcję i kogo szkoda, gdy coś awarii.

Kontrola finansowa jest przydatnym modelem tutaj. Wymagania audytowe są standaryzowane na całym świecie, ale materialność jest zawsze oceniana w kontekście. Standardy, które szanują ten podział, mają tendencję do przyjęcia. Standardy, które próbują dyktować kontekst-zależne wartości, mają tendencję do ignorowania, a standard bezpieczeństwa, którego nikt nie stosuje, nie chroni nikogo.

Twoje ostatnie badania dotyczyły wielokulturowej i przeciwniczej wytrzymałości w ocenie bezpieczeństwa AI. Jakie rodzaje awarii modelu są prawdopodobnie pomijane przez zachodnio-centryczne lub globalnie uśrednione benchmarki, i jak przedsiębiorstwa powinny oceniać systemy przeznaczone do wdrożenia w wielu kulturach?

Patrzenie tylko na uśrednione benchmarki może ominąć awarie, które mają znaczenie. Model może uzyskać silny ogólny wynik bezpieczeństwa, podczas gdy źle radzi sobie z konkretnym językiem, dialektem lub kontekstem kulturowym, ponieważ te awarie znikają w średniej. Zachodnio-centryczna ocena dodaje kolejną ślepotę. Omija szkody, które są specyficzne dla kultury, takie jak idiomy, gesty i konteksty religijne lub regionalne, w których ta sama odpowiedź jest nieszkodliwa w jednej kulturze i szkodliwa w innej. Omija również testowanie kodowania, transkrypcji i nazw i jednostek niezachodnich. Istnieje również przeciwniczy kąt. Atakujący nie atakują Twojego średniego wyniku. Znajdują Twoją najslabszą część, a dla większości modeli ta część jest językiem o niższych zasobach lub kontekstem kulturowym, który jest niedostatecznie oceniany.

To jest to, co skłoniło mnie do przyczynienia się do badań nad benchmarkami bezpieczeństwa AI w wielu kulturach. Główne odkrycie jest proste. Ocena bezpieczeństwa w różnych kulturach wymaga danych oceny i ludzkiej oceny pochodzącej z tych kultur. Nie można ocenić szkody spoza kontekstu, w którym występuje.

Dla przedsiębiorstw proponuję trzy reguły. Ocenić każdy segment, który obsługujesz, i nigdy nie akceptuj średniej jako dowodu. Zbuduj zestawy oceny z Twoich rzeczywistych populacji klientów. Uruchom testy przeciwnika w językach, których używają Twoi klienci. Jeśli obsługujesz klientów w 40 krajach i oceniasz tylko w języku angielskim, zmierzyłeś swój system dla kogoś innego.

Również posiadasz przyznany patent Urzędu Patentów i Znaków Towarowych USA w dziedzinie stosowanej nauki o maszynach. Jaki problem próbowałeś rozwiązać, co proces nauczył cię o przekształcaniu badań AI w praktyczną innowację, i jaki nierozwiązany problem AI agentic jesteś najbardziej zainteresowany, aby rozwiązać jako następny?

Patent, który został niedawno zatwierdzony, dotyczy problemu skali i spójności w przeglądzie jakości usług finansowych — konwencjonalny przegląd wywołań jest ręczny, więc recenzenci ludzcy mogą tylko próbkować ułamek wywołań, a ich oceny różnią się od osoby do osoby. Mój podejście kieruje każde pytanie jakości i zgodności do metody najlepiej dostosowanej do odpowiedzi, z każdą decyzją zalogowaną i możliwą do audytu.

Można zobaczyć te same tematy, które opisałam na przestrzeni tego wywiadu. Skieruj każde zadanie do najmniej potężnego narzędzia, które może to zrobić dobrze. Trzymaj ludzi w pętli, gdzie osąd ma znaczenie. I spraw, aby każda zautomatyzowana decyzja była śladem, ponieważ w regulowanym instytucie odpowiedź bez dowodu nie jest odpowiedzią.

Co proces patentowy nauczył mnie, to to, że dyscyplina leży w szczegółach. Nie możesz zapatentować mglistego pomysłu. Musisz pokazać dokładnie, co Twoja metoda robi inaczej, i dokładnie gdzie ma zastosowanie. Ta wymuszona precyzja sprawiła, że podstawowa praca była lepsza.

Nierozwiązany problem, którym najbardziej się interesuję, to weryfikacja w czasie wykonywania dla systemów wieloagentowych. Definiowanie semantycznych niezmiennych dla jednego agenta jest zarządzalne. Wiem, bo robimy to w produkcji. Kiedy agenci delegują pracę do innych agentów, zachowanie staje się emergentne, a awarie przechodzą do obszaru delegacji. Instrukcja zostaje nieznacznie ponownie zinterpretowana na każdym kroku. Polityka ma zastosowanie do jednego agenta, ale nie do agenta, którego rekrutuje. Weryfikacja interakcji między agentami, a nie tylko ich akcji, jest tam, gdzie oczekuję, że pojawi się następne pokolenie awarii. To jest problem, nad którym chcę pracować jako następny.

Dziękuję za wspaniały wywiad, czytelnicy mogą również chcieć zamówić jej książkę Agentic AI for Engineers.