Actualización de publicaciones del Project Management Institute (I): "The standard for project management"

Con este post inicio una serie corta de tres artículos (que probablemente se intercalen con posts de temáticas completamente diferentes) en que comentaré y valoraré brevemente algunas de las últimas publicaciones del PMI ('Project Management Institute'), la probablemente autoridad más reconocida a nivel mundial en materia de dirección de proyectos. 

En ellos, uno en cada post, comentaré brevemente tres documentos, a saber:

• The standard for project management (ANSI/PMI 99-001-2025)
• A guide to the Project Management Book Of Knowledge. PMBOK Guide. 8th edition.
• The Standard for Artificial Intelligence in Portfolio, Program, and Project Management

Antes de los breves comentarios, una pequeña explicación acerca de mis motivaciones.

Motivaciones: la importancia de los proyectos y el PMP

Hasta que en 2018 inicié mi andadura profesional por cuenta propia bajo mi marca 'Reingeniería digital', una parte muy importante de mi carrera ha estado dedicada de una forma u otra a proyectos.

He formado parte de equipos de proyecto, he actuado como jefe de proyecto y director de proyecto de iniciativas de todo tipo, algunas sencillas pero otras muy ambiciosas y de alto presupuesto, y he dirigido equipos que, a su vez, dirigían proyectos.

Y cada vez más fui apreciando la disciplina de la dirección de proyectos y, aún más, la figura del jefe de proyecto. Esta importancia se me hizo especialmente patente cuando los proyectos a que nos dedicábamos estaban dirigidos a clientes pertenecientes a las grandes cuentas de Telefónica Empresas, donde se encontraban la mayor parte de empresas del IBEX y muchas otras empresas y administraciones de gran tamaño y presupuesto. Llegué al profundo convencimiento de lo importante que era la figura del jefe de proyecto para alcanzar el éxito y no me refiero sólo a la figura en sí como un rol abstracto, que también, sino a la cualificación y voluntad de las personas concretas que ejercían ese rol. La relación con el cliente y el éxito de los proyectos, dependían en buena medida de esa figura y de la persona que la ejerciese. 

En 2012, cuando ya realmente no ejercía como director de proyecto sino como gerente, decidí, a pesar de ello, obtener la certificación PMP ('Project Management Professional'), lo cual sucedió en Junio de 2012, hace ahora catorce años, a lo largo de los cuales, y como establece el PMI, he ido renovando esa certificación que aún tengo en vigor y que pienso volver a renovar el año que viene.

Cuando obtuve la certificación, el PMBOK vigente se encontraba en su quinta edición. Desde entonces he adquirido y estudiado las siguientes ediciones, la sexta, la séptima... y ahora le toca a la octava, publicada en Enero de 2025.

Además, me interesó mucho conocer, dado mi interés y dedicación a la inteligencia artificial, que PMI junto con ANSI, habían lanzado también un estándar para proyectos de inteligencia artificial.

La idea, pues, ha sido realizar una nueva actualización y, en este caso, además, compartir con los lectores de este blog un poco del contenido objetivo de los documentos, y otro poco de mi valoración personal. 

Explicado esto, vamos con el primero de los documentos, el 'Standard for project management'

El contenido del "Standard for Project management"

Este estándar ha sido definido mediante una colaboración entre el PMI ('Project Management Institute') y ANSI ('American National Standards Institute'), colaboración que se inició, si la memoria no me falla, con la anterior versión del PMBOK (la séptima).

Aunque se trata de un documento separado, se publica en el mismo volumen que el PMBOK, del cual hablaré en otro post de esta serie.

Según reza en el propio documento, este estándar

provides a basis for understanding project management and how it facilitates intended outcomes.

y, un poco más abajo, dice

The standard describes how project management creates value and benefits in organizations as well as how organizational and project leaders can harness the power of project management for success.

 

Como se pude deducir un poco de estas declaraciones de intenciones, y como insistiré en mi comentario personal, se trata de un documento más descriptivo que normativo.

El documento de poco más de setenta páginas  y se estructura en cuatro secciones:

