Dhivya Nagasubramanian, VP di Trasformazione e Innovazione AI – Serie di Interviste

Dhivya Nagasubramanian è VP di Trasformazione e Innovazione AI in una importante istituzione finanziaria statunitense, dove guida la progettazione, il dispiegamento e la governance di sistemi agentic AI di produzione. È l’autrice di Agentic AI per Ingegneri (Apress/Springer Nature), una guida pratica per la costruzione di sistemi autonomi AI che possono essere affidati in produzione. Dal suo rilascio, il libro ha registrato oltre 6.000 accessi istituzionali su SpringerLink, detenzioni in oltre 260 biblioteche in tutto il mondo e adozione in università. È titolare di un brevetto concesso dall’USPTO in apprendimento automatico applicato. I suoi interessi di ricerca includono la costruzione di applicazioni resistenti agli attacchi di jailbreak avversariali e il contributo a sforzi industriali più ampi per sviluppare modelli migliori per la sicurezza e la sicurezza multiculturale. È un esperto ricercato e relatore in多ple conferenze industriali e accademiche.

La tua carriera è progredita dal consulting aziendale e dalla scienza dei dati al lideraggio della trasformazione AI nei servizi finanziari. Come hanno plasmato queste esperienze Agentic AI per Ingegneri, e quale gap ricorrente tra la ricerca AI e il dispiegamento aziendale ti ha convinto che questo libro doveva essere scritto?

Ho iniziato nel 2008 costruendo sistemi di contabilità e misurazione delle prestazioni per piattaforme bancarie. Uno di quei progetti era un motore GIPS-compliant per il calcolo dei rendimenti ponderati nel tempo, che le istituzioni finanziarie in oltre 80 paesi hanno utilizzato in seguito. Quel lavoro mi ha insegnato una lezione che ha plasmato tutta la mia carriera. Nella finanza regolamentata, il fallimento più pericoloso è un numero errato che sembra giusto. Un calcolo sottilmente errato viene affidato, segnalato e agito per anni, perché nulla sembra rotto.

Ho visto lo stesso modello di nuovo in seguito. Ho trovato un gap strutturale nel modello di attribuzione di marketing basato su Markov. La struttura era utilizzata da centinaia di migliaia di utenti e l’errore era sopravvissuto per anni per una ragione: i risultati sembravano ragionevoli. Quando mi sono spostato nella trasformazione AI nei servizi finanziari, ho guardato i sistemi agentic ripetere questo modello con poste molto più elevate. Un agente non produce solo un risultato errato. Agisce in base ad esso.

Il gap che mi ha convinto a scrivere il libro è che la ricerca e il dispiegamento aziendale si curano di cose diverse. La ricerca misura la capacità sui benchmark. Le aziende dipendono da come un sistema si comporta sotto ambiguità, dati in cambiamento e pressione avversariale. La maggior parte della scrittura sugli agenti si ferma allo stadio demo. Ho scritto Agentic AI per Ingegneri per l’ingegnere che deve mettere il proprio nome su un sistema che verrà eseguito con una supervisione limitata all’interno di un’istituzione regolamentata.

Il libro descrive il passaggio dall’automazione all’autonomia come una nuova mentalità ingegneristica. Cosa separa veramente un agente AI autonomo da un flusso di lavoro automatizzato sofisticato, e dove le organizzazioni sono più probabili di confondere i due?

Do un test semplice alle squadre. Puoi elencare ogni percorso che il sistema può prendere prima di eseguirlo? Se sì, hai l’automazione. Potrebbe essere un’automazione molto sofisticata con un modello linguistico all’interno, ma è ancora automazione. Se il sistema divide gli obiettivi, sceglie gli strumenti e decide l’ordine delle azioni in fase di esecuzione in base al contesto che non hai scriptato, hai l’autonomia. La differenza non ha nulla a che fare con quale modello utilizzi. Si tratta di dove vengono prese le decisioni.

