Automatización robótica de procesos (RPA), flujos de trabajo y agentes de IA: qué significa cada término

Tres palabras que en las ofertas se usan como tres niveles de precio de un mismo servicio son tres mecanismos distintos. En qué se diferencia cada uno, qué recibe quien compra y por qué la diferencia ahora es también jurídica.

Tres palabras suelen aparecer en una misma oferta como si fueran tres niveles de precio de un mismo servicio: la automatización robótica de procesos, la automatización de flujos de trabajo y los agentes de IA. Quien compra tiene la impresión de que hay que elegir uno de tres productos, y de ordinario se elige el más caro, porque suena más moderno.

En realidad son tres mecanismos distintos, que resuelven problemas distintos, y la mayor parte de las tareas reales pide precisamente el que menos cuesta. Este artículo no compara herramientas ni recomienda una plataforma; explica en qué se diferencia técnicamente cada mecanismo, qué recibe quien compra en cada caso y por qué precisamente esta diferencia se ha convertido también, en los últimos dos años, en una cuestión jurídica.

Tres mecanismos que responden a tres preguntas distintas

La forma más sencilla de mantenerlos separados es preguntar cómo sabe cada uno lo que tiene que hacer. La automatización robótica de procesos repite las acciones que una persona le mostró; la automatización de flujos de trabajo sigue un camino que alguien dibujó; el agente de IA infiere el camino por sí mismo a partir de un objetivo que se le encargó. De esa sola diferencia se sigue casi todo lo demás, incluido el precio, la fragilidad y lo que ocurre cuando la situación es inesperada. El mecanismo que repite, en una situación inesperada, se para; el que sigue un camino dibujado se va por la rama de error, si está prevista; el que infiere inventa algo nuevo, y precisamente por eso necesita una supervisión que los otros dos no necesitan.

Vale la pena probarlo sobre una tarea concreta, que en casi todas las empresas se ve igual: ha llegado una factura por el correo y hay que meterla en el sistema de contabilidad. La automatización robótica de procesos resolvería este trabajo abriendo el programa de correo, descargando el adjunto, abriendo la ventana de contabilidad y rellenando los campos exactamente en el mismo orden en que lo haría un empleado. Un flujo de trabajo lo resolvería recibiendo el documento por una interfaz y llamando a la interfaz del sistema de contabilidad con los campos ya listos, sin abrir ninguna ventana. Un agente de IA lo resolvería recibiendo el encargo «contabilice esta factura» y decidiendo por sí mismo qué herramientas llamar y qué hacer si falta algo.

Las tres variantes pueden cumplir esta tarea, y precisamente eso engaña. La diferencia no aparece cuando todo va bien, sino cuando el proveedor cambia la plantilla de la factura, cuando en el sistema aparece un campo obligatorio nuevo o cuando un mismo producto se llama de dos maneras, y precisamente estos casos forman la mayor parte del trabajo real.

La automatización robótica de procesos (RPA) repite acciones en pantalla

La automatización robótica de procesos, llamada en el día a día con la abreviatura inglesa RPA, es un robot de software que trabaja exactamente en las mismas interfaces en las que trabaja una persona: abre una ventana, hace clic, copia un campo, pulsa guardar. Los sistemas con los que trabaja quedan del todo inalterados, y precisamente eso es tanto su principal ventaja como su principal debilidad. La ventaja es que el RPA se apaña con programas que no tienen ninguna interfaz de intercambio de datos y que nadie va a reconstruir ya, así que a menudo es el único camino hacia sistemas viejos de contabilidad o de sector. La debilidad es que el robot ve la pantalla, no los datos, así que cualquier cambio en la pantalla —un botón desplazado, un campo nuevo, otra versión de la actualización— detiene el trabajo, y el mantenimiento se convierte en un coste permanente, no en uno de una sola vez.

Quien compra recibe aquí la licencia del robot, su entorno de ejecución y la herramienta de gestión, la descripción del proceso y un registro de las acciones realizadas. Conviene saber que en el propio sector este nombre se considera desafortunado: lo que el RPA automatiza suele ser una tarea suelta, no un proceso entero, y precisamente este desajuste entre el nombre y el contenido genera parte de las expectativas de quien compra que después no se cumplen.

Otra señal que en los proyectos de RPA suele sorprender es que el robot trabaja con el mismo nivel de acceso que la persona cuyas acciones repite. Eso significa que el robot necesita su propio usuario en cada sistema, que los derechos de ese usuario hay que pensarlos igual que los de cualquier otro, y que las acciones del robot en el registro del sistema parecen acciones de una persona, salvo que tenga una cuenta aparte. En las empresas en las que no se ha pensado en ello, más adelante es difícil responder a una pregunta sencilla sobre quién hizo el asiento concreto.

