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.

MCP o la reinvención de los conectores para aplicaciones inteligentes basadas en LLM

En este frenético surgir de tecnologías, modelos y aplicaciones alrededor de la inteligencia artificial generativa y, en particular, de los grandes modelos de lenguaje, una llamémosle tecnología que quizá a recibido menos atención fuera de ámbitos especializados, es MCP ('Model Context Protocol').

Tal y como yo lo entiendo, MCP, en el fondo, es una forma de plantear los tradicionales conectores o APIs para una integración, a un tiempo más encilla y más estándar, de todo tipo de aplicaciones externas con agentes o aplicaciones basadas en LLM ('Large Language Model').

En este post no voy a entrar mucho en detalles sobre la arquitectura de MCP (tal vez lo haga en algún otro post) sino, más bien, en esa visión como una nueva expresión de los conectores.

Sobre las APIs

Cualquiera que haya programado, quizá no tanto los que no lo hayan hecho, tiene una idea de lo que es un API ('Application Programming Interface').

¿Qué es un API?

Bueno, cuando hablo de ellas en mi libro 'Robots en la sombra' indico que

Un API no es más que un conjunto conocido y bien definido de acciones que se pueden solicitar a un software, incluyendo la descripción detallada de los datos de entrada y salida esperados y el resultado que se espera.

Se trata de un mecanismo acordado y estandarizado por el que pueden interactuar dos elementos de software diferentes (dos aplicaciones, dos componentes, etc). 

Vistas desde el lado del desarrollador, las APIs se pueden manifestar como un conjunto de funciones en un lenguaje de programación dado o como un conjunto de objetos y sus métodos expresados en ese lenguaje o, por ejemplo, como unos métodos HTTP y sus datos en la URL, o en forma de ficheros de tipo XML o JSON.

A la hora de distribuir ese API, se puede manifestar también de varias formas: una librería que enlazamos a nuestro programa, una librería compartida o unos 'endpoints' HTTP, por ejemplo.

Aunque hoy en día, casi siempre que se menciona un API se está pensando en APIs REST, no tiene por qué ser así, hay muchas otras variantes.

Sobre los conectores

¿Y qué es un conector?

Estrictamente hablando, y en mi opinión, un conector no es más que una forma un poco especial de presentarse un API. Una forma que, en general, está mucho más adaptada al entorno final de desarrollo y que hace mucho más fácil utilizarla.

Hay quien entiende como conector ese mecanismo de integración que permite incorporar la funcionalidad de otro componente o aplicación, sin necesidad de desarrollar código. 

Así, por ejemplo, en soluciones de automatización 'Low code' como los productos RPA ('Robotic Process Automation') o de automatización de flujos, del tipo de UiPath, Power Automate o Make, los conectores se ven como actividades, pasos, etc que puedes incorporar a un flujo de manera gráfica.

Con mucha frecuencia, los conectores se apoyan a su vez, en un API, siendo, en el fondo, una manifestación más sencilla e integrada de ese mismo API.

Una introducción de urgencia a MCP

¿Y qué es MCP? Pues MCP es un protocolo estándar definido por Anthropic hace poco más de un año y que está siendo rápidamente por terceros, incluyendo a la propia OpenAI.

MCP habilita el uso de componentes o aplicaciones externas (que se manifiestan como los llamados servidores MCP) por parte de aplicaciones, típicamente aplicaciones de inteligencia artificial basadas en LLM que implementan el lado cliente MCP. Y, sí, es que MCP sique un esquema cliente-servidor.

El protocolo define una serie acotada de mensajes que se traducen, desde el punto de vista de datos, en objetos JSON siguiendo el estándar JSON-RPC, y desde el punto de vista de transporte, como HTTP (en general para interacciones externas) o stdio (flujos o streams apoyados en 'pipes') para interacciones locales.

Mediante el intercambio de esos mensajes entre cliente y servidor, se consigue la integración funcional.

Una de las grandes ventajas que se busca con MCP es la integración, usando un único estándar, de todo tipo de aplicaciones. Es decir, la aplicación cliente, accede a cualquier servidor MCP casi de la misma forma, lo cual es casi tanto como decir que accede a cualquier aplicación o componente de la misma forma.

MCP como API

Podemos entender MCP como una forma de API, donde el "conjunto bien definido de acciones" de que hablaba en mi definición, son esos mensajes que constituyen el protocolo MCP, expresándose mediante JSON los datos de entrada y salida.

MCP como conector

Pero, en cierto sentido, también podemos considerar MCP, o más bien los servidores MCP, como una forma de conector que ofrece a las aplicaciones basadas en LLM un acceso razonablemente sencillo y 'en su idioma' a todo tipo de recursos externos.

Y es por ello que hablo de una reinvención de los conectores porque, en el fondo, los servidores MCP hacen el papel de conector, pero supone una reinvención porque es un nuevo estándar, porque se adapta muy bien a ser invocado por aplicaciones basadas en LLM y porque ofrece el valor añadido de unificar y estandarizar esa forma de acceso.

Una gran aportación...aunque, en el fondo, sigamos hablando de conectores, los ya casi vetustos conectores.

MCP y las herramientas que usan los agentes

Cuando hablamos de agentes, ya comentamos que éstos pueden acceder o interaccionar con recursos externos mediante las llamadas herramientas ('tools').

Pues bien, MCP es un mecanismo flexible y estándar de proveer a las aplicaciones basadas en LLM de una cantidad ingente de herramientas (todas las que se expongan como servidores MCP). 

Las Apps de ChatGPT

Una de las formas de usar MCP (o los servidores MCP) más llamativas, en parte por ser ofrecida por OpenAI en su ChatGPT, es el mecanismo de las Apps, una capacidad, anunciada muy recientemente por Open AI que permite que el usuario de ChatGPT interaccione con todo tipo de aplicaciones (Google Drive, GMail, Slack, Figma, etc) en lenguaje natural.