Le organizzazioni confondono i due in entrambe le direzioni, ma solo una direzione è costosa. Chiamare un flusso di lavoro LLM scriptato agentic è principalmente un problema di marketing. L’errore costoso è il contrario. Le squadre dispiegano una presa di decisione autonoma sotto una governance progettata per l’automazione deterministica. Il loro test presuppone la ripetibilità. La loro monitorazione presuppone modelli di fallimento noti. La loro traccia di audit presuppone che ci sia una regola tracciabile dietro ogni azione. Nessuna di quelle ipotesi è valida per un agente.

Quella è la mentalità che sostengo nel libro. Con l’automazione, la principale domanda è se il sistema è stato eseguito correttamente. Con l’autonomia, la domanda diventa se il sistema ha deciso correttamente. Rispondere a quella richiede strumentazione diversa, metodi di valutazione diversi e un livello di cautela diverso.

Molti sistemi AI agentic si esibiscono in modo impressionante nelle dimostrazioni, ma lottano quando esposti a utenti reali, dati in cambiamento e strumenti imprevedibili. Quali componenti dovrebbero essere considerati obbligatori in un’architettura di agente pronta per la produzione?

La risposta onesta è che la produzione richiede tutto ciò che una demo ti fa saltare. Una dimostrazione funziona perché qualcuno ha controllato l’ambiente. La produzione toglie quel controllo.

Nel libro, descrivo un’architettura di riferimento a sette strati, ma queste sono le componenti che considero obbligatorie. Contratti di strumenti con input tipizzati e permessi espliciti, in modo che la portata dell’agente sia limitata per progetto e non per speranza. Gestione dello stato che sopravvive alle interruzioni e ai fallimenti. Gestione dei fallimenti strutturata con percorsi di escalation definiti. Un telaio di valutazione che funziona in continuazione, non solo una volta prima del lancio. E una traccia di audit che registra le decisioni e il ragionamento dietro di esse, non solo le azioni intraprese.

Il componente che le squadre saltano più spesso è la verifica in fase di esecuzione. Questo è uno strato che controlla ogni azione rispetto all’obiettivo dichiarato dell’agente e alle politiche che si applicano ad esso. L’infrastruttura standard ti dice se una chiamata è riuscita. La verifica chiede se la chiamata doveva essere effettuata affatto. Non dimostra mai il suo valore in una demo, perché nulla deve essere catturato. In produzione, è la prima cosa che desidererai di avere.

Il tuo libro copre sicurezza, allineamento, anelli di feedback, test, debug, valutazione e dispiegamento. Come dovrebbero combinare gli ingegneri questi elementi in un processo di assicurazione continua invece di trattare la sicurezza come una revisione finale pre-lancio?

Una revisione finale si basa sull’ipotesi che il sistema che hai revisionato sia il sistema che verrà eseguito. Per l’AI agentic, quell’ipotesi fallisce in tre modi. I modelli di base vengono aggiornati. Gli strumenti e le API di cui l’agente dipende cambiano. E i dati e l’ambiente in cui l’agente opera continuano a cambiare. Una revisione di sicurezza una tantum descrive un sistema che non esiste più alcuni mesi dopo.

L’assicurazione continua significa chiudere il cerchio. Le valutazioni comportamentali vengono eseguite in CI (integrazione continua) allo stesso modo dei test unitari, e bloccano ogni modifica ai prompt, agli strumenti e ai modelli. La monitorazione in fase di esecuzione alimenta tracce di produzione nei set di valutazione. Descrivo quattro modelli di monitoraggio nel libro, perché nessun modello copre l’intera superficie di fallimento. Ogni incidente produce un nuovo controllo, allo stesso modo in cui ogni bug produce un test di regressione. E il test avversariale viene eseguito su una programmazione regolare invece di una sola volta prima del lancio.