La automatización de flujos de trabajo une sistemas, no pantallas

La automatización de flujos de trabajo trabaja un nivel más abajo: no habla con la pantalla, sino con los propios sistemas, a través de sus interfaces de programación. Un flujo de trabajo es un grafo de pasos dibujado de antemano: un evento dispara una cadena, la cadena llama a acciones en otros sistemas, y entre ellas puede haber también un paso en el que una persona confirma algo. Como el intercambio de datos ocurre por la interfaz, no por la imagen, los cambios en el aspecto del sistema no afectan a este mecanismo, y esa es la razón principal por la que, allí donde la interfaz está disponible, es casi siempre una elección más resistente y más barata de mantener que repetir la pantalla. El inconveniente es obvio: si el sistema no tiene interfaz o esta no está disponible en su nivel de licencia, este camino sencillamente no existe.

Quien compra recibe aquí el propio flujo de trabajo, las credenciales de acceso, el registro de ejecución y la rama de errores, y precisamente esto último es aquello por lo que merece la pena valorar la oferta, porque un flujo de trabajo sin tratamiento de errores funciona solo mientras todo va bien. En español este mecanismo tiene su propio nombre: flujo de trabajo es el término asentado, así que no hace falta poner entre paréntesis la palabra inglesa.

Una palabra que aquí sirve y que conviene usar con precisión es robot de software: es un programa que imita las acciones de una persona en una interfaz, y no es ningún robot físico. Esta diferencia importa, porque la palabra «robot» en el día a día significa un aparato, y precisamente de este malentendido vienen parte de las preguntas sobre lo que el robot «ve» y lo que «entiende». No entiende nada: repite lo que se le mostró.

El agente de IA infiere el camino por sí mismo

El agente de IA se diferencia de los dos anteriores en que no se le encarga el camino, sino el objetivo, y el camino lo elige él mismo, llamando a las herramientas que tiene a su disposición: una búsqueda, una base de datos, la interfaz de un sistema, otro modelo. Precisamente actuar con herramientas es la señal que distingue al agente de IA de un chatbot: el chatbot responde, el agente de IA hace. De ahí se sigue que el agente de IA se apaña con tareas en las que la secuencia de pasos no se conoce de antemano, y al mismo tiempo es el único de los tres mecanismos cuyo resultado no es del todo previsible. Dos ejecuciones idénticas pueden elegir caminos distintos, y eso significa que hace falta tanto supervisión como límites claramente fijados de lo que puede hacer por sí mismo y dónde debe pararse y preguntar a una persona.

En el trabajo práctico eso suele significar que el agente de IA es el mecanismo correcto allí donde los datos de entrada son no estructurados y diversos, y el incorrecto allí donde la tarea está fijada con rigor y se repite cientos de veces al día. En el segundo caso el flujo de trabajo es a la vez más barato y más seguro, y usar ahí un agente de IA es gastar dinero en una imprevisibilidad que nadie necesitaba.

En el caso del agente de IA, quien compra recibe algo distinto que en los otros dos casos, y en las ofertas a menudo no está descrito en absoluto. Además del propio agente hacen falta las herramientas que puede llamar, los límites de lo que puede hacer sin confirmación, un registro de lo que hizo en cada ejecución, y un modo de detenerlo. Una oferta en la que solo hay un modelo y un prompt describe una demostración, no una herramienta de trabajo.

Hay también una diferencia de coste que en los planes de proyecto suele faltar. La ejecución de un flujo de trabajo casi no cuesta nada, porque son un par de llamadas, y el coste del RPA es sobre todo la licencia y el mantenimiento. Cada ejecución de un agente de IA, en cambio, se paga por el uso del modelo, y este coste crece con el volumen, así que el mecanismo que en la prueba parecía barato, en cientos de ejecuciones al día puede resultar el más caro de los tres.

Dónde termina la automatización y empieza la inteligencia artificial

Esta frontera se ha convertido en los últimos años en una cuestión jurídica, porque el Reglamento de inteligencia artificial de la Unión Europea vincula sus obligaciones precisamente a la definición de sistema de IA. El artículo 3, apartado 1, del Reglamento lo describe como un sistema que infiere de la información de entrada que recibe la manera de generar un resultado de salida: una predicción, un contenido, una recomendación o una decisión. Tan importante es lo que queda fuera. El preámbulo del Reglamento dice expresamente que no deben incluirse los sistemas basados en las normas definidas únicamente por personas físicas para ejecutar automáticamente operaciones, y las directrices de la Comisión lo repiten todavía con más concreción, al nombrar la inferencia como la característica imprescindible y la ejecución de instrucciones predeterminadas como algo que no entra en la definición.

