Automatización de ChatGPT y Claude mediante la interfaz web: cómo funcionan la protección antibots y los navegadores antidetección

¿Te gustaría probar Octo Browser con descuento?
Usa el código promocional OCTOBLOG para obtener un 30% de descuento en cualquier suscripción. Esta oferta es válida solo para nuevos usuarios.

Por qué automatizar la interfaz web si existe una API

OpenAI y Anthropic ofrecen API oficiales con documentación detallada. Entonces, ¿por qué crear una infraestructura compleja y enfrentarse a los sistemas de protección? Hay tres motivos:

1. Ahorro a escala. Con una API se paga por cada fragmento de texto procesado. La generación masiva de contenido, la traducción de grandes bases de datos o la ejecución de agentes pueden generar facturas de miles de dólares. Las suscripciones ChatGPT Plus y Claude Pro cuestan $20 al mes cada una; los planes superiores cuestan $200 para ChatGPT Pro y desde $100 para Claude Max. Incluso teniendo en cuenta los límites de mensajes, utilizar el sitio web puede salir varias veces más barato.

2. Funciones que no están disponibles en la API. Los sitios web de IA son sus productos principales. La búsqueda en Internet, la ejecución de código y determinados modelos y herramientas no están disponibles a través de la API o llegan más tarde o con limitaciones.

3. API no oficiales. Gran parte del mercado gris está formado por API no oficiales basadas en sitios web de IA. Los desarrolladores ejecutan cientos de sesiones de navegador, convierten el sitio en una API REST convencional y venden el acceso a una décima parte del precio de los planes oficiales. Así funcionan, por ejemplo, muchos bots de Telegram que ofrecen acceso a modelos de IA sin VPN.

Un escenario habitual: tienes una hoja de cálculo con miles de filas y necesitas una respuesta del modelo para cada una. Hacerlo manualmente no es práctico; la API resulta cara o el modelo que necesitas ni siquiera está disponible. En ese momento, automatizar el sitio web empieza a resultar rentable.

¿Por qué no utilizar Selenium o Puppeteer y escribir un script sencillo? El problema es que las empresas de IA también controlan sus costes. No solo quieren vender suscripciones, sino también trasladar a los clientes empresariales a las API de pago. Por eso, los sitios web de IA cuentan con sistemas de protección sólidos, y un script sencillo con un navegador sin interfaz no basta. De hecho, hoy en día este tipo de scripts tiene dificultades en muchos sitios web.

Por qué no funcionan las herramientas de automatización estándar

Antes de hablar de la solución, veamos cuál es el problema. ¿Qué ocurre si se accede directamente al sitio web de ChatGPT o Claude mediante un script sencillo?

La protección moderna va mucho más allá del bloqueo por dirección IP. Comprueba las solicitudes en varios niveles y detiene la automatización en tres situaciones principales.

Nivel 1. Conexión: scripts sin navegador (requests, axios)

En teoría, una solicitud de un script normal debería rechazarse —con un error 403 o 429— antes incluso de empezar a intercambiar datos. El sistema de protección analiza cómo establece el cliente una conexión segura, es decir, su huella TLS. Cada navegador tiene una firma reconocible: un conjunto y un orden específicos de parámetros que envía al servidor en el primer paquete (Client Hello). En esto se basan las huellas JA3 y JA4. Las bibliotecas de red como OpenSSL o urllib tienen una firma diferente. Si un script se presenta como la versión de escritorio de Chrome, pero establece la conexión como lo haría una biblioteca, el servidor detectará la discrepancia y puede interrumpir la conexión.

En la práctica, la protección es más sutil. Si la dirección IP no está en una lista de bloqueo, el servidor puede responder con 200 OK, pero devolver una página en blanco o una página de comprobación de Cloudflare Challenge en lugar del sitio web operativo. Para continuar, es necesario ejecutar código JavaScript ofuscado. Un script sin navegador no tiene motor JS, así que ahí termina su ejecución.

Ejemplo del funcionamiento de un script sencillo

Nivel 2. Navegador: Puppeteer o Selenium sin modificaciones

