RPA o integración por API: cuando el robot de pantalla es deuda

La automatización robótica de procesos tiene una mala fama que se merece a medias. La tecnología está bien. El problema es que suele elegirse por la razón equivocada: es lo más rápido de demostrar y no requiere la cooperación de nadie.

Esa segunda propiedad es el atractivo real. Una integración por API exige que el proveedor tenga API, que compras apruebe el acceso y que alguien del otro lado conteste el correo. Un robot manejando la interfaz no exige nada de eso. Entregas en dos semanas sin pedir permiso.

Entonces el proveedor mueve un botón.

Qué estás eligiendo en realidad

La distinción que importa no es "robot o API". Es de qué contrato pasas a depender.

Una integración por API depende de un contrato que el proveedor publica, versiona y le da vergüenza romper. La automatización de pantalla depende del layout de una página, que no es contrato alguno. Es un detalle de implementación que el proveedor cambia sin avisar a nadie, porque de su lado no se rompió nada.

Todo lo demás se deriva de eso.

Situación	Elige	Razonamiento
El proveedor tiene API documentada	API	El robot ahorra semanas ahora y las devuelve en cada release.
Tiene API pero el acceso está bloqueado internamente	API, tras escalar	Es un problema de procesos. Resolverlo con un robot lo vuelve permanente.
Sin API, el proveedor sale en un año	RPA	Uso correcto de una herramienta desechable. Deja por escrito la fecha de retiro.
Sin API, sistema estratégico que se queda	Ninguno todavía	Necesitas un camino real: intercambio de archivos, réplica de lectura o presión al proveedor.
Aplicación heredada interna, con código fuente	API	Añadir un endpoint suele costar menos que mantener un robot un año.
Proceso de 5+ pantallas con juicio humano	Ninguno	Automatizar un mal proceso lo hace más rápido, no mejor. Rediséñalo antes.

El costo que no aparece en la estimación

Una estimación de RPA cubre construir el robot. Rara vez cubre lo que cuesta mantenerlo vivo.

• Cada release de interfaz del proveedor es una caída potencial, y te enteras por una ejecución fallida, no por un changelog.
• El robot necesita credenciales que normalmente usa una persona, lo que significa una cuenta de servicio con los permisos de alguien real, o peor, la contraseña de alguien real.
• Los fallos son silenciosos por defecto. Un robot que hace clic en lo equivocado no lanza una excepción. Termina con éxito y hace algo incorrecto.
• Solo corre donde existe una sesión. Autenticación en dos factores, expiración de sesión y restricciones de IP se vuelven tareas operativas.

Nada de esto es razón para no usar RPA nunca. Son razones para presupuestarlo como un compromiso operativo continuo y no como un proyecto.

Si RPA es la única opción

A veces lo es de verdad. En ese caso, cuatro prácticas separan un robot con el que puedes vivir de uno que se vuelve un pasivo.

Verifica resultados, no pasos. Cuando el robot termine, comprueba el resultado de forma independiente: consulta el registro, revisa el total, confirma que el estado cambió. Un robot que solo sabe "hice clic en las cosas" no puede decirte que falló.

Haz cada ejecución idempotente y reanudable. Los robots mueren a mitad de camino constantemente: sesiones expiradas, navegadores que se caen, máquinas que se reinician. Una ejecución que no puede repetirse con seguridad convierte cada interrupción en limpieza manual.

Dale identidad propia. Una cuenta de servicio dedicada, solo con los permisos del proceso, y credenciales en un gestor de secretos en vez de dentro del script. Esto importa tanto para auditoría como para seguridad, y es parte de lo que cubrimos en nuestras prácticas de seguridad.

Fija una fecha de revisión, no una esperanza de retiro. Pon en el calendario, dentro de seis meses, una sola pregunta: ¿este proveedor ya tiene API? Los robots sobreviven a su justificación porque nadie revisa la decisión.

Dónde cambia el panorama con IA, y dónde no

La automatización basada en visión, que "entiende" la pantalla, sobrevive mejor a pequeños cambios de layout que el scripting por selectores. Es una mejora real a un problema real.

No cambia el asunto de fondo. Sigues dependiendo de una capa de presentación en vez de un contrato, y añadiste un componente cuyo comportamiento es probabilístico. Un robot 97% correcto en un proceso financiero no es 97% bueno. Es un sistema que produce registros equivocados a una tasa constante, y ahora los registros equivocados son más difíciles de predecir.

Si vas a poner un modelo en un lazo operativo, el umbral de confianza y el camino de revisión humana importan más que el modelo, que es el tema de poner un LLM en producción.

El resumen honesto

RPA es una respuesta correcta cuando el sistema objetivo no tiene interfaz y tiene fecha de fin. Es una mala respuesta cuando se elige para evitar una conversación con un proveedor o con otro equipo, porque entonces el robot se vuelve permanente y la conversación nunca ocurre. Ese juicio es parte de lo que trabajamos en proyectos de IA y automatización.

Si lo que mueves son datos y no una interfaz, la pregunta es otra: mira ETL o ELT.