Como una suerte de prueba de que estamos hablando, en el fondo, de una forma de conectores, el propio ChatGPT, en su apartado de configuración, se refiere a las Apps realmente como conectores, como se puede ver en la figura:

La configuración de conectores en ChatGPT

Así que tenemos una aplicación basada en LLM, como es el propio ChatGPT, capaz de acceder una multitud de recursos externos (las aplicaciones) mediante el uso interno de MCP como mecanismo de integración entre ChatGPT (el cliente MCP) y las aplicaciones (los servidores MCP).

Conclusiones

MCP es un protocolo estándar que permite a las aplicaciones basadas en LLM (como chatbots o agentes) acceder de manera unificada a todo tipo de recursos y aplicaciones que se exponen como servidores MCP.

De esta forma MCP no sería más que un nuevo planteamiento de API y los servidores MCP un caso especial, y una reinvención de los conectores 'de toda la vida'.

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

Revisitando el problema de la explicabilidad en LLMs y modelos razonadores

Uno de los grandes desafíos éticos cuando hablamos de inteligencia artificial es el de la explicabilidad, un problema que, por desgracia, se ha demostrado técnicamente muy difícil de resolver... al menos hasta el momento.

En una reflexión que tuve hace unos días, llegué a la conclusión de que el problema de la explicabilidad de los algoritmos de IA, presenta unas características muy particulares en el caso de los grandes modelos de lenguaje (LLM, 'Large Language Models') o, en general, en los modelos fundacionales.

Aunque hay algunos aspectos en los que todavía tengo pendiente profundizar, sí quisiera comentar en este post algunas de las particularidades que percibo, algunas reflexiones o incluso preguntas abiertas que me gustaría formular... y una esperanza.

En realidad, se trata de un tema que ya traté hace un tiempo en el post 'La explicabilidad en los grandes modelos de lenguaje' y, de hecho, bastantes de las consideraciones que voy a hacer se pueden encontrar ya en ese artículo, pero de todas formas, quisiera reformular un poco y ampliar lo que allí expresé y proporcionar alguna nueva y esperanzadora perspectiva.

El problema de la explicabilidad

Antes de seguir, y aunque asumo que la mayor parte de los lectores de este post tienen alguna noción sobre el problema de la explicabilidad, realizaré un muy breve repaso.

Como es bien sabido, los algoritmos de inteligencia artificial realizan cada vez mayor número de tareas. Dentro de estas tareas se incluyen muchas que suponen la toma de decisiones. Lo que la explicabilidad de la inteligencia artificial reclama es que el algoritmo pueda explicar en qué basa sus decisiones. Añado de mi cosecha, que esa explicación debe realizarse en términos comprensibles por los humanos.

En el vasto panorama de algoritmos de inteligencia artificial, algunos son claramente explicables, como es el caso de los árboles de decisión, pero otros son claramente e intrínsecamente no explicables, como es el caso de las redes neuronales.

El problema se agrava porque los algoritmos más comunes, más sofisticados, más importantes de hoy en día, son variantes arquitectónicas de redes neuronales. Es decir, los algoritmos que dominan la inteligencia artificial actual, son en principio no explicables.

Además, conviene resaltar que no es que no sean explicables por alguna decisión arbitraria y 'malvada' de un directivo, ingeniero o desarrollador... es que intrínsecamente son así, no explicables. 

Dos opiniones propias: el determinismo y el sentido común

En otras ocasiones  he defendido dos ideas que quisiera traer a colación ahora.

Por un lado el determinismo. Esta idea la defendía en el post que, provocativa e intencionadamente, titulé 'Los algoritmos de Inteligencia Artificial sí saben explicarse'.  Lo que ahí defiendo es que los algoritmos de inteligencia artificial (incluyendo las redes neuronales), son deterministas (misma entrada implica misma salida) y, por tanto, pueden explicar perfectamente por qué obtienen un resultado, por qué llegan a una decisión. ¿Es esto una contradicción? No, realmente. Lo que ahí expreso es que, aunque se pueden explicar perfectamente, lo hacen en términos que los humanos no pueden entender, no pueden contraargumentar y no se pueden recurrir legalmente. Por tanto, aunque en el fondo sean explicables (por ser deterministas), a efectos prácticos no lo son.

Por cierto, que la afirmación de que son deterministas puede sorprender cuando, por ejemplo en el caso de los LLMs de que luego hablaremos se afirma, y correctamente, que son probabilistas. Esto precisa unas explicaciones y matizaciones que no voy a a hacer ahora, sino que pospongo para un futuro post específico sobre el particular.

La otra opinión, que ya no es técnica sino legal y práctica, es la que tiene que ver con el sentido común, y ésta la defendí, por ejemplo, en el último capítulo de mi libro 'Robots en la sombra'. Lo que ahí decía era que no tiene sentido exigir la explicabilidad de los algoritmos sin más ni más. Para decisiones de naturaleza práctica, técnica u operativa (ej. el reconocimiento de una matrícula en un coche y la apertura de la barrera del parking), nos basta con que sean eficaces y eficientes, con que den buenos resultados y, al menos desde el punto de vista ético y legal, no tiene sentido exigir la explicabilidad. La explicabilidad pueden y quizá deben exigirse en decisiones 'delicadas' como la selección de candidatos, la concesión de préstamos o seguros, la sentencia de un juicio (un escenario hoy día no real) y cosas así.

El enfoque legal

Desde Julio de 2024, en Europa la referencia obligada en términos legales sobre la inteligencia artificial es la AI Act o RIA ('Reglamento de Inteligencia Artificial'),  un documento que me encuentro precisamente estos días leyendo despacio e intentando analizar y entender.