Il lato organizzativo è importante quanto il lato tecnico. La sicurezza non può essere un team separato che si presenta alla fine con una checklist. Gli ingegneri che costruiscono l’agente dovrebbero possedere i propri set di valutazione, le proprie invarianti e la propria progettazione di escalation, perché sanno meglio di chiunque altro dove il giudizio del sistema è più debole.

Hai sottolineato il monitoraggio semantico delle chiamate di strumenti dell’agente. Cosa rivela il monitoraggio semantico che gli strumenti di log e di osservabilità convenzionali non possono, e come può rilevare quando un agente è tecnicamente funzionante ma persegue l’obiettivo sbagliato?

Gli strumenti di osservabilità convenzionali rispondono a una domanda: la chiamata è riuscita? Coprono codici di stato, schemi, latenza e tassi di errore. Non possono rispondere alla domanda che più conta per gli agenti, ovvero se la chiamata doveva verificarsi. Una chiamata di strumento può essere tecnicamente perfetta e comunque essere l’azione sbagliata. Formato giusto, credenziali valide, risposta riuscita, cosa sbagliata da fare.

Il monitoraggio semantico valuta ogni azione rispetto all’obiettivo dichiarato dell’agente e alle politiche che si applicano ad esso. Nel libro, descrivo questo come la definizione di invarianti semantiche sulle chiamate di strumenti dell’agente. Queste sono proprietà che devono essere mantenute indipendentemente dal percorso che l’agente prende. Un agente che ricerca un caso di un cliente non dovrebbe mai accedere a registri al di fuori di quel caso. Un agente dovrebbe segnalare una discrepanza al di sopra di una certa soglia, mai risolverla da solo. Quando un’invariante viene violata, si cattura il problema nel momento dell’azione invece che in un’audit trimestrale.

Questo è anche come rilevare la deriva dell’obiettivo, che considero il fallimento definitivo dei sistemi agentic. La deriva dell’obiettivo sembra un agente che completa ogni passaggio correttamente secondo i log mentre lavora silenziosamente verso l’obiettivo sbagliato. Non appare in un log, perché nulla è fallito. Il monitoraggio semantico tratta l’intento come qualcosa da misurare direttamente, e l’intento è dove gli agenti vanno storti.

Quando un agente incontra istruzioni ambigue, politiche in conflitto, strumenti non disponibili o insufficienti, cosa dovrebbe assomigliare una gestione dei fallimenti strutturata? Come possono gli sviluppatori assicurarsi che il sistema si fermi, si escalati o si riprenda invece di improvvisare?

Il problema da progettare contro è che la maggior parte degli agenti ha solo un modo per terminare un compito, che è produrre una risposta. Quando le istruzioni sono ambigue o le politiche sono in conflitto, l’agente improvvisa. Non perché il modello è avventato, ma perché l’improvvisazione è l’unico comportamento che l’architettura consente. La gestione dei fallimenti strutturata significa dare al sistema opzioni migliori e renderle più facili da raggiungere di una risposta inventata.

Nella pratica, significa che il rifiuto e l’escalation vengono progettati e testati con la stessa cura del successo. Raccomando di definire stati di fallimento tipizzati: istruzione ambigua, politica in conflitto, strumento non disponibile, fiducia insufficiente. Ognuno di essi corrisponde a un comportamento specifico. Chiedere una domanda di chiarimento. Passare a un umano con un contesto completo allegato. Ridurre all’operazione in sola lettura. Riprovare entro limiti più stretti. O fermarsi. Le soglie di fiducia dovrebbero corrispondere al rischio dell’azione specifica. La barra per la stesura di un riassunto interno e la barra per toccare un account del cliente non dovrebbero mai essere lo stesso numero.

Due pratiche rendono questo reale. Primo, progettare il percorso di escalation prima del percorso felice. Se un umano riceverà il passaggio, decidere quale contesto ottiene e quale autorità ha prima di scrivere il primo prompt. Secondo, testare il fallimento nel modo in cui si testano le funzionalità. Iniettare istruzioni ambigue. Disabilitare gli strumenti in staging. Alimentare l’agente con politiche in conflitto. Un sistema che non ha mai praticato il fallimento agirà senza guida la prima volta che si verifica in produzione.

