Dhivya Nagasubramanian, VP de Transformación y Innovación de IA – Serie de Entrevistas

Dhivya Nagasubramanian es VP de Transformación y Innovación de IA en una importante institución financiera de EE. UU., donde lidera el diseño, la implementación y la gobernanza de sistemas de IA agenticos de producción. Es autora de Agentic AI for Engineers (Apress/Springer Nature), una guía práctica para construir sistemas de IA autónomos que pueden ser confiados en producción. Desde su lanzamiento, el libro ha registrado más de 6.000 accesos institucionales en SpringerLink, existencias en más de 260 bibliotecas de todo el mundo y adopción en universidades. Es titular de una patente concedida por la Oficina de Patentes y Marcas de EE. UU. en aprendizaje automático aplicado. Sus intereses de investigación incluyen la creación de aplicaciones resistentes a ataques de jailbreak adversarios y contribuir a esfuerzos industriales más amplios para desarrollar mejores modelos de seguridad y seguridad multicultural. Es una experta solicitada y panelista en múltiples conferencias industriales y académicas.

Su carrera ha progresado desde la consultoría empresarial y la ciencia de datos hasta liderar la transformación de la IA en los servicios financieros. ¿Cómo moldearon esas experiencias Agentic AI for Engineers, y qué brecha recurrente entre la investigación de la IA y la implementación empresarial la convenció de que este libro necesitaba ser escrito?

Comencé en 2008 construyendo sistemas de contabilidad de carteras y medición de rendimiento para plataformas bancarias. Uno de esos proyectos fue un motor compatible con GIPS para calcular rendimientos ponderados en el tiempo, que finalmente utilizaron instituciones financieras en más de 80 países. Ese trabajo me enseñó una lección que ha moldeado toda mi carrera. En finanzas reguladas, el fallo más peligroso es un número incorrecto que parece correcto. Un cálculo ligeramente incorrecto se confía, se informa y se actúa durante años, porque nada parece estar roto.

Vi el mismo patrón nuevamente más tarde. Encontré una brecha estructural en el modelo de Markov de un modelo de atribución de marketing ampliamente utilizado. El marco se utilizó para cientos de miles de usuarios, y el error había sobrevivido durante años por una razón: los resultados parecían razonables. Cuando me mudé a la transformación de la IA en los servicios financieros, vi a los sistemas agenticos repetir este patrón con mucho más en juego. Un agente no solo produce un resultado incorrecto. Toma medidas basadas en él.

La brecha que me convenció de escribir el libro es que la investigación y la implementación empresarial se preocupan por diferentes cosas. La investigación mide la capacidad en benchmarks. Las empresas dependen de cómo se comporta un sistema bajo ambigüedad, datos cambiantes y presión adversa. La mayoría de la escritura sobre agentes se detiene en la etapa de demostración. Escribí Agentic AI for Engineers para el ingeniero que tiene que poner su nombre en un sistema que se ejecutará con supervisión limitada dentro de una institución regulada.

El libro describe el cambio de la automatización a la autonomía como una nueva mentalidad de ingeniería. ¿Qué separa realmente a un agente de IA autónomo de un flujo de trabajo automatizado sofisticado, y dónde es más probable que las organizaciones confundan los dos?

Les doy a los equipos una prueba sencilla. ¿Pueden enumerar todos los caminos que puede tomar el sistema antes de ejecutarlo? Si es así, tienen automatización. Puede ser una automatización muy sofisticada con un modelo de lenguaje dentro de ella, pero sigue siendo automatización. Si el sistema descompone objetivos, elige herramientas y decide el orden de las acciones en tiempo de ejecución según un contexto que no se ha programado, tienen autonomía. La diferencia no tiene nada que ver con qué modelo utilizan. Se reduce a dónde se toman las decisiones.

Las organizaciones confunden los dos en ambos sentidos, pero solo una dirección es costosa. Llamar a un flujo de trabajo de LLM automatizado agéntico es principalmente un problema de marketing. El error costoso es el inverso. Los equipos despliegan toma de decisiones autónoma real bajo una gobernanza que se diseñó para la automatización determinista. Su prueba asume repetibilidad. Su monitoreo asume patrones de falla conocidos. Su registro de auditoría asume que hay una regla trazable detrás de cada acción. Ninguna de esas suposiciones se mantiene para un agente.

Es el cambio de mentalidad que argumento en el libro. Con la automatización, la principal pregunta es si el sistema se ejecutó correctamente. Con la autonomía, la pregunta se convierte en si el sistema decidió correctamente. Responder a eso requiere diferentes instrumentos, diferentes métodos de evaluación y un nivel diferente de precaución.

