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.

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

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

 

Inteligentes pero imprevisibles

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

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

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

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

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

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

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

Difíciles de probar, difíciles de monitorizar

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

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

Cuatro patrones para la monitorización de agentes

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

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


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


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


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

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

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

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

Conclusiones

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

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

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'.