• 'Introduction': Establece el propósito del estándar, proporciona un vocabulario de términos y conceptos y ataca algunos aspectos generales de los proyectos como sus características, conceptos de gobernanza, relación con las operaciones de la compañía y las relaciones entre los conceptos de proyecto, programa, porfolio y operaciones.


• 'System for value delivery': Extendiendo lo ya iniciado en la séptima edición, adopta una visión muy de alto nivel y negocio para hablarnos de cómo los proyectos aportan valor y se sitúan como parte de un sistema de valor. Propone un modelo para conceptualizar ese sistema de valor y a partir de ahí comenta elementos de contexto interno y externo a proyectos, programas y porfolios, establece la relación con el 'product management' e identifica una serie de funciones y roles presentes en los proyectos.


• 'Project management principles': Identifica y explica seis principios de la dirección de proyectos, a saber:
  • Adoptar una visión holística
  • Enfocarse en el valor
  • Introducir la calidad en los procesos y los entregables
  • Ejercer un liderazgo responsable
  • Integrar la sostenibilidad en todas las áreas de proyecto
  • Construir una cultura de empoderamiento


• 'Project Life Cycles': Habla de las fases de los proyectos y luego identifica los tres grandes enfoques para la dirección de proyectos (predictivo, adaptativo e híbrido) y proporciona criterios para seleccionar un enfoque u otro. También habla de la cadencia de las entregas, mencionando el despliegue continuo propio de DevOps (aunque sin mencionar a DevOps). Finaliza identificando y describiendo las que denomina cinco áreas de foco, a saber:
  • Inicio
  • Planificación
  • Ejecución
  • Monitorización y control
  • Cierre

Una valoración: ¿Esto es un estándar?

Este estándar es un documento correcto y bien redactado (aunque en el típico estilo profesional austero) y que proporciona un vocabulario y una especie de marco de referencia común, eso sí, un poco abstracto y de bastante alto nivel.

Me parece bueno, a nivel de una disciplina, establecer ese marco de referencia y ese vocabulario comunes y no me parece mal, tampoco, comenzar por un alto nivel para luego ir bajando.

Sin embargo, insisto, es muy alto nivel y en algunas partes un poco abstracto. Le falta mucho bajar a tierra, en mi opinión. si pretende orientar realmente la acción de las organizaciones y de los profesionales.

Y aunque esto sea enmendarle la plana nada más y nada menos que a ANSI, me resisto a ver este documento como un verdadero estándar, porque no detalla nada, no da pautas asertivas, no obliga a nada y no es muy verificable si se está aplicando o no.

La verdad es que esto no es lo que yo entiendo por un estándar.

Hace muchos años, en mis primeros tiempos en Telefónica, me miré muchas normas y estándares del ámbito de las telecomunicaciones, que definían, por ejemplo, protocolos y, desde luego, no tiene nada que ver con esto. Aquello era detalladísimo, normativo, verificable y, todo hay que decirlo, muy farragoso,

No he tenido mucha ocasión de leer directamente estándares o normas del ámbito industrial pero, hasta donde sé, son de nuevo, muy detalladas, muy concretas y completamente verificables en su cumplimiento.

Este documento, pues, lo veo como divulgativo, conceptual e introductorio pero, por mucho que lo firme ANSI, me resisto a verlo como un verdadero estándar.

Conclusiones

Inicio con este artículo, una breve serie de tres posts dedicados a documentos más o menos recientes emitidos por el PMI ('Project Management Institute')

En este primer post, comento brevemente el 'The Standard For Project Management', un documento conceptual y de alto nivel, que establece vocabulario y conceptos, pero que no entra en detalles y que me cuesta mucho verlo como un verdadero estándar.

Los agentes y el martillo de oro (III): soluciones híbridas y ecosistemas de agentes

Y con este post remato la pequeña serie dedicada a los agentes como martillos de oro. Y lo hago ofreciendo algunas soluciones intermedias o híbridas al problema planteado.

Pero vamos a ir poco a poco, recapitulando primero algunos conceptos y recordando la definición del problema.