Curiosamente, en el texto de la RIA no aparece el término 'explicabilidad' más que una vez, en el considerando 27, y como referencia a los principios éticos identificados por el grupo de expertos de alto nivel en y recogidos en el documento 'Directrices éticas para una IA fiable'.

A cambio, se habla de transparencia y bajo este término se pide que el usuario sepa claramente que está interactuando con una inteligencia artificial o que se identifiquen claramente los contenidos generados mediante inteligencia artificial. También bajo el paraguas de este término se habla de proporcionar la documentación técnica del algoritmo, y sí, en su artículo 13 exige cierta documentación (aunque parece que no de mucho detalle) para el caso de los sistemas de alto riesgo.

Por otro lado habla también de  interpretabilidad: y, en este caso, se pide que los resultados sean entendibles e interpretables por los humanos, y no sólo los resultados, sino cómo se ha llegado a esa conclusión o decisión.

Sinceramente, en este momento, no me queda claro si la RIA exige una explicabilidad 'profunda', es decir, que el algoritmo pueda explicar detalladamente sus decisiones o se conforma con una cierta documentación y explicación comprensibles.

Y esta duda es importante resolverla para darnos cuenta de cómo de realista es la exigencia y, sobre todo, cómo afecta a los grandes modelos de lenguaje.

Algunas soluciones tradicionales. El caso de los modelos proxy

Algunas de las soluciones técnicas que se han propuesto para resolver el problema de la explicabilidad, especialmente en el caso de redes neuronales, pasan, por ejemplo, por entender el impacto en la salida de modificar una entrada, o conocer cuánto habría que modificar una entrada para cambiar la decisión de salida. Creo que son propuestas interesantes pero que, aunque ayudan a entender el algoritmo y su funcionamiento (a hacerlo un poco menos 'caja negra')  realmente no resuelven la explicabilidad ya que, de forma general, no pueden responder a por qué toman sus decisiones aunque, a toro pasado, y en un estudio detallado, quizá se podría llegar a determinar cómo se tomo una decisión concreta.

Otras soluciones pasan por los modelos proxy, es decir, poner en paralelo un modelo explicable (como un árbol de decisión) con el no explicable (red neuronal) consiguiendo que den resultados similares y usar la explicación del modelo explicable (en este caso, el árbol de decisión).

Tampoco me convence por dos motivos.

En primer lugar, si usamos redes neuronales es porque son más ricas y potentes que modelos como un árbol de decisión, con lo cual estrictamente no se puede conseguir un verdadero modelo paralelo (si fuese posible, optaríamos directamente por el árbol de decisión, y no por la red neuronal).

Y, en segundo lugar, incluso si el modelo paralelo funcionase bien, estrictamente no estaría explicando la decisión del modelo real. Ofrecería una explicación plausible y comprensible de cómo, quizá, ha razonado la red neuronal...pero estrictamente seguimos sin saber si la red neuronal ha funcionado así o no, con lo que realmente no estamos dando la verdadera explicación.

Los LLMs: explicabilidad intrínseca y explicabilidad mediante prompts

Y pasamos ya al caso de los grandes modelos de lenguaje.

Supongo que muchos lectores de este blog ya lo saben pero, por si acaso, es importante recordar que todos los grandes modelos de lenguaje actual, probablemente todos o casi todos los modelos generativos, se basan en redes neuronales y, por tanto, son intrínsecamente no explicables.

Y, sin embargo, si en lugar de mirar su funcionamiento interno, nos fijamos en su comportamiento externo, un modelo de lenguaje, además de proporcionar respuestas perfectamente interpretables, también nos puede proporcionar, si se lo pedimos, y de nuevo de forma perfectamente entendible, una explicación de su respuesta.    

Técnicas de promting orientadas a la explicabilidad

No sólo eso,  existe técnicas de prompting como el 'Few-Shot prompt' orientadas, en este caso mediante ejemplos, a guiar el razonamiento del modelo de lenguaje. 

Y aún más: otras técnicas de 'prompting' bien conocidas , como el Chain-Of-Thought o 'Self Consistency, no sólo guían el razonamiento de un modelo de lenguaje sino también la explicación que nos proporciona sobre cómo ha llegad a sus conclusiones.

¿Es eso explicabilidad? ¿Está resuelto el problema?

Las explicaciones de un LLM como un proxy

Bueno, creo que sí y no.

Creo que las explicaciones que se obtienen mediante prompting actúan realmente como una suerte de modelo proxy (como el árbol de decisión en paralelo con una red neuronal). Es decir, nos dan una explicación interpretable y plausible de cómo resolver el problema o cómo se ha adoptado la decisión... y una explicación que probablemente en muchísimos casos es correcta, válida y realista.

Pero una explicación que, en el fondo, no refleja el verdadero funcionamiento del modelo de lenguaje y, por tanto, estrictamente hablando, no explica realmente cómo ha llegado a la decisión. Y una explicación que, como cualquier salida de un modelo de lenguaje, también puede ser 'una alucinación'.

La gran pregunta ética y legal

Llegados a este punto, la gran pregunta es: ¿aceptamos como explicabilidad, tanto desde un punto de vista ético como legal esas explicaciones proxy que proporciona un LLM?

Quizá la respuesta dependería de que se pudiese demostrar que en un alto, altísimo porcentaje de los casos (que probablemente debería ser un 99 coma muchos nueves), esa explicación proxy es realista y que, si aplicásemos ese razonamiento que nos ofrece el LLM, llegaríamos a la misma conclusión que el propio LLM.

Y puede, incluso, que ya estemos en ese punto, pero puede que tengamos, incluso, una opción mejor.

Explicabilidad y modelos razonadores: ¿la gran esperanza blanca?

