Dhivya Nagasubramanian, VP de Transformação e Inovação de IA – Série de Entrevistas

Dhivya Nagasubramanian é VP de Transformação e Inovação de IA em uma grande instituição financeira dos EUA, onde lidera o design, implantação e governança de sistemas de IA agêntica em produção. Ela é autora de Agentic AI for Engineers (Apress/Springer Nature), um guia prático para construir sistemas de IA autônomos que possam ser confiáveis em produção. Desde o seu lançamento, o livro registrou mais de 6.000 acessos institucionais no SpringerLink, acervos em mais de 260 bibliotecas em todo o mundo e adoção em universidades. Ela é detentora de uma patente concedida pelo USPTO em aprendizado de máquina aplicado. Seus interesses de pesquisa incluem construir aplicações resistentes a ataques de jailbreak adversários e contribuir para esforços mais amplos da indústria para desenvolver melhores modelos de segurança e segurança multicultural. Ela é uma especialista procurada e palestrante em múltiplas conferências da indústria e acadêmicas.

Sua carreira progrediu de consultoria empresarial e ciência de dados para liderar a transformação de IA nos serviços financeiros. Como essas experiências moldaram Agentic AI for Engineers, e qual lacuna recorrente entre a pesquisa de IA e a implantação empresarial convenceu você de que este livro precisava ser escrito?

Eu comecei em 2008 construindo sistemas de contabilidade de carteira e medição de desempenho para plataformas bancárias. Um desses projetos foi um motor GIPS-compliant para calcular retornos ponderados no tempo, que instituições financeiras em mais de 80 países eventualmente usaram. Esse trabalho me ensinou uma lição que moldou toda a minha carreira. Em finanças regulamentadas, a falha mais perigosa é um número errado que parece correto. Um cálculo sutilmente incorreto é confiável, relatado e agido por anos, porque nada parece quebrado.

Eu vi o mesmo padrão novamente mais tarde. Encontrei uma lacuna estrutural no modelo de Markov de um modelo de atribuição de marketing amplamente utilizado. O framework foi usado por centenas de milhares de usuários, e o erro sobreviveu por anos por um motivo: os resultados pareciam razoáveis. Quando me mudei para a transformação de IA nos serviços financeiros, observei sistemas agênticos repetirem esse padrão com apostas muito mais altas. Um agente não produz apenas um resultado errado. Ele toma ação com base nele.

A lacuna que me convenceu a escrever o livro é que a pesquisa e a implantação empresarial se importam com coisas diferentes. A pesquisa mede a capacidade em benchmarks. As empresas dependem de como um sistema se comporta sob ambiguidade, dados em mudança e pressão adversária. A maioria dos textos sobre agentes para de funcionar no estágio da demonstração. Eu escrevi Agentic AI for Engineers para o engenheiro que tem que colocar seu nome em um sistema que irá funcionar com supervisão limitada dentro de uma instituição regulamentada.

O livro descreve a mudança de automação para autonomia como uma nova mentalidade de engenharia. O que realmente separa um agente de IA autônomo de um fluxo de trabalho automatizado sofisticado, e onde as organizações estão mais propensas a confundir os dois?

Eu dou aos times um teste simples. Você pode listar todos os caminhos que o sistema pode tomar antes de executá-lo? Se sim, você tem automação. Pode ser uma automação muito sofisticada com um modelo de linguagem dentro dela, mas ainda é automação. Se o sistema quebra metas, escolhe ferramentas e decide a ordem de ações em tempo de execução com base no contexto que você não script, você tem autonomia. A diferença não tem nada a ver com qual modelo você usa. Vem abaixo de onde as decisões são tomadas.

As organizações confundem os dois em ambas as direções, mas apenas uma direção é cara. Chamar um fluxo de trabalho LLM script de agêntico é principalmente um problema de marketing. O erro custoso é o inverso. Times implantam tomada de decisão autônoma genuína sob governança que foi projetada para automação determinística. Seu teste assume repetibilidade. Sua monitoração assume padrões de falha conhecidos. Sua trilha de auditoria assume que há uma regra rastreável por trás de cada ação. Nenhuma dessas suposições se mantém para um agente.

Essa é a mudança de mentalidade que eu argumento no livro. Com a automação, a principal pergunta é se o sistema foi executado corretamente. Com a autonomia, a pergunta se torna se o sistema decidiu corretamente. Responder isso requer instrumentação diferente, métodos de avaliação diferentes e um nível diferente de cautela.

