Un registro de cuenta completo deja claros los límites: rellenar formularios, elegir fechas y leer códigos por correo puede automatizarse, pero la verificación por video selfie detiene el flujo. Entender el coste de cada capa es más realista que perseguir una automatización total.
Quienes trabajan con automatización web suelen partir de una idea optimista: si un proceso se divide en pasos lo bastante pequeños, no debería quedar nada imposible de automatizar.
Al ejecutar un flujo completo de principio a fin aparece otra realidad. Los primeros pasos pueden ir sorprendentemente bien y, al final, el proceso choca con una barrera. Una prueba de registro de cuenta fue representativa: completar el formulario, elegir la fecha, recibir el código de verificación y superar los controles de seguridad funcionó en menos de un minuto. Aproximadamente el 85 % del proceso quedó automatizado. Lo que faltaba era una verificación mediante video selfie frente a la cámara.
Si se separa el flujo por costes, sus límites quedan mucho más claros.
Las acciones deterministas en una sola página suelen ser fiables con scripts
Campos como nombre, correo electrónico, contraseña y fecha de nacimiento forman la capa más estable. Simular la escritura por teclado con una pequeña pausa entre campos lleva unos cinco segundos para todo el paso.
El principal problema es localizar los elementos. Muchos frontends modernos generan campos sin un atributo semántico name, por lo que hay que encontrarlos por índice o por estructura. No es la forma más elegante, pero en un flujo automatizado puede resultar incluso más estable.
Este es el primer tipo de tarea: estructura fija, acción clara y resultado predecible. Dentro de este ámbito, la tasa de éxito de los scripts suele ser alta.
Con componentes personalizados, la estructura de la página se convierte en parte del coste
Las selecciones desplegables, como fecha de nacimiento o género, son donde empieza a consumirse más tiempo.
Lo que parece un menú normal puede ser en realidad un componente personalizado con roles de accesibilidad. Los métodos habituales pueden fallar uno tras otro: no funciona la selección estándar, tampoco localizar por etiqueta de accesibilidad ni hacer clic directamente en el elemento objetivo. La vía estable suele ser reproducir toda la secuencia humana: abrir el desplegable, esperar a que se rendericen las opciones, buscar la opción por texto y hacer clic.
El código puede escribirse en segundos, pero depurarlo puede llevar horas. El límite no depende solo de la habilidad técnica, sino de cuánto coopera la estructura de la página. Con componentes personalizados, abandonar pronto el enfoque convencional suele ahorrar tiempo.
Mantener estado entre sitios es donde el coste empieza a crecer de forma evidente
Cuando el código de verificación llega por correo, la lógica es sencilla: abrir la bandeja, localizar el mensaje más reciente, extraer el código numérico e introducirlo. Todo el paso tarda alrededor de 20 segundos.
El fallo típico es simple pero inevitable: si el script lee un correo antiguo, el código será incorrecto. Por eso hay que seleccionar el mensaje más reciente según la hora.
Después, muchas plataformas redirigen a una página de comprobación adicional y envían otro código. La lógica puede reutilizarse, pero no el valor del paso anterior.
La verdadera dificultad es que hay dos sitios y dos sesiones. Hay que mantener iniciada la sesión del correo, conservar la sesión de la plataforma entre pasos y hacer que la IP del proxy, la zona horaria y el idioma coincidan con el entorno. El coste del estado entre sitios se acumula poco a poco. Cada paso aislado es sencillo, pero al encadenarlos aumenta claramente la tasa de fallos.
Aquí el script solo ejecuta acciones; no puede decidir con qué identidad aparece ante el sitio. La huella del dispositivo y la coherencia entre IP y entorno forman parte de las señales que evalúa la plataforma. Por eso los equipos que gestionan varias cuentas suelen separar el aislamiento del entorno como una capa independiente: cada entorno usa su propia huella e IP. Herramientas como PurpleMark cubren esa capa, mientras el script se limita a actuar dentro de ella.
Cuando hay que entender la página, los scripts puros solo pueden sostenerse a base de ramas
Más adelante cambia la naturaleza del problema.
Si los textos o la estructura varían por cuenta, región o experimento gradual, los selectores codificados de forma rígida empiezan a fallar en grupos. Entonces hay dos caminos: añadir al código todas las ramas posibles, con un mantenimiento cada vez más difícil, o delegar ese paso a un modelo capaz de entender la semántica de la página. El significado de un aviso o de un botón es contexto obvio para una persona, pero ruido para un selector.
Si la plataforma se adapta activamente, los scripts puros vuelven a fallar una y otra vez
Hay otro coste fácil de pasar por alto: la otra parte también cambia.
Las plataformas no miran solo si se puede rellenar un formulario. Pueden valorar si la huella del dispositivo parece normal, si la IP coincide con el entorno, si el comportamiento se parece al de una persona y si hay señales de operaciones masivas. Una actualización de los controles de riesgo puede obligar a rehacer selectores o patrones de comportamiento que funcionaban el día anterior.
Por eso una solución basada únicamente en scripts nunca llega a un estado final definitivo. No es una entrega única, sino un trabajo de mantenimiento continuo.
La verificación facial no es simplemente un problema técnico
La última barrera del flujo exige que una persona real se coloque frente a la cámara, y ahí se detiene la automatización.
Un script puede rellenar formularios, pulsar botones, leer correos e introducir códigos, pero no puede realizar legítimamente una acción que requiera rasgos biométricos de una persona. No se trata solo de falta de capacidad técnica: la finalidad de esa verificación es confirmar que hay un ser humano frente a la pantalla, justo lo contrario del objetivo de automatizar. Las soluciones que prometen automatizar la verificación facial suelen implicar información biométrica falsificada y pueden crear riesgos normativos o legales muy superiores al beneficio.
Aunque un paso sea técnicamente posible, también hay que respetar las condiciones de uso de la plataforma. Muchas plataformas restringen explícitamente el registro automatizado. Esa es una limitación de reglas, no de capacidad técnica.
La conclusión es elegir herramientas por capas, no perseguir la automatización total
Al dividir el proceso por capas, la elección queda mucho más clara:
- Use scripts para páginas fijas y acciones deterministas; suelen ser la opción más barata y estable.
- Si hay que conservar sesiones e inicios de sesión entre varios sitios, gestione el entorno del navegador como una capa independiente y no mezcle esos problemas con la depuración del script.
- Si la estructura cambia y la siguiente acción depende de comprender el significado de la página, un modelo puede ser más práctico que acumular ramas en el código.
- Si un paso requiere una persona real o está expresamente prohibido por las condiciones de uso, no fuerce una automatización de extremo a extremo.
Recorra primero todo el proceso de forma manual para detectar cualquier punto imposible de superar y decida después cuánto desarrollo merece la pena. La automatización ofrece más valor en operaciones repetitivas, deterministas y que no requieren juicio.
