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.

La peligrosa combinación del 'automation blindness' y el 'deskilling' y cómo afrontarla

Una de las preocupaciones que surgen con la inteligencia artificial es, más allá de otras problemáticas éticas como la privacidad, los sesgos o la explicabilidad, cómo  va a afectarnos a nosotros, humanos, en nuestro propio desarrollo, en nuestras propias capacidades cognitivas, a medida que nos entreguemos a ella, que la utilicemos intensivamente tanto en el ámbito laboral como doméstico.

Y creo que, en efecto, existe a la vez un interrogante, porque realmente no estanos seguros, y un riesgo, porque creo que realmente podemos perder cosas valiosas por el camino. 

En este post quisiera mostrar cómo dos aspectos que ya he tratado en otros posts, se podrían combinar de una forma perjudicial y potencialmente peligrosa. Hablo de los así llamados 'automation blindness' y el 'deskilling'.

Veamos.

Recordando el 'automation blindness'

De 'automation blidness' hablé en el post anterior a éste titulado 'Automation blindness o el riesgo para human-in-the-loop'. Este fenómeno, en esencia consiste en que los humanos, cuando están apoyados en sus decisiones por sistemas automatizados, poco a poco se 'van confiando' y pasando de realizar una supervisión efectiva y responsable de las decisiones automatizadas, a confiar ciegamente en ellas eliminando, 'de facto', la supervisión e incluso su autonomía.

Se trata de un fenómeno no específico de la inteligencia artificial pero que se acentúa en sistemas inteligentes, tanto por su potencia, como por actuar en situaciones tradicionalmente reservadas al juicio humano.

Recordando la idea de 'deskilling'

Del 'deskilling' hablé brevemente hace un par de meses en el artículo 'Inteligencia artificial, capacidades y las tres olas hacia el desempleo'.  En este caso, de lo que hablamos es que, dado el efecto sustitutivo que la tecnología tiene respecto a  tareas humanas, a medida que vamos delegando en la tecnología esas tareas, perdemos la capacidad para llevarlas a cabo nosotros mismos, es decir, perdemos capacidades y habilidades. 

Se trata de un fenómeno que tampoco es exclusivo, ni mucho menos, de la inteligencia artificial. Lo que ocurre es que, en el pasado, las habilidades que delegábamos y perdíamos eran de naturaleza más bien manual, pero con la digitalización, y sobre todo con el advenimiento de la inteligencia artificial, estamos, cada vez más, delegando capacidades cognitivas y, eventualmente, perdiendo esas capacidades o al menos en riesgo de perderlas.

Una combinación doblemente peligrosa

Si veo ambos fenómenos, creo que cuando se combinan, y me parece muy fácil que se combinen, nos hallamos ante una situación peligrosa en un doble sentido, un sentido más operativo y práctico, y otro más cognitivo y profundo.

Un peligro operativo

En primer lugar, y desde un punto de vista que voy a denominar operativo, es peligrosa porque se pierde la supervisión real de los sistemas automatizados. Ya no es sólo que tendamos a confiarnos ('automation blindness'), es que podríamos incluso perder la capacidad real para entender y controlar un sistema automatizado ('deskilling'). Dado que, por desgracia, los sistemas automatizados pueden fallar, y más si se pretenden apoyar en inteligencia artificial generativa que, como ya analicé en otros posts, no conduce a comportamientos completamente predecibles ni sujetos a reglas, perder la capacidad de supervisión y control puede llevar a puntualmente a comportamientos del sistema incorrectos y eventualmente catastróficos.

Es cierto que los sistemas automatizados, sobre todos los de misión crítica, tienden a ser muy fiables, incluso con frecuencia mucho más que un humano, pero aún así, perder la capacidad última de decisión y control, me parece operativamente arriesgado.

Un riesgo cognitivo y ético

Pero quizá me preocupa más la segunda vertiente, la que voy a denominar cognitiva. En este caso, tiene mucho que ver con el 'deskilling', es decir, con la pérdida de capacidades cognitivas. Esa pérdida de capacidades cognitivas, por sí misma, me parece un empobrecimiento de la persona pero, además, en a medida que se confía más y más en sistemas automatizados, puede devenir en una menor autonomía, una mayor dependencia.

Es cierto que en el pasado, nos hemos deshecho de capacidades que hemos delegado en máquinas y tecnología, y no parece que nos haya ido mal ni que estemos descontentos. Incluso es posible, sólo posible, que a cambio de ceder algunas capacidades, resultemos potenciados en otras, que desarrollásemos nuevas habilidades. 

Pero, claro, hablamos de capacidades cognitivas, muy esenciales de lo que significa ser humano. Y  no sé si estamos dispuestos a asumir (yo, personalmente, no), esa suerte de degradación cognitiva o el riesgo de un incierto cambio de capacidades cognitivas.

