Hay una pregunta que aparece en casi todas las primeras reuniones desde 2024: «¿Esto lo resolvemos con RPA o ya necesitamos un agente de IA?». La respuesta honesta casi nunca es «uno u otro». RPA y agentes IA no compiten por el mismo hueco: resuelven problemas distintos y, bien diseñados, trabajan en capas. Este artículo explica las diferencias reales —sin hype— para que sepas cuándo basta un robot de reglas y cuándo de verdad compensa pagar la complejidad de un agente.
Qué es RPA clásico (y por qué lleva 15 años funcionando)
RPA significa Robotic Process Automation: software que imita los clics, teclas y copia-pega que haría una persona sobre las interfaces que ya existen. No piensa. Ejecuta un guion determinista: «abre este portal, lee la celda B4, pégala en este campo, pulsa Enviar». Si das los pasos exactos, los repite mil veces sin cansarse, sin erratas y sin pedir vacaciones.
Eso es justo su virtud y su límite. El RPA es predecible y barato de razonar: lo que ves es lo que hace. Es ideal para procesos de alto volumen, estables y aburridos. Pero es frágil ante el cambio. El día que el proveedor mueve un botón, renombra una columna del Excel o cambia el orden de dos pantallas, el robot se rompe. No improvisa: o falla en seco o, peor, sigue ejecutando contra el sitio equivocado. Quien haya mantenido una flota de bots de RPA sabe que el coste no está en construirlos, está en mantenerlos vivos cada vez que cambia algo aguas arriba.
Qué es un agente IA (autonomía acotada, no magia)
Un agente IA no sigue un guion fijo: persigue un objetivo. Le das una meta («clasifica este correo de incidencia y abre el ticket en la cola correcta»), un conjunto de herramientas que puede usar (leer el CRM, consultar una base de conocimiento, llamar a una API) y un perímetro de lo que tiene permitido hacer. Dentro de ese perímetro, decide los pasos por sí mismo. Tiene criterio: puede manejar un caso que no estaba escrito de antemano, porque razona sobre el contexto en lugar de seguir una rama de un árbol rígido.
Aquí es donde nuestra postura es tajante: autonomía acotada, no autonomía total. Un agente bien hecho no es una caja negra a la que rezas. Es un sistema con barandillas: cada decisión queda en un log auditable (qué leyó, qué herramienta llamó, con qué argumentos, qué devolvió y por qué eligió ese camino), tiene acciones que requieren confirmación humana y lleva un kill switch para pararlo en seco. Si no puedes auditar por qué hizo lo que hizo, no es un agente listo para producción: es un riesgo con buena demo.
El agente brilla justo donde el RPA sufre: entradas variables, lenguaje natural, casos que no encajan en una plantilla, decisiones que requieren juzgar entre varias opciones. Y se degrada con elegancia: ante el cambio que rompería un bot, un agente bien instrumentado suele adaptarse o, como mínimo, escalar a una persona en vez de fallar silenciosamente.
RPA vs agentes IA: la tabla sin adornos
| Criterio | RPA clásico | Agente IA |
|---|---|---|
| Cómo opera | Reglas fijas, pasos deterministas | Objetivo + herramientas, decide los pasos |
| Entradas que tolera | Estructuradas y estables | Variables, lenguaje natural, casos no previstos |
| Ante un cambio aguas arriba | Se rompe o falla en silencio | Se adapta o escala a una persona |
| Predecibilidad | Total (mismo input, mismo output) | Acotada; requiere validación y guardarraíles |
| Coste de construcción | Bajo-medio | Medio-alto |
| Coste de mantenimiento | Alto en entornos que cambian | Menor ante cambios, pero exige evaluación continua |
| Coste por ejecución | Marginal (casi cero) | Variable (tokens / llamadas al modelo) |
| Auditoría | Trivial: el guion es la documentación | Imprescindible: log de decisiones y trazas |
Cuándo basta el RPA
No hace falta un agente para todo, y proponértelo sería venderte humo. El RPA es la herramienta correcta cuando el proceso cumple tres condiciones: es repetitivo, las reglas son claras y el entorno es estable. Algunos ejemplos donde el RPA basta y compensa:
- Descargar cada noche un informe de un portal que no tiene API y dejarlo en una carpeta.
- Conciliar dos sistemas que siempre devuelven el dato en el mismo formato.
- Dar de alta registros desde una plantilla fija a un ERP heredado sin integración.
- Trasvasar datos entre dos aplicaciones internas estables, con campos que no cambian.
En estos casos, meter un modelo de lenguaje añade coste por ejecución, latencia y una incertidumbre que no necesitas. Si el problema es determinista, la solución debe serlo. Pagar inteligencia para una tarea que no la requiere es derroche, no innovación.
Cuándo necesitas un agente
El agente justifica su complejidad cuando el proceso tiene variabilidad real y exige criterio. Señales claras de que el RPA se te queda corto:
- La entrada es texto libre: correos, tickets, documentos, mensajes que no siguen plantilla.
- Hay que decidir entre varias rutas según el contexto, no solo seguir un if-else.
- Los casos «raros» son frecuentes y mantener reglas para todos sería interminable.
- Necesitas combinar información de varias fuentes y resumir o razonar antes de actuar.
- El proceso cambia a menudo y reescribir guiones rígidos cada mes ya no sale a cuenta.
Ejemplos típicos: triaje de incidencias de soporte, clasificación y enrutado de correos comerciales, extracción de datos de facturas con formatos heterogéneos, asistencia interna que consulta documentación dispersa. Ahí el agente no es un capricho: es lo que hace viable automatizar algo que con reglas fijas sería inmanejable.
Por qué no son rivales, sino capas
El error de marco más común es plantearlo como un duelo. En la práctica, las arquitecturas que funcionan combinan ambos. El agente aporta el criterio —entiende la entrada, decide qué hacer—; el RPA o una integración por API aporta la ejecución determinista y fiable de cada paso concreto.
Un patrón habitual: un agente lee un correo de incidencia, decide que es una devolución, extrae el número de pedido y la razón, y entonces invoca una automatización determinista (un bot de RPA o, mejor, una llamada a API) para registrar la devolución exactamente igual cada vez. El agente piensa; la herramienta actúa sin margen de error. Lo mejor de las dos capas: flexibilidad arriba, fiabilidad abajo, y un log que conecta la decisión con la acción de punta a punta.
Dicho con honestidad de ingeniería: si ya tienes una buena API, muchas veces no necesitas RPA en absoluto —el RPA es un parche elegante para sistemas sin integración. Y si tu proceso es trivial y estable, tampoco necesitas el agente. La arquitectura correcta es la más simple que resuelve tu problema, no la más vistosa.
Coste y mantenimiento: la parte que nadie te cuenta en la demo
El coste de construir es solo la entrada. El coste real vive en el mantenimiento, y aquí RPA y agentes se comportan distinto.
El RPA es barato de ejecutar —su coste marginal es casi cero— pero caro de sostener en entornos vivos: cada cambio de interfaz aguas arriba es una reparación. Su mantenimiento es reactivo: se rompe, lo arreglas.
El agente tiene coste por ejecución (tokens, llamadas al modelo) y un mantenimiento proactivo: hay que evaluarlo de forma continua, vigilar que su calidad no se degrade, ajustar prompts y herramientas, y revisar el log para detectar comportamientos raros antes de que escalen. No es «lo montas y te olvidas»: requiere una disciplina de evaluación que muchos proyectos infravaloran. Quien te prometa un agente que no necesita supervisión te está vendiendo el riesgo como una virtud.
En ambos casos hay implicaciones de cumplimiento que conviene no dejar para el final. Si el proceso toca datos personales, el RGPD aplica igual a un bot que a un agente. Y si el agente toma decisiones que afectan a personas, el AI Act europeo te va a exigir trazabilidad y supervisión humana —exactamente lo que un log auditable y un kill switch resuelven por diseño. Construir con esas barandillas desde el día uno no es burocracia: es lo que diferencia un sistema que puedes defender de uno que tendrás que apagar.
Cómo lo abordamos en Plantekia
Nuestra regla es simple y la repetimos sin rubor: automatizamos solo donde hay retorno real. Antes de proponer nada, diagnosticamos el proceso —volumen, variabilidad, estabilidad, qué cuesta hoy hacerlo a mano y qué cuesta cuando sale mal—. A veces la conclusión es un agente con su log auditable y su kill switch. A veces es un RPA aburrido y eficaz. Muchas veces es una integración por API que hace innecesarias ambas cosas. Y de vez en cuando, lo honesto es decirte que ese proceso no merece automatizarse todavía.
Si estás dándole vueltas a si tu caso pide RPA, un agente IA para empresas o simplemente una buena integración, no lo decidas por moda. Cuéntanos el proceso y te damos un diagnóstico sin humo en nuestro contacto / diagnóstico gratuito: qué capa tiene sentido, qué retorno esperar y qué barandillas necesita para ser auditable desde el primer día.