GDPR Consent — essência, requisitos e obtenção de consentimento

O que é o GDPR Consent?

GDPR Consent é um fundamento jurídico para o tratamento de dados pessoais, definido no artigo 4.º(11) e artigo 7.º do Regulamento Geral de Proteção de Dados da União Europeia. O regulamento entrou em vigor em 25 de maio de 2018 e substituiu a obsoleta Diretiva 95/46/CE, estabelecendo normas uniformes de proteção de dados para todos os Estados-Membros da UE.

De acordo com o GDPR, o consentimento deve ser livre — o utilizador deve ter uma escolha real sem consequências negativas pela recusa. Se a recusa do consentimento resultar na negação do acesso a um serviço que não requer tratamento de dados, esse consentimento é considerado forçado e inválido. O artigo 7.º(4) indica diretamente que as condições contratuais relacionadas não podem condicionar a execução do contrato à obtenção de consentimento para tratar dados que não são necessários para esse contrato.

Informado — o segundo elemento-chave: o titular dos dados deve compreender que dados específicos são recolhidos, para que finalidade, quem os tratará e por quanto tempo serão armazenados. O Comité Europeu para a Proteção de Dados (EDPB) nas orientações 05/2020 sublinha que as informações devem ser fornecidas numa linguagem clara, sem formulações jurídicas complexas. A prática mostra que o consentimento é considerado inválido se a política de privacidade contiver formulações ambíguas ou gerais.

Inequívoco significa que o consentimento deve ser expresso por uma ação ativa — marcar uma caixa, clicar num botão ou assinar um formulário. A inação, o silêncio ou as caixas pré-marcadas não cumprem o requisito de inequivocidade. No acórdão do processo Planet49 GmbH (C-673/17), o Tribunal de Justiça da União Europeia confirmou que o consentimento não pode ser inferido da inação do utilizador.

Que dados estão abrangidos pelo GDPR

Dados pessoais ao abrigo do GDPR são qualquer informação relativa a uma pessoa singular identificada ou identificável. Isto inclui não apenas identificadores óbvios — nome, morada, email, telefone — mas também endereços IP, identificadores de cookies, identificadores publicitários de dispositivos (IDFA, GAID), dados biométricos, geolocalização e informação genética.

O artigo 9.º do GDPR destaca categorias especiais de dados cujo tratamento é proibido sem consentimento explícito: origem racial ou étnica, opiniões políticas, crenças religiosas, filiação sindical, dados genéticos e biométricos, dados de saúde e orientação sexual. Para estas categorias, é exigida a forma mais rigorosa de consentimento — separado, detalhado e não implícito do contexto geral.

Quando o GDPR Consent é obrigatório

O GDPR Consent é necessário quando o tratamento de dados não pode basear-se noutros fundamentos jurídicos: necessidade contratual (artigo 6.º(1)(b)), interesse legítimo (artigo 6.º(1)(f)) ou cumprimento de uma obrigação legal (artigo 6.º(1)(c)). Na prática, o consentimento é necessário para comunicações de marketing, tracking para fins publicitários, recolha de dados não obrigatórios e utilização de cookies que não sejam estritamente necessários para o funcionamento do serviço.

De acordo com o Relatório Anual de Governação IAPP-EY (2024), 67% das empresas utilizam o consentimento como principal fundamento jurídico para o tratamento de dados em aplicações móveis, apesar de uma tendência crescente para o recurso ao interesse legítimo quando possível. Isto deve-se ao facto de o consentimento proporcionar a relação mais transparente com o utilizador, mas simultaneamente impor as maiores obrigações de registo e gestão de consentimentos.

Requisitos básicos do GDPR para o consentimento

O artigo 7.º do GDPR estabelece seis condições para a validade do consentimento, cada uma das quais deve ser cumprida simultaneamente. A violação de pelo menos uma condição invalida o consentimento e torna o tratamento de dados ilegal. Analisemos cada condição em detalhe, tendo em conta as orientações do EDPB e a jurisprudência.

A liberdade do consentimento é violada quando existe um desequilíbrio de poder entre o responsável e o titular dos dados. O EDPB afirma diretamente que os empregadores não podem basear-se no consentimento dos empregados devido à dependência na relação laboral. Do mesmo modo, as autoridades públicas não podem exigir o consentimento dos cidadãos na prestação de serviços públicos.