Sin recetas, pero con un planteamiento a corto plazo

La verdad es que creo que nadie puede tener claro lo que va a ocurrir en el futuro, y cómo vamos a evolucionar. Es posible que, al final, los riesgos y peligros no sean tan grandes o, al menos, que sepamos encauzarlos y el resultado final sea bueno. Y como estamos ante un panorama incierto, es difícil saber cuál es el camino adecuado.

Sin embargo, pase lo que pase en el futuro, creo que los riesgos que he mencionado son reales y afectan a temas muy importantes, de seguridad y casi a nuestra propia naturaleza. Así que, si existen riesgos reales, pero tenemos poco clara la visión futura, creo que conviene actuar, al menos a corto plazo. Desde luego, creo que podemos, casi diría que debemos, utilizar, y utilizar mucho, una tecnología tan potente y versátil como es la inteligencia artificial. Pero debemos hacerlo de una forma consciente y responsable, responsable con los demás y con nosotros mismos. 

Y así, creo que cada uno de nosotros deberíamos exigirnos y esforzarnos en la supervisión de aquello que delegamos en la inteligencia artificial, desde grandes automatizaciones corporativas, hasta simples consultas a ChatGPT. Aunque nos cueste, aunque nuestra naturaleza nos impulse a ser cómodos y confiarnos, debemos esforzarnos conscientemente en ejercer el juicio crítico, el control y la autonomía. 

Y, además, deberíamos cuidar nuestras capacidades cognitivas, intentando no sólo no perderlas sino incluso aumentarlas. Y para ello, dado que no vamos a dejar de utilizar la inteligencia artificial, quizá debamos reforzar nuestras capacidades, y hacerlo conscientemente, mediante actividades en paralelo que cuiden y desarrollen esas capacidades: lectura, estudio, actividades artísticas, interacción humana, etc

Es cierto que pongo mucho énfasis en la responsabilidad individual, en el auto-cuidado cognitivo, es cierto que, además, lo que propongo exige acción consciente y puede que esforzada, y es cierto, finalmente, que puede que las cosas cambien, y que en unos años o que las valoremos de una forma diferente, pero ahora mismo, a corto plazo, creo que es lo mejor que podemos hacer... y hacerlo cada uno de nosotros.

Conclusiones

El uso intensivo de las tecnologías, muy en especial la inteligencia artificial, puede conducir, por un lado, a una confianza excesiva en de las decisiones automatizadas y, por otro, a una progresiva degradación de nuestras capacidades cognitivas.

La combinación de ambos fenómenos, creo que es peligrosa tanto desde un punto de vista operativo como humano, cognitivo y casi ético.

Existe mucha incertidumbre sobre el nivel de riesgo real o cómo afrontarlo pero, a corto plazo, lo que creo que debemos hacer es reforzar, conscientemente, nuestra supervisión de los sistemas y, sobre todo, nuestro propio desarrollo cognitivo. 

Workflows, agentes y una automatización de baja intensidad

Ya desde hace muchos años, desde que la informática tomó cierta presencia en las organizaciones, uno de sus objetivos ha sido la automatización de procesos, una tarea esencial para lograr calidad, escalabilidad y eficiencia.

En busca de este objetivo, muchas son las tecnologías o tipologías de soluciones que se han aplicado.

Algunas soluciones tradicionales de automatización 

En mi segundo libro, 'Robots en la sombra', hago un repaso de las tecnologías de automatización de procesos. De entre ellas, dos son las grandes protagonistas.

Por un lado, y dentro de las soluciones que denomino 'conscientes de proceso' (implementan procesos de negocio aunque éste no es editable y se refleja de manera implícita) las grandes protagonistas son los sistemas empresariales, los ERP ('Enterprise Resource Planning') y los CRM ('Customer Relationship Management') tan importantes en los mapas de sistemas de las empresas y administraciones ya desde los años ochenta y primeros noventa del siglo pasado y aún en plena forma hoy en día, generalmente en forma de soluciones SaaS ('Software as a Service') desde la nube.

Por otro, tenemos los sistemas orientados a proceso (sistemas en que el proceso de negocio se modela y gestiona de forma explícita y ese modelo de  proceso es la base de la digitalización y automatización). En este campo caen los BPMS ('Business Process Management Systems'), inicialmente denominados sistemas de worfklow y actualmente con frecuencia denominados, de manera incorrecta, simplemente BPM.  También se incluyen los 'Case Management Systems' (CMS) habitualmente integrados como producto con los anteriores.

Por el camino, muchas otras soluciones de nicho o alcance menor como las soluciones ITSM (implementando procesos ITIL) o, a pequeña escala, las macros. 

