LGPD e dados analíticos se cruzam sempre que um dashboard ou relatório exibe dado pessoal, mesmo que de forma indireta, como CPF, e-mail ou dado de saúde. A exigência central da lei é simples de enunciar e difícil de implementar: tratar apenas o dado pessoal necessário, com base legal definida, e reduzir a exposição desse dado ao mínimo possível em cada camada da arquitetura analítica.
O que a LGPD exige de quem faz analytics?
A LGPD não proíbe usar dado pessoal em BI ou analytics, exige que esse uso tenha finalidade definida, base legal e tratamento proporcional ao risco. Na prática, isso significa que a arquitetura de dados precisa responder, para cada informação pessoal tratada: por que ela está ali, quem tem acesso, e por quanto tempo ela precisa ficar identificável.
Dado pessoal em dashboard: onde mora o risco?
O risco raramente está na intenção do time de dados, está na exposição desnecessária. Um dashboard de vendas com nome completo de cliente visível para toda a equipe comercial, quando só o gestor precisaria dessa granularidade, é o tipo de exposição que a LGPD trata como risco, mesmo sem qualquer uso indevido. O mesmo vale para relatórios exportáveis em Excel, que tiram o dado do ambiente controlado e multiplicam o risco de vazamento.
Anonimização e pseudonimização na prática
Os dois principais mecanismos técnicos de redução de risco são:
- Anonimização: transforma o dado de forma irreversível, de modo que ele não possa mais ser associado a uma pessoa identificável. Quando efetiva e não correlacionável com outras bases, o dado anonimizado deixa de ser considerado dado pessoal pela LGPD, e sai do escopo da lei. É a técnica indicada para relatórios agregados, dashboards históricos e pesquisas estatísticas.
- Pseudonimização: substitui o identificador direto por um código, mantendo a informação que permite reidentificação separada e protegida. É usada quando a identificação ainda é necessária para a operação (por exemplo, atendimento clínico), mas o acesso ao dado completo deve ser restrito.
A ANPD recomenda uma abordagem baseada em risco: a técnica escolhida deve considerar o tipo de tratamento, o volume de dados pessoais envolvido e a chance real de reidentificação, e não um único método aplicado de forma genérica a toda a base (ANPD).
Controle de acesso por camada
Uma arquitetura de dados compatível com a LGPD normalmente define pelo menos três camadas de acesso:
| Camada | Quem acessa | O que vê |
|---|---|---|
| Dado bruto/identificado | Time de engenharia de dados, com justificativa de acesso | Dado pessoal completo, quando estritamente necessário |
| Dado pseudonimizado | Times operacionais que precisam de granularidade individual | Identificador substituído, sem exposição do dado direto |
| Dado agregado/anonimizado | Gestores e dashboards de acompanhamento geral | Métricas e indicadores, sem qualquer dado pessoal identificável |
Esse desenho evita o erro mais comum: dar acesso amplo “por praticidade” e só restringir depois que um incidente acontece.
O que exigir do fornecedor de BI (nós incluídos)
Ao contratar uma consultoria ou fornecedor de BI, vale exigir, por escrito: onde os dados ficam armazenados, quem no fornecedor tem acesso a dado identificado, como o acesso é revogado ao final do contrato e se existe processo de anonimização/pseudonimização definido antes de qualquer dashboard entrar em produção. Um fornecedor que não sabe responder essas perguntas com precisão é, ele mesmo, um risco de conformidade.
Checklist de conformidade para dados analíticos
- Cada dado pessoal tratado tem finalidade e base legal documentadas.
- Dashboards de uso amplo mostram apenas dado agregado ou anonimizado.
- Dado pseudonimizado é usado sempre que a identificação completa não for indispensável.
- Acesso a dado identificado é restrito e registrado (log de acesso).
- Exportação de relatórios com dado pessoal é controlada, não livre.
- Contratos com fornecedores de BI e dados definem claramente responsabilidade e prazo de retenção.
Isso se conecta diretamente à governança de dados da empresa: sem papéis e processo definidos, controle de acesso por camada não se sustenta no dia a dia.
Conclusão
LGPD e dados analíticos não são forças opostas. A lei não impede dashboards e relatórios com dado pessoal, exige que a arquitetura reduza a exposição ao mínimo necessário, com anonimização, pseudonimização e controle de acesso por camada bem definidos. É o mesmo cuidado que a beAnalytic aplica em setores sensíveis, como na análise de dados para saúde, onde dado pessoal sensível exige um padrão ainda mais rígido de proteção.
Quer um diagnóstico de conformidade para a sua arquitetura de dados? Fale com a beAnalytic e veja onde estão os pontos de exposição no seu ambiente analítico.
Perguntas frequentes
A LGPD proíbe usar dado pessoal em dashboards de BI?
Não. Exige finalidade definida, base legal e tratamento proporcional ao risco, reduzindo a exposição do dado ao mínimo necessário em cada camada de acesso.
Qual a diferença entre anonimização e pseudonimização?
Anonimização torna o dado irreversivelmente não identificável, e retira o dado do escopo da LGPD quando efetiva. Pseudonimização substitui o identificador por um código, mantendo a possibilidade de reidentificação sob controle restrito.
Quem deve ter acesso a dado pessoal identificado em um projeto de BI?
Apenas quem tem justificativa operacional direta para isso, geralmente um grupo pequeno da engenharia de dados ou da área que realiza o atendimento direto ao titular do dado.
O que perguntar a um fornecedor de BI antes de contratar, sob a ótica da LGPD?
Onde os dados são armazenados, quem tem acesso interno, como o acesso é revogado ao fim do contrato e se existe processo formal de anonimização ou pseudonimização antes da produção dos dashboards.
Daniel Luz
CEO da beAnalytic. Na liderança da empresa há mais de 6 anos, minha missão é transformar a forma como as organizações enxergam e utilizam dados para tomar decisões estratégicas. Ajudo empresas a destravar insights valiosos, impulsionar eficiência operacional e gerar impacto financeiro real, com uma equipe especializada em Business Intelligence, Engenharia de Dados e Machine Learning.
- Daniel Luz
- Daniel Luz
- Daniel Luz
- Daniel Luz
