Qué es RPA: automatización robótica, cuándo sí y cuándo no

Te van a vender RPA como la solución universal para automatizar tu empresa; este artículo te cuenta lo que el vendedor no. RPA (Robotic Process Automation, automatización robótica de procesos) es software que opera otros sistemas a través de la pantalla, igual que un humano: abre la aplicación, hace click en los botones, tipea en los campos y copia datos de un lado a otro. No hay ningún robot físico — es un programa que imita a un usuario. Y esa virtud (no necesita que el sistema colabore) es también su mayor debilidad: todo lo que cambie en la pantalla puede romperlo.

Cómo funciona un bot RPA, de verdad

Un bot RPA se construye "grabando" o programando la secuencia exacta que hoy hace una persona:

1. Abrir el sistema de gestión y loguearse.
2. Localizar elementos de la pantalla: el botón "Nueva factura", el campo "CUIT". Los identifica por su posición, su texto o su identificador interno.
3. Ejecutar la secuencia: click, tipeo, copiar, pegar, siguiente registro.
4. Repetir para cada fila del lote, a velocidad de máquina y sin errores de tipeo.

La diferencia clave con una integración por API: el RPA entra por la puerta de adelante (la interfaz visual, hecha para humanos), mientras que la API entra por la puerta de servicio (un canal hecho para programas). Si no tenés claro qué es una API, arrancá por qué es una API y cómo conectar tus sistemas — es el contexto necesario para decidir bien.

Cuándo RPA es la única opción (y está perfecto usarlo)

Hay escenarios donde el RPA no es un parche sino la herramienta correcta, porque no existe puerta de servicio:

• Sistemas viejos sin API: software de escritorio de los 90/2000, sistemas a medida cuyo desarrollador ya no existe, ERPs antiguos sin licenciamiento de integración.
• Terminales y aplicaciones cerradas: home banking empresarial, terminales tipo AS/400, aplicaciones de obras sociales o aseguradoras que solo existen como pantalla.
• Portales de terceros que no controlás: el portal del organismo público o del cliente corporativo donde hay que cargar datos a mano sí o sí, y que no ofrece otra vía.
• Puentes temporales: necesitás la automatización ya, y la integración formal va a tardar meses. Un bot RPA bien planteado compra tiempo — siempre que se asuma como transitorio.

Una aclaración del mundo real: antes de aceptar que "el sistema no tiene API", vale la pena que alguien técnico lo verifique. Más de una vez encontramos que el sistema sí tenía una vía de integración —API parcial, base de datos accesible, exportación programable— que nadie había explorado. Las alternativas las cubrimos en conectar sistemas legacy sin API.

Cuánto cuesta el RPA: licencias vs bot a medida

Números de referencia para LATAM en 2026, conservadores:

Concepto	UiPath	Power Automate (Microsoft)	Bot a medida (código)
Licencia mensual	~USD 400-1.400 por bot según tipo (attended/unattended)	~USD 150-215 por bot unattended	USD 0 (sin licencia)
Implementación por proceso	USD 3.000-15.000 con integrador	USD 2.000-10.000	USD 2.000-8.000 proyecto único
Mantenimiento anual típico	15-30% del costo inicial + licencias	15-30% + licencias	10-20% del costo inicial
Costo total a 3 años (1 proceso)	USD 20.000-60.000	USD 10.000-30.000	USD 3.000-12.000

La lectura honesta de la tabla: las plataformas RPA comerciales tienen sentido para corporaciones que van a automatizar decenas de procesos y necesitan gobernanza centralizada, auditoría y un ejército de bots administrados. Para una PyME que necesita automatizar 2 o 5 procesos, las licencias perpetuas suelen costar más que construir bots a medida — que además se pueden diseñar para usar APIs donde existan y pantalla solo donde no quede otra, lo mejor de los dos mundos dentro de un proyecto de software a medida.

¿Te cotizaron RPA y no sabés si es la herramienta correcta para tu caso? Agendá una llamada de 30 minutos y te damos una segunda opinión técnica sin compromiso.