Muchos sistemas de IA agénticos funcionan de manera impresionante en demostraciones, pero luchan cuando se exponen a usuarios reales, datos cambiantes y herramientas impredecibles. ¿Qué componentes deben considerarse obligatorios en una arquitectura de agente lista para la producción?

La respuesta honesta es que la producción necesita todo lo que una demostración te permite omitir. Una demostración funciona porque alguien controló el entorno.

En el libro, describo una arquitectura de referencia de siete capas, pero estos son los componentes que considero obligatorios. Contratos de herramientas con entradas tipificadas y permisos explícitos, para que el alcance del agente esté limitado por diseño y no por esperanza. Gestión de estado que sobreviva a interrupciones y fallas. Manejo de fallas estructurado con caminos de escalada definidos. Un arnés de evaluación que se ejecuta continuamente, no solo una vez antes del lanzamiento. Y un registro de auditoría que registra las decisiones y el razonamiento detrás de ellas, no solo las acciones tomadas.

El componente que los equipos omiten con más frecuencia es la verificación en tiempo de ejecución. Esta es una capa que verifica cada acción contra el objetivo declarado del agente y las políticas que se aplican a él. La infraestructura estándar te dice si una llamada tuvo éxito. La verificación pregunta si la llamada debería haberse realizado en absoluto. Nunca demuestra su valor en una demostración, porque nada en una demostración necesita ser atrapado. En producción, es lo primero que desearás que hubieras tenido.

Su libro cubre seguridad, alineación, bucles de retroalimentación, pruebas, depuración, evaluación y despliegue. ¿Cómo deben combinar los equipos de ingeniería estos elementos en un proceso de aseguramiento continuo en lugar de tratar la seguridad como una revisión final previa al lanzamiento?

Una revisión final se basa en la suposición de que el sistema que se revisó es el sistema que se ejecutará. Para la IA agéntica, esa suposición falla de tres maneras. Los modelos subyacentes se actualizan. Las herramientas y API en las que depende el agente cambian. Y los datos y el entorno en los que opera el agente siguen cambiando. Una revisión de seguridad única describe un sistema que ya no existe unos meses después.

El aseguramiento continuo significa cerrar el bucle. Las evaluaciones de comportamiento se ejecutan en CI (integración continua) de la misma manera que las pruebas unitarias, y bloquean cada cambio a prompts, herramientas y modelos. El monitoreo en tiempo de ejecución alimenta trazas de producción de vuelta a los conjuntos de evaluación. Describo cuatro patrones de monitoreo en el libro, porque ningún patrón único cubre toda la superficie de falla. Cada incidente produce una nueva comprobación, de la misma manera que cada error debería producir una prueba de regresión. Y las pruebas adversas se ejecutan en un calendario regular en lugar de solo una vez antes del lanzamiento.

El lado organizativo es tan importante como el lado técnico. La seguridad no puede ser un equipo separado que se presente al final con una lista de verificación. Los ingenieros que construyen el agente deben ser dueños de sus suites de evaluación, sus invariantes y su diseño de escalada, porque saben mejor que nadie dónde es más débil el juicio del sistema.

Ha enfatizado la monitorización semántica de las llamadas de herramientas del agente. ¿Qué revela la monitorización semántica que las herramientas de registro y observabilidad convencionales no pueden, y cómo puede detectar cuándo un agente está funcionando técnicamente pero persiguiendo el objetivo incorrecto?

La observabilidad convencional responde a una pregunta: ¿tuvo éxito la llamada? Cubre códigos de estado, esquemas, latencia y tasas de error. No puede responder a la pregunta que más importa a los agentes, que es si la llamada debería haber ocurrido. Una llamada de herramienta puede ser técnicamente perfecta y aún ser la acción incorrecta. Formato correcto, credenciales válidas, respuesta exitosa, cosa equivocada para hacer.

La monitorización semántica evalúa cada acción contra el objetivo declarado del agente y las políticas que se aplican a él. En el libro, describo esto como definir invariantes semánticos sobre las llamadas de herramientas del agente. Estas son propiedades que deben mantenerse sin importar qué camino tome el agente. Un agente que investiga el caso de un cliente no debe acceder a registros fuera de ese caso. Un agente debe marcar una discrepancia por encima de un umbral determinado, nunca resolverla por su cuenta. Cuando se viola un invariante, se atrapa el problema en el momento de la acción en lugar de en una auditoría trimestral.

Esta es también la forma en que se detecta la deriva de objetivos, que considero el fallo definitorio de los sistemas agénticos. La deriva de objetivos se parece a un agente que completa cada paso correctamente según los registros, mientras trabaja silenciosamente hacia el objetivo incorrecto. Nunca aparece en un registro, porque nada falló. La monitorización semántica trata la intención como algo que se mide directamente, y la intención es donde los agentes se equivocan.