Llegan los robots software

Hace unos años surgió una solución alternativa de automatización, más orientada a tareas y pequeños procesos que a procesos de negocio extremo a extremo, y más orientadas también a complementar la infraestructura IT y de automatización ya existente que a crear soluciones completas extremo a extremo. 

Hablo, fundamentalmente, de la Automatización Robótica de Procesos, RPA ('Robotic Process Automation') en que se crean unos módulos software, los robots, que implementan pequeños procesos basados en un flujo (con sus pasos o actividades, sus condiciones, ramificaciones y bucles y con sus variables de proceso) pero capaces, sobre todo, de interactuar con todo tipo de recursos IT externos, documentos y aplicaciones, bien sea interaccionando con pantallas (lo que constituye el origen de RPA) o mediante APIs y conectores.

Los robots RPA se constituyen así en una suerte de orquestadores o integradores de otros recursos y aplicaciones, uniendo y dando continuidad a las capacidades de automatización o almacenamiento de información de cada uno de esos recursos.

Los robots RPA eran protagonistas principales de mi libro 'Robots en la sombra' ya citado.

Pero en ese libro había otros protagonistas, los chatbots, otra forma de robots software pero estos fundamentalmente orientados a interactuar con humanos aunque luego, en background, también acceden, y hasta cierto punto orquestan, otros recursos como sistemas y servicios.  

Por detrás de los BPMS y, sobre todo, de los robots RPA, existe un flujo, un workflow que contiene la lógica que enlaza las diversas actividades, tareas y acciones.

La automatización visual de flujos

Y, precisamente alrededor de ese concepto de flujo o workflow surgen otro tipo de soluciones que es de las que fundamentalmente quería hablar aquí, una serie de soluciones que tienen mucho en común con RPA, pero con alguna pequeña, aunque notable, diferencia.

Estoy hablando de un tipo de soluciones que, hasta donde se me alcanza, no han cristalizado en un nombre de categoría de producto, aunque algunos de los que he podido ver que se les aplican son iPaaS ('integration Platform as a Service'), plataformas de automatización de workflow ('workflow automation platoforms') o, incluso, automatización visual. En sus orígenes, y para versiones que creo simples, también se aplicaba el término IFTTT ('If This Then That') significando que lo que hacían es, ante un estímulo o evento, ejecutar una acción.

¿En qué consisten?

Básicamente, permiten construir flujos de trabajo ('workflows') mediante en enlazado en serie o bien con ramificaciones, condiciones y bucles, de una serie de tareas, actividades o pasos. Esas tareas, en general, se realizan mediante la lectura, escritura o invocación de datos y capacidades externas a las que se accede mediante conectores que recubren las APIs correspondientes. Estos flujos pueden ser invocados externamente por un usuario o por otros programas, pero también pueden programarse para ejecución planificada o lanzarse automáticamente ante la detección de un evento. Internamente manejan variables y, sobre todo, lo que se suele denominar 'contenido dinámico' que son variables generadas de forma automática por el flujo sin que el desarrollador deba ocuparse de definirlas (y sólo tenga que usarlas).

¿Cuál es el valor que ofrecen este tipo de herramientas?

• Por un lado, son herramientas en que el desarrollo de un flujo es muy sencillo porque se apoyan en entornos visuales conforme a las filosofías 'Low Code / No Code'.


• Por otro, ofrecen una amplísima colección de conectores que permiten, de forma simple, el acceso a todo tipo de aplicaciones (prácticamente cualquier aplicación conocida) y recursos (correo, sistemas empresariales, documentos ofimáticos, redes sociales, etc) incluyendo los modernos modelos de lenguaje o soluciones de IA.


• Además, ofrecen una larguísima y creciente colección de plantillas ('templates') con flujos ya construidos y casi listos para ser usados.

El lector avezado se dará cuenta de que se parecen mucho a RPA. En efecto, son soluciones muy similares. La diferencia habitual entre ambos tipos de herramientas es que estas de que hablamos ahora,  normalmente sólo se pueden ejecutar en la nube, no pudiendo acceder a recursos o ficheros locales del ordenador del usuario (sólo pueden acceder a ficheros en la nube, típicamente en OneDrive o Google Drive) y tampoco siendo capaces de interactuar con las pantallas de aplicaciones. Por su parte las soluciones RPA sí que son capaces de acceder a recursos locales y pantallas y tienden a ser herramientas algo más sofisticadas.

Entre las herramientas de esta categoría algo indefinida tenemos soluciones como Make, Zapier o N8N e, incluso Power Automate Cloud, la parte de Power Automate que opera en la nube.

Agentes