Como no se puede prescindir de la ejecución de JavaScript, el siguiente paso lógico es utilizar un navegador headless, es decir, sin interfaz gráfica. Este navegador puede establecer la conexión, cargar la página y ejecutar scripts sin problemas, pero se atasca en la comprobación invisible de Cloudflare Turnstile. Desde fuera, parece una página «Just a moment…» o una casilla de verificación que no deja de girar.

Al revisar las solicitudes de red, puedes observar que el navegador envía telemetría a los endpoints de challenge-platform y recibe respuestas, pero el sistema no llega a emitir la cookie cf_clearance que permite acceder al sitio web.

El problema no está en cómo hace clic el script: todavía ni siquiera hemos llegado a los clics. El propio navegador revela al sistema de protección los indicios de automatización:

• Indicador de automatización. Un navegador controlado por un script se identifica mediante la propiedad navigator.webdriver = true. Selenium funciona mediante WebDriver, mientras que Puppeteer utiliza el protocolo CDP, pero ambos inician el navegador con este indicador activado. Los sistemas de protección lo detectan fácilmente, incluso si intentas ocultarlo con inyecciones sencillas de JavaScript.

• Gráficos sin GPU (WebGL/Canvas). En un servidor o contenedor Docker no hay GPU, por lo que el navegador renderiza los gráficos utilizando la CPU. El sistema de protección solicita información sobre el sistema gráfico y detecta en WebGL Renderer el típico renderizado por software de un servidor: ANGLE sobre SwiftShader. Además, dibuja discretamente una imagen en un elemento Canvas oculto y compara su hash con el valor esperado.

Cuando detecta el indicador de automatización y el renderizado sin GPU, el sistema entiende que está ante un bot que se ejecuta en un servidor.

No te bloquean directamente: te someten a comprobaciones interminables sin llegar a darte acceso al modelo de IA

Nivel 3. Comportamiento: la respuesta se interrumpe

La principal dificultad llega después. La respuesta del modelo se recibe por partes a través de una conexión persistente con el servidor: Server-Sent Events (SSE) o WebSocket. Durante todo ese tiempo, el sistema sigue evaluando la sesión.

Si detecta que el cursor salta instantáneamente hasta los botones necesarios en lugar de moverse con suavidad, aceleración y un ligero temblor, como lo haría una persona, la respuesta puede interrumpirse a mitad de la generación. En el caso de WebSocket, la conexión se cerrará con el código 1006, Abnormal Closure. El cursor es solo un ejemplo: los sistemas de protección analizan muchas más señales.

En el peor de los casos, la cuenta recibe un shadowban. Sigues dentro de la cuenta y el script envía solicitudes POST con prompts, pero la respuesta es un objeto JSON vacío o un mensaje de “error temporal de generación”.

El callejón sin salida de las soluciones estándar

Si juntamos los tres niveles, la conclusión es clara: los clientes HTTP no sirven sin un motor JS, mientras que las herramientas de automatización estándar se delatan mediante el indicador navigator.webdriver, el renderizado gráfico por software y los eventos de entrada sintéticos.

Se puede optar por la vía más sencilla: modificar Selenium o Puppeteer con un par de inyecciones de JavaScript y añadir un servicio para resolver CAPTCHAs. Pero conviene reservar presupuesto para ello, porque habrá muchos CAPTCHAs y, aun así, la configuración no será estable.

Existe otra opción: crear un sistema robusto para trabajar con interfaces web de LLM. Debe ofrecer tres cosas:

1. Un entorno completo. Un motor de navegador real que ejecute las comprobaciones ofuscadas igual que Chrome normal.

2. Control indetectable. El protocolo de control no debe dejar rastros en el objeto window: ni indicadores de automatización ni variables de WebDriver.

3. Coherencia con el hardware. Los hashes de Canvas y WebGL, las fuentes y otros parámetros deben coincidir con la GPU y el sistema operativo declarados, en lugar de revelar un servidor virtual.

¿Cómo se pueden cumplir estos requisitos sin reescribir por cuenta propia el motor Chromium?

