Usar Google reCAPTCHA respetando la protección de datos

Google reCAPTCHA analiza el comportamiento del usuario para la detección de bots y carga recursos de Google (EE. UU.), a menudo ya al cargar el formulario.

reCAPTCHA es un caso especial porque la finalidad — protección frente al spam y al abuso de bots — puede en principio basarse en un interés legítimo conforme al art. 6.1.f RGPD. Eso no cambia nada respecto al art. 25 TDDDG: en cuanto reCAPTCHA v2/v3 carga scripts desde Google y establece o lee identificadores más allá de lo técnicamente necesario, el acceso al terminal está sujeto a consentimiento. La jurisprudencia sigue siendo inconsistente aquí; la línea conservadora es incluir reCAPTCHA en el consentimiento.

El compromiso práctico de muchos operadores: cargar reCAPTCHA solo en las páginas que realmente contienen un formulario (contacto, inicio de sesión, registro), y no globalmente vía la plantilla. Esto limita la transmisión de datos a los casos en que cumple un objetivo de protección concreto y hace la ponderación más sólida. reCAPTCHA v3, que corre en todas las páginas para formar un score, es bastante más difícil de justificar en términos de protección de datos.

Hay alternativas más minimizadoras de datos que evitan por completo la transferencia a Google: hCaptcha (opción de alojamiento en la UE), Cloudflare Turnstile (sin captcha visible, sin cookies), Friendly Captcha (alojado en Alemania) o — para formularios simples — un honeypot del lado del servidor más limitación de tasa. Para muchos sitios pequeños basta la última variante y funciona sin ninguna transmisión a terceros.

¿Es un riesgo?

La protección contra el spam puede ser un interés legítimo (art. 6 apdo. 1 letra f RGPD). Sin embargo, si reCAPTCHA establece identificadores no necesarios o se carga en todas las páginas, entra en juego el § 25 TDDDG. Hay que justificar la transferencia a EE. UU.

Qué puedes hacer

• Cargar reCAPTCHA solo en páginas con formularios, no de forma global.
• Considerar alternativas respetuosas con los datos (p. ej. hCaptcha, honeypot, límites de tasa del lado del servidor).
• En la política de privacidad, nombrar la finalidad, la base jurídica, a Google como destinatario y la transferencia a EE. UU.

Preguntas frecuentes

¿Está permitido reCAPTCHA sin banner de cookies?

Se juzga de forma inconsistente. Como reCAPTCHA carga scripts desde Google y trata identificadores, la línea conservadora es incluirlo en el consentimiento. Algunos operadores basan un uso puramente en formularios en un interés legítimo — eso es un riesgo.

¿Qué alternativa evita la transferencia a Google?

Cloudflare Turnstile, hCaptcha con alojamiento en la UE o Friendly Captcha no transmiten datos a Google. Para formularios simples suele bastar un honeypot del lado del servidor con limitación de tasa.

¿Basta con cargar reCAPTCHA solo en las páginas de formulario?

Reduce considerablemente la transmisión de datos y refuerza la ponderación, pero no elimina del todo la cuestión del consentimiento conforme al art. 25 TDDDG. reCAPTCHA v3 corriendo globalmente es lo más difícil de justificar.

¿Qué debe ir en la política de privacidad?

Finalidad (protección anti-spam/bots), base jurídica, Google como destinatario, la transferencia a EE. UU. y su base, además de una referencia a las propias condiciones de privacidad y de uso de Google.

Cómo ayuda consentglass

El análisis gratuito comprueba el HTML entregado y muestra qué servicios están integrados, si se detecta un banner de cookies y si hay enlaces a la privacidad y al aviso legal — con contexto para cada hallazgo. No sustituye el asesoramiento jurídico.