Por un lado, me resulta excitante el concepto y la posibilidad de que seamos capaces de construirlos y, además, con cierta facilidad.
Por otro, me generan dudas, no de manera general, sino en aspectos particulares o casos de uso particulares.
Voy a recoger algunas de esas consideraciones en una mini-serie de posts, entre tres o cuatro artículos, comenzando por el de hoy.
En concreto hoy hablaré de lo que tiene que ver con la automatización, la repetitividad y la calidad, un tema al que de alguna forma ya me he aproximado en algún artículo anterior.
Martillos y clavos. El martillo de oro
En cierto modo, y más allá de que creo que los agentes IA constituyen todavía una tecnología y un tipo de solución que tiene que mejorar mucho en cuanto a fiabilidad, pruebas y gobernanza, podría decir que mis cuitas con respecto a los agentes tienen que ver, sobre todo, con que los estemos tratando como un martillo de oro. ¿A qué me refiero? ¿Qué es un martillo de oro? En su entrada en wikipedia se expresa de una forma muy simple
Un martillo de oro (o martillo dorado) es cualquier herramienta, tecnología, paradigma o similar cuyos partidarios ensalzan de manera exagerada. Predicen que resolverá múltiples problemas, incluso aquellos para los que obviamente no es adecuada.
Aunque, quizá su formulación más conocida, también para mí, sea la que se atribuye al muy afamado psicólogo Abraham Maslow y que se denomina por ello, a veces, como martillo de Maslow, a saber:
Si sólo tienes un martillo, todo parece un clavo.
Y, en efecto, tengo la sensación de que estamos considerando a los agentes, en ocasiones a toda la IA, como un martillo y que, por tanto, sólo vemos clavos, queriendo decir con ello que todo lo queremos resolver mediante agentes, sean o no adecuados, y existiendo o no mejores soluciones alternativas.
Agentes y Agentic AI
Simplificando, y como ya he explicado en algún otro post, y como probablemente muchos lectores de este blog conozcan, los agentes (en la acepción de agente referida a los agentes IA que conforman la denominada Agentic AI) no son más (bueno, ni menos) que aplicaciones construidas alrededor de un gran modelo de lenguaje de tipo razonador, unas aplicaciones que, aunque pueden interactuar con el usuario, en general funcionan de manera autónoma y que, además, pueden realizar tareas especiales y, sobre todo, interactuar con el exterior, mediante las denominadas herramientas ('tools').
Mediante estas herramientas, el agente es capaz, por ejemplo, de leer un correo electrónico, leer datos de una pantalla, consultar datos en una aplicación y un larguísimo, casi infinito, etcétera. Y no sólo leer, también escribir o invocar acciones.
¿Hemos descubierto la pólvora?
Sin embargo, existen ya desde hace años, muchos otros tipos de aplicaciones que hacen algo similar, en el sentido de aplicar una cierta lógica para automatizar un proceso o tarea funcionando de manera autónoma e interactuando con el exterior haciendo uso, fundamentalmente, de APIs y conectores.
Cabe decir, además, que con independencia de los cambios de nombre, las herramientas funcionan de forma similar a, y de hecho se suelen apoyar en, APIs y conectores. Los afamados servidores MCP no dejan de ser una implementación algo especial de los conectores de toda la vida.
Entre ese tipo de soluciones que aplican de forma autónoma una lógica interrelacionándose vía conectores con el exterior, tenemos los chatbots basados en reglas y, sobre todo los robots RPA sobre todo en su variante no atendida, protagonistas ambos de mi libro 'Robots en la sombra'. Y, hasta cierto punto, aunque normalmente con menor autonomía, también podríamos incluir en este apartado las soluciones BPMS ('Business Process Management System').
¿Qué pasa entonces? ¿Es que con los agentes hemos 'descubierto la pólvora' o el Mediterráneo? ¿Es que no son más que un nuevo nombre o una nueva implementación de algo que ya teníamos?
Elementos diferenciales de los agentes IA
No, aunque comparten elementos comunes, bastante elementos comunes de hecho, con otras formas de automatización, tienen algunas características diferenciales, alguna tremendamente diferencial.
Me voy a centrar en dos.
La primera que, con ser importante, casi la veo secundaria, es que a un agente IA sus objetivos o la tarea a realizar se le indican en lenguaje natural, no mediante código, ni mediante reglas o flujos expresadas en un lenguaje más o menos formal. Simplemente, lenguaje natural.
Pero lo que creo que cambia radicalmente el planteamiento es que el 'cerebro', quien decide el plan y, por tanto la lógica, a aplicar, es un modelo de lenguaje razonador, no un desarrollador humano. Y esto tiene varias implicaciones muy importantes:
- Decide la IA, no el humano, la lógica a aplicar en cada caso.
- Por lo anterior, eventualmente un agente podría atacar la automatización de una tarea que un humano no sabe exactamente cómo resolver.
- La lógica, el plan a aplicar, se decide en tiempo de ejecución, no en tiempo de diseño o desarrollo
- El plan, la lógica a aplicar, es flexible, dinámico y adaptativo
- El plan que se aplica puede variar de una instancia de tarea (un caso que se diría en proceso so automatización) a otra.
Automatización
Cuando automatizamos tareas, es decir, cuando eliminamos la participación de un humano (o eventualmente un animal) de un proceso, solemos buscar los siguientes objetivos:
- Ahorro de costes, ya que el trabajo humano es caro
- Alta disponibilidad
- Reducción de tiempos de proceso
- Eliminación de errores
- Control del proceso y predecibilidad de sus resultados (calidad)
- Cumplimiento normativo
Los sistemas basados en reglas y workflows
Los sistemas de automatización de procesos y tareas, típicamente los BPMS (Appian, Pega, etc) , RPA (UiPath, Blue Prism, Automation Anywhere, Power Automate, etc) o workflows en la nube (Make, Zapier, N8N, etc) o incluso soluciones de automatización construidas como un desarrollo a medida, definen el flujo en tiempo de desarrollo con lo cual su lógica en producción está perfectamente determinada, perfectamente conocida por anticipado.
Por tanto, las aplicaciones de automatización construidas con estas herramientas cumplen con todos los objetivos expresados acerca de la automatización.
Sólo un matiz respecto a la frase anterior: como hoy en día estas soluciones incluyen también la posibilidad de invocar a grandes modelos de lenguaje usando APIs y conectores, la certeza en cuanto a su lógica se podría debilitar un tanto, pero esto no deja de ser una primera manifestación de las limitaciones que pueden exponer los agentes, basados precisamente en modelos de lenguaje y que expongo en la siguiente sección.
Alguna desventaja de los agentes
Paradójicamente, creo que, de todos los objetivos de la automatización mencionados más arriba, en el único en que los agentes pueden superar a otras opciones de automatización más tradicionales es en el ahorro de costes.
En principio, igualan a las soluciones tradicionales puesto que, para una tarea dada, si ambas soluciones eliminan el trabajo humano, el ahorro es el mismo. Sin embargo, a priori los agentes permiten automatizar tareas que otras soluciones no pueden, precisamente por su capacidad de decidir 'ellos mismos' qué hacer en cada momento, siendo capaces de acometer automatizaciones de tareas que un humano no sabe definir bien o tareas sometidas a muchas incertidumbres o variantes que son difíciles de reflejar en un workflow.
En cuanto al segundo punto, probablemente podamos considerar que los agentes proporcionan la misma escalabilidad que los sistemas tradicionales, quizá con una cierta penalización por su alto consumo computacional, del que me ocuparé en otro post.
Hasta aquí vamos bien con los agentes, pero en los siguientes puntos, cambian las tornas.
Pero, sobre todo, los agentes no son completamente previsibles con lo cual perdemos una parte del control y predecibilidad de otro tipo de automatizaciones. Además, podemos esperar que se produzcan algunos errores porque el agente 'alucine' o no reaccione correctamente a un escenario dado.
Exactamente por lo mismo, introducimos algún riesgo, si bien creo que pequeño, de no conseguir el cumplimiento normativo.
¿Por qué no un workflow?
Estando así las cosas, ¿Por qué, en lugar de liarnos a hacer agentes, no automatizamos directamente al modo tradicional, mediante una solución basada en un workflow?
En el fondo, y esto es lo que origina todo el post, es porque a veces parece que sólo tenemos un martillo, un martillo de oro que son los agentes, y nos parece que todo son clavos. Pero no es así, disponemos de destornilladores, llaves inglesas y mucho más, y podemos no solo clavar, sino atornillar, poner tuercas o pernos y muchas más tareas.
Probablemente, lo sensato sea diferenciar el tipo de procesos y tareas que queremos automatizar, saber si son clavos o tornillos y, con criterio, seleccionar la herramienta adecuada, no sólo el martillo.
Me reservo una posible solución
Me reservo para el último post de la serie una idea que se me ocurre, que no tengo claro cómo es de viable ni si ya se está trabajando en ella y que reconciliaría un poco las diferentes visiones y podría convertir a nuestro martillo, los agentes, en una especie de navaja suiza.
Conclusiones
Los agentes de IA son una forma de automatización que, si bien comparte bastantes ideas con otras formas de automatización existentes, aportan sobre todo su planificación y decisión en tiempo de ejecución con base en un modelo de lenguaje razonador.
Esto es enormemente potente y diferencial pero, sin embargo, puede que no sea siempre la mejor solución. A lo mejor, hay casos en que siguen siendo preferibles soluciones basadas en reglas y workflows.