Un paso atrás: los agentes de la Agentic AI

Damos, pues, un paso a atrás para recordar conceptos. Y lo primero es recordar de qué hablamos cuando hablamos de un agente. Y antes de hacerlo, insistir en que el término 'agente' se lleva utilizando desde hace décadas, e incluso siglos, y no sólo en tecnología. Así que, de los que hablamos son de los agentes de que hablamos bajo el paraguas de la Agentic AI.

Y se trata, como vimos, de programas construidos alrededor de un modelo de lenguaje razonador que son capaces de funcionar de manera autónoma, recibir sus tareas u objetivos mediante una especificación en lenguaje natural y, con base en sus capacidades razonadoras, decidir por sí mismos, y en tiempo de ejecución el plan a ejecutar para conseguir el objetivo. Un plan que puede ser revisado conforme avanza y se obtienen resultados intermedios, y un plan en cuyos diferentes pasos se puede incluir la selección y ejecución de una herramienta externa que le permite, entre otras cosas, interactuar con el mundo exterior.

Agentes versus workflows

Estructura de un agente

Estructura de un agente

Conforme a lo comentado, la estructura de alto nivel de un agente es la que se muestra en la figura. En el núcleo tenemos un modelo de lenguaje razonador y, como apoyo, una serie de herramientas con las que puede interactuar y que, aparte de alguna posibilidad adicional, fundamentalmente le ayudan a entrar en contacto con aplicaciones y recursos externos (una web, un sistema empresarial, el correo electrónico, etc)

En la figura dibujo a trazos la unión entre el modelo de lenguaje y las herramientas queriendo indicar que, según el plan generado, se invocan o no.

Estructura de un workflow

Y es importante comparar a estos agentes basados en modelos de lenguaje razonadores con otro tipo de soluciones anteriores que funcionan bajo un paradigma de reglas y, sobre todo flujos o workflows. Denomino genéricamente 'workflows' a ese tipo de soluciones que incluye, por ejemplo, los robots RPA ('Robotic Process Automation'), a los a veces denominados workflows en la nube o IPaaS (como Make, N8N o Zapier) e, incluso, forzando un poco, a los BPMS ('Business Process Management System') y los CMS ('Case Management System').

Estructura de un workflow

A alto nivel estas soluciones que agrupo bajo la etiqueta 'workflows' exhiben patrones estructurales muy similares entre sí, e incluso con los agentes.

En el caso de los workflows, el plan está predefinido en tiempo de desarrollo y adopta la forma de un flujo con sus pasos y, eventualmente, bifurcaciones y/o bucles. Y también pueden interactuar con aplicaciones y recursos exteriores, en este caso haciendo uso, habitualmente, de conectores que recubren un API generalmente de tipo REST.

Comparativa

En el fondo, estructuralmente hablando, se trata de soluciones muy similares. En la figura inferior, los ponemos frente a frente.

Comparativa Agente-Workflow

En esa figura, e intencionadamente, he eliminado la mención explícita a herramientas (en el caso de agentes) y a conectores (en el caso de workflows). ¿Por qué? Pues porque, a despecho de alguna diferencia en cuanto a la definición, y algunas variantes en cuanto a implementación, su rol es exactamente el mismo y, por tanto, de cara a la comparativa estructural prefiero que no se muestre ninguna diferencia.

La diferencia fundamental es que, en el caso de los agentes, el plan de acción se decide y revisa de forma dinámica en tiempo de ejecución por el propio agente, mientras que en los workflows el plan de acción se define en tiempo de desarrollo por el desarrollador humano y es estático. Esta diferencia es fundamental, tanto para lo bueno de los agentes, la flexibilidad, potencia e inteligencia de los agentes, como para lo malo de los agentes: incertidumbre y consumo computacional.

