Agentes de IA vs RPA

Lo que un bot realmente hace

Comienza con la arquitectura, porque la comparación de agentes de IA versus RPA se resuelve por ella. UiPath, el mayor proveedor de RPA, describe a sus robots de software como "imitando acciones humanas al interactuar con pantallas y sistemas" para manejar "tareas repetitivas y basadas en reglas como ingresar datos, mover archivos o procesar transacciones". Los flujos de escritorio de Microsoft, su producto de RPA dentro de Power Automate, dicen lo mismo en términos mecánicos: puedes "interactuar con la máquina utilizando elementos de la interfaz de usuario de la aplicación, imágenes o coordenadas", contra "aplicaciones heredadas, como emuladores de terminal, aplicaciones web y de escritorio modernas, archivos de Excel y carpetas". Un bot puede ejecutarse atendido, junto a una persona en el escritorio, o desatendido, en una máquina propia.

Toma una tarea concreta: registrar un recibo de mercancías en un sistema de inventario antiguo que no tiene API. El bot abre la aplicación, navega por el menú hasta el formulario de recibos, busca la orden de compra, tabula en el campo de cantidad para cada línea, escribe el número y presiona la tecla Guardar. Una persona grabó esos pasos una vez; el bot los reproduce miles de veces, más rápido y sin transponer dígitos. Para una aplicación estable con alto volumen y sin otra forma de acceso, ese es un buen intercambio, y se ha pagado por sí mismo en muchos equipos de finanzas y operaciones.

Los proveedores dicen dónde encaja, y tienen razón. La propia definición de UiPath es "tareas de alto volumen, repetitivas y basadas en reglas, especialmente aquellas que abarcan múltiples sistemas": volumen, determinismo y alcance en sistemas que no ofrecen nada más. Una comparación honesta mantiene esos elementos sobre la mesa.

Por qué se rompe, y por qué eso no es un defecto

Una pantalla es un contrato con una persona. Su diseño, etiquetas, orden de pestañas y la posición del botón Guardar son promesas hechas a los ojos y a un puntero, y ninguna de ellas está prometida a una máquina. Cuando el proveedor mueve el campo de cantidad a una nueva pestaña, agrega un pop-up de confirmación o renombra un menú, la persona se adapta en segundos sin darse cuenta. El bot falla, o peor, escribe la cantidad en el campo incorrecto y guarda. Ese fallo no dice nada sobre la competencia del proveedor de RPA; la interfaz que se le dio al bot está mostrando sus limitaciones.

La misma limitación sigue a un modelo de lenguaje cuando se le hace manejar pantallas. El uso de computadora de Anthropic le da a Claude "control de captura de pantalla, mouse y teclado de un entorno de escritorio", y es genuinamente útil donde no existe nada más. Pero la propia documentación de Anthropic te aleja de ello siempre que haya una interfaz más ajustada disponible, recomendando su herramienta de navegador para trabajos que se mantienen dentro de una página web, y pide "a un humano que confirme decisiones que podrían resultar en consecuencias significativas en el mundo real", nombrando transacciones financieras entre ellas. Un modelo que maneja una pantalla hereda la fragilidad de la pantalla y añade su propia variabilidad encima. Esa es la combinación menos atractiva de las dos categorías, y es a lo que muchas presentaciones de "RPA impulsada por IA" equivalen.

Lo que un agente llama en su lugar

Un agente que opera un sistema de negocios construido para agentes nunca ve una pantalla. Pregunta al sistema qué puede hacer y recibe una lista de herramientas, cada una con un nombre, una descripción escrita para el modelo, un esquema para sus entradas y anotaciones opcionales que indican si solo lee, si puede destruir datos y si llamarlo dos veces es seguro. El Protocolo de Contexto del Modelo estandariza este intercambio: el cliente envía una solicitud para listar herramientas, el modelo elige una, el cliente la llama con argumentos escritos, y el servidor la ejecuta y devuelve un resultado. La especificación requiere que los servidores "validen todas las entradas de herramientas" y "implementen controles de acceso adecuados", y le dice a los clientes que "registren el uso de herramientas para fines de auditoría". Aquí está la forma de una de estas herramientas, utilizando el recibo de mercancías de antes.