Muitos sistemas de IA agêntica performam impressionantemente em demonstrações, mas lutam quando expostos a usuários reais, dados em mudança e ferramentas imprevisíveis. Quais componentes devem ser considerados obrigatórios em uma arquitetura de agente pronta para produção?

A resposta honesta é que a produção precisa de tudo o que uma demonstração deixa você pular. Uma demonstração funciona porque alguém controlou o ambiente. A produção tira esse controle.

No livro, descrevo uma arquitetura de referência de sete camadas, mas esses são os componentes que considero obrigatórios. Contratos de ferramentas com entradas tipadas e permissões explícitas, para que o alcance do agente seja limitado por design e não por esperança. Gerenciamento de estado que sobrevive a interrupções e falhas. Tratamento de falha estruturado com caminhos de escalada definidos. Uma estrutura de avaliação que roda continuamente, não apenas uma vez antes do lançamento. E uma trilha de auditoria que registra decisões e o raciocínio por trás delas, não apenas as ações tomadas.

O componente que as equipes pulam com mais frequência é a verificação em tempo de execução. Essa é uma camada que verifica cada ação contra o objetivo declarado do agente e as políticas que se aplicam a ele. A infraestrutura padrão diz se a chamada foi bem-sucedida. A verificação pergunta se a chamada deveria ter sido feita em primeiro lugar. Nunca prova seu valor em uma demonstração, porque nada em uma demonstração precisa ser capturado. Em produção, é a primeira coisa que você desejará ter.

Seu livro cobre segurança, alinhamento, laços de feedback, teste, depuração, avaliação e implantação. Como as equipes de engenharia devem combinar esses elementos em um processo de garantia contínua em vez de tratar a segurança como uma revisão final pré-lançamento?

Uma revisão final se baseia na suposição de que o sistema que você revisou é o sistema que irá funcionar. Para a IA agêntica, essa suposição falha de três maneiras. Os modelos subjacentes são atualizados. As ferramentas e APIs em que o agente depende mudam. E os dados e o ambiente em que o agente opera continuam mudando. Uma revisão de segurança única descreve um sistema que não existe mais alguns meses depois.

Garantia contínua significa fechar o loop. Avaliações comportamentais rodam em CI (integração contínua) da mesma forma que os testes de unidade, e elas bloqueiam cada alteração em prompts, ferramentas e modelos. A monitoração em tempo de execução alimenta traços de produção de volta para os conjuntos de avaliação. Descrevo quatro padrões de monitoramento no livro, porque nenhum único padrão cobre toda a superfície de falha. Cada incidente produz uma nova verificação, da mesma forma que cada bug deve produzir um teste de regressão. E o teste adversário roda em um cronograma regular em vez de apenas uma vez antes do lançamento.

O lado organizacional importa tanto quanto o lado técnico. A segurança não pode ser uma equipe separada que aparece no final com uma lista de verificação. Os engenheiros que constroem o agente devem possuir seus conjuntos de avaliação, suas invariantes e seu design de escalada, porque eles sabem melhor do que ninguém onde o julgamento do sistema é mais fraco.

Você enfatizou a monitoração semântica de chamadas de ferramentas do agente. O que a monitoração semântica revela que os logs e ferramentas de observabilidade convencionais não podem, e como pode detectar quando um agente está funcionando tecnicamente, mas perseguindo o objetivo errado?

Os logs e ferramentas de observabilidade convencionais respondem a uma pergunta: a chamada foi bem-sucedida? Eles cobrem códigos de status, esquemas, latência e taxas de erro. Eles não podem responder à pergunta que mais importa para os agentes, que é se a chamada deveria ter acontecido. Uma chamada de ferramenta pode ser tecnicamente perfeita e ainda ser a ação errada. Formato correto, credenciais válidas, resposta bem-sucedida, coisa errada para fazer.

A monitoração semântica avalia cada ação contra o objetivo declarado do agente e as políticas que se aplicam a ele. No livro, descrevo isso como definir invariantes semânticos sobre chamadas de ferramentas do agente. Essas são propriedades que devem ser mantidas, não importa qual caminho o agente tome. Um agente que pesquisa o caso de um cliente nunca deve acessar registros fora desse caso. Um agente deve sinalizar uma discrepância acima de um certo limiar, nunca resolvê-la sozinho. Quando uma invariante é violada, você captura o problema no momento da ação em vez de em uma auditoria trimestral.

Essa é também a forma como você detecta a deriva de objetivo, que considero a falha definidora dos sistemas agênticos. A deriva de objetivo parece um agente que completa cada etapa corretamente de acordo com os logs, enquanto trabalha silenciosamente para o objetivo errado. Nunca aparece em um log, porque nada falhou. A monitoração semântica trata a intenção como algo que você mede diretamente, e a intenção é onde os agentes dão errado.