Y ahora tenemos también los famosos agentes de la agentic AI, que también se parecen mucho a RPA. La gran diferencia de los agentes de la Agentic AI respecto a RPA, y también respecto a las soluciones de automatización de workflow que acabamos de ver, es que, en los agentes el flujo, el workflow, no es explícito, sino que se realiza conforme a planes que genera de forma dinámica un modelo razonador y que la forma de especificar los objetivos de esos agentes suele basarse en lenguaje natural.

Hibridación

Existe, no obstante un gran solape e hibridación entre las soluciones que acabamos de ver: soluciones de automatización de flujos, robots RPA, agentes, chatbots (especialmente los chatbots modernos basados en modelos generativos) e, incluso, soluciones BPMS.

De hecho, en uno de sus últimos cuadrantes mágicos, Gartner habla de 'Business Orchestration and Automation Technologies (BOAT)' y en ese cuadrante mágico vemos soluciones que normalmente encuadraríamos como BPMS, junto con otras de tipo RPA y alguna de automatización de workflows.

La automatización de baja intensidad... que puede ser todo lo contrario

En efecto, lo que se ve en este tipo de soluciones (RPA, workflows y agentes) es el foco en la automatización muy sencilla, no de grandes procesos de negocio, sino de tareas concretas o de procesos muy sencillitos pero que involucran a dos o tres sistemas.

Por eso en mi mente surge la idea de una automatización de baja intensidad, aunque el nombre correcto sería, mas bien, el de una automatización de baja complejidad, porque, en efecto, son herramientas sencillas, al alcance de personas no desarrolladoras, poniendo la automatización al alcance de cualquiera y, por tanto, lo que creo que están consiguiendo, o pueden conseguir, es una altísima intensidad de automatización, especialmente en PYMEs e incluso autónomos, es decir, automatizaciones sencillas...pero en gran cantidad.

Conclusiones

Desde hace unos pocos años tenemos un conjunto de nuevas soluciones de automatización, centradas en flujos y tareas relativamente simples y que, además, son de uso muy sencillo, lo que puede llevar a una automatización básica, pero masiva.

Exactitud vs. flexibilidad en modelos de inteligencia artificial (y IV): humanoides, escala y tecnología

Y con este post finalizo la corta serie dedicada a examinar la tensión que se produce entre la exactitud y fiabilidad de técnicas digitales tradicionales, incluyendo los modelos no generativos de inteligencia artificial, frente a la potencia y flexibilidad (a cambio de menor fiabilidad) de las soluciones generativas.

En este post, primeramente voy a mirar hacia la traslación de estos conceptos al mundo físico, y muy en concreto al caso de los robots humanoides. Y luego voy a intentar razonar si debemos mantener una diversidad de soluciones o si podría tener sentido, y en qué condiciones, quedarnos sólo con la visión generativa (y los robots humanoides).

Un repaso de la tensión exactitud vs. flexibilidad

Simplemente, a modo de recordatorio, resumo brevemente lo visto en los tres posts anteriores.

Lo que he intentado mostrar es que las técnicas digitales tradicionales  e, incluso en muchos casos, los modelos discriminativos de inteligencia artificial, nos proporcionan soluciones a diversas problemáticas que son adecuadas y, sobre todo, fiables, predecibles y confiables.

Así, en el caso de la analítica, si usamos meras consultas mediante SQL a bases de datos relacionales, o empleamos técnicas tradicionales de 'business intelligence', los análisis, los indicadores, los resultados son consistentes, repetibles y fiables. Incluso si realizamos modelos predictivos basados en un machine learning 'más tradicional', y dentro de que un modelo siempre es una abstracción, podemos fiarnos bastante de sus resultados y que, sobre todo, de que éstos serán consistentes.

En el mundo de la automatización de procesos, todos los sistemas tradicionales de automatización (sistemas empresariales, sistemas BPMS y Case Management, formas sencillas de RPA, etc) se basan en reglas y flujos perfectamente claros, exactos y predecibles.

Finalmente, en el ámbito del desarrollo software, y aunque en este caso nos encontramos ante una actividad más artesanal, la aplicación rigurosa de la ingeniería de software, especialmente si se apoya en implementaciones fuertemente automatizadas como las que ofrece DevOps, no conseguimos una completa exactitud y fiabilidad, pero sí un cierto rigor y control y una razonable predecibilidad.

El punto surge cuando utilizamos los modelos generativos. Unos modelos que son enormemente potentes,  que no dejan de evolucionar, crecer en capacidades y asombrarnos. Pero, además, unos modelos que son muy transversales, que se pueden aplicar a 'casi cualquier cosa', que nos pueden servir para hacer analítica, para automatizar (pensar en el caso de los agentes) y para generar código software. A su potencia y transversalidad unen, además, su facilidad de uso. 

¿El problema? 

