LGPD na prática para áreas de dados e BI

Conformidade não é problema do jurídico, é problema de quem modela o dado#

Quando alguém diz "estamos em conformidade com a LGPD", quase sempre está falando de um documento: uma política de privacidade no rodapé do site, um contrato revisado, um treinamento de uma hora que metade do time esqueceu. Nada disso toca no lugar onde o dado pessoal realmente vive, que é a sua base, o seu modelo semântico e os seus relatórios. LGPD na prática para áreas de dados e BI é justamente isso: o conjunto de decisões técnicas que quem constrói pipeline, dataset e dashboard toma todo dia, e que determinam se o CPF de um cliente está protegido ou exposto por um link. Este artigo trata dessas decisões sem juridiquês e é honesto sobre onde cada controle protege e onde ele para.

A Lei nº 13.709/2018, a LGPD, não foi escrita para times de dados, e por isso chega distorcida à mesa técnica. O jurídico traduz para "não pode vazar", o negócio para "não pode atrapalhar o dashboard", e o analista fica no meio sem saber o que fazer com a coluna de CPF que veio na extração. A boa notícia é que a lei tem um punhado de conceitos que, uma vez entendidos, viram checklist de engenharia: mapear o dado pessoal, definir a base legal, minimizar, controlar acesso, definir retenção e saber quem é o encarregado. O resto é execução.

Antes de proteger, você precisa saber o que na sua base é dado pessoal#

Não dá para proteger o que você não mapeou. O primeiro trabalho, e o mais ignorado, é olhar cada tabela do modelo e responder: aqui tem dado pessoal? A LGPD define dado pessoal como qualquer informação relacionada a pessoa natural identificada ou identificável, e isso é mais amplo do que a maioria imagina. Não é só CPF e nome. É e-mail, telefone, matrícula, placa de veículo, geolocalização, e muitas vezes uma combinação de colunas aparentemente inofensivas que, juntas, identificam alguém.

Dentro do dado pessoal existe uma categoria mais rígida, o dado pessoal sensível, que a lei trata numa lista fechada: origem racial ou étnica, convicção religiosa, opinião política, filiação sindical, dado referente à saúde, à vida sexual, dado genético ou biométrico. A distinção importa porque a base legal para tratar dado sensível é mais restrita. Confundir os dois leva a dois erros opostos: relaxar com o que é sensível ou travar o projeto tratando saldo bancário como se fosse prontuário médico.

Na prática, o entregável dessa etapa é um inventário: uma planilha que lista fonte, tabela, coluna, se é dado pessoal, se é sensível, a finalidade e onde ele aparece nos relatórios. Parece burocracia, mas é o mapa sem o qual todos os outros controles viram tentativa e erro. Esse inventário é o coração de qualquer trabalho de governança de dados sério, e ferramentas de catálogo como o Microsoft Purview existem para manter esse mapa vivo em vez de morto numa planilha desatualizada.

LGPD na prática para áreas de dados e BI começa pela base legal, não pela ferramenta#

Aqui está o erro mais comum do time técnico: sair comprando controle antes de responder a pergunta jurídica que sustenta tudo. Todo tratamento de dado pessoal precisa de uma base legal, e a LGPD lista as hipóteses no art. 7º para dado comum e no art. 11 para dado sensível. Não é opcional: é a organização que precisa saber, para cada finalidade, sob qual base está operando.

As bases mais usadas em contexto de dados e BI são consentimento, execução de contrato, cumprimento de obrigação legal ou regulatória, e legítimo interesse. Consentimento é só uma delas, e costuma ser a mais frágil, porque o titular pode revogá-lo a qualquer momento. Na maioria dos painéis operacionais internos, a base é execução de contrato ou legítimo interesse, não consentimento. Já para dado sensível, o art. 11 fecha o cerco: fora consentimento específico e destacado, só um rol reduzido de hipóteses autoriza o tratamento, e legítimo interesse não está entre elas.

