RPA vs software a medida: cuándo el robot es la respuesta y cuándo es un parche

El RPA —automatización robótica de procesos— hace una cosa muy concreta: un programa maneja la interfaz de otro programa como si fuera una persona. Abre la pantalla, hace clic en el campo, escribe, tabula, aprieta guardar.

Suena a truco y es un truco. Pero es un truco legítimo, y hay situaciones en las que es exactamente lo correcto.

Cuándo el RPA es la respuesta correcta

Cuando el sistema no tiene otra puerta. Un software de 2006 sin API, sin base accesible, sin exportación. El proveedor ya no existe o cobra una fortuna por cualquier cambio. El RPA es literalmente la única forma de sacar o meter datos ahí sin reemplazar el sistema.

Cuando la vida útil es corta y conocida. Vas a migrar ese ERP en diez meses y hasta entonces hay que sostener un proceso manual. Construir una integración seria para algo que se apaga el año que viene no tiene sentido; un robot que aguante diez meses, sí.

Cuando el volumen no justifica un proyecto. Cuarenta registros por semana. Automatizarlos bien cuesta más de lo que ahorra. Un robot armado en tres días paga por sí mismo aunque se rompa cada tanto.

Cuando hace falta demostrar que el proyecto vale. A veces la única forma de conseguir presupuesto es mostrar el proceso funcionando. Un robot como prueba de concepto es una herramienta política perfectamente válida.

Por qué es frágil por diseño

Todo lo que hace fácil al RPA es lo mismo que lo hace frágil: depende de que la pantalla no cambie.

• El proveedor mueve un botón en una actualización y el robot se rompe.
• Un diálogo inesperado —"su contraseña vence en 5 días"— y el robot se queda esperando para siempre.
• El sistema tarda dos segundos más de lo habitual y el robot escribe en un campo que todavía no existe.
• Alguien deja la sesión abierta en esa máquina y el robot hace su trabajo encima.

Y hay un problema más serio que la fragilidad: el robot no valida nada. Copia. Si el dato de origen está mal, lo replica más rápido y con más constancia que un humano, que al menos podría notar que un importe tiene un cero de más.

Después está el costo que nadie proyecta: cada robot necesita mantenimiento cada vez que cambia alguno de los sistemas que toca. Con tres robots es manejable. Con treinta, tenés un equipo entero dedicado a mantener robots, que es exactamente el trabajo manual que querías eliminar, solo que ahora con licencias.

Cuándo conviene construir en serio

Vale la pena hacer la integración de verdad cuando se da alguna de estas:

• El proceso es central y va a seguir existiendo. Si dentro de tres años sigue siendo importante, el robot es deuda técnica que se paga con intereses.
• Hay que validar, no solo copiar. En cuanto aparecen reglas —"si el importe supera X, requiere aprobación"— el RPA se vuelve incómodo y el código se vuelve natural.
• El volumen crece. Un robot es lineal: el doble de registros es el doble de tiempo de pantalla. Una integración procesa mil o cien mil sin cambiar.
• Necesitás trazabilidad. Quién cambió qué, cuándo y por qué. Un robot deja, en el mejor caso, un log de clics.
• Los sistemas sí tienen API. Si la puerta existe, entrar por la ventana es una decisión difícil de defender.

Lo que cambió con la IA

El punto de equilibrio se movió, y bastante.

Buena parte del RPA existía porque construir una integración era caro. Ese costo bajó de forma sustancial: lo que antes eran ocho semanas de desarrollo hoy son dos. Con esa cuenta nueva, muchos casos que hace tres años justificaban un robot ahora justifican hacerlo bien.

Al mismo tiempo, la IA le da al RPA una capacidad que no tenía: entender contenido no estructurado. Un robot que además lee el mail, entiende qué pide y decide a dónde va es mucho más útil que uno que solo repite clics.

Nuestra lectura: el RPA está bien como puente táctico y con fecha de vencimiento explícita. Si el robot no tiene fecha de baja, no es un puente — es la arquitectura de tu empresa, y nadie la eligió.

Una regla práctica

Antes de montar un robot, escribí la respuesta a estas tres preguntas:

1. ¿Cuándo lo apagamos, y qué lo reemplaza?
2. ¿Quién lo arregla el día que se rompa? (Porque se va a romper.)
3. ¿Qué pasa si copia mal cien registros antes de que alguien lo note?

Si las tres tienen respuesta, adelante: es una buena herramienta. Si alguna no la tiene, lo que estás por construir no es una automatización sino un problema futuro con muy buena presentación.

¿No tenés claro de qué lado cae tu caso? Es exactamente el tipo de cosa que resolvemos en un diagnóstico corto.