A especificidade exige um consentimento separado para cada finalidade de tratamento. Se uma aplicação recolhe dados para análise, personalização de publicidade e melhoria do serviço — para cada finalidade é necessária uma caixa separada. A combinação de várias finalidades num único consentimento viola o requisito de especificidade e invalida o consentimento.

A demonstrabilidade é o requisito tecnologicamente mais complexo. O artigo 7.º(1) indica diretamente que o responsável suporta o ónus da prova da obtenção do consentimento. Na prática, isto significa a necessidade de manter um registo de todas as ações do utilizador: quem, quando, para que finalidades deu o consentimento, que versão da política de privacidade foi apresentada e como o utilizador o retirou.

Como implementar a recolha de consentimento numa aplicação móvel

A implementação do GDPR Consent numa aplicação móvel requer uma abordagem abrangente, combinando os requisitos legais com a implementação técnica. A principal ferramenta é uma Plataforma de Gestão de Consentimentos (CMP) que gere o ciclo de vida do consentimento: exibição do pedido, registo da escolha, armazenamento de dados e sincronização com SDKs de publicidade e análise.

Utilização do SDK Google UMP

A Google fornece o SDK da User Messaging Platform (UMP) para Android e iOS, que se integra com o AdMob, Google Analytics e outros serviços Google. O SDK da UMP determina automaticamente a necessidade de exibir o consentimento com base na geolocalização do utilizador e nos requisitos do GDPR. Vejamos a integração em Kotlin para Android:

val requestParams = ConsentRequestParameters
    .Builder()
    .setTagForUnderAgeOfConsent(false)
    .build()

ConsentInformation
    .getInstance(this)
    .requestConsentInfoUpdate(requestParams, { @Override
        fun onConsentInfoUpdateSuccess() {
            if (ConsentInformation
                    .getInstance(this@MainActivity)
                    .isConsentFormAvailable()
            ) {
                loadConsentForm()
            }
        }
    }, { @Override
        fun onConsentInfoUpdateFailure(error: FormError) {
            Log.e("UMP", error.message)
        }
    })

Após carregar o formulário de consentimento, este deve ser apresentado ao utilizador. O SDK da UMP suporta dois tipos de formulários: para obter consentimento para publicidade personalizada e para gerir as escolhas posteriormente. O tratamento do resultado deve ter em conta todos os resultados possíveis — o utilizador pode dar o consentimento, recusá-lo ou fechar o formulário sem escolher.

Armazenamento e verificação do consentimento

Para cumprir o requisito de demonstrabilidade, é necessário armazenar não apenas o facto do consentimento, mas também o contexto da sua obtenção. O conjunto mínimo de dados para armazenamento inclui: identificador do utilizador ou dispositivo, carimbo temporal com fuso horário, versão da política de privacidade, finalidades específicas do tratamento e o mecanismo de consentimento utilizado.

data class ConsentRecord(
    val userId: String,
    val timestamp: Long,
    val privacyPolicyVersion: String,
    val purposes: List<String>,
    val consentGiven: Boolean
)

class ConsentRepository(
    private val dao: ConsentDao
) {
    suspend fun saveConsent(record: ConsentRecord) {
        dao.insert(record.toEntity())
        AnalyticsManager.logConsentEvent(record)
    }
}

O Comité Europeu para a Proteção de Dados (EDPB) nas recomendações 01/2023 sublinha que os registos de consentimento devem ser conservados durante todo o período de tratamento de dados e até três anos após a sua cessação. Para aplicações móveis, isto significa a necessidade de armazenamento no servidor dos registos, não apenas local, uma vez que o utilizador pode reinstalar a aplicação ou mudar de dispositivo.

Em que difere o GDPR de outros reguladores de privacidade

O GDPR não é o único regulador de privacidade no mundo, mas tornou-se um modelo para muitas leis nacionais de proteção de dados. Compreender as diferenças entre o GDPR e outros reguladores é de importância crítica para os programadores de aplicações internacionais que trabalham com utilizadores de diferentes jurisdições.

A CCPA (California Consumer Privacy Act) difere fundamentalmente do GDPR: funciona segundo o modelo de opt-out, não de opt-in. Ao abrigo da CCPA, as empresas são obrigadas a fornecer ao utilizador o direito de recusar a venda dos seus dados, mas não são obrigadas a obter consentimento prévio para a recolha. No entanto, com a adoção da CPRA (California Privacy Rights Act) em 2023, os requisitos de consentimento para dados sensíveis aproximaram-se do GDPR.