Sólo por apuntar alguna otra diferencia, se puede observar en la figura que, en el caso de los agentes, y como mencioné más arriba, dibujo con trazos la unión con los nodos herramienta, mientras que en los workflows esa flecha la dibujo con trazo continuo. Lo que esto trasmite es una consecuencia del dinamismo del plan de los agentes: a priori no podemos estar seguros de qué herramientas va a invocar ni de qué forma. En el caso de los workflows sí se sabe, porque está definido en el flujo.

Podríamos apuntar algunas otras diferencias de menor calado, pero prefiero quedarme con estas que son nucleares.

Aunque me preocupan un poco las connotaciones de la palabra 'determinismo' en el ámbito de la inteligencia artificial, diría, por expresarlo de una forma aún más compacta que:

Un agente es una solución muy flexible y potente pero no determinista, mientras que un workflow es una solución más rígida y acotada, pero determinista.

 

Estableciendo el enunciado del problema

Llegados hasta aquí, y antes de pasar a la soluciones que propongo, recordar cuál es el problema a que me refiero (y que puede que el lector identifique como tal o no).

Mi argumentación parte de la idea de que, al menos a nivel de discurso, parece que los agentes son la solución a cualquier problema, especialmente de automatización de tareas y procesos. Es decir, se considera a los agentes como un martillo de oro, capaz de soluciones cualquier problema que, por tanto, vemos siempre como un clavo. 

Salvo que alguien me demuestre lo contrario, creo que los agentes, al menos en su estado de arte actual, no deben ser la solución única, que todavía hay muchas tareas que se automatizan mejor mediante una solución más clásica basada en un workflow. 

En concreto, cuando la solución al problema la tengamos clara y sepamos claramente las reglas que la gobiernan, un workflow parece mejor solución que un agente, por los siguientes motivos:

• Dado que un workflow es determinista, es mucho más sencillo de probar y, una vez probado, garantiza un comportamiento correcto, conocido y reproducible, cosa que en un agente nunca podemos estar 100% seguros.


• El coste computacional de ejecutar un agente, para una tarea similar, es muchísimo más alto que el de la misma tarea ejecutada por un workflow


• Dado que el coste computacional es mucho más alto, el coste económico es también más elevado y, además, no del todo predecible (no podemos saber con seguridad los tokens que se necesitarán).


• Finalmente, ese coste computacional se traduce en consumo eléctrico y de refrigeración, incrementando la huella de carbono y el impacto medioambiental

El razonamiento es, pues, resumiendo, que aunque los agentes son de una potencia extraordinaria y nos abren unas grandísimas posibilidades, no siempre son la mejor solución, y por lo tanto, no debemos considerarlos martillos de oro, sino elegir en cada momento la solución de automatización más adecuada.

Algunas posibles soluciones intermedias e integradoras

La verdad es que, hasta aquí, casi que lo que he hecho es nada más que resumir e ilustrar, el contenido de los dos posts anteriores. Vamos ahora con algunas soluciones o planteamientos que se me ocurren. En concreto, y aunque es posible que existan otras soluciones, o que las que propongo se puedan combinar, voy a proponer cuatro opciones, a saber:

• Solución 0: seleccionar la solución caso a caso
• Solución 1: el modelo generador de workflows
• Solución 2: orquestadores
• Solución 3: ecosistemas híbridos

En lo que sigue, comento brevemente cada una.

Solución 0: seleccionar la solución caso a caso 

Esta solución le llamo solución 0, porque, en realidad, es casi trivial. 

Si se admite que no todos los problemas se resuelven mejor con un agente pues entonces, simplemente, antes de lanzarse a desarrollar un agente o un workflow decidir conscientemente y con criterio cuál es la solución adecuada para ese caso concreto

Solución 1: el modelo generador de workflows

La solución 1 consistiría en que el propio modelo razonador que genera el plan fuese capaz de detectar, por sí mismo o con asistencia humana, qué tipo de solución es mejor y si, al inicio de su resolución detecta que es un problema basado en reglas y resoluble mediante un flujo, simplemente que genere ese flujo.

Me parece perfectamente viable técnicamente puesto que casi todas las herramientas de tipo workflow expresan ese workflow mediante un lenguaje de marcado (tipo YAML) o mediante JSON, dos formatos que un modelo de lenguaje domina muy bien.

