La deuda técnica oculta de los bots de RPA

Un equipo puede tener cien bots de RPA funcionando de maravilla un viernes y, el lunes, descubrir que la mitad dejó de andar. No los tocó nadie. Lo único que pasó es que un proveedor SaaS lanzó un rediseño de su interfaz durante el fin de semana.

Esa fragilidad no es un bug: es una propiedad inherente de cómo funciona RPA. Y entenderla te ahorra el dolor de comprar la promesa de "automatizá y olvidate".

Por qué el bot se rompe con un cambio cosmético

Un bot de RPA se ata a la interfaz gráfica, no a los datos por debajo. Localiza un botón por su posición, su texto, su id en el DOM o incluso por una imagen de píxeles. Todos esos anclajes son volátiles:

• El botón "Guardar" pasa a llamarse "Confirmar" → el selector por texto falla.
• Una columna nueva corre todo medio centímetro a la derecha → el click por coordenadas erra.
• El sitio migra de tabla HTML a un componente moderno → el selector del DOM ya no existe.

Ninguno de estos cambios afecta a un humano: vos seguís viendo el botón y lo apretás. Pero el bot no "ve", sigue una receta exacta. Por eso se dice que RPA automatiza por la ventana y no por la puerta —el contraste fino está en RPA vs API.

La deuda se acumula sin que la veas

Acá está lo traicionero. Cada bot nace prolijo. El problema es el efecto acumulado:

1 bot   → 1 superficie que vigilar
50 bots → 50 superficies, cada una con su propio dueño que puede cambiarla sin avisarte

A esto se suma una capa de excepciones parche. Cada vez que el bot encuentra un caso raro —un pop-up de sesión expirada, un mensaje de mantenimiento— alguien le agrega un if para sortearlo. Con el tiempo, ese script de "automatización simple" se convierte en una maraña de condiciones que nadie se anima a tocar. Es deuda técnica clásica, pero invisible: no está en un repo que revisás, está enterrada en un orquestador y solo aparece cuando explota en producción.

Cómo convivir con la fragilidad

No es un argumento para no usar RPA. Es un argumento para usarlo con los ojos abiertos y un costo de mantenimiento presupuestado desde el día uno:

• Tratá los bots como software, no como macros. Control de versiones, code review, ambiente de testing. Un bot es código que corre en producción.
• Anclá a lo más estable que puedas. Un id semántico aguanta más que una coordenada de píxel; un atributo de accesibilidad más que un texto de UI.
• Monitoreá activamente. Un bot que falla en silencio es peor que uno que no existe: estás confiando en datos que no se movieron. Acá ayuda diseñar con idempotencia, para que un reintento no duplique ni corrompa.
• Tené un plan de salida. Si el sistema destino ofrece una API, migrá hacia ella apenas puedas. Y cuando una tarea de verdad necesita criterio, no la parchees con más if: ese es el límite donde conviene sumar IA y orquestación.

RPA es genial para tapar el hueco que dejan los sistemas que no se hablan entre sí. Pero es un parche sobre la interfaz, y los parches se despegan. La pregunta no es si tu bot se va a romper, sino cuándo y cuánto te va a costar enterarte. Presupuestá ese mantenimiento antes de firmar el ROI: muchos proyectos de RPA fracasan no porque el bot no funcione, sino porque nadie contó cuánto cuesta mantenerlo vivo.