La detección de AI Agents evoluciona: cuatro claves de consistencia del cliente

Durante el último año, los AI Agents se han integrado cada vez más en los flujos de negocio: desde invocar herramientas del navegador hasta iniciar sesión en sistemas internos, procesar pedidos y responder correos. Al mismo tiempo, los sistemas de control de riesgo están cambiando su forma de evaluar la actividad: ya no observan solo un atributo del navegador, sino la sesión completa.

La detección pasa de atributos aislados a toda la sesión

Cuando las plataformas describen sus capacidades de detección de IA, mencionan señales de comportamiento a lo largo de toda la sesión: si el movimiento del puntero es demasiado regular, si la velocidad y el ritmo de escritura resultan anómalos, si siguen produciéndose entradas cuando la página no tiene el foco, si hay actividad del puntero cuando la página no es visible y si todo el proceso mantiene coherencia de principio a fin.

Estas señales tienen algo en común: no dependen de que un parámetro concreto sea verdadero o falso, sino de la continuidad a lo largo del tiempo. Por eso, alterar un solo atributo sirve de poco frente a este tipo de evaluación.

Fuera de la sesión existe otra capa de correlación

Además de las señales de comportamiento, los controles de riesgo pueden evaluar conjuntamente el entorno del navegador, las cookies, el estado de inicio de sesión, el entorno de red y el historial de la cuenta: si el entorno se mantiene consistente, si cookies, almacenamiento local y sesión tienen continuidad, si el entorno cambia con demasiada frecuencia, si la red presenta saltos anómalos, si varias cuentas comparten el mismo entorno de navegador y si el comportamiento encaja con un flujo de negocio normal.

Estas comprobaciones pueden dividirse en dos capas. Una es el entorno de ejecución del navegador, que determina si el entorno y el estado de sesión pueden conservar continuidad. La otra es la estrategia de ejecución del Agent, que influye en si el conjunto de acciones parece automatizado. Si falla cualquiera de las dos, resulta difícil mantener una ejecución estable.

Por qué las incoherencias del entorno pueden interpretarse como automatización

Pensarlo al revés ayuda. Una persona real que visita un sitio con un dispositivo deja muchas pistas coherentes entre sí: si la IP de salida está en una región, la zona horaria del sistema debería estar cerca; el idioma habitual debería guardar una relación razonable con la región de la IP; la resolución de pantalla, la lista de fuentes y la información de la GPU deberían ser compatibles; y las cookies y el estado de inicio de sesión deberían cambiar gradualmente con el tiempo, no comenzar desde cero en cada visita.

La incoherencia es, por sí misma, una anomalía. Una salida en Fráncfort con la zona horaria del navegador en Los Ángeles; un conjunto de fuentes y resolución esta hora y otro distinto la siguiente; cinco cuentas iniciadas en diez minutos dentro del mismo entorno. Por separado ya son situaciones sospechosas; juntas, resultan difíciles de explicar como comportamiento humano normal.

La lógica de la plataforma es sencilla: los usuarios normales no suelen actuar así. Por tanto, el coste de mantener la consistencia recae en el cliente.

Cuatro áreas que el cliente puede preparar

Primero, coherencia interna del entorno: zona horaria, idioma, resolución, fuentes, GPU y otros parámetros no deben contradecirse entre sí.

Segundo, independencia entre entornos: cada tarea debe contar con su propio directorio de datos, sus propios parámetros y su propia salida de red, para evitar que varias identidades queden vinculadas al mismo entorno de dispositivo.

Tercero, continuidad del estado: cookies, almacenamiento local y estado de inicio de sesión deben guardarse por separado para cada entorno y restaurarse tras un reinicio, en vez de iniciar sesión desde cero cada vez.

Cuarto, alinear la salida con los parámetros geográficos: si la salida cambia a otro país, la zona horaria y el idioma del entorno deberían cambiar con ella para evitar contradicciones prolongadas.

Los dos primeros puntos pertenecen principalmente a la capa del entorno. Los dos últimos se reparten entre la capa del entorno y la lógica de planificación. Cuando un equipo ejecuta decenas de Agents a la vez, estas necesidades suelen concentrarse en la gestión de entornos, donde se administran conjuntamente entornos aislados, salidas independientes y configuración masiva. PurpleMark es una de las herramientas que ofrecen esta capa.

Algunos métodos antiguos ya funcionan peor

Cambiar solo el User-Agent es una práctica común, pero si las características subyacentes no cambian, la contradicción entre el UA y el entorno real se vuelve aún más evidente. Cambiar únicamente la IP tiene el mismo problema: las características del dispositivo y el ritmo de comportamiento siguen iguales, por lo que otra salida no resuelve la cuestión. El modo incógnito afecta al almacenamiento local, no a las características del dispositivo.

Tampoco compensa colocar varias tareas en un mismo entorno. Cuando se ejecutan en paralelo, pueden sobrescribir cookies y estados de inicio de sesión, y varias identidades procedentes de un mismo entorno constituyen por sí solas una señal de correlación. Del mismo modo, alargar todas las esperas a un valor fijo introduce una regularidad que también puede identificarse.

Criterios de evaluación

En lugar de obsesionarse con si las características están suficientemente ocultas, conviene plantear otra pregunta: ¿el entorno tiene coherencia interna, los entornos son independientes entre sí y el ritmo de comportamiento se parece al de una persona real? Solo cuando se cumplen las tres condiciones puede hablarse de una ejecución estable.

Límites

Superar la detección no equivale a tener permiso para operar. Respete los términos de servicio y las reglas robots de la plataforma objetivo, no utilice identidades falsas, no eluda medidas técnicas de protección, controle la frecuencia de las solicitudes y no interfiera con el funcionamiento normal del servicio ajeno.