LGPD e dado sensível no setor financeiro

O CPF do cliente aparece no relatório e ninguém sabe quem pode ver#

Em banco, cooperativa, financeira ou fintech, a cena se repete. Um analista abre um dashboard de carteira, e ali estão CPF, nome, saldo devedor e histórico de atraso de cada cliente, visível para qualquer pessoa com o link do workspace. Ninguém decidiu que seria assim. Foi a consequência de publicar um relatório rápido sem pensar em quem tinha acesso a quê. Quando se fala em LGPD setor financeiro, é esse descuido silencioso que vira multa, incidente e desgaste com o cliente. O risco raramente é o hacker externo, é o acesso interno indevido que ninguém mapeou. Este artigo é sobre tratar dado pessoal e financeiro em BI de forma que a proteção seja parte do modelo, não um remendo aplicado depois que alguém reclamou.

Dado financeiro não é dado sensível, e essa distinção muda a lei que se aplica#

Aqui mora o primeiro erro comum. Muita gente no setor chama saldo, limite e score de "dado sensível" por hábito. Pela Lei nº 13.709/2018, a LGPD, isso está errado, e a confusão leva a decisões ruins. A lei separa três categorias.

Dado pessoal é qualquer informação que identifique ou torne identificável uma pessoa natural: nome, CPF, e-mail, endereço. Dado pessoal sensível é uma categoria fechada, definida no art. 5º, II: origem racial ou étnica, convicção religiosa, opinião política, filiação a sindicato, dado de saúde, vida sexual, dado genético ou biométrico. Saldo bancário, renda e score de crédito não estão nessa lista. São dado pessoal comum.

Isso não quer dizer que dado financeiro seja de baixo risco. Quer dizer que a proteção dele não vem da classificação de "sensível" da LGPD, e sim de outra camada: o sigilo bancário, disciplinado pela Lei Complementar nº 105/2001, que impõe às instituições financeiras o dever de guardar sigilo sobre operações ativas e passivas e serviços prestados. Na prática, o dado financeiro carrega uma obrigação legal própria, independente e às vezes mais rígida que a da LGPD, e tratá-lo como "só mais uma coluna" é o caminho mais curto para um problema.

A consequência para o BI é direta. Se o relatório cruza dado de saúde, por exemplo num seguro ou consignado com informação médica, você entrou no território de dado sensível e precisa de base legal específica. Se trata só de saldo e inadimplência, o desafio é sigilo bancário e controle de acesso.

Em LGPD setor financeiro, a base legal vem antes do dashboard#

Nenhum tratamento de dado pessoal se sustenta sem uma base legal. O art. 7º da LGPD lista dez hipóteses que o autorizam, e no setor financeiro três ou quatro concentram quase tudo. A pergunta que o projeto precisa responder, antes da primeira query, é simples: por que esse dado está aqui e com que autorização.

Base legal (art. 7º)	Quando se aplica no BI financeiro	Cuidado prático
Cumprimento de obrigação legal ou regulatória	Reportes ao Banco Central, prevenção à lavagem de dinheiro, retenção fiscal	A finalidade é a norma, não o interesse comercial. Não use como base coringa
Execução de contrato	Gestão da carteira do próprio cliente, cobrança, cálculo de juros	Só cobre o titular da relação contratual, não terceiros
Legítimo interesse	Prevenção a fraude, análise de risco agregada, melhoria de produto	Exige teste de proporcionalidade documentado e não vale para dado sensível
Consentimento	Marketing, ofertas cruzadas, uso secundário do dado	Precisa ser específico, revogável e registrado. É a base mais frágil

O erro que mais vejo é usar consentimento para tudo. Ele é a base mais difícil de sustentar, porque o titular pode revogá-la a qualquer momento, e aí o dado precisa sair do modelo. Em crédito, execução de contrato e obrigação legal cobrem a maior parte do necessário, sem depender de um "aceito" que o cliente pode retirar. Consentimento fica para o opcional, como oferta de outro produto. Se a sua casa ainda não tem esse mapa, um trabalho de governança de dados é o lugar certo para construí-lo antes de publicar relatório.

RLS deixou de ser opcional no Power BI financeiro#

Definida a base legal, o controle de acesso é o próximo pilar. No Power BI, isso se chama Row Level Security, a segurança em nível de linha: o mesmo relatório mostra dados diferentes dependendo de quem abre. O gerente de Recife vê a carteira de Recife, e não a carteira nacional inteira.