La misma frontera, en términos prácticos: un sistema que solo ejecuta pasos predeterminados, sin aprendizaje y sin predicción —ya sea un robot de RPA o un motor de reglas de negocio— no es un sistema de IA. El valor práctico es directo: un robot de RPA que copia datos entre dos ventanas y un flujo de trabajo que llama a una interfaz siguiendo un camino dibujado no generan las obligaciones del Reglamento de inteligencia artificial. Un agente de IA que infiere sí puede generarlas, y precisamente por eso mezclar los nombres en una oferta no es solo una cuestión de estilo.

Qué recibe quien compra en cada caso

Comparar ofertas es más fácil si se mira no el nombre, sino lo que, al terminar el trabajo, se queda en la empresa. En el caso de la automatización robótica de procesos quedan la licencia, el entorno de ejecución, la herramienta de gestión, la descripción del proceso y el registro de las acciones realizadas, y de todo ello lo más importante es la descripción del proceso, porque precisamente ella dice qué hace el robot cuando algo no corresponde a lo esperado.

En el caso del flujo de trabajo quedan el propio flujo, las credenciales de acceso a cada sistema conectado, el registro de ejecución y la rama de errores, y aquí conviene prestar atención a quién pertenecen las credenciales y dónde se ejecuta el flujo. Si se ejecuta en la cuenta del proveedor con las claves del proveedor, una interrupción de la relación significa también una interrupción del trabajo, y eso es más fácil de ordenar en el momento de firmar el contrato que más adelante.

En el caso del agente de IA, además de todo lo anterior, queda también la responsabilidad de lo que hizo, y precisamente por eso el registro no es ahí un detalle técnico, sino la esencia misma. Si no se puede decir por qué el agente de IA, en un caso concreto, actuó como actuó, tampoco se puede responder al cliente que pregunta por qué su solicitud se tramitó precisamente así.

Qué plazos ya han empezado

Como las exigencias del Reglamento entran en vigor por etapas, conviene saber qué ya está en vigor hoy y qué aún no. La obligación de informar a una persona de que interactúa con un sistema de IA se aplica desde el 2 de agosto de 2026, y atañe a un agente de IA o a un chatbot visible para los clientes en su sitio web. Si hay uno instalado, es una cuestión que hay que resolver ahora, no en el futuro.

Las exigencias de alto riesgo, que atañen a ámbitos como la selección de personal y las decisiones de empleo, empiezan a aplicarse el 2 de diciembre de 2027, y esta fecha se aplazó hace poco, así que en parte de los artículos sigue un año anterior. En cambio, las prácticas prohibidas y la propia definición de sistema ya están en vigor.

Independientemente del Reglamento de inteligencia artificial sigue en vigor también la exigencia de protección de datos sobre las decisiones que se adoptan únicamente de forma automatizada y que producen efectos jurídicos en la persona o la afectan significativamente de modo similar. Esta exigencia no depende de que el mecanismo sea un agente de IA o un simple flujo de trabajo: lo que importa es si la decisión sobre una persona la toma una máquina ella sola.

Conviene también entender por qué esta frontera se ha trazado precisamente a través de la inferencia, y no a través de la complejidad. Un programa puede ser muy complejo y seguir sin ser un sistema de IA, si cada uno de sus pasos lo ha fijado una persona, y al revés: una solución del todo pequeña, que usa un modelo para decidir qué hacer, entra en la definición. Eso significa que la respuesta a la pregunta sobre las obligaciones no la da ni el presupuesto del proyecto ni el número de líneas, sino solo el modo en que se toma la decisión sobre la siguiente acción.

En la práctica estos plazos atañen con más frecuencia a una cosa concreta que muchas empresas ya tienen: un chatbot o un asistente en el sitio web. Si es visible para el cliente y se basa en un modelo de lenguaje, la obligación de decir que el interlocutor no es una persona ya está en vigor, y en la práctica se cumple con un rótulo claro en la interfaz, no con un párrafo en la política de privacidad. Si es un simple árbol de reglas con respuestas escritas de antemano, entonces no es un sistema de IA y esta obligación no nace, pero la diferencia conviene fijarla por escrito, porque al cabo de un año ya nadie recordará cómo estaba hecho.