Un caso que quisiera mencionar, pero del cual necesito más información para juzgar (y me refiero no a explicaciones pedagógicas o comerciales superficiales, sino a información técnica de cierto nivel de detalle de la que aún no dispongo), es el caso de los llamados modelos razonadores, tan importantes ahora mismo y que sirven como base de los tan traídos y llevados agentes.

Este tipo de modelos (el propio GPT5 recién lanzado incluye un modo razonador) generan y siguen un procesos lógicos de razonamiento, unos procesos que, además, pueden revisar y cuestionar según avanzan y observan resultados. De hecho, en el entrenamiento de este tipo de modelos se utilizan, hasta donde sé, algunas de las técnicas de prompting orientadas a razonamiento que hemos mencionado (como el 'Chain-of-Thought').

Según cómo se encuentre implementado este razonamiento, las explicaciones que pudiesen dar esos modelos razonadores sobre cómo han llegado a una decisión sí que podría ser una verdadera explicación, y no sólo un proxy de la misma. Y si eso fuese así, quizá, quizá, podría considerarse resuelto el problema de la explicabilidad en los grandes modelos de lenguaje y los modelos fundacionales.

Y dado que actualmente, y parece que así será en el futuro, este tipo de modelos van a ser ubicuos en las soluciones de inteligencia artificial, a lo mejor podemos dar casi por resuelto el problema de la explicabilidad ... lo cual sería, dicho sea paso, absolutamente 'alucinante'.

En el título del epígrafe hablo de 'gran esperanza blanca'. Tengo mucho interés en profundizar en el conocimiento técnico interno de los modelos razonadores y tengo mucha curiosidad sobre la posición regulatoria respecto a los mismos en materia de explicabilidad.

Preventivamente, no quiero ni mucho menos dejarme llevar por el optimismo, pero si las respuestas a ese interés técnico y esa curiosidad regulatoria son positivas, y dado que los modelos razonadores ya están aquí, es posible que no estemos hablando de sólo de una esperanza, sino de un extraordinaria realidad.

Conclusiones

El problema de la explicabilidad ha sido uno de los grandes retos éticos ligados a la inteligencia artificial, un reto que, en el caso de las redes neuronales ha sido hasta ahora casi inabordable desde un punto de vista técnico.

La llegada de los grandes modelos de lenguaje abre otra forma de enfocar la explicabilidad, una forma que podría dar por válida la explicabilidad proxy ofrecida por estos modelos pero que, en el caso de los modelos razonadores, pudiera incluso, llegar ya a ser una solución prácticamente definitiva.

Human-Robot Interaction y los posibles modelos emocionales

Uno de los temas que más llaman la atención cuando hablamos de interacción con las máquinas, y muy especialmente con los robots, es todo lo que tiene que ver con las emociones: la detección de las emociones humanas por parte del robot, la expresión de emociones por parte de ese mismo robot y, si queremos ir muy lejos (probablemente demasiado lejos), la posibilidad de que alguna vez el robot pueda experimentar sus propias emociones.

Se trata de un tema que además, personalmente me fascina, tanto en su vertiente técnica como en sus implicaciones éticas. 

Uniendo algunas lecturas (y docencias) recientes que tienen que ver tanto con la disciplina del human-robot interaction como con inteligencia artificial generativa y agentes conversacionales, he creído detectar una evolución, una posible evolución que intuyo, pero que tengo pendiente de confirmar, que supone un cierto cambio de paradigma en el tratamiento de las emociones por parte de los robots.

Un cambio de paradigma que, en el fondo, simplemente trasladaría al mundo de la robótica social un cambio que ya se está produciendo en chatbots o agentes conversacionales.

Vayamos paso a paso.

Human-Robot Interaction

La relación robots-personas (HRI, 'Human-Robot Interaction') es una disciplina que auna conocimientos procedentes del campo de la robótica y la inteligencia artificial, pero también de la psicología o la antropología, y que se ocupa del estudio de la interacción entre personas y robots y del diseño de los mejores robots y mecanismos de interacción.

Tiene en cuenta cosas como, por supuesto, el lenguaje verbal, pero también el no verbal, la proxémica, las convenciones sociales y... si, la detección y gestión de emociones, donde se solaparía con la así llamada computación afectiva ('affective computing').

Gestión de emociones

Podríamos decir que, a la hora de gestionar emociones por parte de un robot, se podrían distinguir como tres fases, o tres dinámicas, interrelacionadas pero distinguibles:

• Detección de emociones en los humanos
• Experimentación de las propias emociones por parte del robot
• Expresión de emociones por parte del robot

De las tres anteriores, la segunda, experimentación de emociones por el propio robot, hoy en día es una pura fantasía, así que no nos detendremos más en ella.

Sí que son relevantes, y con importantes resultados tangibles, las otras dos: la detección de las emociones humanas por parte del robot y la expresión de unas emociones propias del robot (aunque se trate de emociones impostadas, no sentidas).

Modelado de emociones

Ya desde hace décadas, y de manera con frecuencia independiente al tratamiento mediante máquinas, en el campo de la psicología se han venido analizando e intentando modelar las emociones.

Uno de los primeros y más populares resultados fueron los hallazgos de Paul Ekman quien identificó las conocidas seis emociones básicas (alegría, ira, miedo, asco, sorpresa, tristeza) que eran reconocibles a partir de la expresión y que trascendían las culturas.

Expresiones faciales correspondientes a las seis emociones básicas

Posteriormente, Ekman amplió su catálogo a quince. Se trata de unos hallazgos no siempre bien interpretados o utilizados pero que, a efecto de HRI, me interesa destacar que permite la identificación de emociones a partir de expresiones faciales y que el resultado es una categoría de entre un número finito disponible de emociones.

El propio Ekman propuso posteriormente otro modelo en que, más que recoger expresiones faciales completas, se centraba en diversos detalles. Definía el Facial Action Coding System (FACS) donde se identificaban las AU ('Action Units') en número de varias decenas.