Pues que esa potencia y flexibilidad viene con el coste de su no completa fiabilidad (siguen sufriendo 'alucinaciones') y la no completa predecibilidad de resultados, pudiendo ofrecer conclusiones o acciones diferentes en cada invocación.

Un paralelismo en robótica: ¿Tienen sentido los robots humanoides en una fábrica?

En mi opinión, existe un razonable paralelismo entre estas problemáticas y la situación con un eventual uso de robots humanoides en fábricas (tal como sugería Musk, apostando por el uso masivo de su Optimus en las fábricas de Tesla).

La automatización industrial se mueve en entornos muy predecibles y con reglas tremendamente claras. En ese ámbito, los mecanismos tradicionales de automatización industrial se comportan perfectamente. Hablo, por ejemplo, de los sistemas PLC, de las máquinas de control numérico o de los propios robots industriales, especialmente los brazos robóticos que actúan como manipuladores. No sólo es que el ámbito industrial esté sometido a reglas muy claras, es que además, y como recordaba en el primer post de esta serie, un atributo clave del concepto de calidad es, precisamente, la repetitividad, el que los resultados sean similares por más veces que se repita un proceso.

Salvando las distancias, un robot humanoide (no los que tenemos ahora mismo, sino los que aspiramos a tener en unos meses o años) sería algo parecido a un modelo generativo (incluso, internamente, los pueden utilizar): una máquina muy potente, capaz de hacer cosas muy diferentes y, por tanto, muy flexible. A cambio, cabe pensar que, al estar menos especializados, serían menos eficientes que sus contrapartidas tradicionales. No sólo eso, probablemente (aunque esto está por comprobar), sus resultados serían menos predecibles.

Y es que, en general, la flexibilidad tiende, aunque no de forma absoluta, a estar reñida con la eficiencia y la predecibilidad. 

Según eso, al menos a corto y puede que medio plazo, parece difícil que los robots humanoides puedan sustituir con ventaja a los robots industriales y otras formas de automatización industrial más tradicionales 

¿Diversidad de soluciones o apuesta por lo flexible?

Y tras este inciso, volvemos al problema principal. Dado que, en bastantes casos, los sistemas tradicionales parecen garantizar resultados más fiables, más exactos y, en general, una mayor eficiencia, pero dado también que, por otro lado, los modelos flexibles (modelos generativos de IA o robots humanoides) ofrecen tanta potencia, tanta flexibilidad y tanta facilidad de uso ¿debemos considerar una diversidad de soluciones y elegir en cada caso la más adecuada?

O, por el contrario ¿Debemos apostar 'a saco' por los modelos flexibles, como los modelos generativos en IA y los humanoides en robótica?

Estimo que a corto plazo, debemos ser cautos y no apostar a ciegas por los modelos generativos (o los robots humanoides), sino razonar en cada situación, con objetividad y argumentos, qué es mejor: si el modelo generativo (o los robot humanoides, en su caso) o soluciones más tradicionales y exactas. 

Pero identifico tres elementos, tres razonamientos, que podrían cambiar esa consideración y volcar la apuesta hacia los modelos más flexibles en un futuro, quizá no lejano:

• El factor escala y el razonamiento económico
• La curva de aprendizaje
• La evolución tecnológica

Veámoslo.

El factor escala y el razonamiento económico

El factor escala aplica en general, pero me resulta especialmente relevante en el caso de los robots humanoides.

Si mantenemos la apuesta por una diversidad de opciones, cada una de esas opciones se aplicará de una forma más limitada. Quiero decir, en ocasiones los problemas se resolverán con una tecnología y en otras ocasiones con otra. Eso quiere decir que ninguna tecnología dominaría completamente el mercado. Y hay que tener en cuenta que, en el caso concreto de la automatización industrial, los equipos y especialmente los robots son máquinas caras. Y los robots humanoides, también son caros, muy caros.

¿Qué ocurriría si en lugar de esa diversidad de soluciones el mercado apostase decididamente por una sola, por ejemplo, por los robots humanoides? Pues pasaría que se venderían miles, millones de unidades. Y, por tanto, aumentaría la competencia y, sobre todo, se conseguirían economías de escala. Y el precio de los robots humanoides podría bajar mucho. En esa situación, podría ser económicamente mucho más eficiente adoptar robots humanoides que, además, por su flexibilidad, podrían valer casi para cualquier tarea. Y eso podría llevar a que los robots humanoides desbancasen a las oras formas de automatización industrial. En el caso concreto de los robots humanoides esa economía de escala podría ser mucho más profunda si triunfasen, no sólo en el ámbito industrial, sino también en los servicios y en el entorno doméstico.

Aparte de esa visión 'macro', si pensamos en la economía de una empresa concreta, es más barato en términos de soporte, mantenimiento y formación, el usar una sola tecnología. Y el uso de una sola tecnología es más posible cuando esta es flexible.

