¿Cumplirá Google reCAPTCHA el GDPR en 2026?

Ilustración que explora el cumplimiento del GDPR de reCAPTCHA mostrando un navegador con consentimiento de cookies, una casilla de verificación “No soy un robot”, conexiones de flujo de datos, un escudo de la UE y una lista de comprobación de privacidad que indica la revisión reglamentaria.
captcha.eu

Si tiene un sitio web en Europa, la actualización reCAPTCHA de Google del 2 de abril de 2026 es importante. A primera vista, el cambio parece tranquilizador: Google afirma que los clientes de reCAPTCHA se convertirán en los únicos responsables del tratamiento de los datos de los clientes, mientras que Google actuará como procesador de datos en virtud de las Condiciones de Google Cloud y el Anexo de procesamiento de datos en la nube. Google también indica que los clientes deben eliminar las referencias a la Política de privacidad y las Condiciones de uso de Google del distintivo reCAPTCHA y de sus sitios web a partir de esa fecha.

Sin embargo, esto no significa que todos los reCAPTCHA se ajusten automáticamente al GDPR de la noche a la mañana. En la práctica, la cuestión para los operadores de sitios web no es si Google “arregló” reCAPTCHA en abstracto. La verdadera cuestión es si su despliegue específico es legal y operativamente defendible.

Esta distinción es importante porque reCAPTCHA suele proteger flujos de trabajo de alto riesgo, como páginas de inicio de sesión, registros, restablecimiento de contraseñas, formularios de contacto y pasos de pago. Google describe reCAPTCHA como una herramienta para la seguridad, el fraude y la prevención de abusos, incluida la protección contra el spam, la creación de cuentas falsas, el relleno de credenciales y formas similares de abuso automatizado. Por lo tanto, si lo eliminas sin un sustituto adecuado, puedes aumentar la exposición a ataques automatizados. Por otro lado, si la mantiene sin revisar los aspectos de privacidad, transferencia, cookies y gobernanza, puede aumentar el riesgo legal y de cumplimiento.



La respuesta corta es simple: reCAPTCHA es más fácil de estructurar bajo GDPR en 2026 que antes, pero todavía no es automáticamente compatible con GDPR por defecto.

El matiz clave es el siguiente: los operadores de sitios web no se convierten en controladores por primera vez en 2026. Según Google, los clientes ya han sido controladores de sus datos de usuario final. Lo que cambia es que Google ya no se posiciona como un controlador independiente adicional para los datos de los clientes de reCAPTCHA. En su lugar, Google afirma que procesará esos datos en el marco contractual de Google Cloud.

Como resultado, mejora la estructura jurídica. Sin embargo, el operador del sitio web sigue teniendo responsabilidades. Los operadores todavía tienen que identificar una base legal, explicar claramente el tratamiento, revisar las transferencias internacionales, evaluar las implicaciones de las cookies o la privacidad electrónica, y asegurarse de que la aplicación sigue siendo proporcional al riesgo abordado.


El cambio legal es claro, pero muchos equipos lo sobreinterpretarán si no tienen cuidado.

A partir del 2 de abril de 2026, Google afirma que reCAPTCHA estará sujeto a las condiciones de Google Cloud y que Google procesará los datos de los clientes como procesador en lugar de como controlador independiente de dichos datos. Al mismo tiempo, Google afirma que los clientes deben eliminar las referencias a la Política de privacidad y las Condiciones de uso de Google de la insignia y de sus propios sitios web, ya que dichas referencias dejarán de reflejar con exactitud las funciones legales. Google también afirma que el cambio de controlador a procesador no requiere cambios inmediatos en el código por sí solo.

Sin embargo, el cambio de 2026 también genera trabajo práctico. La documentación de migración de Google indica que reCAPTCHA Enterprise incluye un nivel gratuito de 10.000 evaluaciones mensuales. Por encima de ese umbral, la facturación pasa a ser relevante. Si los clientes superan las evaluaciones mensuales gratuitas después de la migración automática y no habilitan la facturación, reCAPTCHA devuelve un error para las nuevas solicitudes. Google también documenta un comportamiento de apertura por error para algunas rutas de solicitud de SiteVerify tras superar la cuota, donde las respuestas pueden devolver success:true con una puntuación de 0,9 más un mensaje de error.

