Consentimento e base legal no tratamento de dados

A diferença entre consentimento e base legal

Consentimento e base legal são frequentemente confundidos, paralisando projetos de dados por dúvida regulatória. A diferença é fundamental: consentimento é a permissão do titular; base legal é a autorização da lei. Consentimento é revogável — o titular pode retirar permissão a qualquer momento. Bases legais são permanentes — uma vez aplicada, autoriza o processamento enquanto a condição existir. Na prática corporativa, a maioria dos dados opera sob bases legais, não consentimento. Dados de funcionários, por exemplo, processam sob base de contrato de trabalho, não consentimento. Dados de clientes em contrato processam sob base contratual. Consentimento é exigido apenas quando nenhuma outra base legal se aplica — e quando exigido, deve ser documentado e revogável.

As 10 bases legais da LGPD e quando aplicam

A Lei Geral de Proteção de Dados reconhece dez bases legais que legitimam o processamento de dados. Entender cada uma reduz riscos de conformidade e acelera projetos de BI.

1. Consentimento: titular autoriza explicitamente. Exigência: deve ser livre, informado e revogável. Exemplo: cliente opt-in em newsletter.
2. Contrato: dados são necessários para executar contrato. Exemplo: endereço de entrega, dados bancários para pagamento.
3. Obrigação legal: lei exige o processamento. Exemplo: retenção de notas fiscais por anos, cumprimento de auditoria tributária.
4. Proteção de vida: preservar vida ou segurança física. Exemplo: dados de emergência médica, identificação em risco.
5. Interesse público: função pública ou política. Exemplo: órgãos governamentais processando dados para interesse coletivo.
6. Interesse legítimo: benefício legítimo do controlador que não sobrepuja direitos do titular. Exemplo: análise de fraude, manutenção de segurança.
7. Pesquisa científica: dados para pesquisa com salvaguardas. Exemplo: estudos epidemiológicos, análises demográficas anonimizadas.
8. Políticas públicas: execução de política de governo. Exemplo: programas de saúde pública, educação.
9. Crédito e proteção ao crédito: avaliação de risco creditício. Exemplo: scoring de crédito, análise de inadimplência.
10. Execução de contrato de pessoa jurídica: dados processados para cumprir contrato com pessoa jurídica. Exemplo: fornecedores, parceiros.

Mapeamento prático: dados de clientes, funcionários e parceiros

Aplicar base legal correta depende da origem e finalidade dos dados. Um guia prático por tipo de relacionamento evita erros comuns^[2].

Dados de clientes: Base típica é contrato se o cliente comprou seu produto. Se você quer analisar comportamento além do necessário para entregar serviço, use interesse legítimo (justifique por que beneficia ao cliente ou negócio). Se solicitar dados adicionais, peça consentimento explícito. Consentimento é obrigatório para marketing, análises secundárias ou compartilhamento com terceiros não mencionados no contrato inicial.

Dados de funcionários: Base é contrato de trabalho e obrigação legal. Você pode processar dados para admissão, folha, segurança do trabalho, histórico de performance sem consentimento adicional — está tudo na relação contratual. Dados sensíveis (saúde, origem étnica) exigem consentimento explícito, mesmo internamente, a menos que sejam necessários para proteger vida ou cumprir obrigação legal.

Dados de parceiros e fornecedores: Base é contrato. Você pode processar para pagamento, conformidade, avaliação de desempenho. Análises secundárias (tendências de mercado, benchmarking) entram em interesse legítimo se não identifi­carem o parceiro ou se o benefício é mútuo.

Dados legados (coletados antes de LGPD): Precisam ser legalizados retroativamente. Para cada dataset, identifique qual base legal se aplica hoje. Se nenhuma se aplica e consentimento não foi documentado, você pode presumir legitimidade se o processamento era esperado quando coletado — mas documente essa decisão e revise o processamento contínuo.

Documentação: registro de processamento e auditoria

Conformidade exige prova de que você respeitou LGPD. A documentação central é o Registro de Operações de Processamento (RoPA) — não um formulário mágico, mas um inventário claro de quais dados você processa, por qual base legal, com qual finalidade, e quem acessa.

Num RoPA mínimo conste: (1) nome do dataset, (2) origem dos dados, (3) base legal aplicada e justificativa, (4) finalidade, (5) quem acessa, (6) retenção esperada, (7) se há compartilhamento com terceiros. Para cada projeto novo, antes de processar dados, atualize o RoPA. Isso força discussão sobre qual base legal aplicar — e cria auditoria. Pequenas empresas podem manter isso numa planilha; médias em ferramenta de governança; grandes implementam sistemas de auditoria automática vinculados aos repositórios de dados.

Além do RoPA, documente: (1) políticas internas sobre processamento de dados, (2) consentimentos obtidos (e quando revogados), (3) avaliações de impacto (AIPD) para processamentos de risco, (4) comunicações com titulares (se houve vazamento, por exemplo), (5) decisões de base legal (especialmente interesse legítimo, que deve ser justificado).

Operacionalizar direitos do titular em BI

LGPD reconhece direitos ao titular de dados: acesso, retificação, exclusão (direito ao esquecimento), portabilidade e oposição. Quando alguém pede para ser esquecido, ou quer copiar seus dados, como você operacionaliza isso num pipeline de BI sem quebrar análises históricas?

Acesso é o mais simples — você confirma que tem dados, lista quais são, explica por qual base legal processa. Retificação exige atualizar registros (e históricos, se aplicável). Exclusão é a mais complexa em BI: você pode precisar remover dados de clientes que saíram, mas análises que incluíram essa pessoa no passado permanecem válidas. Solução: remova dados atuais, mas mantenha análises históricas anonimizadas. Portabilidade exige fornecer dados em formato estruturado — exportar relatório não satisfaz a lei, é preciso dados brutos em formato padrão. Oposição permite ao titular se recusar a certo tipo de processamento — por exemplo, recusar marketing — mas não afeta dados já processados sob contrato ou obrigação legal.

Operacionalmente: (1) crie processo de atendimento para solicitações de direitos, (2) integre ao seu sistema de RoPA e auditoria, (3) documente resposta (prazo é 15 dias), (4) para exclusão, implemente flag de "recusou processamento" nos dados, (5) treine equipe que acessa dados sobre como respeitar essas marcações.

Consentimento revogável vs. bases permanentes: implicações operacionais

Consentimento pode ser revogado; bases legais não. Isso cria assimetria operacional que muitas empresas subestimam. Se você processa dados sob consentimento e o titular revoga, precisa parar de processar imediatamente (com exceção de registros legalmente obrigatórios). Se processa sob contrato e o contrato termina, parada é natural. Se processa sob interesse legítimo, pode continuar enquanto há interesse — a revogação não aplica.

Implicação prática: dados processados sob consentimento exigem infraestrutura de revogação em tempo real. Pipelines de BI que alimentam data warehouses devem ser capazes de remover dados ou marcar como "revogados". Dados históricos já agregados podem permanecer para análise passada, mas não alimentam análises futuras. Isso é caro tecnicamente — exige rastreabilidade de cada dado ao titular e capacidade de "desagregar" agregações. Por isso, muitos dados que poderiam rodar em consentimento são melhor operacionalizados sob interesse legítimo ou contrato.

Regra prática: use consentimento apenas quando a lei exigir ou quando há fácil revogação — marketing, preferências. Para análises operacionais, prefira bases permanentes.