RPA — automatización robótica de procesos — es software que opera otro software a través de su interfaz. Abre el portal, inicia sesión, busca el campo, escribe el valor, pulsa guardar. Es rápido, no se aburre y puede trabajar con un sistema que no tiene API ni exportación alguna. Esa última parte es toda la razón de su existencia.
Un modelo de lenguaje hace algo distinto: convierte entrada sin estructura en estructura. Con un correo, un albarán escaneado o la transcripción de una llamada, produce campos con los que se puede actuar. No hace clic en nada y no mueve datos entre sistemas. Son dos capacidades complementarias, no alternativas, y por eso la pregunta tal como suele plantearse no tiene respuesta.
Casi todo proceso que nos piden automatizar llega con un supuesto ya puesto: alguien decidió que era trabajo de RPA, o de IA, antes de mirar qué pueden hacer los sistemas. Sale más barato recorrer tres opciones en orden.
Una API o la base de datos. Si ambos sistemas la exponen, esa es la respuesta. Es más rápida, más barata de operar, sobrevive a un rediseño de interfaz y falla en voz alta. Compruébalo antes que nada, incluso con proveedores que no la anuncian.
Un fichero que el sistema ya genera. Una exportación nocturna, un informe, un CSV que alguien descarga a mano. Poco elegante y completamente fiable, y elimina la mayor parte de los motivos para manejar una pantalla.
Y luego el robot. La automatización a nivel de pantalla es lo que queda cuando de verdad no hay otra forma de alcanzar el sistema. Es una opción legítima: simplemente es la tercera, no la primera.
Un modelo puede vivir dentro de cualquiera de las tres, y normalmente ahí vive: lee lo que llega como lenguaje y entrega campos estructurados al paso que mueve los datos.
Hay trabajo que no puede hacer otra cosa. Sistemas heredados con interfaz de terminal y ningún proveedor a quien preguntar. Portales públicos y bancarios que no publican API y nunca lo harán. Aplicaciones de escritorio cuya licencia prohíbe el acceso directo a la base de datos. En esos casos un robot en la pantalla no es un compromiso: es el único camino, y puede ser muy bueno.
Donde se tuerce es en el alcance. Un bot que entra en un portal, descarga un extracto y lo deja en una carpeta funcionará durante años. Un bot que recorre catorce pantallas en cuatro sistemas, cada uno mantenido por alguien que rediseña sin avisar, se convierte en un trabajo de mantenimiento que cuesta en silencio más que la tarea que sustituyó.
RPA se rompe con el diseño. Un botón movido, un nuevo diálogo de consentimiento, una página lenta, un paso extra de confirmación: el robot no entiende la pantalla, sigue coordenadas y selectores. Las actualizaciones del proveedor son su enemigo natural.
El modelo se rompe con la confianza. No se detiene cuando duda; produce una respuesta fluida, plausible y equivocada. Eso se gestiona con umbrales, referencias a la fuente y una vía hacia una persona, no con esperanza.
RPA falla a la vista, el modelo en silencio. Un bot parado es una alerta. Un campo mal leído entra en tu contabilidad y aparece en el cierre de mes. El segundo modo exige el diseño más cuidadoso.
Ambos fallan con la política sin decidir. Si nadie ha escrito qué pasa con una excepción, ninguna tecnología inventará la respuesta. Es una decisión de gestión disfrazada de asunto técnico.
Escribe los pasos de un proceso y marca en cada uno qué necesita: mover datos o interpretar algo. Después, para cada paso de mover datos, pregunta si ya existe una API o una exportación — pregúntalo al proveedor directamente, porque muchas veces no está en la documentación. Lo que quede tras esas preguntas es la superficie honesta de RPA, y suele ser mucho menor de lo que parecía.
En nuestra experiencia la respuesta es una integración pequeña más un modelo en el paso o dos que leen lenguaje, sin robot alguno. Cuando el robot hace falta de verdad, lo mantenemos en el tramo más estrecho posible — un sistema, un recorrido de pantallas — para que un rediseño cueste una tarde y no una reconstrucción.
Hacemos este mapa gratis en una miniauditoría: los pasos, qué necesita cada uno, qué sistemas tienen una API que no sabías que existía y qué haría falta para funcionar sin robot de pantalla.
Conectar los sistemas bien, para que nadie tenga que manejar una pantalla.
La pregunta vecina, con la misma respuesta: reglas o criterio.
Un ejemplo resuelto: leer el documento, registrar el asiento, marcar el desajuste.
Usamos cookies solo para analítica: para ver desde qué páginas llegan las consultas. Nada más, y nada antes de que aceptes. Política de cookies