Cuando un agente encuentra instrucciones ambiguas, políticas contradictorias, herramientas no disponibles o confianza insuficiente, ¿cómo debe parecerse el manejo de fallas estructurado? ¿Cómo pueden los desarrolladores asegurarse de que el sistema se pause, escale o se recupere en lugar de improvisar?

El problema que hay que diseñar es que la mayoría de los agentes solo tienen una forma de terminar una tarea, que es producir una respuesta. Cuando las instrucciones son ambiguas o las políticas entran en conflicto, el agente improvisa. No porque el modelo sea temerario, sino porque improvisar es el único comportamiento que la arquitectura permite. El manejo de fallas estructurado significa darle al sistema mejores opciones y hacer que sean más fáciles de alcanzar que una respuesta inventada.

En la práctica, eso significa que la negativa y la escalada se diseñan y prueban con el mismo cuidado que el éxito. Recomiendo definir estados de falla tipificados: instrucción ambigua, política contradictoria, herramienta no disponible, confianza insuficiente. Cada uno se asigna a un comportamiento específico. Preguntar una pregunta aclaratoria. Pasar a un ser humano con contexto completo adjunto. Caer a una operación de solo lectura. Volver a intentarlo dentro de límites más estrictos. O detenerse. Los umbrales de confianza deben coincidir con el riesgo de la acción específica. La barra para redactar un resumen interno y la barra para tocar una cuenta de cliente nunca deben ser el mismo número.

Dos prácticas hacen que esto sea real. Primero, diseñe el camino de escalada antes del camino feliz. Si un ser humano recibirá el pase, decida qué contexto obtendrá y qué autoridad tendrá antes de escribir el primer prompt. Segundo, pruebe la falla de la misma manera que pruebe las características. Inyecte instrucciones ambiguas. Deshabilite herramientas en la etapa de prueba. Alimente al agente con políticas contradictorias. Un sistema que nunca ha practicado fallar actuará sin orientación la primera vez que suceda en producción.

Las instituciones financieras deben equilibrar la experimentación con requisitos estrictos sobre privacidad, auditoría, riesgo de modelo y cumplimiento regulatorio. ¿Dónde debe permanecer obligatoria la aprobación humana, y dónde se les puede dar a los agentes una mayor autonomía operativa?

Mi regla es que la aprobación humana debe permanecer obligatoria para cualquier acción que sea irreversible, que mueva dinero o afecte el resultado de un paciente, que involucre comunicaciones del cliente con peso regulatorio, que alimente informes regulatorios o que cambie las herramientas, políticas o permisos del agente. Los agentes pueden asumir más autonomía en el trabajo de leer y razonar: investigación, recuperación, análisis de documentos, triage, redacción y reconciliaciones que marcan discrepancias para revisión humana en lugar de resolverlas.

El error común es requerir aprobación humana en cada paso. Eso no hace que el sistema sea más seguro. Reproduce el proceso manual con pasos adicionales y entrena a los revisores para sellar con el sello de aprobación. Las aprobaciones pertenecen a puntos de decisión reales. Deben ser pocos y cada uno debe estar ocupado por alguien con autoridad real para decir no.

El otro principio es que la autonomía debe ser ganada y no concedida. Comience de manera estrecha. Expanda a medida que el sistema se demuestra bajo monitoreo. Mantenga el registro. En términos de riesgo de modelo, su entorno de control debe permitirle mostrarle a un regulador no solo qué hizo el agente, sino por qué estuvo justificado al darle ese nivel de independencia. Ese registro es la verdadera licencia para operar.

A través de su trabajo en salvaguardias y estándares de inteligencia artificial, está ayudando a definir reglas para sistemas cuyas capacidades siguen cambiando. ¿Qué salvaguardias pueden estandarizarse realistamente hoy, y qué áreas siguen siendo demasiado dependientes del contexto, la industria o el caso de uso?

Las salvaguardias que podemos estandarizar hoy son estructurales. Requieren que ciertos controles existan, estén documentados y puedan ser inspeccionados. Límites de capacidad y permisos documentados para sistemas autónomos. Mecanismos de supervisión y escalada humanos definidos. Obligaciones de detección y notificación de incidentes. Métodos de evaluación y requisitos de evidencia. Responsabilidad clara en todo el ciclo de vida del sistema, para que cuando algo salga mal, la respuesta a quién es responsable nunca sea solo la IA. Estas pueden estandarizarse porque se preocupan por si existen los controles y cuán buenos son, no por los valores específicos que toman.