Por qué los nombres se mezclan en el mercado

La confusión también tiene una razón del todo objetiva, y no es solo el marketing. Las herramientas que antes hacían una cosa ahora hacen varias: las plataformas que empezaron como herramientas de flujos de trabajo ahora ofrecen también un paso de agente de IA, y las empresas que vendían automatización robótica de procesos ahora describen los mismos productos como si funcionaran por sí mismos.

Eso significa que por el nombre del producto ya no se puede determinar el mecanismo, y la única pregunta segura ante una oferta es cómo se determina el camino de las acciones en esa solución concreta: si lo escribe una persona, si se dibuja como un grafo, o si en cada ejecución lo elige un modelo. La respuesta a esta sola pregunta dice el precio, la fragilidad y si las obligaciones del Reglamento pueden siquiera nacer.

Hay también palabras con las que conviene ser precisos. La abreviatura RPA no debería aparecer sola en un texto, sin la forma completa en la primera mención. La forma que se encuentra de automatización de procesos de robótica es un error: la robótica son los robots físicos, y aquí se trata de software.

El otro sitio en el que los nombres se mezclan es el propio uso de la palabra «automatización». En español con ella se designa tanto el control de procesos industriales como la automatización del trabajo de oficina, y son dos mercados del todo distintos, con proveedores distintos. Si usted busca una oferta, conviene decir cuál de las dos se pretende, porque de lo contrario parte de las ofertas recibidas serán de un sector completamente distinto.

Tres afirmaciones que en las ofertas son incorrectas

La primera es que la automatización robótica de procesos sea inteligencia artificial. No es solo una cuestión de terminología, porque de ella se siguen obligaciones: un sistema que ejecuta pasos escritos por una persona no entra en la definición de sistema de IA, y una oferta que llama inteligencia artificial al robot o bien vende más caro de lo que hace falta, o bien crea inquietudes que no tienen fundamento. La segunda es que el agente de IA sea sencillamente un chatbot más inteligente. La diferencia no está en la inteligencia, sino en la acción: el chatbot genera una respuesta, el agente de IA llama a herramientas y cambia el estado en otros sistemas, y precisamente por eso el agente de IA necesita límites que el chatbot no necesita. La empresa que no los distingue suele dar al agente de IA un acceso en el que nadie ha pensado.

La tercera es que la elección entre estos tres sea una elección entre tres proveedores. En realidad una misma herramienta a menudo puede hacer los tres: las plataformas que empezaron como herramientas de flujos de trabajo ahora ofrecen también un paso de agente de IA, y eso significa que la pregunta no es qué comprar, sino cómo se determina el camino de las acciones en esa solución concreta.

Cómo elegir el mecanismo para un trabajo concreto

La elección en la práctica es breve, si las preguntas se hacen en el orden correcto. Averigüe primero si los sistemas implicados tienen una interfaz de programación, porque, si la hay, el flujo de trabajo será casi siempre más resistente y más barato de mantener que repetir la pantalla, y a partir de ahí la pregunta ya no es el mecanismo, sino el volumen. Si no hay interfaz y el sistema no se puede cambiar, entonces la automatización robótica de procesos es la herramienta adecuada, pero con los ojos abiertos: en el presupuesto tiene que haber mantenimiento, y en el proyecto tiene que haber un responsable que repare el robot cuando la pantalla cambie. Si los datos de entrada son no estructurados, cada caso es distinto y la secuencia de pasos no se puede escribir de antemano, solo entonces merece la pena mirar hacia un agente de IA, y también entonces hay que saber dónde se para y quién lo supervisa.

La solución práctica más frecuente es mixta: el flujo de trabajo dirige la cadena y ejecuta todos los pasos previsibles, pero en un punto concreto llama a un modelo para tratar una entrada no estructurada, y devuelve el resultado a la cadena. Eso une previsibilidad con flexibilidad precisamente allí donde hace falta, y es también la más barata de las variantes que realmente funcionan.

Hay aún una consideración práctica que suele decidir la elección más que la técnica. Cada uno de los tres mecanismos pide una persona distinta que lo mantenga: un flujo de trabajo puede mantenerlo quien entiende las interfaces de los sistemas, el robot necesita a alguien que conozca precisamente esa herramienta y las pantallas con las que trabaja, y el agente de IA necesita además a alguien que mire con regularidad lo que realmente hace. Si en la empresa no hay esa persona y no está previsto comprar el mantenimiento, entonces la elección entre mecanismos tiene que empezar por cuál de ellos se podrá mantener de verdad.

