RPA vs IA: no son lo mismo y confundirlas sale caro

Cuando alguien en un comité de dirección pregunta qué es el RPA y si no será lo mismo que la IA, casi siempre está preguntando otra cosa: quiere saber por qué le han presentado dos presupuestos distintos para lo que, desde fuera, parece el mismo problema. La respuesta corta es que RPA e IA resuelven cosas diferentes. El RPA ejecuta pasos que ya sabes describir; la IA decide cosas que no sabes describir con reglas. Mezclar esas dos definiciones es el origen de la mayoría de automatizaciones que se abandonan al año.

Este artículo separa las dos cosas con ejemplos concretos, explica cuándo conviene cada una, por qué tantos robots de RPA se rompen y cómo se combinan bien cuando el proceso lo pide. Sin siglas de más y sin prometer que un software elimina el trabajo de nadie por sí solo.

¿Qué es RPA y qué hace exactamente?

RPA son las siglas de Robotic Process Automation, automatización robótica de procesos. La palabra "robótica" despista: aquí no hay ningún brazo mecánico. Un robot de RPA es un programa que imita lo que hace una persona con el ratón y el teclado sobre las aplicaciones que ya tienes: abre el correo, descarga el adjunto, entra en el ERP, copia doce campos, pulsa guardar, escribe una línea en un Excel y manda un aviso.

Tres características lo definen:

• Trabaja sobre la interfaz, no sobre la base de datos. Por eso puede automatizar sistemas antiguos que no tienen API. Es su mayor virtud y su mayor fragilidad a la vez.
• Sigue reglas deterministas. Si el campo A dice "urgente", va a la cola B. Cero interpretación, cero ambigüedad. Si ocurre algo que nadie previó, se para.
• No aprende. Un robot de RPA hará dentro de dos años exactamente lo mismo que hace hoy, ni mejor ni peor, salvo que alguien lo modifique.

Ejemplos reales de lo que un RPA hace bien: conciliar extractos bancarios con asientos cuando el criterio es exacto, dar de alta pedidos que llegan siempre con el mismo formato, extraer un listado del ERP cada lunes a las 7:00 y dejarlo en una carpeta, o replicar un alta de cliente en tres sistemas que no se hablan entre sí.

¿En qué se diferencia el RPA de la IA?

La diferencia práctica no es de tecnología, es de tipo de problema. El RPA automatiza tareas que sabes escribir en un procedimiento; la IA aborda tareas donde el criterio existe pero nadie lo ha conseguido poner por escrito sin dejarse cincuenta excepciones.

Un ejemplo que lo deja claro: "cuando llegue una factura de este proveedor, con este formato, coge el importe de la casilla de abajo a la derecha" es RPA. "Cuando llegue una factura de cualquier proveedor, en el formato que sea, encuentra el importe total" es IA. El primer enunciado es una regla. El segundo es un criterio.

| | RPA | IA | |---|---|---| | Qué resuelve | Pasos repetitivos y descritos | Decisiones, clasificación, interpretación | | Entrada típica | Datos estructurados y estables | Texto libre, imágenes, formatos variables | | Comportamiento | Determinista: mismo input, mismo output | Probabilístico: acierta con un porcentaje | | Qué pasa ante lo inesperado | Se para o falla | Da una respuesta, a veces equivocada | | Cómo se corrige | Modificando el flujo a mano | Con más datos, ajustes o revisión humana | | Qué necesita para empezar | El proceso documentado | Datos históricos o ejemplos etiquetados | | Coste de mantenimiento | Alto si los sistemas cambian | Alto si el negocio o los datos cambian | | Trazabilidad | Total: cada paso es explícito | Parcial: hay que diseñarla |

Hay una consecuencia de gobierno que muchas empresas descubren tarde. El RPA es auditable línea a línea: si hizo algo mal, se sabe exactamente por qué. La IA da respuestas con un margen de error conocido, y ese margen hay que decidirlo antes, no descubrirlo en producción. En procesos con implicaciones legales o contables, esa diferencia pesa más que cualquier comparativa de precio.