O RLS estático usa papéis fixos com filtros escritos na mão. Você cria um papel "Região Sul" com o filtro Regiao = "Sul" e adiciona os usuários daquela região. Funciona bem com poucos grupos estáveis. O problema aparece quando são cinquenta gerentes: manter cinquenta papéis vira trabalho manual e fonte de erro.

O RLS dinâmico resolve isso. Em vez de um papel por grupo, você usa uma tabela de mapeamento que associa cada usuário à sua carteira, e um único papel com um filtro que lê a identidade de quem abriu o relatório pela função USERPRINCIPALNAME(). O filtro fica parecido com [GerenteEmail] = USERPRINCIPALNAME(). Um papel só, e a tabela faz o resto: quando entra um gerente novo, você adiciona uma linha, não um papel. Para o setor financeiro, onde a estrutura de carteiras muda toda hora, RLS dinâmico é quase sempre a resposta certa.

Um alerta que economiza dor de cabeça: RLS filtra linhas, não protege o dado no armazenamento, e quem tem direito de edição no dataset pode contorná-lo. Por isso ele anda de mãos dadas com a governança do workspace e com os grupos do Microsoft Entra ID, onde as identidades vivem e onde USERPRINCIPALNAME() busca quem é o usuário. RLS bem feito exige modelagem limpa, e vale revisar as boas práticas de modelagem e DAX antes, porque um modelo mal desenhado transforma segurança de linha em pesadelo de performance.

Mascaramento resolve a exibição, não resolve o acesso#

RLS decide quais linhas o usuário vê. Mascaramento decide como o valor de uma coluna aparece. São complementares. Um analista com direito de ver a linha de um cliente para a cobrança não precisa do CPF inteiro na tela: 123.***.***-45 já basta.

No banco de origem, o SQL Server oferece o Dynamic Data Masking, que mascara colunas sensíveis de forma que usuários sem o privilégio de desmascarar vejam só a versão ofuscada, protegendo o dado antes mesmo de ele chegar ao Power BI.

Duas ressalvas honestas. Primeiro, o Dynamic Data Masking mascara a apresentação, não criptografa nem impede que um usuário privilegiado recupere o valor. Reduz exposição casual, não é controle forte por si só. Segundo, e mais importante para BI: ao importar o dado, o Power BI o passa pelo motor VertiPaq, que o armazena comprimido dentro do arquivo do modelo. Se o CPF entrou em claro, ele está lá em claro, mascarado ou não na tela. A regra é dura mas correta: o dado que o relatório não precisa mostrar não deveria entrar no modelo. Mascare ou remova na camada de engenharia de dados, no ETL, antes do VertiPaq.

Rótulos do Purview levam a proteção para fora do relatório#

RLS e mascaramento protegem o dado dentro do Power BI. O problema é que o dado sai do Power BI. Alguém exporta para Excel, cola num e-mail, salva no desktop. É nesse momento que a maioria dos controles evapora, e é aqui que os rótulos de confidencialidade do Microsoft Purview entram.

Um rótulo é uma classificação que viaja com o arquivo. Você define uma taxonomia, por exemplo "Público", "Interno", "Confidencial" e "Restrito", aplica o rótulo ao dataset e ao relatório, e a classificação acompanha o dado exportado para Excel ou PowerPoint. Mais do que rotular, o Purview acopla proteção ao rótulo: criptografia, restrição de quem abre o arquivo, bloqueio de exportação, herança do rótulo da origem. Uma carteira "Restrito" pode simplesmente não permitir exportação, ou gerar um arquivo que só abre para quem está no grupo autorizado do Entra ID.

Para o setor financeiro isso fecha o buraco que RLS sozinho não fecha: o dado que já saiu da plataforma. Montar essa taxonomia e conectá-la ao ciclo de vida dos relatórios é parte de um trabalho maior de governança de dados e LGPD no Power BI, não um botão que se liga numa tarde.

O dado mais seguro é o que você decidiu não guardar#

Todo o resto deste artigo é sobre proteger dado que existe. A LGPD, no art. 6º, pede algo anterior: os princípios de finalidade, adequação e necessidade. A necessidade, ou minimização, diz que você deve tratar apenas os dados estritamente necessários para a finalidade. Traduzindo para BI: se o painel de inadimplência por região não precisa do CPF, o CPF não deveria estar no modelo. Ponto.