Es cierto que, especialmente en automatización, y más especialmente en automatización industrial, las soluciones flexibles (robots humanoides o modelos generativos) tendrían que alcanzar un mínimo admisible de fiabilidad pero, incluso, y siempre que no entremos en aplicaciones peligrosas, podría seguir siendo rentable un proceso de algo menor calidad (que produce más piezas defectuosas que hay que desechar) si, a cambio, el coste en su conjunto es menor. 

La curva de aprendizaje

He mencionado ya en el punto anterior el aprendizaje. En efecto, utilizar una diversidad de tecnologías implica tener multitud de habilidades y capacidades en las personas, y eso implica más formación y más dificultad de adaptación.

Si en lugar de eso nos centramos en una única tecnología (y, en ese caso, parece lógico optar por la más flexible) el coste de formación sería menor y la curva de aprendizaje de trabajadores y profesionales se aceleraría.

Si a esto añadimos que las nuevas tecnologías flexibles (como los modelos generativos) son cada vez más sencillas de utilizar, parece claro que esa facilidad de aprendizaje puede ser un importante factor de decisión y un impulso a la adopción. 

La evolución tecnológica

Finalmente, es importante dar 'un voto de confianza' a la tecnología y la evolución tecnológica.

Los motivos para mantener soluciones más tradicionales en lugar de 'ir de cabeza' a por las más flexibles (modelos generativos y humanoides) tienen que ver, sobre todo, con la eventual falta de fiabilidad y eficiencia de esos modelos flexibles frente a los tradicionales. Pero esa ventaja puede acortarse o, incluso, desaparecer. Y puede suceder en poco tiempo.

Es cierto que, en el caso de los modelos generativos, al menos en sus arquitecturas actuales, las alucinaciones parecen casi inevitables. Pero ¿Quién dice que mediante entrenamiento, mediante retoques en la arquitectura de los algoritmos o mediante adición de piezas adicionales, no seremos capaces de reducir esas alucinaciones a un mínimo perfectamente admisible salvo, quizá, en aplicaciones de misión crítica?

¿Quién dice que, igual que los modelos generativos supusieron un cambio de paradigma y un salto cualitativo en potencia y flexibilidad, no aparecerá un nuevo paradigma dentro de seis meses o un año, que haga que las eventuales desventajas de las soluciones flexibles desaparezcan? De la misma forma ¿Quién dice que en el caso de los robots humanoides no encontraremos algoritmos que los hagan más fiables o materiales que los hagan más baratos? 

Los últimos años nos han demostrado un avance tan espectacular en materia de tecnología que casi que, lo que no es racional ahora mismo, es no dar un margen de confianza a esa mejora tecnológica.

Conclusiones

Existe una tensión entre la fiabilidad, eficiencia y exactitud que nos proporcionan por un lado las tecnologías mas tradicionales y, por otro, la potencia, flexibilidad y facilidad de uso que viene de la mano de tecnologías 'flexibles' como los modelos generativos de la IA o los robots humanoides.

Y eso aplica a campos como la analítica, la automatización o la generación de código que hemos revisado en esta serie de artículos.

Actualmente, y seguramente durante un tiempo, habrá que saber elegir de manera consciente e informada entre qué solución es mejor en cada caso.

Pero de cara al futuro elementos como las economías de escala, la curva de aprendizaje o la mejora tecnológica, podrían llegar a volcar de manera definitiva la apuesta hacia esas soluciones flexibles.

Habrá que observar, analizar y decidir. 

Artículos de este blog relacionados

• Exactitud vs. flexibilidad en modelos de inteligencia artificial (III): ingeniería software y 'vibe coding'
• Exactitud vs. flexibilidad en modelos de inteligencia artificial (II): automatización inteligente
• Exactitud vs. flexibilidad en modelos de inteligencia artificial (I): analítica inteligente

Exactitud vs. flexibilidad en modelos de inteligencia artificial (II): automatización inteligente

Acometo ahora el caso de la automatización, tras abordar en el post anterior el dominio de la analítica inteligente, como uno de los grandes campos de aplicación de la inteligencia artificial y donde también se produce, seguramente más que en el caso de la analítica, esa tensión entre la exactitud de modelos anteriores y la flexibilidad y potencia de los modelos generativos.

Vamos a verlo.

Recordando ideas básicas sobre automatización de procesos

De forma muy sencilla, podemos decir que automatización es la realización por parte de máquinas, de procesos y tareas antes realizadas por personas (u animales).

Aunque existe, y es muy importante, la automatización que involucra elementos físicos (como la automatización que se produce en procesos industriales y, por ejemplo, plantas de fabricación), prefiero centrarme en este post en la automatización de procesos de negocio de oficina u administrativos, donde se trabaja fundamentalmente con información y documentos (todo ello en formato digital), más que con materiales físicos. 

