Un equipo de desarrollo conjunto de Microsoft y Novo Nordisk ha reimplementado un agente de IA que los expertos médicos utilizan para explorar los datos de ensayos clínicos de Novo Nordisk, trasladándolo a Microsoft Foundry como agente alojado. En un artículo publicado en Command Line, los autores afirman que el cambio simplificó las operaciones, reforzó la separación entre las sesiones de los usuarios y conectó el agente directamente con las herramientas de trazabilidad, evaluación y optimización de Foundry.
Qué hace el agente
El agente respalda el análisis secundario, es decir, el trabajo que va más allá del protocolo de un ensayo, como contrastar una hipótesis o comparar grupos de pacientes. Según el equipo, su herramienta central es el código que escribe y ejecuta en un entorno controlado, tras lo cual devuelve un resumen y un gráfico. El proyecto surgió de un trabajo de ingeniería de despliegue avanzado (forward-deployed engineering). Su primera versión de producción se ejecutaba en Azure Container Apps, con PostgreSQL para almacenar las conversaciones y las sesiones dinámicas de Azure Container Apps como entornos aislados (sandboxes) para el código. Eso dejaba al equipo a cargo del escalado, los ciclos de vida de las sesiones, el aislamiento, las redes y la telemetría.
Con el nuevo planteamiento, los autores afirman que siguen eligiendo los modelos y las herramientas y decidiendo cómo orquesta el agente su trabajo. Foundry ahora gestiona el punto de conexión y la identidad del agente, aporta capacidad de cómputo para cada sesión, conserva el estado y se encarga del escalado.
Sesiones separadas
Uno de los cambios que destacan los autores es la forma de separar las sesiones. Cada una se ejecuta ahora en un entorno aislado dedicado, con aislamiento a nivel de máquina virtual, que Foundry inicia bajo demanda y elimina cuando transcurre un periodo de inactividad configurado. El equipo señala que esto es importante porque el propio código generado por el agente opera sobre datos clínicos sensibles. Foundry Agent Service también ofrece redes privadas, que según los autores les permiten controlar el tráfico entrante y saliente de datos que deben permanecer dentro de un perímetro aprobado.
La plataforma no asume la responsabilidad de la seguridad ni de la calidad, subraya el equipo. Aun así, tuvieron que definir controles de acceso, proteger y reducir la telemetría, probar el agente con su propio caso de uso y examinar cada sistema al que el agente puede llamar.
Planificar la red con antelación
Los autores sostienen que las redes privadas deben resolverse en la fase de diseño. Las sesiones consumen direcciones IP y la subred asociada a una cuenta de Foundry no se puede cambiar después, por lo que un rango demasiado pequeño podría convertir un aumento de capacidad rutinario en una migración de infraestructura de mayor alcance. Citan la guía actual de Foundry: una subred /24 para producción, siendo /27 el tamaño mínimo admitido para implementaciones más pequeñas.
Trazas y controles de calidad
La trazabilidad de Foundry se basa en OpenTelemetry y guarda los datos en Azure Monitor Application Insights; durante la transición, el equipo también envió trazas a Langfuse. Dado que una traza puede registrar peticiones, resultados y las entradas y los resultados de las herramientas, los autores afirman que la telemetría clínica merece el mismo tratamiento que otros datos sensibles de producción, lo que incluye la redacción u ocultación de datos, la minimización, los límites de conservación y el acceso restringido.
El equipo no tocó sus contratos de backend, de modo que su marco de evaluación existente pudo acceder al agente reconstruido sin cambios y puntuarlo con el mismo conjunto de pruebas y los mismos evaluadores, incluidas comparaciones con respuestas de referencia de expertos en la materia. Esas puntuaciones sirvieron como referencia de migración y como control frente a regresiones, señalan los autores.
El artículo es el relato del propio equipo del proyecto, y no una evaluación independiente.
