El screen scraping se tacha rápido de retroceso. Solo está justificado cuando un sistema no tiene interfaz. Cuándo se aplica y cuándo no.
El screen scraping tiene mala reputación, y la mayoría de las veces con razón. Cuando un robot de software se abre paso haciendo clic en pantallas en lugar de obtener datos a través de una interfaz, rara vez es la solución más limpia. Aun así, en la pequeña y mediana empresa existen procesos en los que ese es precisamente el único camino. La pregunta decisiva no es si el método parece anticuado, sino si el sistema de destino tiene una interfaz utilizable.
El screen scraping designa la lectura y el manejo automatizados de una aplicación a través de su interfaz de pantalla: un robot mueve el puntero del ratón, rellena campos y lee valores de la pantalla, tal como lo haría una persona. Una integración API evita la interfaz y se comunica directamente con la interfaz de datos del sistema.
Microsoft resume la diferencia en su documentación de Power Automate con una fórmula concisa: con una API se le dice a la aplicación qué hacer, con la interfaz se le muestra (Tipos de automatización de procesos, Microsoft Learn). Solo una de las dos es un acuerdo vinculante. Una interfaz es una promesa del fabricante de que los campos y formatos se mantendrán. Una pantalla no es esa promesa.
La recomendación es inequívoca, y proviene de los propios fabricantes de RPA. Microsoft aconseja elegir la automatización basada en API para toda aplicación que cuente con un conector API disponible, porque las interfaces deben permanecer estables aunque la aplicación cambie.
Según el fabricante, Power Automate cubre más de 380 aplicaciones con conectores API ya preparados, a los que se suman conectores personalizados para cualquier sistema con una API disponible (Microsoft Learn). La automatización a través de la interfaz no es, por tanto, una alternativa equivalente a la integración API, sino la salida de emergencia documentada. Quien recurre primero al robot compra una carga de mantenimiento que nadie pidió.
El precio a pagar es la carga de mantenimiento, y está bien documentada. Las automatizaciones a través de la interfaz dependen de selectores, es decir, de la descripción técnica de dónde se encuentra un elemento y cómo se llama. Si esa descripción cambia, el robot ya no encuentra el elemento y la ejecución falla.
Para los flujos de escritorio ejecutados sin supervisión, Microsoft enumera seis factores que pueden inutilizar un selector: la resolución de pantalla y el escalado DPI, las actualizaciones de la aplicación, la versión del sistema operativo, el tamaño de la ventana, el estado de un elemento y los permisos del usuario conectado (Solución de problemas de ejecución sin supervisión, Microsoft Learn). Ninguno de estos puntos tiene relación con el proceso de negocio. El proceso sigue siendo igual de correcto, la automatización tropieza con el envoltorio.
UiPath describe el mismo problema desde otro ángulo: los selectores clásicos se basan en atributos y jerarquías rígidas, por lo que basta con una etiqueta modificada, un ID de elemento dinámico o un nuevo tema para detener la automatización. El propio fabricante califica de alta esta carga de mantenimiento (Acerca de los selectores semánticos, UiPath Docs). Con una integración API no existe ninguno de estos problemas. A una interfaz no le importa la resolución de pantalla.
El screen scraping es el medio adecuado cuando un sistema no tiene ninguna interfaz utilizable y solo puede manejarse a través de su pantalla. Microsoft precisa la condición en su documentación de licencias: se necesita RPA para aplicaciones para las que no existe ni un conector ya preparado ni una API a partir de la cual se pueda construir uno propio.
En la práctica, esto se aplica a cinco situaciones:
El último punto se pasa por alto con frecuencia: el enfoque es una tecnología puente legítima. Solo se convierte en un problema cuando el puente se convierte en un estado permanente y ya nadie sabe por qué sigue ahí. La propia cuestión de la herramienta la analizamos en nuestra prueba práctica de n8n y Power Automate.
Entonces también hay que incluir en el cálculo los costes de licencia que desaparecen con la variante API. Con Power Automate, cada máquina que ejecuta flujos de escritorio sin supervisión necesita una licencia Process, y para Microsoft 365 además una licencia Unattended (Microsoft Learn). Desde el punto de vista de las licencias, el robot es un usuario más. Hemos desglosado los componentes de licencia de UiPath en nuestro artículo sobre licencias de UiPath para pymes.
Antes de cualquier decisión sobre RPA debe hacerse una comprobación que suele llevar media hora y que con frecuencia hace innecesario al robot. A menudo existe una interfaz, solo que se llama de otra manera. Cuatro preguntas lo aclaran:
Si aun así la decisión recae en el robot, la justificación debe quedar por escrito. Para una administración municipal presentamos exactamente esta evaluación en julio de 2026 y desaconsejamos convertir la RPA en el fundamento de la estrategia de automatización: sí como complemento puntual, no como base. La herramienta no era mala, simplemente no encajaba con la tarea. Esta evaluación es el verdadero contenido de un servicio de consultoría de interfaces e integración.
El web scraping lee contenido de páginas web, normalmente a través del código fuente HTML, y para ello no necesita ninguna interfaz visible. El screen scraping maneja la aplicación tal como la ve una persona, e incluye programas de escritorio, sesiones de terminal y de Citrix.
Técnicamente sí, contractualmente depende. Algunos fabricantes de software excluyen el manejo automatizado en sus condiciones de uso o lo condicionan a licencias adicionales. Antes de construir un robot conviene comprobar las condiciones de licencia del sistema de destino, y en caso de duda, con asesoramiento legal.
No, pero el riesgo no se puede eliminar programando. Una actualización que solo cambia la lógica de negocio deja al robot intacto. En cuanto cambian las etiquetas, la disposición de las ventanas o los ID de los elementos, los selectores se quedan sin nada que agarrar. Quien utiliza RPA debe planificar el mantenimiento como algo fijo, en lugar de tratarlo como una incidencia.
Lo atenúan, no lo eliminan. Fabricantes como UiPath trabajan en selectores que reconocen un elemento por su significado en lugar de por su posición. Esto reduce la carga de mantenimiento, pero no cambia el hecho de que la automatización depende de una interfaz que nadie mantiene contractualmente estable.
Fundador de NordFlux. Siete años de experiencia, desde la web y el SEO hasta la automatización a escala de grupo, hoy de forma pragmática para las pymes y con soberanía de datos alemana.
Certificaciones
Automatizar SAP a través de Citrix: por qué fallan los selectores de UiPath en sesiones virtuales y qué enfoques se mantienen realmente estables en la práctica.
El propio SAP menciona los bots RPA en el Digital Access. Qué significa esto para el RPA en SAP y Business One, y cuándo la propia pila de SAP es el camino más corto.
Studio, Robots, Orchestrator, Platform Units: lo que una pyme realmente necesita de UiPath, cuánto cuesta y cuándo otra herramienta resulta más barata.
El screen scraping parece la única opción cuando falta una interfaz, pero rara vez es la más económica. Analizamos su panorama de sistemas en busca de API disponibles y, solo donde realmente no existe ninguna interfaz, construimos una solución RPA robusta que resiste la próxima actualización.