Así que, aunque el cambio legal no obliga por sí mismo a cambios inmediatos en el código del frontend, sigue requiriendo la revisión de los equipos legal, de privacidad y operativo. En otras palabras, no se trata sólo de una actualización legal. También es una cuestión de migración, propiedad y gobernanza.


El principal cambio es la responsabilidad.

Antes de 2026, muchos equipos consideraban que reCAPTCHA era en parte “un problema de cumplimiento de Google”. Ahora ese argumento es mucho más débil. Google dice explícitamente que los clientes siempre han sido los controladores de sus datos de usuario final y que, a partir del 2 de abril de 2026, el cliente será el único controlador de los datos del cliente mientras Google procese esos datos en el marco de la nube. Por lo tanto, el operador del sitio web lleva ahora el caso de cumplimiento de forma más visible: la base legal, la transparencia, la configuración contractual, la evaluación de la transferencia y la proporcionalidad se asientan más claramente en el controlador.

A menudo, reCAPTCHA protege los flujos principales de ingresos y cuentas, como la inscripción, el inicio de sesión, el pago, la generación de clientes potenciales y la recuperación de contraseñas. Si esos flujos dependen de claves migradas, propiedad de proyectos, límites de cuota o ajustes de facturación, la privacidad y el tiempo de actividad pasan a estar vinculados. La documentación de migración y facturación de Google hace explícita esa dependencia operativa.


No automáticamente. El cambio de procesador 2026 resuelve un problema estructural importante. Sin embargo, el cumplimiento del GDPR sigue dependiendo de cómo implemente, documente y justifique reCAPTCHA en su sitio web.

El responsable del tratamiento debe determinar la base jurídica, explicar el tratamiento en el aviso de privacidad, evaluar si se está utilizando algún mecanismo de transferencia internacional y revisar si se activan las normas locales sobre cookies o ePrivacy. Google recomienda explícitamente que los clientes revisen sus declaraciones de privacidad dirigidas al usuario final para que describan con precisión la finalidad del tratamiento realizado por reCAPTCHA. Google también confirma que la cookie _grecaptcha permanece tras el cambio de función.

Esta distinción es importante. El análisis GDPR y el análisis ePrivacy sí no responden a la misma pregunta. Incluso si una empresa cree que los intereses legítimos pueden apoyar la seguridad o la prevención de abusos en virtud del artículo 6, apartado 1, letra f) del RGPD, eso no resuelve automáticamente si las cookies o el acceso a dispositivos similares necesitan una evaluación separada en virtud de las normas nacionales de privacidad electrónica. Además, los responsables del tratamiento deben evaluar si podrían lograr el mismo objetivo a través de medios menos intrusivos.

Así que sí, el cambio de 2026 mejora el marco contractual. Pero no, no sustituye la responsabilidad del operador.


Incluso después del 2 de abril de 2026, el operador del sitio web sigue siendo el propietario del caso de cumplimiento en torno a reCAPTCHA.

En la práctica, eso suele significar cinco tareas básicas:

  • Definir y documentar la base jurídica
  • Actualizar el aviso de privacidad
  • Asegúrese de que la configuración contractual de Google Cloud está actualizada
  • Evaluar las transferencias internacionales
  • Revisar si se activan las normas sobre cookies o ePrivacy

Preguntas frecuentes de Google remite a los clientes a sus propios avisos de privacidad y confirma que la capa de cookies sigue vigente tras el cambio de función.

Este punto es aún más importante para las organizaciones que se basan en intereses legítimos. El sitio Directrices EDPB 1/2024 sobre intereses legítimos dicen que deben cumplirse tres condiciones acumulativas: el responsable del tratamiento debe perseguir un interés legítimo, el tratamiento debe ser necesario para ese fin y los derechos y libertades del interesado no deben prevalecer sobre ese interés. Las directrices también indican que los responsables del tratamiento deben comprobar si medios menos restrictivos podrían lograr el mismo resultado con la misma eficacia.

Para la protección de bots, eso significa que la “seguridad” por sí sola suele ser demasiado vaga. Los operadores deben explicar la amenaza concreta a la que se enfrentan, por qué reCAPTCHA es necesario para ese flujo de trabajo, por qué el ámbito de aplicación es proporcionado y qué salvaguardas aplican.


Sí, y esa distinción es importante.

