Cuatro patrones para la monitorización de agentes IA en producción

Probablemente, una de las áreas en que más se trabaje, o al menos que, digamos, más 'preocupación' genere en el tema de los agentes IA sea la gobernanza de éstos y, más específicamente, como gestionarlos adecuadamente en producción, cómo hacer que sean seguros, cómo vigilar que tengan un comportamiento correcto, cómo asegurar que funcionan como esperamos que funcionen.

 

Inteligentes pero imprevisibles

Y esta labor no es trivial en absoluto pese a la cantidad de años que llevamos monitorizando todo tipo de sistemas, garantizando su seguridad, sus prestaciones y su escalabilidad, y a pesar de la abundancia de soluciones y herramientas que existen para ello.

Y la dificultad surge, no del hecho de que los agentes sean un tipo de software novedoso, sino de la naturaleza misma de este tipo de solución basada en IA, de lo que les diferencia y les da valor.

Los agentes son un tipo de software autónomo, pero eso no es nada nuevo. Existen desde hace décadas sistemas que se comportan de manera autónoma. Y sabemos monitorizarlos y operarlos.

Los agentes, como su propio nombre indica, son también capaces de actuar, esto es, de realizar acciones sobre sistemas de ficheros, sobre bases de datos o sobre otras aplicaciones. Pero esto no es tampoco nada nuevo y nada que en general no sepamos controlar. Esa misma capacidad de actuación, además de una forma bastante parecida, la tienen también muchos otros sistemas autónomos, como los robots RPA que describía en mi libro 'Robots en la sombra' o los modernos workflows en la nube que construimos con plataformas como Make, N8N, Zapier o Power Automate Cloud.

No, la verdadera dificultad no está ahí, no está en la autonomía y ni en la capacidad de actuación. sino en la forma en que estos sistemas autónomos 'deciden' que hay que hacer. Todos los demás sistemas autónomos que les han precedido y con los que conviven, tienen marcada, de una forma rigurosa y cerrada, la lógica que deben seguir para llevar a cabo la tarea que tienen encomendada y automatizarla. Esta lógica se establece en tiempo de desarrollo por el propio desarrollador y suele adoptar la forma de un flujo, un workflow, aunque pueden existir otras formas de fijar reglas de comportamiento.

El caso de los agentes es muy diferente. No tienen una lógica pre-establecida, sino un objetivo o tarea, unas reglas de comportamiento muy generales expresadas en lenguaje natural y una serie de capacidades de actuación mediante las denominadas herramientas ('tools'). Pero la verdadera lógica de solución la decide el agente usando sus capacidades razonadoras basadas en un gran modelo de lenguaje, y lo hace en tiempo de ejecución, no de desarrollo.

Eso nos lleva a un comportamiento sin duda más inteligente, más flexible y más adaptativo, pero precisamente por eso, hasta cierto punto imprevisible. No quiero decir con ello que sean completamente imprevisibles, pero sí que no existen unas reglas exactas y que el agente tiene, digamos, grados de libertad.

Difíciles de probar, difíciles de monitorizar

Esa imprevisibilidad los hace difíciles de probar, porque no podemos establecer un catálogo exhaustivo y cerrado de casos de prueba que garanticen haber ejercitado con éxito todas los escenarios posibles. Ni siquiera es siempre posible definir con claridad cuál es el resultado que consideraríamos correcto para dar por bueno el caso.

Esas mismas dificultades se trasladan a a la monitorización en producción. Podemos monitorizar, claro, ciertas manifestaciones externas de su comportamiento como, por ejemplo, invocaciones de cada herramienta a su disposición o los datos que generan. Pero como el comportamiento es abierto, y hasta cierto punto imprevisible, es difícil disponer de unos mecanismos claros y cerrados para asegurar que el agente se comporta adecuadamente, que no incurre en riesgos no admisibles y que, por supuesto, no comete errores.

Cuatro patrones para la monitorización de agentes

Es por eso que me ha interesado la propuesta de patrones para esa monitorización que he encontrado en el libro 'Building Applications with AI Agents' de Michael Albada donde nos plantea cuatro patrones de monitorización. Son los siguientes:

• Shadow mode (modo sombra): Se trata, en realidad, de un mecanismo transitorio hasta que ganemos confianza en un agente nuevo. La idea es, cuando despleguemos un agente nuevo, mantener a este recibiendo datos reales pero sin enviar salidas a los usuarios y sin realizar acciones reales. De esta forma, durante un tiempo se puede observar su comportamiento en situaciones reales y ver que se comporta bien, antes de otorgarle 'plenos poderes'. En realidad, es casi más un mecanismo de prueba que de monitorización.


• Canary deployments (despliegues 'canario'): También se sitúa un poco en la línea de poner a prueba un agente nuevo en situaciones reales sin dejarle hacer daño, pero va un poco más lejos que la opción anterior. En este caso lo que se hace es que el nuevo agente sólo actúe en un porcentaje bajo (digamos entre un 3% y un 5%) de las situaciones reales, mientras que el resto se tratan 'normalmente' (con una versión anterior del agente, con un sistema más tradicional o manualmente, si es el caso). Estrictamente hablando, no impedimos que el agente pueda hacer daño, pero minimizamos el riesgo y el posible impacto


• Regression trace collection (recolección de trazas de regresión): Ahora, más bien, lo que tratamos es de aprender del pasado. Y lo hacemos también mediante un mecanismo bien conocido: la recolección y análisis de trazas. Para ello se recopilan trazas (logs) y, cuando se produce un fallo, se estudian para intentar entender qué ha pasado y arreglarlo de cara al futro.


• Self-healing agentes (agentes auto-curativos): Se trata de agentes que reciben los propios datos de monitorización, y las propias métricas y son capaces de implementar mecanismos de recuperación ante fallos.

La verdad es que de estos cuatro mecanismos, sólo el último es realmente novedoso. Los otros tres ya se han venido aplicando con mayor o menor intensidad en la monitorización y operación de otro tipo de sistemas.

Se trata de mecanismos que disminuyen el riesgo y el impacto de posibles malos funcionamientos, pero, por supuesto, no los evitan completamente.

En cualquier caso, parecen buenas prácticas que 'van a favor de obra' en busca de ese objetivo de tener a los agentes bajo control.

Conclusiones

Los agentes de IA, por su propia naturaleza, son difíciles de probar, de monitorizar y de operar.

Hemos visto cuatro patrones de operación de agentes que, si bien no eliminan el riesgo, sí pueden ayudar a tenerlo bajo control.