FACS

Estas action units se pueden reconocer visualmente o, en laboratorio, mediante medida de actividad muscular. Aunque no conducen de forma inmediata a una categorización de emoción, existen guías complementarias que sí lo hacen

En ambos casos, al final podemos llegar a una emoción como una etiqueta, de entre un conjunto finito de ellas, que caracteriza el estado emocional del ser humano.

Existen otros modelos que, trabajan es espacios continuos, bidimensionales (como el modelo circunflejo de Russell) o tridimensionales, y donde algunas de las variables de ese espacio suelen ser la denominada excitación ('arousal') que, de alguna forma, mide la intensidad de la emoción, y la valencia ('valence') que indica si se trata de una emoción más positiva o más negativa. 

Modelo circunflejo de Russell

Otros modelos, en este caso tridimensionales, como PAD, usado por el mítico robot Kismet, añade una dimensión de dominancia.

Aunque en estos modelos de emociones existe una continuidad, y no unas categorías cerradas, tampoco nos alejamos demasiado de esa visión de emociones como un catálogo de posibilidades, como se puede ver en la propia figura. De alguna manera, regiones de ese espacio de estado se corresponden con una emoción

Detección de emociones

Los robots detectan las emociones humanas tomando, en primer lugar, alguna forma de medida de su manifestación externa en los humanos, mediante sensores. Los dos más comunes, y probablemente al mismo tiempo los más potentes y ricos en información, son las cámaras (que permiten captar, fundamentalmente la expresión del rostro humano, pero también sus gestos y otros elementos de lenguaje no verbal) y los micrófonos que captan la voz incluyendo los elementos prosódicos como intensidad, acento, etc.

Sólo con esos dos tipos de sensores, tan familiares en todo tipo de aplicaciones, los robots obtienen casi toda la información que necesitan. Existen otros sensores, más especializados, pero ahora no profundizaré en ellos.

El caso es que, mediante los sensores, los robots tienen la información primaria sobre las emociones expresadas por el humano.

Desde ahí, la conclusión de la emoción subyacente y si nos basamos en un catálogo de emociones como el propuesto en su momento por Ekman,  se puede reducir a un problema de clasificación, tan común en el machine learning y deep learning.

Si utilizamos un espacio de estados, parece que hay un primer paso de regresión, para situar el estado emocional del humano en las características de ese espacio de estados, y luego, si queremos 'darle nombre' a la emoción, un problema de clasificación adicional casi trivial (que no precisa siquiera de inteligencia artificial) para asignar la emoción subyacente según la región en que nos encontremos.

Chatbots basados en reglas

Establecidas esas fases, paso ahora a comentar la evolución de los chatbots. Los chatbots de los que hemos dispuesto hasta hace poco, antes de la explosión de los modelos generativos, se han venido construyendo en general implementando un modelo de conversación que ya explicaba en mi libro 'Robots en la sombra' y que se muestra en la figura:

Modelo de conversación

En ese modelo, las intenciones ('intents') son una forma de categorización de lo que el usuario puede pedir al chatbot (reserva de cita, compra de un billete de avión, conocimiento sobre un producto, etc). Eso sí, como trabajamos en lenguaje natural esas intenciones se pueden manifestar verbalmente con expresiones ('utterances') diferentes e incluso muy diferentes. Asociada a cada interacción el humano suele añadir información en forma de parámetros o entidades como ciudades, personajes etc.

La labor donde interviene la inteligencia artificial en ese tipo de chatbot es, en primer lugar, en la conversión voz-texto (en caso de que interactuemos de viva voz) y, sobre todo, en la detección de la intención y la extracción e entidades a partir de la expresión del usuario. Este último problema, la detección de la intención, se trataría claramente de un problema de clasificación.

A partir de ahí, el resto de cosas (consulta o interacción con servicios o sistemas externos) e incluso emisión de la respuesta, sucede sin usar la inteligencia artificial y procede de configuraciones o desarrollos realizados por el desarrollador del chatbot. Sólo se añade inteligencia artificial en la eventual conversión texto-voz para contestar al usuario de viva voz.

Este tipo de chatbots hoy en día tienden a denominarse como 'basados en reglas' porque, en efecto, es el desarrollador el que establece, para una intención dada, qué sistemas o servicios deben consultarse o invocarse y qué respuesta corresponde a esa intención.

Comportamiento emocional de robots basado en reglas

Aunque confieso que me falta información técnica de detalle, y aunque puede variar de modelo de robot a modelo de robot, intuyo que los robots sociales que manejan emociones funcionan de una manera parecida a como lo hacen estos chabots.

Es decir, a partir de la información de los sensores (pensemos por ejemplo la cámara), detectan la emoción subyacente en el humano mediante la aplicación de un algoritmo de clasificación. A partir de ahí, se desencadena la respuesta del robot: qué información debe consultar, qué emoción debe expresar el propio robot (en caso de que tenga capacidad para ello) y qué debe contestar al humano.

Y sospecho que todo lo que tiene que ver con los pasos posteriores a la detección de la emoción, está fundamentalmente basado en algún tipo de reglas no muy diferentes a las que emplean los chatbots.

Chatbots basados en modelos generativos

Volvamos a los chatbots, pero para ver cómo cambia la cosa con los modelos generativos.

Cuando usamos un chatbt basado en un modelo generativo, un modelo fundacional o un gran modelo de lenguaje, la cosa funciona de manera muy diferente: no existe un distinción tan nítida entre la entrada y saluda, y no se clasifican los deseos del usuario en intenciones, sino que se trata su entrada (su 'prompt') en su conjunto, sin clasificar y, sobre todo, el propio modelo genera la respuesta, que no se basa en ningún tipo de regla aunque sí se puede realizar un cierto condicionamiento.

