Usar o Google reCAPTCHA respeitando a proteção de dados

O Google reCAPTCHA analisa o comportamento do utilizador para a deteção de bots e carrega recursos do Google (EUA), muitas vezes já no carregamento do formulário.

O reCAPTCHA é um caso especial porque a finalidade — proteção contra spam e abuso de bots — pode em princípio basear-se num interesse legítimo nos termos do art. 6.º n.º 1 al. f) do RGPD. Isso não altera nada quanto ao art. 25.º do TDDDG: assim que o reCAPTCHA v2/v3 carrega scripts da Google e define ou lê identificadores para além do tecnicamente necessário, o acesso ao dispositivo está sujeito a consentimento. A jurisprudência ainda é inconsistente aqui; a linha conservadora é incluir o reCAPTCHA no consentimento.

O compromisso prático de muitos operadores: carregar o reCAPTCHA apenas nas páginas que contêm efetivamente um formulário (contacto, início de sessão, registo), e não globalmente através do template. Isto limita a transmissão de dados aos casos em que cumpre um objetivo de proteção concreto e torna a ponderação mais robusta. O reCAPTCHA v3, que corre em todas as páginas para formar uma pontuação, é consideravelmente mais difícil de justificar em termos de proteção de dados.

Existem alternativas mais minimizadoras de dados que evitam totalmente a transferência para a Google: hCaptcha (opção de alojamento na UE), Cloudflare Turnstile (sem captcha visível, sem cookies), Friendly Captcha (alojado na Alemanha) ou — para formulários simples — um honeypot do lado do servidor mais limitação de taxa. Para muitos sites pequenos, a última variante é suficiente e dispensa qualquer transmissão a terceiros.

Isto é um risco?

A proteção contra spam pode ser um interesse legítimo (art. 6.º n.º 1 al. f RGPD). No entanto, se o reCAPTCHA define identificadores não necessários ou carrega em todas as páginas, entra em jogo o § 25 TDDDG. A transferência para os EUA tem de ser fundamentada.

O que pode fazer

• Carregar o reCAPTCHA apenas nas páginas com formulários, não globalmente.
• Ponderar alternativas parcas em dados (p. ex. hCaptcha, honeypot, limites do lado do servidor).
• Na política de privacidade, nomear a finalidade, o fundamento jurídico, o Google como destinatário e a transferência para os EUA.

Häufige Fragen

O reCAPTCHA é permitido sem banner de cookies?

Avaliado de forma inconsistente. Como o reCAPTCHA carrega scripts da Google e trata identificadores, a linha conservadora é incluí-lo no consentimento. Alguns operadores baseiam um uso puramente em formulários num interesse legítimo — isso é um risco.

Que alternativa evita a transferência para a Google?

Cloudflare Turnstile, hCaptcha com alojamento na UE ou Friendly Captcha não transmitem dados à Google. Para formulários simples, basta muitas vezes um honeypot do lado do servidor com limitação de taxa.

Basta carregar o reCAPTCHA apenas nas páginas de formulário?

Reduz consideravelmente a transmissão de dados e reforça a ponderação, mas não elimina totalmente a questão do consentimento nos termos do art. 25.º do TDDDG. O reCAPTCHA v3 a correr globalmente é o mais difícil de justificar.

O que tem de constar da política de privacidade?

Finalidade (proteção anti-spam/bots), base jurídica, a Google como destinatário, a transferência para os EUA e a sua base, além de uma remissão para as próprias condições de privacidade e de utilização da Google.

Como o consentglass ajuda

A análise gratuita verifica o HTML entregue e mostra que serviços estão incorporados, se é detetado um banner de cookies e se as ligações para privacidade e informação legal estão presentes — com enquadramento para cada constatação. Não substitui aconselhamento jurídico.