Lo que no podemos estandarizar todavía son los valores en sí. Umbrales de confianza específicos, taxonomías de daño y niveles de autonomía apropiados dependen en gran medida del contexto. La tolerancia de falla aceptable para un agente de contenido de marketing y para un sistema que toca decisiones clínicas o financieras no son dos puntos en la misma escala. Pertenecen a regímenes diferentes, moldeados por el dominio, la jurisdicción y quién sufre el daño cuando algo falla.

Los controles financieros son un modelo útil aquí. Los requisitos de auditoría se estandarizan a nivel mundial, pero la materialidad siempre se juzga en contexto. Los estándares que respetan esa división tienden a ser adoptados. Los estándares que intentan dictar valores dependientes del contexto tienden a ser ignorados, y un estándar de seguridad que nadie sigue no protege a nadie.

Su investigación reciente ha explorado la robustez multicultural y adversaria en la evaluación de la seguridad de la IA. ¿Qué tipos de fallas de modelo son probablemente pasadas por alto por benchmarks centrados en Occidente o promedios globales, y cómo deben evaluar las empresas los sistemas destinados a la implementación multicultural?

Mirar solo los benchmarks promediados puede pasar por alto las fallas que más importan. Un modelo puede tener una puntuación de seguridad general fuerte mientras falla mal para un contexto cultural o lingüístico específico, porque esas fallas desaparecen en el promedio. La evaluación centrada en Occidente agrega otro punto ciego. Pasa por alto los daños que son culturalmente específicos, como modismos, gestos y contextos religiosos o regionales donde la misma salida es inofensiva en una cultura y dañina en otra. También subprueba el cambio de código, la transliteración y los nombres y entidades no occidentales. Hay un ángulo adversario también. Los atacantes no apuntan a su rendimiento promedio. Encuentran su rebanada más débil, y para la mayoría de los modelos esa rebanada es un lenguaje de bajo recurso o un contexto cultural subevaluado.

Esto es lo que me llevó a contribuir a la investigación de benchmarks de seguridad de la IA multicultural. El hallazgo central es sencillo. Juzgar la seguridad a través de las culturas requiere datos de evaluación y juicio humano extraídos de esas culturas. No se puede evaluar el daño desde fuera del contexto en el que ocurre.

Para las empresas, sugiero tres reglas. Evalúe cada segmento que sirva, y nunca acepte un promedio como evidencia. Construya conjuntos de evaluación a partir de sus poblaciones de clientes reales. Ejecute pruebas adversas en los idiomas que utilizan sus clientes. Si sirve a clientes en cuarenta países y solo evalúa en inglés, ha medido su sistema para la implementación de alguien más.

También es titular de una patente concedida por la Oficina de Patentes y Marcas de EE. UU. en aprendizaje automático aplicado. ¿Qué problema estaba tratando de resolver, qué le enseñó el proceso sobre convertir la investigación de la IA en innovación práctica, y qué desafío de la IA agéntica sin resolver es el que más le interesa abordar a continuación?

La patente que se aprobó recientemente aborda un problema de escala y coherencia en la revisión de la calidad de los servicios financieros — la revisión de llamadas convencional es manual, por lo que los revisores humanos solo pueden muestrear una fracción de las llamadas, y sus evaluaciones varían de persona a persona. Mi enfoque enruta cada pregunta de calidad y cumplimiento a el método mejor adaptado para responderla, con cada decisión registrada y trazable para auditoría.

Puede ver los mismos temas que he descrito a lo largo de esta entrevista. Enrutar cada tarea a la herramienta menos poderosa que pueda hacerlo bien. Mantener a los humanos en el bucle donde la juicio importa. Y hacer que cada decisión automatizada sea trazable, porque en una institución regulada una respuesta sin evidencia no es una respuesta.

Lo que me enseñó el proceso de patentes es que la disciplina está en los detalles. No se puede patentar una idea vaga. Tienes que mostrar exactamente qué hace tu método de manera diferente, y exactamente dónde se aplica. Esa precisión forzada hizo que el trabajo subyacente fuera mejor.

El desafío sin resolver que más me importa ahora es la verificación en tiempo de ejecución para sistemas de múltiples agentes. Definir invariantes semánticos para un agente único es manejable. Lo sé, porque lo hacemos en producción. Cuando los agentes delegan trabajo a otros agentes, el comportamiento se vuelve emergente, y las fallas se mueven a las transferencias. Una instrucción se interpreta ligeramente de manera diferente en cada paso. Una política se aplica a un agente pero no al agente que recluta. Verificar la interacción entre los agentes, no solo las acciones de cada uno, es donde espero que aparezcan la próxima generación de fallas silenciosas. Ese es el problema que quiero trabajar a continuación.

Gracias por la gran entrevista, los lectores también pueden pedir su libro Agentic AI for Engineers.