Las dos cosas más relevantes que cambian son, pues, que es que el modelo, la inteligencia artificial, funciona extremo a  extremo, en entrada, salida y procesamiento. Y, además, que no existe clasificación en intenciones.

Computación afectiva basada en modelos generativos. Los modelos emocionales

Visto lo anterior, y dada la posibilidad cierta (de hecho, seguro que ya se está haciendo) de que los nuevos robots se apoyen en sus aspectos verbales en modelos de lenguaje generativos, parece más que probable (aunque no tengo noticias de ello, apostaría a que ya alguna empresa o laboratorio está en ello) que en los aspectos de la computación afectiva se utilicen también este tipo de modelos.

Si eso fuese así, parece que perderían sentido la clasificación de emociones en categorías cerradas (igual que en los chatbots pierde sentido categorizar las intenciones) y, no sólo eso, lo más importante es que la respuesta del robot, incluyendo sus aspectos emocionales, se crearían por el propio modelo (no por unas reglas).

Aunque entiendo que esos es técnicamente viable desde ya mismo, calculo que se debe realizar un entrenamiento, (un más que probable 'fine-tunning') para conseguir un buen funcionamiento de estos 'modelos emocionales'.

Como digo, no puedo afirmar taxativamente que esto que indico este sucediendo, pero tengo una casi completa seguridad de que sí, y de que, probablemente,  veremos cosas en este sentido a no mucho tardar, quizá ligado al campo emergente de la así llamada 'embodied AI'.

Conclusiones

La llegada de los modelos generativos y su eventual inclusión en robots sociales, puede cambiar el paradigma de cómo se gestionan las emociones humanas en los robots, pasando de un modelo más basado en reglas, a un modelo extremo a extremo, sin clasificación de emociones y apoyado en lo que podríamos denominar un 'gran modelo emocional'.

La hibridación de los robots software: agentes frente a RPA y robots conversacionales

En el post anterior de este blog, hablaba del nacimiento de una nueva especie robótica, un nuevo tipo de robots software: los agentes de la Agentic AI. 

Le pongo el apellido 'de Agentic AI' a la espera de que la industria genere algún nuevo nombre, porque el término agente, como expliqué en ese último post, es demasiado genérico y denomina a muchos entes ya existentes incluyendo a las propias personas.

En este artículo pretendo mostrar cómo, desde un punto de vista funcional, no tanto tecnológico, estos agentes, al menos lo que de ellos se nos ha mostrado hasta la fecha, son una suerte de hibridación y evolución de las dos especies de robótica software anteriores: los robots RPA y los robots conversacionales.

Esas dos especies robóticas, robots RPA y robots conversacionales o chatbots, son las que yo identificaba y explicaba en mi libro 'Robots en la sombra'.

Antes de hablar los agentes, pues, recordemos brevemente las ideas principales sobre robots RPA y robots conversacionales.

Los robots RPA

Esquematizo la idea de RPA en la siguiente figura

Robots RPA

Los robots RPA ('Robotic Process Automation') son un tipo de módulos software orientados a interaccionar con recursos IT ya existentes, tanto en la propia empresa como en Internet. Entre esos recursos se encuentran las aplicaciones (a las que acceden ya sea vía conectores o interactuando directamente con su interfaz de usuarios) los documentos recogidos en todo tipo de ficheros, y otros recursos y protocolos con que se interactúa fundamentalmente usando APIs y conectores.

En ese sentido, los robots RPA suelen automatizar orquestando recursos digitales ya existentes, coordinando lecturas, escrituras y solicitud de acciones. 

La lógica de estos robots se basa en reglas, o mejor, en flujos o workflows que define el desarrollador... en tiempo de desarrollo.

Los robots conversacionales

Por su parte, los robots conversacionales, fundamentalmente los chatbots y voicebots tradicionales se ajustan a la siguiente figura:

Robots conversacionales tradicionales

Para los robots conversacionales, su entorno natural son las personas, ya que están diseñados, precisamente, para una interacción natural con ellas mediante conversaciones. En ese sentido, suelen actuar como front-end de una aplicación o de un conjunto de ellas de las que obtienen información o a las que solicitan acciones. Por eso, aunque su entorno principal son las personas, interaccionan también, un poco en back-office, con aplicaciones y recursos haciendo uso, al igual que los robots RPA, de conectores y APIs.

Presentan en su entrada capacidades de procesamiento de voz y lenguaje natural que son entrenadas, en realidad ajustadas, en tiempo de desarrollo, para reconocer intenciones y entidades en lo que el usuario transmite. A partir de ahí, las respuestas y la interacción con el back-office se define con base en reglas claras y en tiempo de desarrollo. 

El planteamiento de los chatbots y su construcción cambia con la llegada de los chatbots basados en modelos generativos, pero prefiero dejar como está la descripción de los robots conversacionales, en parte por claridad de discurso, pero en parte también porque podría no ser descabellado considerar un chatbot basado en modelo generativo como una forma muy simple, quizá un poco degradada, de agente.

¿Y qué son los agentes?

Y llegamos a los agentes.

Los agentes (los de la Agentic AI, me refiero) son módulos software cuyo 'cerebro', por decirlo de alguna manera, es un modelo generativo (podríamos decir que un gran modelo de lenguaje, pero creo que el nombre empieza a resultar inadecuado dada su misión y su probable evolución tecnológica). 

Siguen siendo módulos software autónomos (como los anteriores), y por tanto robots software, en mi opinión. La gran diferencia, la grandísima diferencia, es que ellos mismos deciden la lógica de actuación y lo hacen en tiempo de ejecución, no en tiempo de desarrollo.

Los agentes reciben una solicitud o indicación mediante un prompt que les fija un objetivo y, a partir de ahí, deducen ellos mismos, o al menos esa es la promesa, las acciones a llevar a cabo... y las ejecutan, hasta conseguir los resultados deseados.

