LGPD e cookies: implicações ao vincular CPF a ferramentas de analytics

Vincular CPF a ferramentas de analytics — enviando-o como userId, hash ou parâmetro de conversão — viola múltiplos princípios da LGPD (Lei nº 13.709/2018) e pode resultar em multas de até 2% do faturamento por infração. A solução é separar a validação de identidade (feita via API no backend) do rastreamento comportamental (feito com identificadores pseudonimizados), garantindo que o CPF nunca trafegue por cookies ou ferramentas de terceiros.

Introdução

A combinação de cookies com dados de CPF em ferramentas de analytics cria um cenário regulatório delicado sob a LGPD. Muitas empresas utilizam plataformas de analytics para rastrear o comportamento do usuário em seus sites e aplicativos. Quando esse rastreamento é associado a um dado pessoal direto como o CPF, o nível de risco e as exigências de conformidade aumentam significativamente.

Empresas de e-commerce, fintechs, plataformas de saúde e outros setores que coletam CPF no cadastro ou no checkout frequentemente enviam esse dado (ou um identificador derivado dele) para ferramentas como Google Analytics, Mixpanel, Amplitude ou plataformas de marketing. Essa prática, se não for tratada com cuidado, pode violar a LGPD.

O que são cookies e como se relacionam com o CPF

Cookies

Cookies são pequenos arquivos de texto armazenados no navegador do usuário. Eles servem para:

• Sessão -- Manter o usuário logado.
• Preferências -- Armazenar configurações do site.
• Analytics -- Rastrear comportamento de navegação.
• Marketing -- Segmentar anúncios com base no perfil do usuário.

Vinculação com CPF

A vinculação ocorre quando:

• O CPF é enviado diretamente como parâmetro para a ferramenta de analytics (ex: userId = CPF).
• O CPF é usado para gerar um hash que serve como identificador do usuário.
• O CPF é armazenado em um cookie de sessão que é lido pela ferramenta de analytics.
• Uma plataforma de CRM associa o CPF ao cookie de navegação para criar perfis unificados.

Por que isso é problemático sob a LGPD

CPF como dado pessoal direto

O CPF é um dado pessoal que identifica diretamente uma pessoa física. Ao vinculá-lo a cookies e dados de navegação, a empresa está criando um perfil comportamental detalhado vinculado a uma pessoa identificada -- o que constitui tratamento de dados pessoais nos termos da LGPD.

Princípio da finalidade

Se o CPF foi coletado para uma finalidade específica (ex: validação de identidade no cadastro), utilizá-lo para analytics ou marketing constitui desvio de finalidade, salvo se houver base legal e transparência.

Princípio da necessidade

A vinculação do CPF a cookies de analytics raramente é necessária. Na maioria dos casos, um identificador anônimo ou pseudônimo é suficiente para análises comportamentais.

Transferência internacional de dados

Muitas ferramentas de analytics processam dados em servidores fora do Brasil. Enviar CPF para esses servidores configura transferência internacional de dados pessoais, sujeita a regras específicas da LGPD (art. 33).

Riscos concretos

• Sanções da ANPD -- A Autoridade Nacional de Proteção de Dados pode aplicar advertências, multas (até 2% do faturamento, limitadas a R$ 50 milhões por infração) e determinações de cessação.

• Vazamento de dados -- CPFs vinculados a cookies podem ser expostos em incidentes de segurança de ferramentas de terceiros.

• Perda de confiança -- Usuários que descobrem que seu CPF está sendo usado para rastreamento comportamental podem perder a confiança na empresa.

• Ações judiciais -- Titulares de dados podem mover ações individuais ou coletivas por violação da LGPD.

Como tratar dados de CPF corretamente

Separação entre validação e analytics

A validação de CPF (para confirmar identidade) e o uso de dados para analytics devem ser tratados como processos completamente separados:

• Validação de CPF -- Feita via API no backend, com dados armazenados no banco de dados da empresa, protegidos e com acesso controlado.

• Analytics -- Deve usar identificadores anônimos ou pseudonimizados, sem enviar CPF para ferramentas de terceiros.

Pseudonimização

Se houver necessidade de vincular dados de analytics a um usuário específico, use pseudonimização:

import hashlib
import requests

def gerar_id_anonimo(cpf, salt_secreto):
    """
    Gera um identificador pseudonimizado a partir do CPF.
    O ID resultante nao permite reconstruir o CPF original.
    """
    dado = f"{cpf}:{salt_secreto}"
    return hashlib.sha256(dado.encode()).hexdigest()