Eso sí, no eliminamos al 100% el no determinismo, puesto que el agente puede equivocarse y no darse cuenta de que un problema se resuelve mejor mediante workflow. Tampoco es óptimo computacionalmente, porque la propia decisión de si vale la pena crear un workflow, e incluso la creación del workflow propiamente dicho sigue usando los mecanismos propios de un modelo de lenguaje.

No es pues, creo, una solución absoluta, pero alivia el problema.

Solución 2: orquestadores

La siguiente solución se apoya en la idea de que la relación de agentes entre sí, y de workflows entre sí puede hacerse jerárquica e incluso recursiva. Es decir, un agente puede invocar a otro agente (que actúa como herramienta) y un flujo puede invocar a otro flujo (usando una especie de conector). 

Esta opción, que no sólo es viable, sino que ya hay plataformas que permiten su creación, es hacer automatizaciones en que exista un nodo orquestador, y otros nodos que realizan tareas. Y, para aquellas tareas en que la solución mejor sea un workflow, pues se utiliza un workflow y para aquellas en que la mejor solución sea un agente y es el orquestador quien lo decide. El esquema de esta opción se muestra en la figura.

Orquestadores

Se puede ver que, además, esta solución tiene una doble vertiente: que el orquestador sea un agente o que el orquestador sea un workflow. Además, y aunque en la figura se muestra que un agente sólo invoca workflows y un workflow sólo invoca agentes, en realidad, ya sea orquestado por un agente o por un workflow, los nodos que ejecutan las tareas pueden ser cualquier tipo.

Como digo, este tipo de esquemas ya se pueden hacer hoy en día, no sólo en código, sino en herramientas como Make.

Solución 3: el ecosistema híbrido

La solución 2 ya anticipa un poco lo que es la solución 3 (realmente es un caso particular de la solución 3).

La solución 3, el ecosistema, parte de concebir las automatizaciones como una interacción entre unos nodos que pueden ser agentes o workflows y que se combinan en interaccionan entre sí según la naturaleza del problema. Es lo que intento mostrar en la siguiente figura: 

Ecosistemas de agentes, con workflows como forma de agente

Es una solución muy similar a la del orquestador pero sin que haya nodos con ese rol especial, sino que interactúen en un esquema más P2P. En el fondo, esta solución se basa en la idea de los ecosistemas de agentes, pero reconociendo a los workflows también como agentes.

Para que está solución sea óptima, como en el fondo también en el caso anterior, ha de cumplirse que cuando el orquestador seleccione un nodo para delegar una tarea, o cuando un agente del ecosistema delegue en otro la ejecución de una tarea, se 'acierte' siempre, en el sentido de identificar siempre cuándo una tarea se resuelve mejor mediante un workflow.

No voy a profundizar más en ello, pero se me ocurre que sino conseguimos que un modelo de lenguaje acierte siempre en la elección de workflows, se le 'podría ayudar' mediante alguna forma de catálogo de tareas que se resuelven mejor mediante workflows.

Algún pequeño 'disclaimer'

Antes de cerrar este post, hacer algún pequeño 'disclaimer'.

El primero es que las propuestas que hago no dejan de ser eso, propuestas, hechas un poco 'a bote pronto', aunque es un tema al que le doy vueltas con cierta frecuencia últimamente.

Por otro lado, ni reclamo ni dejo de reclamar la 'autoría' u originalidad de estas propuestas. No renuncio a esa supuesta 'autoría' u 'originalidad', porque es fruto de mi propia reflexión, no es nada que haya visto en ningún sitio salvo, hasta cierto punto, la idea del orquestador. Pero tampoco me atrevo a reclamar la autoría y, sobre todo, originalidad, porque me cuesta pensar que no haya ya mucho pensado e incluso escrito sobre estos temas y que existan propuestas, implementadas y/o publicadas, iguales o muy parecidas a las que hago..

Finalmente, apostaría a que hay más soluciones que yo no he planteado aquí y puede que mejores... así que me encantará o bien descubrir en alguna publicación o bien que se me ocurran a mi en un proceso de indagación y reflexión.