Aunque todavía son una idea naciente y que debe evolucionar, concretarse y consolidarse, podemos hacernos una idea de 'por dónde van los tiros', viendo este vídeo reciente de OpenAI mostrando su 'Operator'.

Vemos que el usuario hace una petición de viva voz al agente (y por tanto genera un prompt) lo que quiere y, a partir de ahí, el agente decide lo que tiene que hacer y, en ese lo que tiene que hacer se incluye interaccionar con sitios web a través de sus pantallas. Es decir, el agente interacciona con una persona pero, además, interacciona con aplicaciones.

Yendo ligeramente más allá de lo que se ve en esta demostración, pero reflejando algunas cosas que ya se hacen en frameworks como LangChain y alguna evolución casi evidente y que creo que inminente, el esquema de un agente de la Agentic AI como el que se ve en el vídeo podría ser el ue se muestra en la figura:

Agente

Respecto a lo que se ve en el vídeo, esta figura añade la posibilidad de interactuar con ficheros y la invocación a conectores y APIs, pero no tengo ninguna duda de que, si eso no está disponible ya, lo estará prontísimo, tanto por su utilidad como porque tecnológicamente no supone un desafío ni dificultad adicionales.

Agentic AI como hibridación y evolución de RPA y robots conversacionales

La figura anterior en que esquematizo la idea de un agente, se parece mucho a la que utilizo para RPA o para robots conversacionales. Y eso no es casual. Es intencionado para mostrar los paralelismos que, para mí, son evidentes.

De hecho, para cualquiera que sea conocedor de RPA, lo que muestra la demostración de Operator recuerda muchísimo a RPA, casi lo podríamos considerar RPA: ese interactuar con pantallas de aplicaciones para obtener datos y pedir acciones es lo que supuso el nacimiento de RPA como tipología de solución diferenciada, y lo que todavía hoy en día más la caracteriza, aunque no necesariamente sea como más su utiliza.  Si a eso le añadimos el trabajo con ficheros y el uso de conectores y APIs, tendríamos lo mismo que RPA

Y, es evidente, que estos agentes pueden, si así se desea (aunque es muy probable que en muchas realizaciones prácticas no se utilice) interactuar con usuarios, con personas, mediante texto o de viva voz...de la misma manera que que hacen los robots conversacionales y como se muestra en el video.

Es por ello que considero que los agentes de la Agentic AI no es sólo que sean robots software es que reúnen y fusionan las capacidades de RPA y de los robots conversacionales, las dos 'especies' anteriores, como se ve en la figura que ya auna las tres figuras de cada una de las especies de robot software.

Las tres especies de robot software

La diferencia, la gran diferencia, tanto para lo bueno como para lo malo, frente al caso del RPA que hemos tenido hasta ahora, y a los robots conversacionales que han dominado el panorama hasta la aparición de los chatbots generativos, está en el 'cerebro' y en la lógica de actuación de los agentes.

En el caso de los robots RPA hablamos de flujos o workflows definidos por un desarrollador. Aunque es cierto que hoy en día se pueden enriquecer con elementos de inteligencia artificial y de decisión en tiempo de ejecución, en esencia se basan en reglas y flujos conocidos y establecidos en tiempo de desarrollo.

En el caso de los robots conversacionales tradicionales, aunque interviene un poco de inteligencia artificial en la entrada, a partir de ahí trabajamos con reglas y lógicas definidas por el desarrollador y también en tiempo de desarrollo.

Sin embargo, los agentes, que se basan en modelos generativos, no sólo es que generen una respuesta textual o de voz no predefinida sino que, muchísimo más importante, define el plan de acción de manera autónoma y en tiempo de ejecución. Por decirlo de alguna forma, son muchísimo más inteligentes y mucho más autónomos. Al menos esa es la promesa.

El arma de doble filo

Si los agentes 'cumplen su promesa', si están a la altura no de lo que ya se puede hacer con LangChain hoy en día sino que realmente son capaces de crear planes de actuación de manera autónoma como se muestra en el vídeo y en lo que se está publicando, las posibilidades son inmensas, casi revolucionarias.

Sin embargo, hablo de un arma de doble filo porque, en según qué entornos, por ejemplo la automatización industrial o procesos uniformes y masivos, podemos preferir las reglas claras, conocidas y predecibles de los robots y sistemas tradicionales, antes que unos planes que podrían hacer cosas extrañas (la versión de 'alucinación' llevada a un plan de acción), inesperadas o poco eficientes

Habrá que, por un lado, ver lo que los agentes sean capaces de ofrecer realmente, y por otro aplicar el sentido común.

Conclusiones

Creo haber mostrado, no sólo que los agentes de la Agentic AI son un tipo de robot software sino que, además, al menos en lo que se está prometiendo, aúnan las capacidades tanto de RPA como de robots conversacionales, pero de una forma mucho más inteligente y autónoma y, eso sí, algo más impredecible.

Va a ser interesantísimo ver a dónde se llega realmente en las próximas semanas y meses.

Una nueva especie robótica: los agentes

El título puede parecer, la verdad, algo grandilocuente, pero tras algunas semanas pensando en ello, y tras haberlo adelantado en alguna charla y clase, creo poder afirmar que estamos atendiendo al nacimiento de una nueva especie robótica, entendiendo como tal a un nuevo tipo de entidades a las que se le puede aplicar el calificativo de 'robot'.

Me refiero a la AgenticAI y, claro, a los módulos que la tangibilizan: los así denominados  agentes.

Y digo que ha nacido una nueva especie robótica pero, además, y según consultoras como Gartner, y según el típico 'hype' tecnológico, ha nacido también una estrella, aunque este último extremo, el estrellato, los logros reales que puedan alcanzar estos agentes, las capacidades reales que puedan lograr, y su impacto real en el mercado y la sociedad aún está por demostrar... una demostración o refutación que creo que veremos este mismo año, y, caso de tratarse de un éxito, seguramente en el primer semestre.