He mencionado la palabra procesos de negocio. ¿Qué es un proceso de negocio? De forma sencilla, en mi libro 'Robots en la sombra', los defino como:

Un conjunto de actividades que, coordinadas, producen un resultado de negocio 

El tratamiento de pedidos de cliente es un proceso de negocio, el tratamiento de reclamaciones también, o la sección de un candidato para incorporarse a una empresa.

Los procesos implican una serie de actividades que se enlazan mediante una lógica que puede incluir incluir simples secuencias, o ramificaciones, basadas o no en condiciones , bucles, etc. Esas actividades atómicas que componen los procesos, es lo que con frecuencia se denomina tareas. En cierto modo, podemos pensar que un proceso se compone de tareas (que es donde realmente 'se hace algo') y elementos que le dan lógica y estructura (las secuencias, ramificaciones y bucles) y que enlazan de alguna forma las actividades o tareas.

En los procesos manuales, las tareas las realizan personas, y las decisiones de lógica, también las adoptan las personas (normalmente de una manera bastante informal y basada en su experiencia).

Cuando automatizamos procesos de negocio, lo que hacemos es sustituir, total o parcialmente a personas por máquinas. En el caso de procesos de negocio de oficina, las sustituimos total o parcialmente por aplicaciones o sistemas de información. Estas aplicaciones ejecutan total o parcialmente, todas o algunas de las tareas y, además, realizan las decisiones lógicas y estructurales acerca de qué actividad hay que hacer a continuación aplicando las famosas secuencias, ramificaciones y bucles. Además, de automatizar las tareas y la lógica, el tercer gran elemento de una automatización de procesos es el almacenamiento y recuperación de información.

No voy a entrar en detalles, pero, aunque hay muchas soluciones de automatización de procesos tradicionales, algunas muy de nicho, las más generalistas son los sistemas empresariales (CRM y ERP) y los sistemas orientados a proceso  como los BPMS ('Business Process Management Systems') o los CMS ('Case Management Systems') sin despreciar la multitud de soluciones 'ad-hoc' hechas a medida por las diferentes organizaciones.

Reglas y flujos

En cualquier caso, en todas esas automatizaciones tradicionales, las tareas siguen procedimientos más o menos fijos y basados en reglas. Y la estructura del proceso, su lógica, también sigue unas reglas reflejadas generalmente en un flujo.

Una gran fortaleza de esta forma de actuar es su eficiencia y también su previsibilidad, y recuerdo que la previsibilidad o, si se prefiere, la repetitividad de un proceso, es un atributo esencial del concepto de calidad.

Automatización inteligente

Dicho de forma muy sencilla, la automatización inteligente no es más que introducir elementos de inteligencia artificial en la automatización. 

Esto se lleva haciendo desde hace unos pocos años, pero hasta ahora los elementos inteligentes se han venido centrando en aspectos particulares.

Así, por ejemplo, una forma de introducir automatización inteligente es, simplemente recurrir a procesamiento de lenguaje natural y a reconocimento y generación de voz para relacionarse con las personas (los típicos chatbots). 

También los robots RPA ('Robotic Process Automation') utilizan, por ejemplo, inteligencia artificial para extraer información de a partir de texto libre contenido en webs, correos y documentos, o variantes de la visión artificial como el OCR para extraer texto de imágenes.

También se ha ido haciendo más común el invocar módulos de inteligencia artificial para, por ejemplo, hacer un análisis de sentimiento, o para tomar una decisión con base en algún modelo de machine learning previamente entrenado.

Pero todas estas formas de incluir inteligencia artificial apenas cambian el hecho de que la estructura del proceso se sigue basando fundamentalmente en reglas y flujos predefinidos, y que la mayor parte de las tareas siguen estando perfectamente procedimentadas.

La irrupción de los modelos generativos

Y en esto surgen y sobre todo, se generalizan, los modelos generativos que, como comentábamos en el post anterior, son enormemente potentes, muy transversales y muy flexibles pero que, a cambio, no siguen unas reglas cerradas y completamente previsibles, a veces 'alucinan' y, en general, no podemos estar del todo seguros de 'lo que van a hacer' y si lo van a hacer de la mejor manera posible, ni siquiera de si lo van a hacer bien.

Y sin embargo, cada vez se utilizan más para automatizar y es previsible que esto se incremente rápidamente, especialmente a medida que los agentes de IA ('Agentic AI') madure y se extiendan estas soluciones.

Y ahí surge la tensión: ¿Cuándo tiene sentido usar una automatización basada en modelos generativos y cuándo una más tradicional basada en reglas y flujos?