Google documenta diferentes configuraciones de sitios web, incluidas las claves basadas en puntuación, las claves de casilla de verificación y las claves de desafío basadas en políticas. Las claves basadas en puntuaciones funcionan en segundo plano sin un desafío visible, mientras que las implementaciones basadas en casillas de verificación y desafíos son más explícitas. Google también afirma que las claves de sitios web basadas en puntuaciones y retos utilizan datos de interacción para respaldar el análisis de riesgos.

Esa diferencia técnica es importante para el análisis GDPR. Google afirma que las claves basadas en la puntuación funcionan mejor cuando tienen contexto sobre las interacciones en el sitio y recomienda colocarlas en formularios, acciones y en el fondo de todas las páginas web. Por lo tanto, cuanto más amplio sea el despliegue, más se plantearán las cuestiones de necesidad, proporcionalidad y minimización de datos. Esta no es una conclusión jurídica que Google afirme directamente, sino que es la inferencia práctica de cumplimiento cuando la orientación de Google sobre la instrumentación se observa a través de la lente de la necesidad, la proporcionalidad y la minimización de datos.

Así que la respuesta de conformidad no es idéntica para cada configuración de reCAPTCHA. Depende de la versión, el ámbito, el propósito y el patrón de implementación.


Incluso después del cambio de 2026, tres áreas de riesgo siguen siendo especialmente relevantes:

  • Riesgo de base legal: En algunos casos puede haber intereses legítimos, pero sólo si la evaluación está debidamente documentada y el despliegue es realmente necesario y proporcionado.
  • Riesgo de transferencia internacional: El panorama de las transferencias es más estable que inmediatamente después de Schrems II, pero los operadores siguen necesitando una posición documentada y coherente.
  • Riesgo de dependencia operativa: Los problemas de migración, el agotamiento de las cuotas, los vacíos en la propiedad o una mala configuración de la facturación pueden afectar directamente a los flujos de producción.

En resumen, el cambio de procesador elimina un problema estructural importante. No elimina el resto del archivo de cumplimiento y operaciones.


El panorama de las transferencias internacionales en 2026 es más estable que inmediatamente después de Schrems II. Sin embargo, sigue siendo relevante.

La Comisión Europea Orientaciones sobre transferencia de datos UE-EE.UU. explica que, sobre la base de la decisión de adecuación adoptada el 10 de julio de 2023, los datos personales pueden fluir desde la UE a las empresas estadounidenses que participan en el Marco de Privacidad de Datos. Google también declara que Google LLC ha certificado que se adhiere a los Principios del DPF.

Esto mejora sustancialmente la situación de las transferencias. Aun así, no elimina la necesidad de transparencia, responsabilidad y revisión específica de la aplicación. Los controladores siguen teniendo que documentar la configuración que utilizan y explicarla de forma coherente en su expediente de cumplimiento.


Empieza con un inventario. A continuación, avance paso a paso:

  1. Identifique cada punto de contacto reCAPTCHA
    Revise las páginas de inicio de sesión, los flujos de registro, el restablecimiento de contraseñas, los formularios de contacto, los formularios de clientes potenciales, el proceso de pago, la recuperación de cuentas y cualquier implementación en segundo plano.
  2. Revisar el ámbito de aplicación
    Compruebe si reCAPTCHA se limita a las acciones de alto riesgo o si se aplica de forma generalizada en todo el sitio. Esto es importante porque la orientación de Google basada en la puntuación admite la implementación en formularios, acciones y actividad de fondo de la página. Cuanto más amplia sea la implementación, más cuidadosamente deberá justificar su necesidad y proporcionalidad.
  3. Actualizar la documentación sobre privacidad
    Elimina las referencias a la Política de privacidad y a las Condiciones de uso de Google de la insignia y de los sitios web de los clientes, si procede. A continuación, asegúrese de que su propio aviso de privacidad explica la finalidad del tratamiento, la base jurídica, los destinatarios o encargados del tratamiento pertinentes y la posición de transferencia.
  4. Revisar el contrato y la configuración de la transferencia
    Confirme que el servicio se rige por las condiciones pertinentes de Google Cloud y la APD. Si hace referencia al Marco de Privacidad de Datos, compruebe que el estado de participante pertinente sigue activo.
  5. Compruebe si la migración, las cuotas y la facturación están listas
    Confirme el estado de la migración, la propiedad de las claves, la configuración del proyecto, la exposición de las cuotas y la preparación de la facturación. Incluso cuando no se requiere código nuevo, una configuración deficiente de Cloud puede provocar tiempos de inactividad, una protección contra bots degradada o fallos inesperados en las solicitudes. La documentación de Google es explícita en cuanto a que el uso superior a 10.000 evaluaciones mensuales depende de la configuración del proyecto y del estado de facturación.

