Cada semana alguien anuncia que el RPA está muerto y que los agentes de IA lo han jubilado. Es un buen titular y una mala decisión de arquitectura. Porque quien mata el RPA por moda acaba pidiéndole al agente que haga trabajo de peón —mover un dato del sistema A al sistema B, mil veces, sin pensar—, y eso es caro, lento y absurdo. Y quien se aferra al RPA por costumbre le pide que decida sobre una factura rara, y el bot se planta. La pregunta útil no es cuál gana. Es qué parte del trabajo hace cada uno.
Agentes de IA vs RPA: la pelea está mal planteada
RPA (Robotic Process Automation) es un robot que imita clics y teclas sobre una pantalla. Le grabas los pasos y los repite igual, a toda velocidad, sin cansarse ni improvisar. Es determinista: mismo input, mismo output, siempre. Un agente de IA es otra cosa: lee texto sin estructura, entiende la intención, decide dentro de unos límites y se adapta cuando algo cambia. Uno es músculo. El otro es criterio. Ponerlos a competir es como preguntar si es mejor un destornillador o un electricista: dependen el uno del otro.
La confusión viene de que ambos «automatizan», así que parecen sustitutos. No lo son. Automatizan capas distintas del mismo proceso. Y el error caro —el que vemos una y otra vez— es meter a uno a hacer el trabajo del otro. Antes de decidir nada conviene tener claro qué es automatizar de verdad un proceso con agentes, porque la mitad de los proyectos fallidos no fallan por la herramienta: fallan por elegir mal quién hace qué.
Qué hace bien el RPA (y por qué no está muerto)
El RPA brilla donde el trabajo es repetitivo, estructurado y estable. Nada de matices: reglas fijas, cero excepciones, la misma pantalla todos los días. En ese terreno es imbatible —barato, rápido, auditable— y ningún agente lo va a superar, porque no hay nada que razonar. Casos donde el RPA sigue siendo la respuesta correcta:
- Mover datos entre sistemas que no hablan por API: copiar de una hoja al ERP, del ERP al portal del banco, siempre igual.
- Rellenar formularios idénticos a partir de una plantilla, en volumen alto y complejidad cero.
- Generar informes programados: extraer, pegar, exportar, enviar. Sin decisiones por medio.
- Conciliaciones triviales donde la regla es «si coincide el importe, marca como pagado» y no hay grises.
El talón de Aquiles del RPA es conocido: es frágil. Como trabaja imitando la pantalla, el día que alguien mueve un botón, renombra un campo o el proveedor actualiza el portal, el bot se rompe y hay que repararlo a mano. Ese mantenimiento no es anecdótico. Recopilaciones de mercado que citan a Deloitte estiman que el mantenimiento se come entre el 70% y el 75% del presupuesto de RPA (Neomanex, 2025). No es un motivo para tirarlo: es un motivo para no pedirle lo que no sabe hacer.
Qué hace bien el agente (y dónde el RPA se rompe)
El agente entra justo donde el RPA se planta: cuando hay que leer algo sin formato, entender el contexto y decidir. No sigue un guion grabado; interpreta. Por eso aguanta la excepción, el correo mal escrito, la factura con el concepto en un sitio raro. Terreno del agente:
- Datos sin estructura: correos, PDFs, contratos, chats. El agente lee y extrae lo que importa aunque cada documento venga distinto.
- Excepciones con criterio: una discrepancia en una factura, un pedido raro, un caso que no encaja en la regla. El agente razona dentro de sus límites en vez de plantarse.
- Coordinar varios sistemas por su significado, no por su pantalla: cruza CRM, ERP y bandeja de entrada entendiendo qué es cada cosa.
- Clasificar y priorizar cuando la respuesta no está en una tabla: triaje de tickets, enrutado de leads, categorías que dependen del contexto.
El agente también tiene su precio: cuesta más por operación que un bot, hay que ponerle guardarraíles y supervisión, y no querrás que decida solo sobre cosas sensibles el primer día. Montar uno que aguante en producción —no una demo— tiene su oficio, y lo desglosamos en cómo se crea un agente de IA que funcione de verdad. La regla operativa: no uses un agente para lo que una regla fija ya resuelve. Es como contratar a un abogado para fotocopiar.
| Dimensión | RPA | Agente de IA |
|---|---|---|
| Cómo trabaja | Imita clics y teclas sobre una pantalla | Lee, razona y decide sobre el significado |
| Tipo de dato | Solo estructurado (tablas, campos fijos) | Estructurado + sin estructura (correos, PDFs, chats) |
| Excepciones | Se planta y escala a un humano | Razona dentro de sus límites |
| Cuando cambia la pantalla | Se rompe, hay que repararlo | Se adapta por el contexto |
| Coste por operación | Muy bajo | Más alto |
| Su terreno | Repetitivo, estable, sin grises | Complejo, con excepciones, multi-sistema |
El patrón que gana en 2026: el híbrido
Aquí está la tesis, y va a contracorriente del titular fácil: no elijas bando, combínalos. El patrón que sale rentable no es «agente en vez de RPA» ni «RPA de toda la vida». Es el híbrido, con un reparto limpio: el agente lee y decide, el RPA ejecuta lo repetitivo. El criterio arriba, el músculo abajo. Cada uno haciendo lo que hace barato y bien.
Un ejemplo que se entiende solo: extraer los datos de una factura y meterlos en tu sistema. La factura llega como PDF, cada proveedor la maqueta a su manera, a veces falta un campo o el IVA está mal puesto —eso es lectura y criterio, terreno del agente—. Una vez el agente ha entendido y validado los datos, meterlos en el ERP campo a campo, mil veces igual, es puro músculo repetitivo —terreno del RPA o de una integración por API—. El agente hace la parte que piensa; el bot hace la parte que suda. Ni el agente pierde tokens tecleando, ni el bot se planta ante un PDF raro.
Cómo decidir en tu caso, sin comprar humo
No necesitas un comité para elegir. Necesitas mirar el proceso y responder a estas preguntas en orden:
- ¿Los datos vienen ordenados o hechos un lío? Si todo llega en tablas limpias y estables, empieza por RPA. Si llega en correos, PDFs y adjuntos, necesitas un agente que lea.
- ¿Hay excepciones que requieren decidir? Si el proceso es «siempre igual, sin grises», es RPA. Si a menudo hay un «depende», es agente.
- ¿La pantalla o el formato cambian a menudo? Si el portal se actualiza cada dos por tres, un bot va a vivir roto; ahí el agente sale más barato a la larga aunque cueste más por operación.
- ¿Puedes partir el proceso en dos capas? Casi siempre sí: el trozo que piensa y el trozo que repite. Ese es el momento híbrido, y suele ser la respuesta correcta.
Y un aviso para no tropezar con lo de siempre: la herramienta no es el proyecto. Elegir agente o RPA es el 10% del trabajo; el 90% es entender el proceso, ponerle límites y dejarlo corriendo con algo que se mide. Eso es automatización de operaciones sobre lo que ya tienes, no una compra de tecnología. Quien te vende «agentes» sin preguntarte por tu proceso te está vendiendo la etiqueta de moda, igual que antes te vendía «RPA» sin mirar. La moda cambia; el oficio de repartir bien el trabajo, no.