Casi todo lo que aparece cuando buscás qué es RPA está escrito por empresas que venden RPA. Es lógico, pero deja afuera la pregunta que más importa cuando tenés que decidir: ¿es la mejor forma de automatizar este proceso, o hay una más estable? En esta guía explicamos qué es la RPA, para qué sirve, cuáles son sus límites reales y cómo se compara con una integración por API y con un agente de IA.
¿Qué significa la sigla RPA?
RPA es la sigla de Robotic Process Automation, en español automatización robótica de procesos. El nombre confunde un poco: no hay ningún robot físico. Es software que opera otras aplicaciones igual que lo haría una persona sentada frente a la computadora.
¿Qué es un RPA y para qué sirve?
Un RPA (o "bot" de RPA) es un programa que imita los clics y el tipeo de una persona sobre la interfaz de otros sistemas. Abre una aplicación, entra a una pantalla, copia un dato de un lugar, lo pega en otro, aprieta un botón y pasa al siguiente caso. Lo hace siguiendo una secuencia de pasos que alguien definió antes, siempre igual.
Sirve para tareas que cumplen tres condiciones:
- Se repiten mucho: cientos de veces por semana, el mismo procedimiento.
- Siguen reglas fijas: no hay que interpretar nada, solo ejecutar.
- Los datos vienen ordenados: campos, planillas o pantallas que siempre tienen el mismo formato.
Ejemplos típicos: pasar datos de una planilla a un sistema de gestión, descargar reportes de un portal y guardarlos en una carpeta, completar formularios en un sistema interno o copiar información entre dos aplicaciones que no se hablan entre sí.
La gran ventaja de la RPA es que no necesita que el sistema de destino tenga una API (una puerta de entrada pensada para que otros programas le manden datos). Si el sistema solo tiene pantallas, el robot trabaja sobre esas pantallas. Por eso es muy usada en empresas con sistemas viejos que nadie quiere o puede tocar.
¿Cómo funciona la RPA?
En la práctica, un proyecto de RPA tiene tres partes:
- Se graba o se diseña el procedimiento: qué pantalla abrir, en qué campo escribir, qué botón apretar.
- El robot lo ejecuta: en una computadora o un servidor, con un usuario propio, a demanda o en horarios fijos.
- Alguien lo supervisa: revisa los casos que fallaron y ajusta el robot cuando algo cambia.
Ese tercer punto es el que menos aparece en los folletos y el que más pesa con el tiempo.
¿Cuáles son los RPA más usados?
Las herramientas de RPA más conocidas del mercado son:
- UiPath, una de las plataformas más conocidas de automatización empresarial.
- Automation Anywhere, otra plataforma enfocada en automatización empresarial.
- Microsoft Power Automate, que incluye automatización de escritorio y se integra con el ecosistema de Microsoft.
- Blue Prism, hoy parte de SS&C, muy asociada a la automatización en empresas grandes.
Todas resuelven lo mismo con matices de precio, licenciamiento y ecosistema, y en los últimos años casi todas sumaron funciones de IA. Cuando alguien busca "empresas de RPA", en general encuentra a estos fabricantes y a las consultoras que implementan sus productos.
Los límites reales de la RPA
La RPA funciona, pero tiene límites que conviene conocer antes de apostar un proceso entero a un robot.
Se rompe cuando cambia una pantalla
El robot no entiende lo que hace: sabe que tiene que hacer clic en cierto botón de cierta pantalla. Si el proveedor del sistema actualiza la interfaz, mueve un campo o cambia el nombre de un botón, el robot se frena o, peor, carga datos en el lugar equivocado.
El mantenimiento es alto
Cada cambio en cualquiera de los sistemas que toca el robot obliga a revisarlo. Con diez o veinte robots en producción, el mantenimiento se vuelve un trabajo en sí mismo.
No entiende contenido que no viene ordenado
Un robot de RPA clásico sabe leer un campo en una posición fija. No sabe qué hacer con un correo escrito de cualquier manera, un comprobante sacado con el celular o un pedido mandado por WhatsApp. Para eso necesita apoyarse en otra tecnología.
Automatiza el proceso tal como está
La RPA copia lo que hace una persona, incluso los pasos que no deberían existir. Si un dato se carga tres veces en tres sistemas, el robot lo va a cargar tres veces. Muchas veces el problema de fondo no era la carga manual, sino que los sistemas no estaban conectados.
¿Qué es un agente de IA?
Un agente de IA es un sistema que usa un modelo de lenguaje para entender un pedido y decidir qué hacer, dentro de reglas que la empresa define. A diferencia de un robot de RPA, no sigue una secuencia de clics: interpreta el contenido (un mensaje, un audio, un documento, una foto), elige el paso que corresponde y lo ejecuta usando las herramientas que tiene habilitadas, como consultar un sistema o registrar un dato.
Por eso sirve justo donde la RPA no llega: en los pasos que necesitan criterio. Leer una factura que viene en cualquier formato, entender qué quiere un cliente que escribe por WhatsApp o clasificar un pedido según su contenido.
Un agente bien construido no hace lo que quiere. Tiene reglas escritas, sabe qué puede y qué no puede hacer, valida lo que registra contra el sistema y, cuando no está seguro, deriva el caso a una persona. Si querés ver cómo se diseñan, lo contamos en detalle en nuestra página de desarrollo de agentes de IA.
RPA vs integración por API vs agente de IA
La comparación que casi nunca aparece es la de tres opciones, no dos. Antes de elegir entre un robot y un agente, conviene preguntarse si los sistemas se pueden conectar directamente.
| RPA | Integración por API | Agente de IA | |
|---|---|---|---|
| Cómo trabaja | Imita clics y tipeo sobre la pantalla | Los sistemas se pasan datos directamente | Interpreta el contenido y decide con reglas definidas |
| Sirve para | Sistemas viejos que solo tienen pantallas | Mover datos entre sistemas que tienen API | Pasos que necesitan leer un mensaje, un documento o una foto |
| Datos de entrada | Ordenados y siempre iguales | Ordenados | Ordenados o desordenados: textos, audios, imágenes, PDF |
| Se rompe cuando | Cambia una pantalla o un botón | Cambia la versión de la API sin aviso | Las reglas no están escritas y tiene que adivinar |
| Mantenimiento | Alto | Bajo | Medio: revisar derivaciones y ajustar reglas |
| Ejemplo | Cargar datos en un sistema sin API | Cada venta del e-commerce entra sola al ERP | Leer un comprobante que llega por WhatsApp y registrar el pago |
¿Cuándo conviene cada uno?
Conviene una integración por API cuando
- Los dos sistemas tienen API (la mayoría de los ERP, CRM y plataformas de e-commerce modernas la tienen).
- Querés que el dato viaje solo, en el momento, sin depender de una pantalla.
- El proceso tiene que durar años sin mantenimiento constante.
Conviene un flujo con n8n o Make cuando
- El proceso es simple: un formulario que crea un contacto en el CRM y avisa al vendedor.
- Querés que tu equipo pueda ver y tocar el flujo.
- Los sistemas ya tienen conectores listos en esas herramientas.
Conviene un agente de IA cuando
- Hay que interpretar algo: un correo, un audio, un comprobante, una foto.
- Cada caso llega distinto, pero las reglas para resolverlo se pueden escribir.
- Hoy una persona lee, decide y carga, y ese es el cuello de botella.
Conviene RPA cuando
- El sistema no tiene API, no permite leer la base de datos ni intercambiar archivos.
- Reemplazar o modificar ese sistema no es una opción en el corto plazo.
- El proceso es estable y las pantallas cambian poco.
Nuestra postura: API siempre que exista, RPA como último recurso
En Axlan usamos una regla simple para decidir cómo automatizar cada paso de un proceso:
- API siempre que exista. Es la opción más estable y la que menos mantenimiento pide.
- Flujos (n8n, Make) para lo simple. Cuando el proceso es corto y conviene que tu equipo lo pueda manejar.
- IA donde hace falta criterio. Solo en los pasos que necesitan interpretar contenido. Usar IA donde no hace falta encarece y agrega errores.
- RPA como último recurso. Cuando el sistema no ofrece otra puerta de entrada, y sabiendo desde el principio cuánto mantenimiento va a pedir.
Casi todos los proyectos reales combinan más de una pieza. Lo que define si una automatización dura años o se rompe al primer cambio es elegir bien cada una. Lo explicamos con más detalle en nuestra página de automatización de procesos con IA e integración de sistemas.
Dos casos donde un agente hizo lo que un robot no podía
Lector automático de comprobantes para retail
Para una empresa de retail construimos un lector que ingesta las facturas de compra y venta, extrae los datos y los carga en el ERP y el CRM según los parámetros de imputación de la empresa. Un robot de RPA clásico no podría hacerlo solo, porque cada comprobante llega con un formato distinto: hace falta leer y entender el documento, no copiar un campo en una posición fija. La IA pone el criterio en la lectura y las reglas de imputación de la empresa definen dónde va cada dato.
M.I.C.A con Integrando Salud
M.I.C.A es un agente que atiende pacientes por WhatsApp, desarrollado junto con Integrando Salud. Entiende textos, audios e imágenes, y escribe directamente en el sistema de gestión de cada clínica: da de alta pacientes, bloquea turnos y registra pagos verificados, sin que nadie los cargue a mano. Ante una emergencia, un pedido explícito o un caso que no le corresponde, deriva a una persona. Es un buen ejemplo de la combinación: el agente pone el criterio y la integración con el sistema pone la estabilidad.