Un navegador antidetección como base de la infraestructura de automatización

La solución procede del marketing de afiliados y la gestión de múltiples cuentas: los navegadores antidetección, en este caso Octo Browser. Su principal diferencia frente a Puppeteer parcheado está en el nivel en el que se suplantan las huellas digitales. No se hace mediante scripts de JavaScript, sino en el código fuente del motor Chromium.

Es importante entender que Puppeteer también utiliza el protocolo CDP, así que la diferencia no está en el método de control. Está en el navegador al que se conecta el script. Lo que importa es qué huellas revela y si contiene marcadores de automatización.

¿Qué aporta esto en la práctica?

• Parámetros de GPU plausibles. En lugar de utilizar renderizado por software a través de SwiftShader, el navegador muestra parámetros correspondientes a hardware real: Nvidia, AMD o Apple Silicon. Los hashes de Canvas y WebGL son coherentes con la GPU declarada.

• Aislamiento de perfiles. Cada cuenta de ChatGPT o Claude funciona en un perfil cifrado independiente. Cada perfil tiene sus propias fuentes, configuración de WebRTC y zona horaria.

• Control mediante API local y CDP. No hace falta configurar el entorno en el código. El perfil se inicia mediante la API REST local del navegador y el script se conecta a él a través del puerto CDP.

En esta configuración, un script en Python o Node.js se encarga únicamente de la lógica. Toma los datos de origen, construye un prompt, lo envía a la interfaz web de IA que se ejecuta en el navegador antidetección y recupera el resultado. El entorno preparado es el que permite cumplir los requisitos de los sistemas antifraude.

Arquitectura de la solución: perfiles guardados y conexión mediante CDP

Así, el trabajo con la interfaz web de IA se convierte en un proceso estable en el que el navegador antidetección cumple dos funciones.

1. Entorno de preparación inicial. Abres la interfaz una vez en una ventana de perfil normal y la utilizas como cualquier usuario: inicias sesión manualmente y completas el CAPTCHA si aparece. El navegador guarda las cookies, la caché y los tokens de autenticación en perfiles aislados. Para el servidor, parece una persona normal que simplemente ha cerrado una pestaña.

2. Nodo de la infraestructura. Cuando necesitas ejecutar la automatización, el script inicia el perfil ya preparado mediante la API local y se conecta a él a través de CDP.

El perfil ya tiene la sesión iniciada, así que al acceder a chatgpt.com o claude.ai se abre directamente la interfaz de chat. No hace falta volver a iniciar sesión ni resolver un CAPTCHA: para Cloudflare, es la continuación de una sesión previamente verificada en un dispositivo de confianza. Puede haber varios perfiles de este tipo, cada uno correspondiente a un dispositivo.

Las funciones se distribuyen así: el navegador antidetección suplanta los parámetros de hardware a nivel del motor, conecta los proxies y guarda las cookies; el script envía prompts y recupera respuestas; CDP conecta ambos componentes. En esencia, el navegador se utiliza para su propósito habitual, solo que en lugar de una persona lo controla el código.

Conclusión

Los sistemas de protección de las interfaces web de LLM comprueban a los clientes en tres niveles: cómo establecen la conexión, en qué entorno se ejecutan y cómo se comportan durante la sesión. Por eso, las soluciones puntuales, como los plugins stealth, los parches de JavaScript o los cambios de proxy, ofrecen como mucho resultados temporales. Resuelven una comprobación y dejan las demás sin abordar.

La automatización estable parte del entorno, no del script. Un navegador con huellas coherentes a nivel del motor, perfiles preparados de antemano y control mediante CDP evita que el código tenga que encargarse de ocultar su naturaleza. Al script solo le queda su función directa: enviar prompts y procesar respuestas.

Aun así, conviene valorar los riesgos con realismo. Los sistemas de protección siguen evolucionando y el acceso automatizado a las interfaces web contradice las condiciones de OpenAI y Anthropic. Cualquier configuración de este tipo requiere mantenimiento, y es importante entender cómo funciona el sistema de protección al que te enfrentas.