Agentes de navegador y RPA frente a una API: cuándo conducir la pantalla es lo correcto

Hay una generación de herramientas —agentes que conducen navegadores, RPA clásica, modelos de uso de ordenador— cuyo argumento es que automatizan cualquier cosa que una persona pueda hacer en una pantalla. Para los sistemas que de verdad no tienen otra interfaz, eso es una capacidad real y no hay sustituto.

Para todo lo demás, es la forma más cara de hacer algo que podrías hacer con una llamada HTTP.

Usa la API cuando exista

Suena obvio y se ignora, porque el camino de la pantalla se construye antes en una tarde. La comparación no es el tiempo de construcción, es el coste total a dos años.

Una integración por API se rompe cuando el fabricante cambia un contrato documentado, cosa que anuncia y versiona. Una integración por pantalla se rompe cuando el fabricante mueve un botón, cosa que no anuncia, no versionará y puede hacer en una publicación de un martes que solo afecte al grupo de pruebas A/B de tu inquilino. Una de las dos produce un correo de obsolescencia; la otra produce un fallo silencioso en producción.

Comprueba en este orden: API pública, API privada o de partners, base de datos o exportación de ficheros, webhook del fabricante y, por último, la pantalla. En alguno de los cuatro primeros suele haber respuesta, y una exportación más una importación gana a una sesión de navegador más veces de las que la gente espera.

Cuándo conducir la pantalla es genuinamente correcto

Sistemas heredados sin ninguna interfaz. El terminal bancario, el ERP de 1998, el portal de la administración. La RPA clásica existe para esto y funciona. No hay alternativa elegante y la aburrida es una persona reescribiendo a mano.

Fabricantes que esconden la API tras un plan empresarial. A veces las cuentas favorecen la automatización frágil frente a la subida de licencia. Haz las cuentas de forma explícita, incluyendo una estimación de mantenimiento, en vez de ir a la pantalla por defecto porque está disponible hoy.

Trabajo puntual o de vida corta. Una migración que corre dos veces, un relleno histórico, una extracción con fecha límite. Aquí la fragilidad se paga en horas y la cosa se borrará antes de romperse.

Verificación genuinamente visual. Comprobar que una página se renderiza bien, que un flujo se completa de punta a punta. Eso son pruebas, y la pantalla es justo el objetivo.

Hacer que la versión frágil sobreviva

Si te comprometes con el camino de la pantalla:

Ánclate en cosas estables. Etiquetas accesibles, roles e identificadores de prueba estables, en ese orden. Nunca XPaths absolutos ni coordenadas: codifican una maquetación que va a cambiar.

Verifica en cada paso y falla ruidosamente. El fallo catastrófico de la RPA no es una caída, es un bot que hizo clic en lo que no era y siguió con confianza durante doscientos registros. Después de cada acción, afirma que llegó el estado esperado. Un bot parado es una molestia; un bot que continuó es un incidente.

Hazlo idempotente y reanudable. El mismo requisito que en todas partes, con más probabilidad de ejercitarse. Anota lo ya procesado antes de la acción, para que un fallo a mitad reanude en vez de reiniciar: idempotencia y reintentos aplica directamente.

Ejecútalo sin interfaz, en un contenedor y con una programación que controles tú. No en el escritorio de alguien, que es como las instalaciones de RPA acaban dependiendo de que un portátil siga con la sesión abierta.

Gestiona bien las credenciales. Estas automatizaciones inician sesión como un usuario, lo que significa una cuenta real con permisos reales y a menudo sin doble factor, porque el doble factor rompe el bot. Eso es una excepción de seguridad y debería estar escrita, acotada a una cuenta dedicada con el rol mínimo y con sus accesos revisados como cualquier otro camino privilegiado.

Presupuesta el mantenimiento. Una regla aproximada sacada de los proyectos que hemos visto: una automatización por pantalla contra un producto SaaS en desarrollo activo necesita atención cada seis a diez semanas. Contra un sistema heredado congelado, casi nunca. La cadencia de publicación del fabricante es el mejor predictor de tu coste de mantenimiento, y se puede conocer antes de empezar.

Dónde ayuda la parte de IA

Un modelo que lee la página en vez de encajar selectores sobrevive a un rediseño que rompería un bot con guion, y eso es una mejora real de robustez. También es más lento, cuesta por paso e introduce no determinismo en una automatización que al menos era predecible cuando era quebradiza. La combinación pragmática es un camino con guion y un modelo como plan B cuando un selector falla, más una alerta que avise de que el plan B se activó, porque esa alerta es tu aviso temprano de que la interfaz cambió.

Qué hacer esta semana

Lista tus automatizaciones que conducen pantallas y, para cada una, dedica quince minutos a comprobar si el destino ha publicado una API desde que se construyó. Los fabricantes añaden APIs; nadie revisa la decisión. En la mayoría de carteras hay al menos una que puede jubilarse en una llamada HTTP este trimestre.