Le istituzioni finanziarie devono bilanciare la sperimentazione con requisiti severi relativi alla privacy, alla tracciabilità, al rischio del modello e alla conformità normativa. Dove dovrebbe rimanere obbligatorio l’approvazione umana e dove gli agenti possono essere sicuramente dotati di maggiore autonomia operativa?

La mia regola è che l’approvazione umana dovrebbe rimanere obbligatoria per qualsiasi azione che sia irreversibile, che sposti denaro o influenzi il risultato di un paziente, che coinvolga comunicazioni dei clienti che trasportano peso normativo, che alimenti la segnalazione normativa, o che cambi gli strumenti, le politiche o i permessi dell’agente stesso. Gli agenti possono prendere più autonomia in lettura e ragionamento: ricerca, recupero, analisi del documento, triage, stesura e riconciliazioni che segnalano le discrepanze per la revisione umana invece di risolverle.

L’errore comune è richiedere l’approvazione umana a ogni passaggio. Ciò non rende il sistema più sicuro. Ricrea il processo manuale con passaggi aggiuntivi e addestra i revisori a timbrare. Le approvazioni appartengono ai punti di decisione reali. Dovrebbero essercene pochi e ognuno dovrebbe essere gestito da qualcuno con l’autorità reale di dire no.

Il principio è che l’autonomia dovrebbe essere guadagnata e non concessa. Iniziare a livello stretto. Espandere man mano che il sistema si dimostra sotto monitoraggio. Conservare le prove. In termini di rischio del modello, il vostro ambiente di controllo dovrebbe consentirvi di mostrare a un regolatore non solo cosa ha fatto l’agente, ma anche perché eravate giustificati nel dargli quel livello di indipendenza. Quel record è la vera licenza di operare.

Attraverso il tuo lavoro su salvaguardie e norme di intelligenza artificiale, stai aiutando a definire regole per sistemi le cui capacità continuano a cambiare. Quali salvaguardie possono realisticamente essere standardizzate oggi e quali aree rimangono troppo dipendenti dal contesto, dall’industria o dal caso d’uso?

Le salvaguardie che possiamo standardizzare oggi sono strutturali. Richiedono che determinati controlli esistano, siano documentati e possano essere ispezionati. Confini di capacità e permessi documentati per sistemi autonomi. Meccanismi di supervisione umana e di escalation definiti. Obblighi di rilevamento e segnalazione di incidenti. Metodi di valutazione e requisiti di prova. Chiarezza di responsabilità in tutto il ciclo di vita del sistema, in modo che quando qualcosa va storto, la risposta a chi è responsabile non sia mai solo l’AI. Queste possono essere standardizzate perché riguardano se i controlli esistono e quanto sono buoni, non i valori specifici che assumono.

Cosa non possiamo ancora standardizzare sono le impostazioni stesse. Soglie di fiducia specifiche, tassonomie di danno e livelli di autonomia appropriati dipendono fortemente dal contesto. La tolleranza di fallimento accettabile per un agente di contenuto di marketing e per un sistema che tocca decisioni cliniche o finanziarie non sono due punti sulla stessa scala. Appartengono a regimi diversi, plasmati dal dominio, dalla giurisdizione e da chi subisce il danno quando qualcosa fallisce.

I controlli finanziari sono un modello utile qui. I requisiti di audit sono standardizzati a livello globale, ma la rilevanza è sempre giudicata nel contesto. Gli standard che rispettano quella divisione tendono a essere adottati. Gli standard che cercano di dettare valori dipendenti dal contesto tendono a essere ignorati, e uno standard di sicurezza che nessuno segue non protegge nessuno.