Si puedes escribir el procedimiento completo en una página sin usar la palabra "depende", tu problema es de RPA. Si necesitas la palabra "depende", es de IA.

¿Cuándo conviene RPA y cuándo conviene IA?

La decisión se toma mirando el proceso, no el catálogo del proveedor. Estas señales orientan bien en la práctica:

Elige RPA cuando:

• El proceso está documentado y las excepciones son menos del 10-15 % de los casos.
• Los datos de entrada llegan siempre en la misma estructura: un CSV, un formulario, una pantalla del ERP.
• Los sistemas implicados no tienen API y no la van a tener a corto plazo.
• Necesitas trazabilidad completa para auditoría o cumplimiento.
• El volumen es alto y constante: cientos o miles de repeticiones idénticas al mes.

Elige IA cuando:

• La entrada es texto libre, correos, documentos escaneados o formatos que cambian según quién los envía.
• La tarea implica clasificar, resumir, priorizar o predecir, no solo mover datos.
• Las excepciones son la norma y mantener el árbol de reglas se ha vuelto inviable.
• Existe histórico suficiente para aprender de él, o un experto dispuesto a validar ejemplos al principio.

No elijas ninguna de las dos cuando el proceso está roto de base. Automatizar un circuito de aprobaciones que nadie respeta solo consigue que se incumpla más rápido. Y si el proceso se ejecuta cuatro veces al mes, el retorno rara vez paga el mantenimiento: sale más barato dejarlo como está y dedicar el esfuerzo a otro sitio. En automatización de procesos con IA desarrollamos ese criterio de priorización con más detalle.

¿Por qué se rompen tantos proyectos de RPA?

Es la pregunta incómoda del sector, y la respuesta no es que la tecnología sea mala. Los robots de RPA se rompen por razones muy concretas y casi todas previsibles:

Dependen de la pantalla. Si el robot busca un botón "Guardar" en una posición concreta y el proveedor del ERP publica una actualización que mueve ese botón, el robot deja de funcionar esa misma mañana. Multiplica ese riesgo por cada aplicación que toque el flujo.

Nadie mantiene lo que nadie ve. Un robot funcionando es invisible. Cuando falla a las tres de la madrugada de un cierre de mes, aparece la pregunta de quién lo mantiene, y con frecuencia la persona que lo construyó ya no está o era de una consultora que cerró el proyecto hace dos años.

Se automatizó el proceso equivocado. El caso clásico: se automatiza el paso más visible en lugar del más costoso, o se automatiza un proceso que iba a desaparecer con el cambio de ERP previsto para el año siguiente.

Las excepciones crecen. Empiezas con un 5 % de casos que el robot deriva a una persona. Dos años después es un 30 %, porque el negocio añadió variantes que nunca se incorporaron al flujo. Llega un punto en que la persona revisa casi todo y el robot solo ha añadido una capa de complejidad.

No hay medición. Sin un dato de cuántos casos procesa, cuántos derivan y cuánto tiempo ahorra, es imposible defender el mantenimiento en un presupuesto. Los robots sin métricas son los primeros que se quedan sin partida.

La lección no es evitar el RPA: es tratarlo como software en producción. Necesita dueño, monitorización, alertas cuando falla y una revisión al menos semestral. Si tu proveedor no incluye eso en la oferta, el proyecto tiene fecha de caducidad aunque el arranque salga perfecto.

¿Cómo se combinan RPA e IA en un proceso real?

En la práctica, los procesos completos rara vez son puros. La combinación que mejor funciona coloca a cada tecnología donde es fuerte: la IA en la entrada, donde hay ambigüedad; el RPA en la ejecución, donde hay pasos fijos.

Un circuito de facturas de proveedor, por partes:

1. Entrada (IA). Llega un PDF por correo, de un proveedor cualquiera, con un formato que no controlas. Un modelo de extracción identifica proveedor, número, fecha, base, IVA y total. 2. Validación (reglas + humano). Se comprueba contra el pedido y el albarán. Si el modelo devuelve confianza alta y los importes cuadran, sigue. Si no, va a una bandeja donde una persona confirma en diez segundos. 3. Ejecución (RPA). El robot entra en el ERP, crea el asiento, adjunta el documento y actualiza el estado. Pasos fijos, cero interpretación. 4. Cierre (medición). Se registra cuántas facturas pasaron solas, cuántas requirieron revisión y qué proveedores concentran los fallos.