{
  "name": "receiveStock",
  "description": "Book goods received against a purchase order into a warehouse location. Fails if the order is closed or the caller cannot receive at that location.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_ref": { "type": "string", "description": "Purchase order reference" },
      "location_id": { "type": "string", "description": "Warehouse location to receive into" },
      "lines": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "sku": { "type": "string" },
            "quantity": { "type": "integer", "minimum": 1 }
          },
          "required": ["sku", "quantity"]
        }
      }
    },
    "required": ["order_ref", "lines"]
  },
  "annotations": { "readOnlyHint": false, "destructiveHint": false, "idempotentHint": false }
}

Una definición de herramienta MCP en la forma que describe la especificación, para el mismo recibo de mercancías en el que el bot estaba escribiendo en un formulario. Los nombres de los campos son ilustrativos; el punto es que una herramienta es un contrato, y un contrato puede ser versionado, validado y autorizado de maneras que una pantalla no puede.

Compara lo que sucede con un cambio. El proveedor rediseña la pantalla de recibos: el bot falla, la herramienta permanece intacta. El proveedor agrega un campo requerido a la herramienta: ese es un cambio versionado a un contrato publicado, anunciado en la lista de herramientas, y el agente lee el nuevo esquema en su próxima llamada. Compara la identidad. El bot inicia sesión como una cuenta de servicio con el acceso que alguien le dio hace años. El agente llama a la herramienta como la persona que representa, y la verificación de permisos se ejecuta dentro de la herramienta, en cada llamada, contra el rol de esa persona.

Determinista versus probabilístico: el intercambio que nadie debería ocultar

Hay un costo del lado del agente, y los proveedores de RPA lo indican con precisión en su propia documentación para agentes: los robots "siguen lógica estructurada y reglas fijas", mientras que los agentes toman "un enfoque probabilístico para tomar decisiones basadas en patrones y datos en tiempo real". Un bot que reproduce los mismos pasos da el mismo resultado para la misma entrada, y se puede demostrar. Un agente que tiene la misma intención toma un camino defendible, generalmente el mismo, no siempre. Para un paso regulado donde se debe demostrar la repetibilidad, o para un millón de transacciones idénticas al mes, la opción determinista es la mejor elección, y decir lo contrario sería engañar.

La ventaja del agente se limita a la variación. Cuando el recibo no coincide con el pedido, cuando el proveedor ha enviado dos entregas contra una línea, cuando la cantidad es plausible pero la unidad es incorrecta, el bot no tiene una rama para ello y se detiene, o hace lo incorrecto con confianza. El agente lee la discrepancia, verifica el pedido, reserva lo que coincide y pregunta a una persona sobre el resto. Ese es el trabajo que solía ser una cola de excepciones en el escritorio de alguien, y es el trabajo para el que está diseñado un agente.

Recurrir a RPA cuando, recurrir a un agente cuando

Usando ambos, y lo que el sistema subyacente decide

El patrón que los proveedores describen ahora, y el que funciona en la práctica, es que el agente decide y el bot ejecuta en sistemas que no tienen nada más. UiPath lo expresa como robots desempeñando "un papel complementario en la pila de ejecución" junto a los agentes. En ese arreglo, el bot es una de las herramientas del agente: una acción envuelta y determinista contra una pantalla heredada, con el agente responsable de elegir cuándo llamarlo y de manejar lo que el bot devuelve. Con el tiempo, los bots se retiran uno a uno a medida que los sistemas detrás de ellos obtienen herramientas propias, y nada en el lado del agente tiene que cambiar cuando eso sucede.

Lo que lleva la decisión de vuelta al sistema empresarial. Sois está construido de tal manera que el bot nunca es necesario contra él: un espacio de trabajo es un servidor MCP, cada acción que una persona puede realizar se expone como una herramienta nombrada, y el agente que ya usas, Claude, ChatGPT o cualquier cliente MCP, se conecta añadiendo la dirección del espacio de trabajo e iniciando sesión una vez. Las herramientas se filtran según el rol de la persona antes de que el agente las vea y se verifican nuevamente cuando se ejecutan, por lo que el acceso falla cerrado; el gasto está limitado por integración; cada llamada se registra con sus entradas y su resultado. Donde aún ejecutas un sistema heredado junto a él, el bot permanece en ese sistema y el agente lo trata como una herramienta más.

Si tu sistema central solo tiene pantallas, RPA es el puente y no hay vergüenza en ello. La decisión que importa es si el próximo sistema que compres necesitará uno.

Preguntas que la gente hace

Este artículo se revisa cuando cambian los productos que describe. Próxima revisión programada: 4 de diciembre de 2026.