Quando um agente encontra instruções ambíguas, políticas conflitantes, ferramentas indisponíveis ou confiança insuficiente, como o tratamento de falha estruturado deve parecer? Como os desenvolvedores podem garantir que o sistema pause, escale ou se recupere em vez de improvisar?

O problema a ser projetado é que a maioria dos agentes tem apenas uma maneira de terminar uma tarefa, que é produzir uma resposta. Quando as instruções são ambíguas ou as políticas conflitam, o agente improvisa. Não porque o modelo é temerário, mas porque improvisar é o único comportamento que a arquitetura permite. O tratamento de falha estruturado significa dar ao sistema melhores opções e torná-las mais fáceis de alcançar do que uma resposta inventada.

Na prática, isso significa que a recusa e a escalada são projetadas e testadas com o mesmo cuidado que o sucesso. Recomendo definir estados de falha tipados: instrução ambígua, política conflitante, ferramenta indisponível, confiança insuficiente. Cada um mapeia para um comportamento específico. Faça uma pergunta esclarecedora. Passe para um humano com contexto completo anexado. Diminua para operação somente leitura. Tente novamente dentro de limites mais apertados. Ou pare. Limiares de confiança devem corresponder ao risco da ação específica. A barra para redigir um resumo interno e a barra para tocar uma conta de cliente nunca devem ser o mesmo número.

Dois práticas tornam isso real. Primeiro, projete o caminho de escalada antes do caminho feliz. Se um humano receber a transferência, decida qual contexto ele obtém e qual autoridade ele tem antes de escrever o primeiro prompt. Segundo, teste a falha da mesma forma que você testa os recursos. Injete instruções ambíguas. Desabilite ferramentas em staging. Alimente o agente com políticas conflitantes. Um sistema que nunca praticou falhar agirá sem orientação da primeira vez que acontecer em produção.

Instituições financeiras devem equilibrar experimentação com requisitos estritos em torno de privacidade, auditoria, risco de modelo e conformidade regulatória. Onde a aprovação humana deve permanecer obrigatória, e onde os agentes podem ser seguramente dados com maior autonomia operacional?

Minha regra é que a aprovação humana deve permanecer obrigatória para qualquer ação que seja irreversível, que mova dinheiro ou afete o resultado de um paciente, que envolva comunicações de clientes com peso regulatório, que alimente relatórios regulatórios, ou que mude as próprias ferramentas, políticas ou permissões do agente. Os agentes podem tomar mais autonomia em trabalho de leitura e razão: pesquisa, recuperação, análise de documentos, triagem, redação e reconciliações que sinalizam discrepâncias para revisão humana em vez de resolvê-las.

O erro comum é exigir aprovação humana em cada etapa. Isso não torna o sistema mais seguro. Isso recria o processo manual com etapas extras e treina revisores para carimbar. As aprovações pertencem a pontos de decisão reais. Deve haver poucas delas, e cada uma deve ser ocupada por alguém com autoridade real para dizer não.

O outro princípio é que a autonomia deve ser conquistada e não concedida. Comece estreito. Expanda à medida que o sistema se prova sob monitoramento. Mantenha o registro. Em termos de risco de modelo, seu ambiente de controle deve permitir que você mostre a um regulador não apenas o que o agente fez, mas por que você estava justificado em dar a ele esse nível de independência. Esse registro é a verdadeira licença para operar.

Através do seu trabalho em salvaguardas e padrões de inteligência artificial, você está ajudando a definir regras para sistemas cujas capacidades continuam a mudar. Quais salvaguardas podem ser realisticamente padronizadas hoje, e quais áreas permanecem muito dependentes de contexto, indústria ou caso de uso?

As salvaguardas que podemos padronizar hoje são estruturais. Elas exigem que certos controles existam, sejam documentados e possam ser inspecionados. Limites de capacidade e permissão documentados para sistemas autônomos. Mecanismos de supervisão humana e escalada definidos. Obrigações de detecção e relatório de incidentes. Métodos de avaliação e requisitos de evidência. Responsabilidade clara ao longo do ciclo de vida do sistema, para que, quando algo dá errado, a resposta para quem é responsável nunca seja apenas a IA. Isso pode ser padronizado porque se preocupa com a existência dos controles e como são bons, e não com os valores específicos que eles tomam.