Conclusiones

El considerar a los agentes como martillos de oro, como la única solución para todos los problemas fundamentalmente de automatización, puede ser un error, ya que existen soluciones, especialmente las basadas en workflows, eventualmente más adecuadas y, además, más seguras, eficientes, baratas y sostenibles.

En este post, tras, revisar conceptos y la naturaleza del problema, se proponen cuatro estrategias de solución híbridas.

Artículos de este blog relacionados

• Los agentes y el martillo de oro (II): agentes y medio ambiente
• Los agentes y el martillo de oro (I): ¿por qué no un workflow?

Los agentes y el martillo de oro (II): agentes y medio ambiente

Con este post continuo la breve serie que quería dedicar a un eventual uso irreflexivo de los agentes, un uso que no se detiene a considerar que en ciertos casos existen  mejores alternativas. Es decir, continuo la serie dedicada a considerar a los agentes como un martillo de oro, la solución para cualquier problema que pasa a ser siempre un clavo. 

Si en el post anterior reflexionaba sobre si no es mejor, desde un punto de vista fundamentalmente técnico y operativo,  usar en ciertos casos soluciones basadas en reglas o workflows mejor que un agente, en este artículo torno mi mirada hacia la sostenibilidad y el impacto medioambiental.

Agentes 101

Antes, recordar brevemente, una vez más, qué es esto de los agentes y de la Agentic AI (aquellos lectores que lo tengan claro pueden saltarse esta breve sección)

Los agentes de la agentic AI, son unos programas construidos alrededor de un gran modelo de lenguaje razonador. Unos programas que son capaces de funcionar de manera autónoma buscando realizar tareas eventualmente complejas o satisfacer objetivos que reciben expresados en lenguaje natural. 

Además son capaces de usar una serie de elementos, denominados herramientas, que les permiten realizar tareas especializadas y, sobre todo, interactuar con el exterior, típicamente con otras aplicaciones.

Y, de manera muy relevante y diferencial, esos agentes, definen ellos mismos el plan de acción a aplicar para realizar la tarea o alcanzar el objetivo encomendado. Y para definir ese plan de acción, utilizan ese modelo de lenguaje razonador. Además, estos planes de acción son dinámicos y se revisan 'en vuelo' según los resultados parciales que el agente vaya obteniendo.

El precio del razonamiento

No sólo es diferencial, es que también es tremendamente atractivo y potente que el agente sea capaz de 'pensar', crear y revisar el plan de acción. Es como un alarde de inteligencia y permite que le encomendemos tareas complejas o, incluso, tareas que nosotros no sabemos resolver.

Pero esa potencia, esa brillantez, tiene un precio en forma de consumo computacional. Si el uso de cualquier modelo de lenguaje, incluso para una tarea simple como completar un texto, es costoso computacionalmente, hacer un plan es mucho más costoso. Y revisarlo también

Y por si eso fuese poco, es posible que no se trate de acciones que se realicen una sola vez. Es que el agente puede estar funcionando de manera permanente, continua, con lo que esa planificación o revisión de planificación puede estarse ejecutando repetidamente. 

La economía y el medio ambiente

Y, claro, el coste computacional se traduce en consumo energético y, por tanto, en coste económico. Un coste económico que se traduce para el proveedor del modelo en factura eléctrica y eventualmente más facturas en forma, por ejemplo, de refrigeración. Y para el que usa el agente en factura IT, por tokens consumidos o la unidad que se haya acordado.

Pero claro, a poco que esa energía utilizada provenga de fuentes no renovables, ese consumo energético se traduce en huella de carbono u otros impactos medioambientales como calentamiento de aire o agua usados en refrigeración.

No, por desgracia no parece que los agentes se lleven muy bien con el medio ambiente

Un consumo muy perceptible

Ese consumo computacional se puede percibir además, no de forma precisa, pero sí muy tangible.