O que isso muda para quem faz BI? Muda que, antes de trazer uma coluna para o modelo, alguém precisa saber por que ela está ali e com qual base. Se ninguém sabe responder, aquela coluna é risco assumido de graça. A base legal não é campo que o analista preenche sozinho, mas é o time de dados que sente o resultado dela na hora de decidir o que entra no pipeline.

Minimizar é a defesa mais barata que você tem#

O art. 6º da LGPD lista os princípios que regem o tratamento, e três deles atingem diretamente o modelo de dados: finalidade, adequação e necessidade. A necessidade, também chamada de minimização, diz que você deve tratar apenas os dados estritamente necessários para a finalidade declarada. É o princípio mais poderoso e o mais ignorado.

Traduzindo para engenharia: se o painel de vendas por região não precisa do CPF do cliente, o CPF não deveria estar no dataset. Se o relatório de RH mostra headcount por área, ele não precisa do salário individual nominal. O padrão do mercado é o oposto: traz a tabela inteira do sistema de origem porque "vai que alguém precisa depois". Cada coluna de dado pessoal sem finalidade clara é uma superfície de exposição que você criou sem ganho nenhum.

Minimização não é só remover colunas. É agregar antes de servir, truncar CPF quando só se precisa validar unicidade, substituir o nome por um identificador quando o relatório não precisa do nome na tela. O dado mais seguro é aquele que você decidiu não trazer: menos dado pessoal no modelo é menos coisa para vazar, auditar e explicar num incidente. Esse trabalho acontece na engenharia de dados, na camada de transformação, antes de o dado chegar ao Power BI. Depois que ele entrou no modelo, mascarar na tela não desfaz o fato de que ele está armazenado no arquivo.

Controlar acesso é decidir quem vê cada linha, cada coluna e cada arquivo#

Mapeou, definiu base, minimizou. O que sobra de dado pessoal legítimo no modelo precisa de controle de acesso, e aqui o time de dados tem ferramentas concretas. O ponto central é que controle de acesso opera em camadas, e cada camada resolve um problema que a outra não resolve.

O RLS, segurança em nível de linha, filtra quais linhas cada usuário enxerga. O gerente da região Sul vê só os clientes do Sul, o vendedor vê só a própria carteira. É o controle mais importante em BI e o mais mal implementado, porque muita gente para no RLS estático quando o cenário pede o dinâmico, que lê a identidade do usuário e cruza com uma tabela de permissões. Detalhamos isso no guia de RLS no Power BI. Acima da linha existe a segurança em nível de objeto, que esconde colunas ou tabelas inteiras de quem não deve nem saber que aquele campo existe.

RLS e OLS controlam o que se vê dentro da plataforma, não o dado depois que ele sai. Para isso existem os rótulos de confidencialidade do Microsoft Purview, que classificam o dataset e o relatório com etiquetas como Público, Interno, Confidencial e Restrito, e essa classificação viaja com o arquivo exportado para Excel ou PowerPoint, podendo inclusive criptografar e bloquear a abertura por quem está fora do grupo autorizado. Na origem, o mascaramento dinâmico no banco esconde a coluna na consulta casual. A tabela abaixo mostra onde cada mecanismo protege e onde ele para.

Mecanismo	Camada	O que protege	Onde não protege
RLS (segurança de linha)	Modelo semântico	Quais linhas cada usuário vê	Quem tem edição no dataset pode contornar
OLS (segurança de objeto)	Modelo semântico	Esconde colunas e tabelas sensíveis	Não filtra linhas nem protege o arquivo exportado
Rótulos do Microsoft Purview	Exportação e ciclo de vida	O dado depois que sai da plataforma	Depende de configuração e adoção corretas
Mascaramento dinâmico	Origem (banco)	Exibição casual da coluna na consulta	Não impede acesso privilegiado nem criptografa
Minimização no ETL	Transformação	Reduz o dado pessoal que existe	O que já entrou continua no arquivo