La parte que el vendedor no te cuenta: por qué los bots RPA se rompen

Esta sección es el motivo de este artículo. El RPA es estructuralmente frágil porque depende de algo que no controla: la pantalla de otro sistema.

• Cambió la interfaz, murió el bot. Una actualización del sistema mueve un botón o renombra un campo, y el bot hace click en el lugar equivocado o se queda esperando algo que ya no existe.
• Los imprevistos lo descolocan: un popup de "nueva versión disponible", un cartel de sesión expirada, una pantalla que tardó 3 segundos más en cargar. Un humano los resuelve sin pensar; el bot clásico, no.
• Falla en silencio o, peor, falla a medias: procesa 200 registros bien y 30 mal, y nadie se entera hasta que un cliente reclama. Por eso el monitoreo y las alertas no son opcionales.
• El mantenimiento no es un extra, es el costo principal. En la industria se asume que un bot RPA en producción requiere ajustes constantes; presupuestá entre 15% y 30% del costo de implementación por año, todos los años.

Nada de esto pasa (o pasa muchísimo menos) con una integración por API: el canal está diseñado para programas, es estable entre versiones y avisa con errores claros cuando algo no va.

Señales de que el RPA es un parche y no la solución

Si reconocés alguna de estas, el problema de fondo es otro:

1. El sistema que estás "robotizando" es tuyo. Si el bot opera la pantalla de tu propio software, lo que falta es desarrollarle una API o modernizarlo — el bot es una curita sobre deuda técnica propia.
2. Estás por encadenar varios bots para mover datos entre tus sistemas centrales. Esa arquitectura colapsa con el primer cambio de pantalla; lo que estás describiendo es una integración, no un robot. Es la diferencia de fondo entre el RPA y la automatización programática por código.
3. El proceso tiene excepciones constantes que requieren criterio. El RPA clásico no decide; ahí la conversación correcta es de automatización con IA, donde un modelo interpreta y el código ejecuta.
4. El costo de licencias ya supera el de desarrollar la integración real. Pasa antes de lo que parece: hacé la cuenta a 3 años, no a 3 meses.
5. Nadie monitorea los bots. RPA sin monitoreo es un empleado fantasma que puede estar cometiendo errores hace semanas.

Si igual vas a hacer RPA, hacelo así

Cuando el RPA es la herramienta correcta —sistema cerrado, sin API, imposible de cambiar— estas prácticas separan un bot que trabaja años de uno que muere al primer mes:

• Identificadores estables antes que coordenadas: que el bot busque el campo "CUIT" por su nombre interno, no "el tercer casillero de la izquierda". Sobrevive a más cambios visuales.
• Validación al final de cada lote: el bot tiene que verificar contra el sistema que lo que cargó quedó cargado, y reportar la cuenta exacta — procesados, fallidos, pendientes.
• Alertas, no silencios: cualquier excepción dispara un aviso inmediato a una persona responsable, con captura de pantalla del momento de la falla para diagnosticar rápido.
• Horario y ritmo humano: correr el bot en ventanas de baja carga y a velocidad razonable evita tanto bloqueos como sospechas en portales de terceros.
• Documento de proceso vivo: cada regla que el bot ejecuta, escrita y con dueño del lado del negocio. Cuando la regla cambie, el cambio entra por ahí y no por un parche de apuro.

La regla de decisión, en una línea

Si el sistema tiene API, integrá por API. Si no la tiene y no podés cambiarlo, RPA — con monitoreo y presupuesto de mantenimiento. Si el sistema es tuyo, arreglá el sistema.

En Deepyze aplicamos esa regla sin fanatismos: construimos integraciones por API cuando la puerta existe, bots a medida cuando no, y sistemas de gestión cuando el software actual es el verdadero problema. Siempre con precio fijo cerrado antes de empezar y un equipo en tu huso horario que mantiene lo que construye. Contanos qué proceso querés automatizar y en 24 horas tenés una propuesta concreta que te dice, con honestidad, cuál de los tres caminos corresponde a tu caso.