Antes de elegir entre un agente de IA y RPA, mire cada etapa del proceso y pregúntese: ¿esto requiere interpretación o solo repetición? La repetición sobre datos estructurados es trabajo de un robot de RPA o de una integración. Interpretar texto libre, excepciones y ambigüedad es donde un modelo de lenguaje se paga solo. La mayoría de los procesos reales tienen las dos cosas, y el error caro es elegir una sola herramienta para todo el proceso.
Por qué esta confusión cuesta dinero ahora
En junio de 2025, Gartner predijo que más del 40% de los proyectos de IA agéntica se cancelarán antes de finales de 2027 por costes crecientes, valor de negocio poco claro o controles de riesgo inadecuados. En el mismo anuncio describió el "agent washing": proveedores que rebautizan asistentes, chatbots y RPA como agentes sin capacidades agénticas reales. Según la estimación de Gartner, solo unos 130 de los miles de proveedores que se presentan como de IA agéntica lo son de verdad.
Los dos errores aparecen en los proyectos. Hay quien compra un "agente" y recibe un robot de RPA con una capa de chat. Y hay quien pone un agente autónomo a hacer lo que una regla de tres líneas haría mejor, más barato y sin sorpresas.
Qué es cada uno, sin marketing
RPA (automatización robótica de procesos) ejecuta un guion fijo sobre interfaces: abre el sistema, lee el campo, copia, pega, hace clic. Es determinista. La misma entrada produce siempre la misma salida, y eso es una virtud cuando el proceso es estable.
Un agente de IA, en la definición que usa Anthropic en Building effective agents, es un sistema en el que el modelo de lenguaje dirige su propio proceso y decide qué herramientas usar y en qué orden. El mismo texto distingue los agentes de los workflows: sistemas en los que el LLM se invoca en puntos definidos de un flujo escrito en código. Y hace una recomendación que mucha gente se salta: empiece por la solución más simple, porque los agentes cambian latencia y coste por rendimiento en tareas abiertas, y la autonomía trae costes mayores y riesgo de errores que se acumulan.
Esa tercera categoría, el workflow con una etapa de LLM, es la respuesta correcta con más frecuencia de lo que el mercado admite.
Dónde gana RPA y dónde se rompe
RPA gana cuando el proceso tiene reglas claras, datos estructurados, alto volumen y sistemas sin API. Conciliaciones entre dos sistemas heredados, carga repetitiva de datos en portales de la administración, descarga diaria de informes. Coste por ejecución bajo, comportamiento predecible, auditoría sencilla.
RPA se rompe cuando cambia la pantalla, cuando un documento llega con otro formato o cuando aparece el caso "casi igual". Cada excepción se convierte en una regla nueva, cada regla nueva en mantenimiento, y el robot que iba a liberar a las personas pasa a necesitar a una persona que lo cuide. Si existe una API, la integración directa suele ser más estable que RPA sobre la interfaz.
Dónde gana un agente y dónde se rompe
El agente gana cuando la entrada es texto libre o documentos variados, cuando el número de pasos no es predecible y cuando la decisión depende del contexto. Leer el correo de un proveedor y entender que está impugnando una penalización y no pidiendo un duplicado de factura. Preparar la respuesta a un ticket consultando tres sistemas distintos según el caso.
El agente se rompe de formas distintas a RPA. Puede equivocarse con seguridad, y el error no aparece como excepción en el registro. Cuesta dinero por cada llamada al modelo, con latencia variable. Y trae una superficie de ataque nueva: el OWASP Top 10 para aplicaciones con LLM incluye la "agencia excesiva" como riesgo, cuando el agente recibe más herramientas, permisos o autonomía de los que necesita la tarea, y sitúa la prompt injection en el primer puesto. Un agente que lee correos externos y tiene permiso para pagar facturas es exactamente ese escenario.
El diseño que suele funcionar: los dos, cada uno en su sitio
Los propios proveedores de RPA ya ordenan el mercado así. UiPath describe su orquestación con el lema los agentes piensan, los robots ejecutan, las personas lideran. Dejando aparte el producto, la división es útil: el modelo interpreta, el flujo determinista ejecuta y una persona decide donde el coste del error es alto.
Un ejemplo: cuentas por pagar
Un proceso de cuentas por pagar de una empresa mediana en Brasil tiene, normalmente, estas etapas:
- Recibir la factura electrónica (NF-e). El XML es estructurado y estándar. Aquí no hay nada que interpretar: una integración o RPA carga los datos en el ERP.
- Recibir boletos bancarios y facturas de servicios en PDF, cada proveedor con su propio formato. Una etapa de LLM extrae importe, vencimiento, número fiscal y código de pago, y un validador determinista comprueba el dígito de control y el número fiscal. Un workflow, no un agente.
- Cotejar con el pedido de compra. Si importe y cantidad coinciden dentro de la tolerancia, una regla fija aprueba. Sin modelo.
- Tratar las discrepancias: un importe distinto, un artículo no recibido, el correo de un proveedor que explica una subida de precio. Aquí un agente tiene sentido. Lee el historial, consulta el pedido y la recepción, y propone una acción con su justificación.
- Aprobar el pago. Por debajo de un importe que fija la empresa, y con una propuesta de alta confianza, el flujo continúa. Por encima, una persona aprueba tras leer la justificación del agente. El agente nunca tiene permiso para pagar por su cuenta.
En este diseño, el agente trabaja solo en las excepciones, que es donde está el trabajo manual caro, y se mantiene lejos del dinero.
Lo que enseña el caso Klarna
En febrero de 2024, Klarna anunció que su asistente de IA atendió 2,3 millones de conversaciones en su primer mes, dos tercios de su atención por chat, el equivalente al trabajo de 700 agentes a tiempo completo. En mayo de 2025, su consejero delegado, Sebastian Siemiatkowski, dijo a Bloomberg que el coste había pesado demasiado en la decisión y que el resultado fue una calidad menor. La empresa volvió a contratar personas para que el cliente siempre pueda hablar con alguien.
El asistente no se apagó. Lo que cambió fue la frontera: automatización para el volumen rutinario, personas para los casos en que el error sale caro. Es la misma lógica del ejemplo de cuentas por pagar.
Seis preguntas para decidir cada etapa
- ¿La entrada tiene un formato fijo (XML, una tabla, un campo de sistema) o es texto y documentos variados?
- ¿El número de pasos es predecible o depende del caso?
- ¿Existe una API? Si la hay, la integración va antes que RPA y que un agente.
- ¿Cuánto cuesta un error en esta etapa, y alguien lo detectará antes de que llegue al cliente o a la tesorería?
- ¿Qué permiso mínimo necesita la automatización? ¿Leer, sugerir o ejecutar?
- ¿Cómo medirá si funciona: tasa de excepciones, retrabajo, tiempo de ciclo, reclamaciones?
Si las respuestas apuntan a formatos fijos, pasos predecibles y errores caros, quédese con reglas y RPA. Si apuntan a texto libre, pasos variables y errores que una persona puede revisar, vale la pena probar un agente.
Los costes que no entran en la hoja de cálculo
En RPA, el coste oculto es el mantenimiento: cada actualización de pantalla del sistema de origen puede detener el robot. En un agente, es la evaluación y el seguimiento: un conjunto de casos de prueba para cada cambio de prompt o de modelo, revisión por muestreo de las decisiones y un registro de lo que hizo el agente. Quien compara solo licencias de RPA con coste de tokens compara la parte más pequeña de ambas cuentas.
Próximo paso
Tome un proceso que hoy consume horas de su equipo, dibuje sus etapas y responda a las seis preguntas para cada una. Si le queda una etapa de interpretación con volumen relevante, pruebe un agente solo en ella, con datos reales y métricas definidas de antemano. Eso es lo que hacemos en la Cyborg Forge: validar en 3 a 6 semanas si el agente resuelve la etapa correcta antes de invertir en producción. Cuando el caso se confirma, nuestro trabajo de agentes de IA lo lleva a producción con permisos, registros y revisión humana definidos desde el primer día.