Isso soa óbvio e quase nunca é praticado. O padrão do mercado é trazer a tabela inteira do core porque "vai que precisa depois", e cada coluna de dado pessoal sem finalidade clara é risco assumido de graça. Minimização não é burocracia, é redução real da superfície de exposição: menos dado no modelo é menos coisa para vazar, auditar e explicar num incidente.

O par natural da minimização é a retenção. A LGPD prevê que o dado seja eliminado após o fim da finalidade que o justificou, com ressalvas legais, e no setor financeiro há prazos regulatórios que obrigam guardar certos registros por anos. As duas coisas convivem: você retém o que a norma exige pelo prazo que ela exige e anonimiza ou elimina o resto. Um modelo que acumula dado pessoal indefinidamente "porque dá" está fora de conformidade e, de quebra, mais caro de manter.

A tabela abaixo resume onde cada mecanismo protege e onde ele para.

Camada	Mecanismo	O que protege	Onde não protege
Origem	Dynamic Data Masking no SQL Server	Exibição casual da coluna na consulta	Não criptografa nem impede acesso privilegiado
Modelo	Minimização no ETL antes do VertiPaq	Reduz o dado pessoal que existe no dataset	O que já entrou continua no arquivo
Acesso	RLS estático e dinâmico com USERPRINCIPALNAME()	Quais linhas cada usuário enxerga	Usuário com edição no dataset pode contornar
Exportação	Rótulos de confidencialidade do Purview	O dado depois que sai da plataforma	Depende de configuração e adoção corretas
Ciclo de vida	Política de retenção e eliminação	Reduz risco acumulado ao longo do tempo	Precisa respeitar prazos regulatórios do setor

Nenhuma linha protege sozinha. Segurança de dado no BI financeiro é a soma delas, e um projeto sério trata as cinco, não só a mais fácil de ligar.

Perguntas frequentes#

Dado financeiro como saldo e score é dado sensível pela LGPD? Não. A LGPD, no art. 5º, II, define dado sensível como uma lista fechada que inclui saúde, biometria, dado genético, convicção religiosa e política, entre outros. Saldo, renda e score são dado pessoal comum. A proteção deles vem principalmente do sigilo bancário da Lei Complementar nº 105/2001, e você o protege com rigor, mas pelo motivo certo.

RLS no Power BI é suficiente para atender a LGPD no setor financeiro? Não sozinho. O RLS controla quais linhas cada usuário vê, mas não protege o dado no armazenamento nem depois que ele é exportado, e quem tem direito de edição no dataset pode contorná-lo. Ele precisa vir acompanhado de minimização no ETL, mascaramento na origem, rótulos do Purview e governança de workspace no Microsoft Entra ID.

Qual a diferença prática entre RLS estático e dinâmico? O estático usa papéis fixos com filtros escritos manualmente, bom para poucos grupos estáveis. O dinâmico usa uma tabela que mapeia usuário para carteira e um único papel que lê a identidade com USERPRINCIPALNAME(). No setor financeiro, com muitas carteiras e troca frequente de gerentes, o dinâmico é quase sempre a escolha certa, porque você administra linhas de uma tabela em vez de dezenas de papéis.

O mascaramento no Power BI resolve o problema de exposição do CPF? Só em parte. Se o CPF entrou no modelo, ele está armazenado no VertiPaq dentro do arquivo, mascarado ou não na tela. A proteção de verdade é não trazer o dado desnecessário. Se o relatório não precisa do CPF completo, ele deve ser removido ou mascarado na engenharia de dados, antes de chegar ao Power BI.

Preciso de consentimento do cliente para usar os dados dele em BI? Depende da finalidade. Para gestão da própria carteira, cobrança e obrigações regulatórias, a base costuma ser execução de contrato ou obrigação legal, que não dependem de consentimento. Ele fica reservado a usos opcionais, como marketing e ofertas cruzadas, e usá-lo como base para tudo é frágil, porque o titular pode revogá-lo.

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

Conformidade em BI se constrói no modelo, não no discurso#

Proteger dado pessoal e financeiro em BI não é um selo aplicado no fim do projeto. É base legal antes da primeira query, RLS dinâmico bem modelado, minimização no ETL, mascaramento na origem, rótulos do Purview e retenção que respeita a regulação. Cada peça cobre o que a outra deixa passar. Fazer só uma é ter a sensação de conformidade sem a conformidade.

Se você olha para os seus relatórios de carteira e não sabe dizer com precisão quem vê o quê e com que base legal, esse é o momento de organizar isso 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.