Ese cuarto punto es el que convierte el proyecto en algo que mejora en lugar de degradarse. Sin él no sabes si el modelo está empeorando ni qué excepción merece la pena cubrir con una regla nueva.

Hay un matiz importante sobre los agentes de IA, que es la evolución que más se está vendiendo ahora. Un agente puede encadenar pasos y decidir el siguiente por sí mismo, lo que parece hacer innecesario el RPA. En procesos con consecuencias contables o contractuales, sin embargo, sigue siendo mejor que la parte de ejecución sea determinista y auditable. Que el agente decida qué hacer no significa que deba ser él quien pulse el botón. Lo desarrollamos en agentes de IA para empresas.

¿Por dónde empezar sin equivocarse de herramienta?

Un orden que funciona, y que no exige comprar nada en los dos primeros pasos:

1. Mide el proceso antes de automatizarlo. Cuántos casos al mes, cuánto tiempo por caso, quién lo hace, qué porcentaje son excepciones. Si no puedes responder, aún no estás listo para pedir presupuestos. 2. Clasifica cada paso. Recorre el flujo y marca cada paso como "regla" o "criterio". Ya tienes el reparto entre RPA e IA, y normalmente descubres que la mayoría del tiempo se va en dos o tres pasos concretos. 3. Revisa si hay API antes que pantalla. Si el sistema ofrece una integración de verdad, úsala: es más estable y más barata de mantener que un robot pulsando botones. Volvemos sobre esto en integrar la IA con tus herramientas. 4. Empieza por un caso con volumen y dolor. Uno solo, medido a 90 días, con un umbral pactado antes de arrancar. 5. Define quién lo mantiene el día uno. Nombre y apellidos, presupuesto anual y qué pasa cuando cambie el ERP. Si esta pregunta no tiene respuesta, no arranques.

Una última advertencia sobre costes: las licencias de plataformas de RPA se facturan habitualmente por robot desatendido y año, y ese importe recurrente puede superar al del desarrollo inicial. Pide siempre el coste a tres años, no el de la implantación. Los rangos y las partidas que se olvidan están en cuánto cuesta un proyecto de IA.

Preguntas frecuentes

¿Qué es RPA en palabras sencillas?

Es un programa que hace con el ratón y el teclado lo mismo que haría una persona sobre las aplicaciones que ya usas: copiar datos entre sistemas, rellenar formularios, descargar informes. Sigue reglas fijas y no interpreta nada, así que sirve para tareas repetitivas y bien descritas.

¿La IA sustituye al RPA?

No lo sustituye, cubre otra parte del problema. La IA resuelve la entrada ambigua —documentos, correos, formatos variables— y el RPA ejecuta los pasos fijos con trazabilidad completa. En procesos con implicaciones contables o legales, esa ejecución determinista sigue siendo una ventaja.

¿Cuánto tarda en amortizarse un proyecto de RPA?

Depende del volumen y del coste de licencias, pero un caso con cientos de repeticiones mensuales suele amortizarse entre seis y dieciocho meses. La clave no es el ahorro inicial sino el mantenimiento: un robot que se rompe cada trimestre puede consumir todo el retorno en horas de soporte.

¿Necesito RPA si mis sistemas tienen API?

Normalmente no. Si existe una integración soportada por el fabricante, es más estable, más rápida y más barata de mantener que un robot que depende de la interfaz. El RPA cobra sentido justo cuando esa vía no existe y no va a existir.

Si estás en el punto de decidir entre las dos —o sospechas que te han vendido una cuando necesitabas la otra—, la vía rápida es mirar el proceso con datos delante. En la auditoría revisamos tus flujos y te decimos qué paso es de reglas, cuál de criterio y cuál no merece automatizarse todavía. Y si prefieres contrastarlo en media hora antes de mover nada, hablemos.