O que ainda não podemos padronizar são os próprios ajustes. Limiares de confiança específicos, taxonomias de dano e níveis de autonomia apropriados dependem fortemente do contexto. A tolerância de falha aceitável para um agente de conteúdo de marketing e para um sistema que toca decisões clínicas ou financeiras não são dois pontos na mesma escala. Eles pertencem a regimes diferentes, moldados pelo domínio, jurisdição e quem sofre o dano quando algo falha.

Controles financeiros são um modelo útil aqui. Requisitos de auditoria são padronizados globalmente, mas a materialidade é sempre julgada no contexto. Padrões que respeitam essa divisão tendem a ser adotados. Padrões que tentam ditar valores dependentes de contexto tendem a ser ignorados, e um padrão de segurança que ninguém segue não protege ninguém.

Sua pesquisa recente explorou robustez multicultural e adversária em avaliação de segurança de IA. Quais tipos de falhas de modelo são prováveis de serem perdidas por benchmarks ocidentais ou globalmente average, e como as empresas devem avaliar sistemas destinados a implantação multicultural?

Olhar apenas para benchmarks average pode perder as falhas que mais importam. Um modelo pode postar uma pontuação de segurança geral forte enquanto falha mal para um contexto linguístico, dialeto ou cultural específico, porque essas falhas desaparecem na média. A avaliação ocidental adiciona outro ponto cego. Ela perde danos que são culturalmente específicos, como expressões idiomáticas, gestos e contextos religiosos ou regionais onde a mesma saída é inofensiva em uma cultura e danosa em outra. Ela também sub-testa a troca de código, transliteração e nomes e entidades não ocidentais. Há um ângulo adversário também. Atacantes não visam seu desempenho médio. Eles encontram seu fatia mais fraca, e para a maioria dos modelos essa fatia é uma linguagem de baixo recurso ou um contexto cultural subavaliado.

Isso me levou a contribuir para a pesquisa de benchmarks de segurança de IA multicultural. A descoberta central é direta. Julgar a segurança através de culturas exige dados de avaliação e julgamento humano extraídos dessas culturas. Você não pode avaliar dano de fora do contexto em que ele ocorre.

Para as empresas, sugiro três regras. Avalie cada segmento que você serve, e nunca aceite uma média como evidência. Construa conjuntos de avaliação a partir de suas populações de clientes reais. Execute testes adversários nas línguas que seus clientes usam. Se você serve clientes em 40 países e avalia apenas em inglês, você mediu seu sistema para a implantação de outra pessoa.

Você também é detentora de uma patente concedida pelo United States Patent and Trademark Office em aprendizado de máquina aplicado. Qual problema você estava tentando resolver, o que o processo ensinou sobre transformar pesquisa de IA em inovação prática, e qual desafio de IA agêntica não resolvido você está mais interessada em abordar em seguida?

A patente que foi recentemente aprovada aborda um problema de escala e consistência na revisão de qualidade de serviços financeiros — a revisão de chamadas convencional é manual, então revisores humanos só podem amostrar uma fração das chamadas, e suas avaliações variam de pessoa para pessoa. Minha abordagem roteia cada pergunta de qualidade e conformidade para o método mais adequado para respondê-la, com cada decisão registrada e rastreável para auditoria.

Você pode ver os mesmos temas que eu descrevi ao longo desta entrevista. Roteie cada tarefa para a ferramenta menos poderosa que possa fazer bem. Mantenha os humanos no loop onde o julgamento importa. E faça cada decisão automática rastreável, porque em uma instituição regulamentada uma resposta sem evidência não é uma resposta.

O que o processo de patente me ensinou é que a disciplina está nos detalhes. Você não pode patentear uma ideia vaga. Você tem que mostrar exatamente o que seu método faz de diferente, e exatamente onde ele se aplica. Essa precisão forçada tornou o trabalho subjacente melhor.

O desafio não resolvido que me importa agora é a verificação em tempo de execução para sistemas de multiagentes. Definir invariantes semânticos para um agente único é gerenciável. Eu sei, porque fazemos isso em produção. Quando os agentes delegam trabalho a outros agentes, o comportamento se torna emergente, e as falhas se movem para as transferências. Uma instrução é ligeiramente reinterpretada a cada etapa. Uma política se aplica a um agente, mas não ao agente que ele recruta. Verificar a interação entre os agentes, não apenas as ações de cada um, é onde eu espero que a próxima geração de falhas silenciosas apareça. Esse é o problema que eu quero trabalhar em seguida.

Obrigado pela grande entrevista, os leitores também podem querer pedir o livro Agentic AI for Engineers.