La automatización de tareas individuales mediante herramientas generativas

Si nos centramos no en la estructura del proceso de negocio, sino en tareas individuales, resultan claramente aplicables en muchas ocasiones las herramientas generativas y se hace cada vez más el uso de soluciones generativas de tipo chatbot (como ChatGPT, Copilot chat, Gemini, etc) aunque, en este caso, el uso habitual es en modo 'copiloto', es decir, la persona sigue realizando o responsabilizándose de la tarea,  lo que ocurre es que ayudada en buena medida por un asistente generativo. 

Es una forma de automatizar en que aún queda un poquito, menos cada vez pero un poquito, de intervención humana. El que quede un poco de intervención humana resta un puntito de la eficiencia posible, y quizá resta algo más de la optimización de tiempos posible frente a una automatización completa, pero a cambio, protege contra alucinaciones y errores absurdos, y permite mantener bastante el control.

La automatización inteligente de procesos: decisiones y planes

Más comprometido, aunque hacia eso apuntan las tendencias, es cuando queremos usar un modelo generativo para que decida la estructura del proceso, es decir, qué lógica de tareas a seguir, e incluso, qué tareas hay que realizar.

A eso es a lo que apuntan los modelos razonadores y los agentes que se apoyan en esos modelos razonadores. Aplicar esta forma de automatizar procesos es enormemente potente y flexible y proporciona a la automatización una gran capacidad de adaptación a las circunstancias, casi de improvisación, ausente en las automatizaciones tradicionales.

A cambio, la automatización en su conjunto, el proceso, es menos predecible, menos repetible (¿de menor calidad?), puede que no siempre optimice la eficiencia y parece más sujeto a errores, incluso errores absurdos. 

La conveniencia de usar esta forma de automatizar basada en modelos generativos (normalmente razonadores) en lugar de métodos más tradicionales, dependerá en parte de hasta qué punto estos modelos maduren y demuestren que son fiables, que se equivocan poco y que no lo hacen de forma catastrófica. No excluyo la eventual realización de 'fine tunning' o de entrenamiento de modelos especializados en ciertos ámbitos de automatización como forma de conseguir esa fiabilidad.

Pero creo que hay otro factor que es la naturaleza del proceso.

La naturaleza del proceso: 'ad-hoc e investigación

Si el proceso de negocio, ya por su propia naturaleza, tiene unas tareas muy claras, con reglas muy claras, parece que, al menos en cuanto a eficiencia, pueden ser mejores los métodos tradicionales aunque, por ejemplo, no cabe excluir escenarios en que incluso estas soluciones tradicionales se apoyen en algunos aspectos en modelos generativos. Por ejemplo, se puede describir en lenguaje natural la lógica del proceso a un sistema generativo (o un asistente generativo) el cual crea esa lógica en notación BPMN, la cual se incorpora ya un BPMS (y esto se puede hacer de forma trasparente).

Un campo donde sí veo bastante directa y próxima la aplicación con ventaja de soluciones generativas es en el caso de procesos que, por su propia naturaleza, son dinámicos y bastante desestructurados, con una lógica que se construye en tiempo de ejecución. Serían los típicos procesos soportados por herramientas de 'Case Management' y modelados en BPMN como procesos 'ad-hoc' (ej, tratamiento de reclamaciones, diagnóstico de averías, etc) o procesos de recopilación de información e incluso investigación donde, de hecho, los modelos razonadores y, especialmente actuando en modo 'deep research', demuestran ya una gran utilidad.

Conclusiones

Aunque la tendencia a utilizar soluciones inteligentes (y muy especialmente los agentes inteligentes) parece imparable, puede que no siempre sea la mejor opción de automatización de procesos, al menos de momento.

Ya actualmente los modelos generativos o soluciones basadas en modelos generativos, encuentran un gran espacio en la automatización de tareas individuales (fundamentalmente actuando como copilotos o asistentes de personas). Igualmente, parecen tener un campo prometedor y ya parcialmente acometido, para la automatización de procesos con una lógica no del todo estructurada y que se construye dinámicamente en tiempo de ejecución.

Más comprometido puede ser el uso para la automatización de procesos de estructura compleja pero clara y, de forma natural, basada en reglas. En ese caso, todavía se podría conseguir mayor eficiencia y sobre todo fiabilidad con esquemas más tradicionales de automatización, aunque esto puede irse modificando según lo que sean capaces de demostrar los modelos razonadores y los agentes. 

Creo, de todas formas, que hay otro elemento muy importante a tener en cuenta y que afecta tanto a analítica inteligente como a automatización inteligente, pero ese lo reservo para un siguiente post.

Artículos de este blog relacionados

• Exactitud vs. flexibilidad en modelos de inteligencia artificial (I): analítica inteligente