LGPD na saúde: como proteger dado de paciente nos relatórios de BI

Um relatório de ocupação de leitos não deveria expor o CPF de ninguém#

Em saúde, o dashboard mais inofensivo costuma carregar o dado mais perigoso. Alguém pede um relatório de ocupação de leitos, taxa de reinternação ou tempo médio de permanência, e a base por trás traz nome do paciente, CPF, número do prontuário, CID da doença e o médico responsável. Quando esse relatório vai para um workspace compartilhado no Power BI, sem controle de acesso por linha, qualquer pessoa com o link enxerga tudo. É aqui que a LGPD na saúde deixa de ser tema jurídico e vira problema de arquitetura de BI.

A Lei nº 13.709/2018 (LGPD) trata dado de saúde como dado pessoal sensível, na mesma categoria de origem racial, convicção religiosa e biometria. Isso muda o jogo: dado sensível tem base legal mais restrita, exige mais cuidado técnico e concentra as multas mais altas da ANPD. Um relatório de BI que expõe diagnóstico associado a um paciente identificável é, na prática, um vazamento esperando para acontecer. Este artigo é sobre como evitar isso usando recursos reais do Power BI e do ecossistema Microsoft, sem teatro de compliance.

Dado de saúde é dado sensível, e isso tem consequência prática#

O artigo 5º da LGPD define dado pessoal sensível e coloca "dado referente à saúde" na lista. O artigo 11 estabelece que o tratamento desse tipo de dado só pode ocorrer em hipóteses específicas: consentimento destacado, tutela da saúde por profissional ou serviço de saúde, cumprimento de obrigação legal, entre outras. Não é uma formalidade. Significa que, para cada relatório que toca dado de paciente, você precisa saber qual é a base legal e quem tem necessidade real de ver aquilo.

Na prática de BI, três consequências aparecem sempre:

• Minimização. O relatório deve conter só o necessário para a finalidade. Se o objetivo é medir taxa de ocupação, não há motivo para o CPF estar no modelo.
• Necessidade de conhecer. Acesso por função, não por conveniência. O analista financeiro não precisa ver o CID; o médico da UTI não precisa ver o custo consolidado do plano.
• Rastreabilidade. Você tem que conseguir provar quem acessou o quê. Sem log, não há defesa possível diante da ANPD.

A boa notícia é que o Power BI, integrado ao Microsoft Entra ID e ao Microsoft Purview, cobre esses três pontos com recursos nativos. A má notícia é que quase ninguém configura direito.

A anonimização certa acontece antes do dado chegar ao relatório#

O erro mais comum é tentar "esconder" a coluna sensível no visual, mantendo-a no modelo. Não funciona: quem tem acesso ao dataset consegue exportar, criar uma nova página ou consultar via XMLA. Proteção de verdade começa na camada de dados, idealmente na engenharia de dados, antes do Power BI.

A LGPD trabalha com dois conceitos que você precisa separar:

Técnica	O que faz	Ainda é dado pessoal?	Uso típico em BI
Anonimização	Remove de forma irreversível a ligação com o titular	Não, sai do escopo da LGPD (art. 12)	Relatórios agregados, indicadores públicos, benchmarking
Pseudonimização	Substitui identificadores por chaves, ligação reversível com chave separada	Sim, continua protegido pela LGPD	Análises longitudinais, coorte de pacientes, pesquisa interna

Anonimização real é difícil. Remover o CPF não basta se a combinação de bairro, idade e data de internação permite reidentificar a pessoa. Para dado que precisa manter rastreabilidade entre atendimentos, a pseudonimização costuma ser a escolha certa: troque o CPF por um id_paciente gerado por hash, guarde a tabela de correspondência em cofre separado, e o modelo de BI nunca vê o identificador original.

Boas práticas que aplicamos em projetos de saúde:

• Camada de transformação separada. Faça a anonimização e o mascaramento no pipeline (Dataflow, notebook no Fabric ou ETL na engenharia de dados), não no relatório.
• Colunas sensíveis fora do modelo por padrão. Inclua CPF, nome e prontuário só quando houver justificativa documentada de finalidade.
• Generalização de quase-identificadores. Idade em faixas, data em mês ou trimestre, CEP truncado. Reduz risco de reidentificação sem matar a análise.
• Cardinalidade a favor da compressão. Como o motor VertiPaq comprime melhor colunas de baixa cardinalidade, substituir CPF por chave hash costuma até melhorar o desempenho do modelo, além de proteger o dado.

Se você ainda está desenhando essa camada, vale conhecer nosso trabalho de engenharia de dados, porque é ali que a proteção nasce robusta.

RLS é o coração do controle de acesso por linha no Power BI#

Row-Level Security (RLS) é o recurso do Power BI que restringe quais linhas cada usuário enxerga dentro do mesmo relatório. Em saúde, é indispensável: permite que o gestor de uma unidade veja só os pacientes da sua unidade, que cada médico veja só os seus, e que o time de auditoria veja tudo, todos no mesmo dataset.