Pero antes de comentar algo más, vamos a ver de qué hablamos cuando hablamos de robot.

Recordando lo que es un robot

Como diría 'el otro', el concepto de robot es un concepto discutido y discutible. No hay una definición abarcadora, y a la vez, aceptada, de lo que es un robot. Y hemos aplicado históricamente el nombre de robot a entidades artificiales bastante diferenciadas.

Comenté los conceptos de robot en uno de los primeros vídeos de mi proyecto 'The robot notes'. En concreto, en el siguiente vídeo expongo algunas de las concepciones y definiciones existentes.

Y seleccionando la concepción que mejor explica la esencia de un robot, hablaba tanto en el vídeo como en mi libro 'Robots en la sombra' de los agentes inteligentes, una idea que se ilustra en la siguiente figura extraída de mi libro.

Un agente, un robot si llega el caso, sería una entidad que se comunica con el exterior, con el entorno obteniendo información del mismo mediante alguna forma de sensores para, a continuación, y con base en sus objetivos, seleccionar las acciones más convenientes y trasladarlas a ese entorno mediante actuadores.

Es muy importante esa relación con el entorno, incluyendo esa capacidad de actuar sobre el mismo mediante actuadores que es lo que le confiere esa naturaleza de agente, puesto que agente significa aquello que hace, que actúa. La inteligencia, que no necesariamente implica sofisticación ni el uso de inteligencia artificial, supone la coherencia entre la situación del entorno, según se percibe por los sensores, con las acciones efectuadas conforme a los objetivos del agente.

Para que un agente sea un robot, aparte de la caracterización propia como agente, se precisa, evidentemente, que se trate de una entidad artificial (un ser humano es también un agente, pero no un robot).

El debate sobre si el software puede ser un robot

Para muchos autores e instituciones, además, el robot debe tratarse de un ente con realidad física, con cuerpo y, de hecho, esa corporeidad, ese 'embodyment', tiene serias implicaciones, incluidas las éticas, en sus resultados y condicionantes. 

Sin embargo, dentro del término 'robot' se mencionan con frecuencia agentes que son esencialmente lógicos o, por entendernos, software.

En mi libro 'Robots en la sombra', que habla de robots software, explico que, por un lado, los robots que denominados software, realmente si que tienen un 'cuerpo', lo que ocurre es que, en lugar de tratarse de un cuerpo físico especializado, se trata de un hardware de propósito general, típicamente un ordenador o un smartphone y que, además, el entorno con el que interactúan es especial puesto que, con frecuencia, es un entorno digital, no físico.

Intentando identificar las características de los robots en general, incluyendo los que denominamos robots software, llegaba a una propuesta de seis características, a saber:

• Artificiales
• Adaptables
• Actuadores sobre su entorno
• Autónomos
• Sustitutivos de personas
• Similares a personas

Algunas de estas características, como la de la artificialidad, parecen indiscutibles. Más laxas y discutibles son, sin embargo, las que hacen mención al papel sustitutivo de personas o su similitud pero que son muy relevantes en el caso de los robots software. Y también hay que reconocer que se aplica muy comúnmente y sin casi discusión término robot a entes que, por su falta de autonomía, e incluso de inteligencia, cabría excluir de la idea de robot, como son los así llamados robots quirúrgicos.

El tema da para mucho debate, pero lo voy a dejar ahí.

Sólo decir, antes de conocer a la nueva especie robótica, que en mi libro hablaba de dos familias o especies de robots software: los robots RPA ('Robotic Process Automation') por un lado, y los robots conversacionales, o chatbots para simplificar, por otro.

Los agentes de la AgenticAI como robots

Bueno, pues creo que ahora hay que unir una tercera especie o familia: los agentes de la denominada 'AgenticAI'. El propio nombre ya nos avisa: estamos hablando de agentes.

En efecto, se trata de unos módulos software, regidos, en este caso, por un 'cerebro' basado en modelos generativos de inteligencia artificial. Se trata de unos módulos que también perciben un entorno (aunque un entorno especial) y que generan acciones sobre él. Y se trata de unos módulos en que las actuaciones son coherentes con el estado del entorno y los objetivos del módulo. El término agente, pues, es absolutamente apropiado para estos módulos,  aunque quizá resulte desafortunado que se apropien de es término que es muy anterior a la existencia de estos nuevos robots, y que es aplicable a otras muchas entidades. En cualquier caso, sí que son agentes y agentes inteligentes.

Y cumplen las seis condiciones que en mi libro 'Robots en la sombra', atribuía a los robots en general, y a los robots software en particular: son artificiales, adaptables, actuadores sobre su entorno, autónomos, sustitutivos de personas y, en cierto sentido, similares en su comportamiento a ellas. Son, por tanto, robots, robots software.

En algún próximo artículo, intentaré explicar que, no sólo es que se trate de robots software, es que, además, y según se ve en sus primeras realizaciones, tienen importantes solapes con las dos anteriores especies robóticas software que había identificado: los robots RPA y los robots conversacionales, convirtiéndose en una suerte de evolución, e incluso convergencia, de sus 'antepasados' robóticos.

Conclusiones

A despecho del debate existente, y justificado en realidad, acerca de lo que realmente significa el término 'robot' y del otro debate, también existente y también justificado, acerca de si un robot software es realmente un robot, creo que, si sigo mi propia doctrina respecto a lo que es un robot, estamos asistiendo al nacimiento de una nueva especie robótica: los agentes de la AgenticAI.

Una especie 'joven' y que habrá que ir viendo cómo se desarrolla. 

Todo apunta a que tendremos muchos noticias al respecto en las próximos meses e incluso semanas.