A Diretiva ePrivacy (Diretiva relativa à privacidade nas comunicações eletrónicas) complementa o GDPR em matéria de cookies e marketing eletrónico. Ao contrário do GDPR, que regula todos os dados pessoais, a ePrivacy centra-se nos dados de comunicações. O requisito de obter consentimento para cookies não essenciais decorre precisamente da ePrivacy, não do GDPR, embora o mecanismo de consentimento seja o mesmo.

A LGPD do Brasil copia quase totalmente a estrutura do GDPR com alterações menores: a idade de consentimento é elevada para 18 anos e o tratamento de dados de pessoas falecidas requer o consentimento dos herdeiros. A PIPL da China, pelo contrário, introduz requisitos mais rigorosos: localização obrigatória de dados, avaliação de impacto sobre a proteção de dados (DPIA) para todas as decisões automatizadas e notificação da transferência de dados para o estrangeiro.

Erros típicos na implementação do GDPR Consent

A análise das multas e decisões das autoridades de supervisão europeias durante 2018-2024 mostra infrações recorrentes na implementação do consentimento. De acordo com o Enforcement Tracker (CMS Law, 2024), mais de 40% de todas as multas do GDPR estão relacionadas com a obtenção e gestão incorretas do consentimento. Vejamos os erros mais frequentes.

Caixas pré-marcadas e consentimento passivo

O erro mais comum é a utilização de caixas pré-marcadas para obter consentimento. O acórdão do Tribunal de Justiça da UE no processo Planet49 GmbH (C-673/17) estabeleceu inequivocamente que o consentimento não pode ser inferido da inação do utilizador. Apesar disso, muitas aplicações continuam a utilizar opções pré-marcadas, especialmente para banners de cookies, levando a multas e ordens diretas.

Em 2024, a Comissão Nacional de Informática e Liberdades francesa (CNIL) multou uma grande empresa de publicidade RTB em 250 milhões de euros por utilizar caixas pré-marcadas e informação insuficientemente transparente aos utilizadores. É a maior multa relacionada com o consentimento, demonstrando a prioridade do controlo do consentimento para os reguladores europeus.

Combinação de finalidades num único consentimento

Muitas aplicações solicitam um único consentimento geral para todos os tipos de tratamento: análise, personalização, publicidade, transferência a terceiros. Isto viola diretamente o requisito de especificidade (limitação da finalidade). O EDPB nas orientações 05/2020 sublinha: se uma finalidade puder ser alcançada sem outra, o utilizador deve poder consentir cada finalidade separadamente.

A Comissão de Proteção de Dados irlandesa (DPC) na sua decisão sobre a Meta Platforms Ireland (2023) declarou que a combinação da personalização de publicidade e melhoria do serviço num único consentimento constitui uma infração. A Meta foi obrigada a implementar mecanismos de consentimento separados para diferentes finalidades de tratamento no Facebook e Instagram.

Retirada difícil ou impossível do consentimento

O GDPR exige que a retirada do consentimento seja tão simples como a sua concessão. Se o utilizador deu o consentimento com um único clique num botão, a retirada não pode exigir o preenchimento de um formulário, o envio de um email ou uma chamada para o apoio. Na prática, muitas aplicações escondem o mecanismo de retirada nas definições ou exigem múltiplos passos para a realizar.

Prática recomendada — adicionar um ecrã dedicado de gestão de consentimentos nas definições da aplicação com a possibilidade de retirar cada consentimento separadamente com um único interruptor. O SDK da UMP da Google fornece um mecanismo integrado para reexibir o formulário de consentimento, que o utilizador pode invocar a partir das definições da aplicação em qualquer momento.

Falta de prova da obtenção do consentimento

Muitos programadores baseiam-se em consentimentos verbais ou não conservam registos da obtenção do consentimento. Isto torna impossível cumprir o requisito de demonstrabilidade (accountability) ao abrigo do artigo 5.º(2) do GDPR. Durante uma inspeção, a autoridade de supervisão solicitará não apenas a política de privacidade, mas também os registos dos consentimentos obtidos durante todo o período de tratamento de dados.

A solução é utilizar uma Plataforma de Gestão de Consentimentos (CMP) com registo automático de todos os eventos: exibição do formulário, escolha do utilizador, versão do documento, carimbo temporal. As CMP mais populares para aplicações móveis incluem Usercentrics, OneTrust e ConsentManager — todas suportam a gravação automática da auditoria de consentimentos.