Funciona assim: você cria papéis (roles) no modelo semântico e associa a cada papel uma expressão DAX de filtro sobre uma tabela. Um filtro comum de RLS dinâmico usa a função USERPRINCIPALNAME() para comparar o e-mail do usuário logado com uma coluna de responsável:

[Email_Responsavel] = USERPRINCIPALNAME()

Há dois modos, e a diferença importa:

Tipo de RLS	Como funciona	Quando usar
RLS estático	Um papel com filtro fixo por valor (ex.: [Unidade] = "Hospital Norte")	Poucos grupos estáveis, times pequenos
RLS dinâmico	Filtro resolvido em tempo de execução pelo usuário logado, via tabela de mapeamento	Muitos usuários, hierarquia de acesso, escala

Pontos que a gente sempre reforça com o cliente:

• RLS filtra linhas, não colunas. Ele não esconde o CPF de quem tem acesso à linha. Se a coluna não deve ser vista por ninguém naquele relatório, ela não deveria estar no modelo. Para restrição de coluna, o caminho é object-level security (OLS) ou remover a coluna na origem.
• Teste com "Exibir como". O Power BI Desktop permite simular cada papel. Em saúde, testar RLS não é opcional, é parte do aceite.
• Cuidado com bidirecional. Relacionamentos bidirecionais podem furar o filtro de RLS. Modele com atenção; nosso material sobre modelagem e boas práticas de DAX ajuda a evitar armadilhas.
• Administrador de workspace ignora RLS ao editar. Quem edita o dataset vê tudo. Controle quem é admin.

Workspaces e Entra ID definem quem entra antes de o RLS decidir o que vê#

RLS controla o que a pessoa vê depois de entrar. Antes disso, quem entra é decidido pela estrutura de workspaces e pelo Microsoft Entra ID (antigo Azure Active Directory). Errar aqui torna o RLS irrelevante.

A organização que recomendamos para ambientes de saúde:

• Separe ambientes por workspace. Desenvolvimento, homologação e produção em workspaces distintos, com pipeline de deployment entre eles. Dado real de paciente não deveria circular em ambiente de desenvolvimento.
• Acesso por grupo do Entra ID, nunca por usuário nominal. Conceda permissão a grupos de segurança, não pessoa por pessoa. Entrada e saída de gente na equipe passa a ser gerida no Entra, e o acesso ao BI acompanha automaticamente.
• Use os papéis do workspace com parcimônia. Admin, Member, Contributor e Viewer têm poderes diferentes. Para consumidores de relatório, Viewer basta, e Viewer respeita RLS.
• Exija MFA e acesso condicional. Autenticação multifator via Entra ID e políticas de acesso condicional (bloquear país, exigir dispositivo gerenciado) são camadas baratas e eficazes contra acesso indevido.
• Publique via app, não compartilhando o workspace. Distribua relatórios por meio de um Power BI App, mantendo o workspace de edição fechado ao time técnico.

Essa arquitetura de acesso é parte do que estruturamos em projetos de governança de dados, e é o alicerce sobre o qual o RLS de fato funciona.

Rótulos do Microsoft Purview classificam e protegem o dado onde quer que ele vá#

RLS e workspaces protegem o dado dentro do Power BI. O problema aparece quando alguém exporta para Excel ou PDF: o dado sensível sai do perímetro controlado. É aí que entram os rótulos de confidencialidade (sensitivity labels) do Microsoft Purview.

Rótulos são classificações (por exemplo, "Público", "Interno", "Confidencial", "Restrito, Dados de Saúde") que você aplica a datasets, relatórios e dashboards. O ganho real é que o rótulo viaja com o arquivo: ao exportar um relatório rotulado como "Restrito" para Excel, a proteção de criptografia e as restrições de uso definidas na política do Purview acompanham o arquivo exportado. Um documento que vaza continua criptografado e inacessível a quem está fora da política.

O que dá para fazer com Purview integrado ao Power BI:

• Classificação obrigatória. Configurar política que exige rótulo antes de publicar, evitando dataset sensível sem classificação.
• Herança de rótulo. Um relatório construído sobre dataset "Restrito" herda a classificação, reduzindo erro humano.
• Proteção na exportação. Criptografia e controle de uso que persistem no arquivo exportado, via integração com Microsoft Purview Information Protection.
• Descoberta e inventário. Mapear onde há dado sensível no tenant, útil para o relatório de impacto à proteção de dados (RIPD) exigido pela LGPD.

Vale um alerta honesto: rótulos exigem licenciamento adequado (recursos de Information Protection costumam depender de planos como o Microsoft 365 E5 ou add-ons de compliance) e uma taxonomia bem pensada. Rótulo demais ninguém usa, rótulo de menos não protege.

Retenção, log e auditoria fecham o ciclo#