No hace mucho, casi más por experimentar, me creé un agente sencillo usando la herramienta Make. Cuando lo ejecuté, me llamó mucho la atención lo que tardó en realizar la tarea, una tarea que realmente era muy simple, casi trivial.

En realidad, se trataba de una tarea que creo impropia para un agente. Creo recordar que consistía en procesar correos entrantes, crear una respuesta para esos correos y contestar al remitente con esa respuesta.

Como usuarios estamos acostumbrados hoy en día a muy bajas latencias, a tiempos de respuesta muy buenos, por lo que esta lentitud era llamativa. Pero hay que tener en cuenta que el agente tenía que entender la tarea, realizar el plan de acción e imaginarse qué herramientas de las que ponía a su disposición utilizar y de qué forma. Eso no es tan fácil.

Esa lentitud percibida era, pues, una manifestación tangible del coste computacional de lo que el agente estaba haciendo.

Workflows: cuando la eficiencia técnica se alinea con la sostenibilidad

Y, sin embargo, con esa misma herramienta Make, que habitualmente se utiliza no para hacer agentes sino workflows, podría haber creado un workflow (escenarios como se llaman en Make) muy simple para hacer la misma labor.

La ejecución de ese workflow, aparte de más fiable en cuanto a estar seguros de que iba a hacer lo encomendado, es mucho, muchísimo más rápida. Y sería muchísimo más rápida porque el flujo ya estaría pensado en tiempo de diseño, no sería necesario crear ningún plan ni revisarlo (el propio workflow es el plan y es estático). Tampoco es necesario deducir qué herramienta (el GMail en este caso) usar, porque el propio workflow indica cuál es y cómo se invoca.

Desde un punto de vista técnico y operativo interesa saber que la tarea realizada con un workflow es mucho más rápida y mucho más fiable en cuanto a resultados.

Esa eficacia y eficiencia técnica y operativa tiene, claro, también su traducción en menor consumo energético y, por tanto, menor coste.

Y, por si algo faltaba, es una solución más respetuosa con el medio  ambiente porque ese menor consumo energético va a tender a crear mucha menor huella de carbono y mucho menor calentamiento.

El martillo de oro

Por tanto, no caigamos en pensar que los agentes son un martillo de oro y que son siempre son la mejor opción.

En el post anterior razoné que de cara a la eficacia, la eficiencia y la calidad, probablemente, para ciertos casos, existan soluciones mejores, soluciones más tradicionales basadas en reglas o workflows.

En este post recuerdo que la sofisticación de un agente viene acompañada de un coste económico y medioambiental y, por tanto, se deben usar con prudencia, cuando el tipo de tarea encomendada realmente sea propia de un agente e, incluso en este caso, debería preocuparnos su impacto medioambiental.

Como se puede observar, ni los agentes son un martillo de oro, ni todos los problemas son clavos.

Conclusiones

Los agentes son unas soluciones excitantes, poderosas y abren enormes posibilidades en automatización y seguramente más campos como investigación.

Pero no son un martillo de oro. No son la mejor solución técnica para todos los problemas y, desde luego, no son la mejor solución para el medioambiente.

Seamos, pues, responsables.

Artículos de este blog relacionados

• Los agentes y el martillo de oro (I): ¿por qué no un workflow?

Los agentes y el martillo de oro (I): ¿por qué no un workflow?

Leo mucho y también le doy muchas vueltas en los últimos meses, seguro que no soy el único, a todo lo relativo a los agentes de IA.

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.

Son características, muy diferenciales y muy potentes, que diferencian claramente a los agentes de otras formas de automatización que, exteriormente se puedan manifestar de forma parecida.

En general, son de una potencia espectacular...pero a lo mejor eso nos lleva a considerarlos martillos de oro y es posible que, pese a su potencia, no siempre constituyan la mejor opción 

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.

Así, aunque no siempre de manera grave, los agentes suelen ser más lentos de ejecución que una solución basadas en workflow. Es decir, sí que reducen el tiempo de proceso, pero algo menos que las soluciones basadas en workflow. Según el caso, la diferencia puede ser casi irrelevante o puede importar.

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.