Screen Scraping o API: cuándo la RPA sigue siendo realmente necesaria

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.

¿Qué es el screen scraping y en qué se diferencia de una integración API?

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.

API o screen scraping: lo que recomiendan los propios fabricantes

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ó.

Por qué el screen scraping resulta más caro de mantener

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.

¿Cuándo es realmente el screen scraping la opción correcta?

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:

• Aplicaciones antiguas sin API: software sectorial heredado que nunca se pensó para la integración.
• Aplicaciones de terminal y Citrix: cuando solo llega una imagen de pantalla, técnicamente no hay nada más a lo que agarrarse que la pantalla misma.
• La interfaz está bloqueada: algunos fabricantes licencian el módulo API por separado o directamente no lo ponen a disposición de clientes pequeños. Entonces la cuestión es comercial, no técnica.
• La API no cubre el proceso: una interfaz que solo lee no ayuda con la operación de escritura necesaria.
• El período de transición antes de una sustitución: si el sistema va a sustituirse en uno o dos años, una integración limpia a menudo ya no compensa. Un robot construido deliberadamente como solución desechable es entonces la inversión más honesta.

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.

¿Cómo se comprueba si realmente no hay ninguna interfaz?

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:

• ¿Qué dice la documentación del fabricante? los módulos API suelen aparecer en la documentación técnica mucho antes de figurar en la oferta comercial.
• ¿Existe una exportación de datos? la interfaz menos espectacular es una exportación CSV o XML programada. Es estable, está documentada y no cuesta nada.
• ¿Es posible un acceso de solo lectura a la base de datos? para fines de análisis suele ser totalmente suficiente.
• ¿Cuánto cuesta el módulo de interfaz? como coste único suele ser más barato que tres años de mantenimiento del robot.

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.

Preguntas frecuentes

¿Cuál es la diferencia entre screen scraping y web scraping?

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.

¿Está permitido el screen scraping?

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.

¿De verdad se rompe el screen scraping con cada actualización?

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.

¿Resuelven el problema los selectores basados en IA?

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.