Nenhuma linha da tabela protege sozinha. Segurança de dado pessoal em BI é a soma delas, e fazer só RLS e chamar de conformidade é ter a sensação de proteção sem a proteção. Dedicamos um artigo inteiro a governança de dados e LGPD no Power BI para quem vai desenhar isso do zero.

Retenção: o dado que você não apaga hoje é passivo amanhã#

A LGPD prevê que o dado seja eliminado após o término do tratamento, quando cumprida a finalidade que o justificou, respeitadas as hipóteses de guarda previstas em lei. Traduzindo: você não pode acumular dado pessoal para sempre "porque dá". Precisa de uma política de retenção que diga, para cada tipo de dado, por quanto tempo ele fica e o que acontece depois.

Isso convive com prazos regulatórios que obrigam a guardar certos registros por anos, e as duas coisas não se contradizem: você retém o que a norma exige pelo prazo que ela exige e anonimiza ou elimina o resto. Um modelo de BI que carrega histórico completo de dado pessoal desde 2015 sem que ninguém saiba por quê está fora de conformidade e, de quebra, mais caro de manter. Anonimização bem feita tira o dado do escopo da LGPD, porque dado anonimizado deixa de ser dado pessoal, e essa é muitas vezes a saída mais elegante para manter a série histórica sem manter o risco.

Os direitos do titular batem na porta da área de dados#

O art. 18 dá ao titular um conjunto de direitos: confirmação de tratamento, acesso aos dados, correção, anonimização ou eliminação, portabilidade, informação sobre com quem os dados são compartilhados. Na teoria isso soa como assunto de atendimento. Na prática, quando um titular pede "me diga todos os dados que vocês têm sobre mim" ou "apague meus dados", quem responde é o time de dados, porque é ele que sabe em quais tabelas e relatórios aquela pessoa aparece.

É por isso que o inventário da primeira seção não é burocracia: sem ele, atender a um pedido de eliminação vira caça ao tesouro por dez datasets. A área de dados precisa de um caminho técnico para localizar, exportar e apagar o dado de um titular específico, e esse caminho precisa existir antes do primeiro pedido, não ser improvisado depois. Um pedido de eliminação que o time não cumpre em prazo razoável é um problema de conformidade que nasceu de uma falha de arquitetura.

O encarregado (DPO) é o seu par, não o seu fiscal#

O art. 41 institui a figura do encarregado, o DPO, como canal de comunicação entre a organização, os titulares e a ANPD, a Autoridade Nacional de Proteção de Dados, que fiscaliza e pode aplicar sanções. Muito time de dados enxerga o encarregado como o chato que trava projeto. Erro. Ele é quem responde a pergunta que o analista não deveria responder sozinho: qual a base legal disso, posso reter por quanto tempo, esse compartilhamento pode acontecer.

A relação saudável é de parceria. O time de dados leva o mapa técnico, o encarregado traz a leitura jurídica, e juntos definem o que entra no modelo e como. Quando essa conversa não existe, o analista decide sozinho e quase sempre erra para o lado do risco, trazendo dado demais porque é mais fácil do que perguntar. Um bom encarregado quer exatamente o inventário, a base legal por finalidade e a política de retenção que descrevemos aqui, porque é isso que ele precisa mostrar à ANPD se o dia chegar. A tabela abaixo resume o checklist que a área de dados deveria fechar com ele.

Movimento	O que a área de dados entrega	Artigo da LGPD
Mapear	Inventário de dado pessoal e sensível por tabela e relatório	Base para tudo
Base legal	Finalidade e base legal declaradas por tratamento	Art. 7º e art. 11
Minimizar	Só o dado necessário no modelo, agregado quando possível	Art. 6º
Controlar acesso	RLS, OLS, rótulos do Purview, mascaramento	Princípio de segurança
Reter	Política de retenção, eliminação e anonimização	Eliminação após finalidade
Atender titular	Caminho técnico para acesso, correção e eliminação	Art. 18