La tua recente ricerca ha esplorato la robustezza multiculturale e avversariale nella valutazione della sicurezza AI. Quali tipi di fallimenti del modello sono probabili di essere persi dai benchmark occidentali o globalmente medi e come le imprese dovrebbero valutare i sistemi destinati a un dispiegamento multiculturale?

Guardare solo i benchmark mediati può perdere i fallimenti che più contano. Un modello può registrare un punteggio di sicurezza generale forte mentre fallisce gravemente per un linguaggio, dialetto o contesto culturale specifico, perché quei fallimenti scompaiono nella media. La valutazione occidentale aggiunge un altro punto cieco. Perde i danni che sono culturalmente specifici, come modi di dire, gesti e contesti religiosi o regionali in cui la stessa uscita è inoffensiva in una cultura e dannosa in un’altra. Perde anche i test di code-switching, translitterazione e nomi ed entità non occidentali. C’è un angolo avversario anche. Gli attaccanti non prendono di mira la tua prestazione media. Trovano il tuo settore più debole e per la maggior parte dei modelli quel settore è un linguaggio a bassa risorsa o un contesto culturale poco valutato.

Questo è ciò che mi ha portato a contribuire alla ricerca sui benchmark di sicurezza AI multiculturale. La scoperta principale è semplice. Giudicare la sicurezza attraverso le culture richiede dati di valutazione e giudizio umano tratti da quelle culture. Non puoi valutare il danno dall’esterno del contesto in cui si verifica.

Per le imprese, suggerisco tre regole. Valutare ogni segmento che servite e non accettare mai una media come prova. Costruire set di valutazione dai vostri popolazioni di clienti effettivi. Eseguire test avversari nel linguaggio che i vostri clienti utilizzano. Se servite clienti in quaranta paesi e valutate solo in inglese, avete misurato il vostro sistema per qualcun altro.

Detieni anche un brevetto concesso dall’Ufficio Marchi e Brevetti degli Stati Uniti in apprendimento automatico applicato. Qual era il problema che stavi cercando di risolvere, cosa ti ha insegnato il processo di trasformazione della ricerca AI in innovazione pratica e quale sfida irrisolta di AI agentic ti interessa di più affrontare dopo?

Il brevetto che è stato recentemente approvato affronta un problema di scala e coerenza nella revisione della qualità dei servizi finanziari – la revisione convenzionale delle chiamate è manuale, quindi i revisori umani possono solo campionare una frazione delle chiamate e le loro valutazioni variano da persona a persona. Il mio approccio instrada ogni domanda di qualità e conformità al metodo più adatto a rispondere, con ogni decisione registrata e tracciabile per l’audit.

Puoi vedere gli stessi temi che ho descritto in tutta questa intervista. Instradare ogni compito allo strumento meno potente che possa farlo bene. Tenere gli umani nel loop dove la valutazione conta. E rendere ogni decisione automatizzata tracciabile, perché in un’istituzione regolamentata una risposta senza prove non è una risposta.

Cosa il processo di brevetto mi ha insegnato è che la disciplina è nelle specifiche. Non puoi brevettare un’idea vaga. Devi mostrare esattamente cosa il tuo metodo fa diversamente e esattamente dove si applica. Quella precisione forzata ha reso il lavoro sottostante migliore.

La sfida irrisolta che mi interessa di più ora è la verifica in fase di esecuzione per sistemi multi-agente. Definire invarianti semantiche per un singolo agente è gestibile. So, perché lo facciamo in produzione. Quando gli agenti delegano il lavoro ad altri agenti, il comportamento diventa emergente e i fallimenti si spostano nelle consegne. Un’istruzione viene leggermente reinterpretata a ogni passaggio. Una politica si applica a un agente ma non all’agente che recluta. Verificare l’interazione tra gli agenti, non solo le azioni di ciascuno, è dove mi aspetto che la prossima generazione di fallimenti silenziosi appaia. Quel problema è quello su cui voglio lavorare dopo.

Grazie per la grande intervista, i lettori possono anche voler ordinare il suo libro Agentic AI per Ingegneri.