Conviene nombrar también el error que en esta elección cuesta más caro, y no es la elección del mecanismo, sino el orden. Las empresas suelen elegir primero la herramienta, después buscar qué automatizar con ella, y solo entonces entender que el proceso que se quería automatizar aún no está descrito. El orden correcto es el inverso: primero se describe el trabajo con sus excepciones, después se averigua si los sistemas tienen interfaces, y solo entonces se elige el mecanismo, porque en ese momento la elección suele ser evidente y ocupa cinco minutos. Igual de frecuente es el extremo contrario, en el que la empresa espera a que todo esté ordenado y no empieza nada. Aquí sirve recordar que un flujo de trabajo se puede construir también para un tramo pequeño y ampliarlo más adelante, y que precisamente el primer tramo terminado suele mostrar dónde está de verdad el cuello de botella, con mucha más precisión que cualquier evaluación previa.

Conviene también decir que cambiar de mecanismo más adelante no es una catástrofe, si el propio proceso está descrito. Las empresas suelen temer una elección incorrecta como si fuera irreversible, pero en la práctica el mayor valor del proyecto es precisamente la descripción del proceso con sus excepciones, y esta sigue siendo válida con independencia de que la ejecute un robot, un flujo de trabajo o un agente de IA. Cambiar quién lo ejecuta cuando la descripción ya está ordenada es mucho más barato que escribir la descripción de nuevo.

Qué preguntar al proveedor

Si la oferta ya está sobre la mesa, cuatro preguntas suelen bastar para entender qué se ofrece de verdad, con independencia de las palabras que haya en el título. La primera es quién decide el siguiente paso: un script escrito, un grafo dibujado o un modelo en el momento de la ejecución. Precisamente esta respuesta nombra el mecanismo con más precisión que cualquier nombre de producto en el título.

La segunda es qué ocurre cuando algo no corresponde a lo esperado, y aquí conviene pedir un ejemplo concreto, no una afirmación general sobre la fiabilidad. La tercera es a quién pertenecen las credenciales de acceso y dónde se ejecuta la solución, porque de ello depende si el trabajo continúa si la relación con el proveedor termina. La cuarta es cuánto cuesta el mantenimiento al año y qué se recibe exactamente por él, porque precisamente el mantenimiento es el coste que en las ofertas con más frecuencia no se indica en absoluto.

Si la respuesta a alguna de estas preguntas es poco clara, eso aún no significa que la oferta sea mala, sino que sobre esta parte aún no se ha pensado, y ponerse de acuerdo es mucho más barato antes del contrato que después de la primera parada.

Sirve también la lista contraria, es decir, las preguntas que no deciden nada, aunque se hagan a menudo. A empresas de qué tamaño ha atendido el proveedor, cuántos años lleva en el mercado y cuántos procesos ha automatizado, dicen algo de la experiencia, pero no dicen nada sobre si el mecanismo concreto encaja en la tarea concreta. Tampoco sirve de mucho la pregunta sobre qué plataforma usa el proveedor, porque una misma plataforma hoy puede funcionar en los tres mecanismos, y la respuesta a esta pregunta no le dice a usted nada sobre la fragilidad de la solución ni sobre el coste de mantenimiento.

Por último conviene pedir que el proveedor muestre un ejemplo que ya esté funcionando y cuente qué se ha roto en él desde la instalación y por qué. La respuesta a esta pregunta sobre la calidad del trabajo del proveedor dice más que cualquier lista de referencias, porque se rompe todo lo que funciona el tiempo suficiente, y lo importante es con qué rapidez se advirtió y se reparó.

Es honesto decir también nuestra posición, porque explica por qué este artículo está escrito precisamente así. No vendemos licencias de automatización robótica de procesos y no somos socios de ninguna plataforma de este tipo, así que no tenemos interés en que usted elija el mecanismo más caro.

Nuestro trabajo es la automatización de procesos de negocio con flujos de trabajo e interfaces entre los sistemas que usted ya tiene, incluida la variante mixta en la que la cadena la dirige un flujo de trabajo y el modelo se llama solo en un paso no estructurado, y aparte las soluciones de IA para empresas allí donde la tarea pide de verdad inferencia. Si usted tiene ahora una oferta en la que estas palabras están mezcladas, o sencillamente no está claro qué mecanismo encaja en su tarea, envíenos una descripción: a menudo la respuesta es que basta una conexión, y esa es la respuesta más barata que se puede recibir.