def consultar_e_pseudonimizar(cpf):
    """
    Valida o CPF via API e retorna um ID anonimo para analytics.
    """
    url = f"https://api.cpfhub.io/cpf/{cpf}"
    headers = {
    "x-api-key": "SUA_CHAVE_DE_API",
    "Accept": "application/json"
    }

    response = requests.get(url, headers=headers, timeout=10)
    dados = response.json()

    if dados.get("success"):
    id_anonimo = gerar_id_anonimo(cpf, "salt_secreto_da_empresa")
    return {
    "validacao": "aprovada",
    "nome": dados["data"]["name"],
    "analytics_id": id_anonimo # Enviar apenas este ID para analytics
    }
    else:
    return {"validacao": "rejeitada"}

resultado = consultar_e_pseudonimizar("12345678900")
print(resultado)

Nesse exemplo, o CPF real é usado apenas para a validação via API. Para fins de analytics, um hash irreversível é gerado e enviado como identificador do usuário.

Boas práticas para conformidade

Consentimento para cookies

• Implemente um banner de cookies que permita ao usuário escolher quais categorias aceitar.
• Cookies de analytics e marketing devem ser opcionais (opt-in).
• O consentimento deve ser granular, livre, informado e inequívoco.

Política de privacidade

• Informe claramente quais dados são coletados e para quais finalidades.
• Especifique se dados pessoais (como CPF) são compartilhados com ferramentas de analytics.
• Liste os fornecedores de analytics e seus respectivos países de processamento.

Configuração de ferramentas de analytics

Registro de tratamento (ROPA)

Documente no Registro de Operações de Tratamento de Dados:

• Quais dados são enviados para cada ferramenta de analytics.
• A base legal para esse envio.
• As medidas de segurança implementadas.
• O prazo de retenção.

Impacto nas diferentes ferramentas

Google Analytics

• Não enviar CPF como User ID ou dimensão personalizada.
• Ativar anonymize IP.
• Configurar retenção de dados para o prazo mínimo necessário.
• Considerar alternativas self-hosted (Matomo, Plausible) para dados sensíveis.

Plataformas de CRM/CDP

• Separar dados de identificação (CPF) de dados de comportamento.
• Usar IDs internos ao invés de CPF como chave de unificação.

Pixels de remarketing

• Não enviar CPF como parâmetro de conversão.
• Usar Custom Audiences com hashes seguros quando necessário.

O papel da validação de CPF nesse contexto

A validação de CPF via API deve ser tratada como um processo de backend, isolado das ferramentas de analytics:

1. O CPF é coletado no formulário de cadastro.
2. O backend valida o CPF via API da CPFHub.io, confirmando identidade sem expor o dado a sistemas de terceiros.
3. O resultado da validação é armazenado no banco de dados da empresa.
4. Para analytics, apenas um ID pseudonimizado é enviado ao frontend.

Essa separação garante que o CPF nunca trafega por cookies ou ferramentas de terceiros.

Perguntas frequentes

Enviar o CPF como userId para o Google Analytics é ilegal pela LGPD?

Sim, configura desvio de finalidade e possivelmente transferência internacional de dados pessoais sem base legal adequada. A prática viola os artigos 6º (princípios) e 33 da LGPD. Use sempre um identificador pseudonimizado gerado a partir do CPF com hash irreversível.

Um hash do CPF enviado para analytics já é considerado dado pessoal?

Depende da reversibilidade. Um SHA-256 com salt secreto adequado é praticamente irreversível e tende a ser tratado como dado pseudonimizado, não pessoal direto. Sem salt ou com salt fraco, o hash pode ser revertido e mantém a classificação de dado pessoal — nesse caso, as mesmas restrições se aplicam.

A ANPD já autuou empresas por uso indevido de CPF em analytics?

A ANPD tem intensificado fiscalizações e emitido recomendações sobre cookies e dados de navegação. Embora os casos públicos mais expressivos envolvam vazamentos, o uso de CPF em analytics sem base legal é uma vulnerabilidade autuável. Consulte as orientações atualizadas em gov.br/anpd.

Como devo documentar a separação entre validação de CPF e analytics no ROPA?

Crie dois registros de tratamento distintos: um para a validação de CPF (finalidade: verificação de identidade, base legal: execução de contrato ou legítimo interesse) e outro para analytics (finalidade: melhoria do produto, dados tratados: IDs pseudonimizados — sem CPF). Essa separação demonstra conformidade com o princípio da finalidade.

Conclusão

Vincular CPF a cookies e ferramentas de analytics é uma prática que viola múltiplos princípios da LGPD se não for feita com as devidas precauções. A abordagem correta é separar a validação de identidade (feita via API no backend) do rastreamento comportamental (feito com identificadores pseudonimizados), garantindo que o CPF nunca trafegue por ferramentas de terceiros.

Cadastre-se em cpfhub.io — 50 consultas mensais gratuitas, sem cartão de crédito — e implemente a validação de CPF no backend com total separação dos seus sistemas de analytics.