Proteger o acesso é metade do trabalho. A LGPD também exige que você não guarde dado além do necessário e que consiga demonstrar o que aconteceu com ele.

• Log de auditoria. O log unificado do Microsoft Purview e o log de atividades do Power BI registram quem acessou, exportou e compartilhou cada relatório. Ative e retenha esses logs; são a sua prova documental.
• Política de retenção. Defina por quanto tempo cada base fica disponível no BI e automatize o expurgo. Dado de paciente mantido "por precaução" é passivo, não ativo.
• Revisão periódica de acesso. Trimestralmente, revise quem está em cada grupo do Entra ID. Acesso herdado de projeto antigo é a origem mais comum de exposição.
• Encarregado no loop. O DPO (encarregado) precisa ter visibilidade da arquitetura de BI, não só dos contratos.

Se o volume e a criticidade justificam uma plataforma unificada, o Microsoft Fabric, anunciado em 2023, concentra ingestão, armazenamento no OneLake e consumo com o modo Direct Lake sob uma mesma camada de governança, o que simplifica a aplicação de rótulos e linhagem de ponta a ponta. Avaliamos se faz sentido no seu caso em nosso conteúdo sobre Microsoft Fabric.

Como as camadas se encaixam#

Vale fixar a ideia de que nenhuma dessas camadas sozinha resolve. Elas se complementam:

Camada	Protege contra	Recurso Microsoft
Anonimização e pseudonimização	Exposição do identificador direto	Pipeline de dados, Dataflow, Fabric
RLS	Ver linhas de outros pacientes ou unidades	Power BI, DAX, USERPRINCIPALNAME()
Workspaces e acesso	Entrar onde não deveria	Entra ID, grupos, acesso condicional, MFA
Rótulos de confidencialidade	Vazamento na exportação	Microsoft Purview Information Protection
Log e retenção	Não conseguir provar nem expurgar	Purview audit, log de atividades

Uma opinião de quem faz isso na prática: a maioria dos incidentes que vemos não vem de ataque sofisticado, vem de configuração preguiçosa. Workspace aberto, coluna sensível esquecida no modelo, grupo do Entra sem revisão. A tecnologia da Microsoft, reconhecida como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e BI, entrega tudo o que você precisa. O que falta, quase sempre, é disciplina de governança.

Perguntas frequentes#

A LGPD proíbe usar dado de paciente em relatórios de BI? Não. A LGPD permite o tratamento de dado de saúde nas hipóteses do artigo 11, como a tutela da saúde por serviço de saúde. O que ela exige é base legal definida, finalidade clara, minimização e segurança adequada. BI com dado de paciente é legítimo quando bem governado.

RLS sozinho é suficiente para conformidade com a LGPD na saúde? Não. RLS controla quais linhas cada usuário vê, mas não esconde colunas de quem tem acesso à linha, não protege a exportação e não classifica o dado. Ele é uma peça importante, combinada com anonimização na origem, controle de acesso no Entra ID e rótulos do Purview.

Qual a diferença prática entre anonimização e pseudonimização? Dado anonimizado perde de forma irreversível a ligação com o titular e sai do escopo da LGPD (art. 12). Dado pseudonimizado troca o identificador por uma chave reversível e continua sendo dado pessoal protegido. Para análise que precisa acompanhar o mesmo paciente ao longo do tempo, use pseudonimização.

Preciso de licença específica para usar rótulos de confidencialidade? Sim. Os recursos de rótulos e proteção do Microsoft Purview Information Protection dependem de licenciamento adequado, geralmente planos como o Microsoft 365 E5 ou add-ons de compliance. O consumo de relatórios ainda depende de Power BI Pro ou PPU por usuário. Confirme sempre as condições vigentes na fonte oficial da Microsoft, pois variam.

Como provo para a ANPD que o acesso ao dado está controlado? Com log. O log de auditoria do Microsoft Purview e o log de atividades do Power BI registram acessos, exportações e compartilhamentos. Combine isso com a documentação da base legal, do RIPD e da política de retenção. Sem registro, não há como demonstrar conformidade.

Dá para usar dado real de paciente em ambiente de desenvolvimento? A recomendação é não usar. Separe workspaces de desenvolvimento, homologação e produção, e use dado sintético ou anonimizado em desenvolvimento. Dado real de paciente deve viver apenas em produção, com todos os controles ativos.

Onde isso costuma travar#

Proteger dado de paciente em BI não é comprar uma ferramenta, é encadear anonimização, RLS, controle de acesso, rótulos e auditoria com disciplina. A Fynx faz isso há 6 anos, com mais de 50 clientes e mais de 2.000 soluções Microsoft entregues, e sabe onde cada uma dessas camadas costuma falhar na prática. Se você tem relatórios de saúde rodando sem essa arquitetura, ou não tem certeza de quem enxerga o quê, fale com a gente e vamos revisar o seu ambiente.