Para muchas organizaciones, reCAPTCHA puede seguir siendo una opción viable en 2026. La estructura jurídica es mejor que antes y el panorama de las transferencias es más manejable que durante el periodo más incierto posterior a Schrems II.

Sin embargo, la cuestión estratégica ha cambiado. La cuestión ya no es sólo si reCAPTCHA puede detener a los bots. En su lugar, las empresas deben decidir si el paquete completo, como el análisis de base legal, las actualizaciones de transparencia, la revisión de cookies, la revisión de transferencias, la supervisión de la migración, la gobernanza de la facturación y el alcance de la implementación, es proporcional al riesgo y merece la pena el gasto general.

Por eso, muchas organizaciones europeas sensibles a la privacidad comparan no sólo la calidad de la detección, sino también la minimización de datos, el modelo de alojamiento, la complejidad jurídica y el control operativo. Si su objetivo es una sólida protección contra bots con menos sobrecarga de cumplimiento, puede tener sentido evaluar si una El primer proveedor europeo de CAPTCHA como captcha.eu se ajusta mejor a su modelo de gobernanza.


Google reCAPTCHA está en una mejor posición legal en 2026 que antes. Sin embargo, sigue siendo no automáticamente conforme al GDPR por defecto.

El cambio del 2 de abril de 2026 elimina un importante problema estructural al pasar Google a desempeñar el papel de procesador de los Datos de Cliente de reCAPTCHA en el marco de Google Cloud. Aun así, la carga de la justificación sigue recayendo en el operador del sitio web. Esto significa que la base legal, la divulgación de la privacidad, el análisis de las transferencias, la revisión de las cookies, la preparación para la migración y el control de la facturación aún deben gestionarse adecuadamente.

Por tanto, la cuestión estratégica para las organizaciones ya no es sólo si reCAPTCHA puede detener a los bots. La cuestión más relevante es si el paquete legal y operativo completo es proporcionado, defendible y merece la pena.


¿El cambio 2026 de Google hace que reCAPTCHA cumpla automáticamente el GDPR?

No. La estructura jurídica mejora, pero los operadores siguen necesitando una base legal, divulgaciones actualizadas, análisis de transferencias y un despliegue que puedan justificar.

¿Necesitan los operadores de sitios web actualizar su política de privacidad?

En la mayoría de los casos, sí. Google recomienda explícitamente que los clientes revisen sus declaraciones de privacidad dirigidas al usuario final, y afirma que las referencias a la Política de privacidad y las Condiciones de uso de Google deben eliminarse de la insignia y de los sitios web de los clientes a partir del 2 de abril de 2026.

¿Permanece la cookie _grecaptcha tras el cambio de procesador?

Sí. Google dice explícitamente que la cookie _grecaptcha permanece y no se ve afectada por el cambio de rol.

¿Afecta esto a reCAPTCHA v2, v3 y Enterprise de la misma manera?

No del todo. Google documenta diferentes tipos de claves y patrones de despliegue, y los despliegues más amplios basados en puntuaciones plantean diferentes cuestiones de necesidad y proporcionalidad que las implementaciones limitadas basadas en desafíos.

¿Pueden las empresas invocar intereses legítimos para reCAPTCHA en 2026?

A veces, pero no automáticamente. Las orientaciones 2024 del OEPD exigen una evaluación estructurada del interés legítimo, la necesidad y el equilibrio. También dice que los responsables del tratamiento deben considerar si medios menos intrusivos podrían lograr el mismo resultado con la misma eficacia.

¿Está totalmente resuelto el problema de la transferencia gracias al Marco de Privacidad de Datos?

No. El DPF mejora la posición de transferencia materialmente, y Google LLC dice que se adhiere a los Principios DPF. Sin embargo, los operadores todavía tienen que documentar y explicar adecuadamente su propia configuración.

¿Qué deben hacer los operadores de sitios web antes del 2 de abril de 2026?

Revise el alcance de la implementación, actualice las declaraciones de privacidad, confirme la migración y la propiedad de Google Cloud, evalúe las cuotas y la facturación, documente la base legal y vuelva a comprobar la posición de transferencia.

es_ESSpanish