Perguntas frequentes#

Preciso de consentimento do titular para usar os dados dele em BI? Nem sempre, e essa é a confusão mais cara. O consentimento é só uma das bases legais do art. 7º. Para painéis operacionais internos, cobrança, gestão de contrato e obrigações regulatórias, a base costuma ser execução de contrato, obrigação legal ou legítimo interesse, que não dependem de consentimento. Ele fica reservado a usos opcionais, como marketing, e depender dele para tudo é frágil, porque pode ser revogado a qualquer momento.

RLS no Power BI já me deixa em conformidade com a LGPD? Não sozinho. O RLS controla quais linhas cada usuário vê, mas não protege o dado armazenado no arquivo, não impede que quem tem edição no dataset o contorne, e não acompanha o dado depois que ele é exportado. Conformidade é a soma de minimização no ETL, RLS e OLS no modelo, rótulos do Purview na exportação, mascaramento na origem e retenção. Fazer só a camada mais fácil dá sensação de segurança, não segurança.

Qual a diferença entre dado pessoal e dado pessoal sensível na prática? Dado pessoal é qualquer informação que identifique ou torne identificável uma pessoa: nome, CPF, e-mail, matrícula. Dado sensível é uma lista fechada que inclui saúde, biometria, dado genético, origem racial, convicção religiosa e política, e filiação sindical. A diferença prática é a base legal: dado sensível só pode ser tratado nas hipóteses restritas do art. 11, onde legítimo interesse não entra.

Por quanto tempo posso manter dado pessoal no meu modelo de dados? Pelo tempo necessário à finalidade que justificou o tratamento, respeitando prazos de guarda que a regulação do seu setor imponha a certos registros. A LGPD pede eliminação após o fim da finalidade, mas isso convive com obrigações legais de reter. A regra saudável é guardar o que a norma exige pelo prazo que ela exige e anonimizar ou eliminar o restante, porque dado anonimizado sai do escopo da lei.

O que a área de dados faz quando um titular pede para apagar os dados dele? Localiza, confirma e elimina o dado daquela pessoa em todas as fontes e relatórios onde ela aparece, respeitando as guardas legais que obriguem a manter parte do registro. Isso só é viável com um inventário que diga em quais tabelas cada tipo de dado pessoal vive. Sem esse mapa, atender ao art. 18 vira improviso, e improviso em prazo legal é onde nasce o problema com a ANPD.

O encarregado (DPO) precisa entender de tecnologia? Ajuda muito, mas o desenho ideal é de parceria. O encarregado traz a leitura jurídica das bases legais, dos prazos e dos compartilhamentos, e a área de dados traz o mapa técnico de onde o dado está e como ele é controlado. O time técnico não deveria decidir base legal sozinho, e o encarregado não deveria escrever RLS. Cada um cobre o que o outro não enxerga.

Conformidade se constrói no pipeline, não no PDF#

LGPD para quem trabalha com dados não é um selo aplicado no fim do projeto nem um documento no rodapé do site. É base legal antes da primeira query, inventário vivo, minimização no ETL, RLS e OLS bem modelados, rótulos do Purview na saída, retenção que respeita a regulação, e uma relação de trabalho com o encarregado. Cada peça cobre o que a outra deixa passar, e a soma delas é a conformidade que a ANPD cobra.

Se você olha para os seus datasets e não consegue dizer com precisão quais colunas são dado pessoal, sob qual base estão ali e quem vê cada linha, esse é o momento de organizar antes que vire incidente. A Fynx faz esse trabalho unindo governança, engenharia de dados e Power BI no mesmo projeto. Fale com a gente e vamos mapear onde o seu ambiente está exposto e o que fechar primeiro.