LGPD na educação: dados de alunos e responsáveis nos relatórios

A planilha de notas vira um problema jurídico mais rápido do que parece#

LGPD na educação não é um debate abstrato de compliance: é a distância entre um painel de evasão que ajuda a coordenação e um vazamento de dados de crianças que rende sanção da ANPD e desgaste de marca. Escolas, universidades, redes de ensino e edtechs concentram alguns dos dados mais delicados que existem, como nome, CPF, endereço, nota, frequência, laudo médico, situação de bolsa e dados socioeconômicos, quase sempre de titulares menores de idade. Quando esses dados entram em um relatório de Power BI, eles ganham público, alcance e um poder de cruzamento que a planilha original não tinha. É exatamente nesse ponto que a maioria dos projetos de BI educacional escorrega.

Este texto é para quem constrói ou governa esses relatórios. Vou tratar o que a Lei nº 13.709/2018 realmente exige quando o assunto é dado de aluno e de responsável, e como traduzir isso em controles concretos dentro do Power BI e do ecossistema Microsoft. Sem teoria genérica: base legal, minimização, segurança em nível de linha e rótulos de confidencialidade do Microsoft Purview.

Nem todo dado de aluno pesa o mesmo na balança da LGPD#

O primeiro erro é tratar tudo como "dado do aluno" e aplicar o mesmo controle para o número de matrícula e para o laudo de um transtorno de aprendizagem. A LGPD separa duas categorias com consequências práticas diferentes. Dado pessoal é qualquer informação relacionada a pessoa natural identificada ou identificável, o que inclui nome, CPF, e-mail do responsável e até um identificador interno que permita chegar ao aluno. Dado pessoal sensível é a categoria reforçada: origem racial ou étnica, convicção religiosa, dado referente à saúde, dado sobre criança, entre outros, e é onde a lei aperta as exigências de base legal e de segurança.

No dia a dia de uma instituição de ensino, os dois convivem no mesmo modelo. Vale mapear antes de modelar:

Categoria na LGPD	Exemplos no contexto educacional	Implicação para o relatório
Dado pessoal	Nome, matrícula, CPF, e-mail e telefone do responsável, endereço	Precisa de base legal e de controle de acesso por perfil
Dado pessoal sensível	Saúde, laudos, necessidades especiais, origem racial declarada em cotas	Exige base legal reforçada, minimização agressiva e, quando possível, ausência total no modelo
Dado de criança e adolescente	Qualquer dado dos anteriores quando o titular é menor de 18 anos	Tratamento no melhor interesse e consentimento específico do responsável para os casos aplicáveis

A lição que passo para todo cliente de educação: dado sensível que não é indispensável ao indicador simplesmente não deve chegar ao modelo. Um dashboard de desempenho acadêmico raramente precisa do laudo médico do aluno. Ele precisa, no máximo, de uma marcação de "atendimento educacional especializado sim ou não", e mesmo essa flag merece discussão.

A base legal muda de figura quando o titular é criança ou adolescente#

Todo tratamento de dado pessoal precisa se apoiar em uma das bases legais do artigo 7º da LGPD, e o tratamento de dado sensível se apoia no rol mais restrito do artigo 11. Consentimento é apenas uma dessas bases, e muitas vezes nem é a melhor. Uma instituição de ensino executa contrato de prestação de serviço educacional, cumpre obrigações legais e regulatórias perante o MEC e os conselhos, e tem interesses administrativos que se enquadram em outras bases. Escolher a base correta importa porque ela define o que você pode fazer com o dado dentro do relatório.

O ponto que exige mais cuidado está no artigo 14, que trata do dado de criança e adolescente. A lei determina que esse tratamento seja feito no melhor interesse do titular e, nas hipóteses de consentimento, com consentimento específico e destacado dado por pelo menos um dos pais ou pelo responsável legal. Traduzindo para o BI: quando o titular é menor, a régua de justificativa sobe. Não basta que o dado seja útil para a gestão. Ele precisa servir ao interesse do próprio aluno, e o consentimento, quando é a base aplicável, tem que ser do responsável, não um "aceito" genérico coletado na matrícula online.

Situação típica na instituição	Onde costuma se apoiar	Cuidado extra no relatório
Nota, frequência e histórico para gestão acadêmica	Execução de contrato e obrigação legal	Restringir acesso por unidade, curso ou turma do responsável pelo dado
Comunicação de campanha para responsáveis	Legítimo interesse ou consentimento	Não misturar base de marketing com base acadêmica no mesmo modelo
Dado de saúde e necessidades especiais	Bases do artigo 11, no melhor interesse do aluno	Idealmente fora do modelo analítico, ou reduzido a uma flag mínima
Programas sociais e cotas	Base legal específica e finalidade determinada	Segregar o modelo e limitar acesso ao núcleo responsável

Este texto não substitui parecer jurídico, mas o recado técnico é claro: a arquitetura do seu BI tem que refletir a base legal e a finalidade de cada dado. Quando as duas divergem, o problema não se resolve com filtro no painel, se resolve na engenharia de dados, antes de o dado virar relatório.

Minimização é o controle que mais previne incidente#

O artigo 6º da LGPD lista os princípios que regem qualquer tratamento, e o da necessidade, que a prática chama de minimização, é o que mais economiza dor de cabeça em projeto de BI. Ele diz, em resumo, que o tratamento deve se limitar ao mínimo necessário para a finalidade. Aplicado ao Power BI, isso vira uma regra simples de arquitetura: o dado que não entra no modelo é o dado que nunca vaza.

Aqui entra uma característica técnica que muita gente ignora. O Power BI armazena os dados importados no motor VertiPaq, uma engine colunar em memória que comprime e guarda cada coluna do modelo. Esconder uma coluna no relatório com "ocultar" não a remove do VertiPaq: ela continua no arquivo, acessível por quem sabe consultar o modelo, exportar ou conectar via XMLA. Minimização de verdade acontece na origem, na etapa de transformação, quando você decide que aquela coluna de CPF ou de laudo simplesmente não é importada.

Na prática, minimização em BI educacional se traduz em algumas decisões concretas:

• Remover CPF, RG e endereço completo do modelo analítico quando o indicador não depende disso, usando um identificador substituto para as junções.
• Agregar antes de importar sempre que o relatório mostra totais por turma ou curso, evitando trazer a linha individual do aluno para o modelo.
• Substituir dado sensível por categoria mínima, como trocar o diagnóstico pelo indicador de necessidade de atendimento especializado, quando a flag já resolve a análise.
• Separar modelos por finalidade, mantendo o modelo de comunicação com responsáveis apartado do modelo de desempenho acadêmico.

Esse trabalho pertence à camada de engenharia de dados, não ao autor do relatório sob pressão de prazo. Quando a minimização acontece no pipeline, o relatório nasce enxuto e o risco cai antes de qualquer discussão sobre permissão de acesso.

RLS decide quem enxerga qual aluno dentro do mesmo relatório#

Minimização define o que existe no modelo. A segurança em nível de linha, o RLS (row-level security), define quem vê o quê dentro do que existe. É o controle que impede que a coordenadora da unidade A enxergue os alunos da unidade B, ou que um professor veja notas de turmas que não são dele, tudo no mesmo arquivo publicado.

O RLS funciona por meio de papéis (roles) com filtros escritos em DAX. Existem dois modelos, e a escolha entre eles define quanto o controle escala.

No RLS estático, você cria um papel por recorte e escreve o filtro fixo. Um papel "Unidade Sul" com o filtro [Unidade] = "Sul", outro papel para cada unidade. Funciona para poucos recortes estáveis, mas vira um pesadelo de manutenção quando a rede tem dezenas de unidades e centenas de professores.

No RLS dinâmico, existe um único papel e o filtro descobre quem é o usuário em tempo de execução. A função USERPRINCIPALNAME() retorna o identificador do usuário autenticado, normalmente o e-mail corporativo, e o filtro cruza esse valor com uma tabela de permissões que associa cada pessoa aos alunos, turmas ou unidades que ela pode ver. Um filtro do tipo [EmailResponsavel] = USERPRINCIPALNAME() na tabela de segurança propaga a restrição para o resto do modelo pelo relacionamento. Quando entra uma coordenadora nova, você não mexe no relatório: adiciona uma linha na tabela de permissões.

Aspecto	RLS estático	RLS dinâmico
Como o filtro é definido	Fixo por papel, escrito no modelo	Calculado em tempo real com USERPRINCIPALNAME()
Manutenção ao crescer	Cria um papel por recorte, vira gargalo	Uma tabela de permissões controla tudo
Quando usar	Poucos recortes estáveis	Muitos usuários, unidades e turmas
Risco principal	Papel esquecido ou desatualizado	Tabela de permissões com dado errado

Dois avisos que dou sempre. Primeiro, o RLS filtra linhas, ele não protege colunas nem o arquivo. Se o dado sensível está no modelo, um usuário com permissão de exportar leva a linha inteira que pode ver, incluindo colunas que você achou que estavam escondidas. Por isso RLS e minimização são complementares, não substitutos. Segundo, a identidade que o USERPRINCIPALNAME() devolve vem do Microsoft Entra ID, o serviço que autentica os usuários. RLS bem feito depende de uma base de identidade limpa, sem e-mails compartilhados por vários funcionários. Se cinco pessoas usam o mesmo login, o RLS não tem como distinguir quem é quem, e o controle desmorona. Vale conferir os detalhes desse desenho no nosso material de governança de dados no Power BI e LGPD.

Rótulos de confidencialidade protegem o dado que sai do Power BI#

RLS resolve o que acontece dentro do serviço do Power BI. O problema é que dado de aluno costuma sair de lá: alguém exporta para Excel, baixa o PDF, manda o arquivo por e-mail. No momento em que o dado deixa o workspace, o RLS deixa de valer. É aqui que entram os rótulos de confidencialidade do Microsoft Purview.

Os rótulos de confidencialidade, do Microsoft Purview Information Protection, são etiquetas como "Confidencial" ou "Restrito" que se aplicam ao próprio conteúdo e viajam com ele. Aplicado a um relatório do Power BI, o rótulo acompanha a exportação: o Excel ou o PDF gerado herda a classificação e as regras de criptografia e de restrição de acesso associadas ao rótulo. Um arquivo rotulado como "Restrito, dados de alunos" pode exigir autenticação para abrir e bloquear encaminhamento externo, mesmo depois de sair da instituição. É a diferença entre um controle que termina na fronteira do Power BI e um que persiste no arquivo.

Como os rótulos vivem no Purview e a identidade vive no Entra ID, o conjunto compõe uma cadeia de proteção coerente: o Entra ID diz quem é a pessoa, o RLS diz quais linhas ela vê, e o rótulo do Purview diz o que acontece com o dado quando ele sai. Nenhum dos três, sozinho, cobre o cenário completo. Estruturar essa cadeia é justamente o trabalho de uma frente de governança de dados, que conecta a política de proteção da instituição às configurações do tenant.

Um roteiro prático para colocar a LGPD na educação de pé no seu BI#

Para sair da teoria, este é o encadeamento que aplicamos em projetos de BI educacional, na ordem em que reduz risco de verdade:

1. Mapeie o dado antes de modelar, classificando cada campo como pessoal, sensível ou dado de menor, e registrando a finalidade e a base legal de cada um.
2. Minimize no pipeline, removendo ou agregando na origem tudo que o indicador não exige, com atenção especial ao dado sensível e ao VertiPaq.
3. Desenhe o RLS dinâmico apoiado em uma tabela de permissões, com identidades limpas no Entra ID e sem logins compartilhados.
4. Aplique rótulos de confidencialidade do Purview para proteger o dado que é exportado do relatório.
5. Documente e revise, mantendo o registro das operações de tratamento e revisando acessos a cada mudança de turma, unidade ou quadro de funcionários.

Nenhuma dessas etapas é um projeto de meses, mas todas dependem de uma base de Power BI bem estruturada. Adaptar a lei ao relatório depois que ele já está no ar é sempre mais caro e mais arriscado do que nascer certo.

Perguntas frequentes#

Preciso de consentimento do responsável para todo dado de aluno menor de idade? Não necessariamente. Consentimento é uma das bases legais, mas boa parte do tratamento acadêmico se apoia em execução de contrato e obrigação legal. O artigo 14 exige que o tratamento de dado de criança e adolescente seja feito no melhor interesse do titular, e o consentimento específico e destacado do responsável se aplica às hipóteses em que o consentimento é a base cabível. A definição da base correta para cada finalidade é uma conversa entre a área jurídica e a de dados.

RLS no Power BI é suficiente para cumprir a LGPD? Não. O RLS controla quais linhas cada usuário vê dentro do relatório, o que é essencial, mas não protege o dado depois que ele é exportado nem substitui a minimização. Uma estratégia sólida combina minimização na origem, RLS dinâmico para o acesso e rótulos de confidencialidade do Purview para o dado que sai do serviço.

Qual a diferença prática entre RLS estático e dinâmico para uma rede de ensino? O RLS estático cria um papel por recorte, com filtro fixo, e funciona quando os recortes são poucos e estáveis. O dinâmico usa um único papel com USERPRINCIPALNAME() e uma tabela de permissões, e escala muito melhor quando existem muitas unidades, turmas e professores. Para uma rede com dezenas de unidades, o dinâmico é quase sempre a escolha certa.

Esconder a coluna de dado sensível no relatório resolve? Não resolve. Ocultar uma coluna a remove da visão do usuário no relatório, mas ela continua armazenada no motor VertiPaq e acessível por exportação ou por conexão ao modelo. A forma correta de eliminar o risco é não importar o dado sensível para o modelo quando ele não é indispensável ao indicador.

O que os rótulos de confidencialidade do Purview fazem que o Power BI sozinho não faz? Eles classificam o conteúdo e fazem a proteção viajar com o arquivo. Quando um relatório rotulado é exportado para Excel ou PDF, o arquivo herda o rótulo e as regras de criptografia e restrição associadas, o que mantém o controle mesmo depois que o dado sai do serviço do Power BI. É a camada que cobre o cenário de vazamento por exportação.

Por onde começo se meus relatórios de aluno já estão no ar sem esses controles? Comece por um inventário: liste os relatórios que contêm dado pessoal e sensível de alunos e responsáveis, classifique os campos e identifique quem tem acesso hoje. A partir daí, priorize a minimização dos modelos com dado sensível e o desenho do RLS. Um diagnóstico estruturado evita retrabalho e mostra onde está o risco maior primeiro.

Onde isso te deixa#

LGPD na educação não se resolve com um aviso de privacidade no rodapé do painel. Ela se resolve na arquitetura: classificar o dado, minimizar na origem, controlar o acesso com RLS e proteger a saída com rótulos do Purview. Cada uma dessas camadas é técnica, verificável e implementável no ecossistema Microsoft que a maioria das instituições já usa. O que falta, quase sempre, é o desenho que amarra tudo antes de o primeiro relatório entrar no ar.

Se a sua instituição lida com dados de alunos e responsáveis em Power BI e quer colocar essa base no lugar certo, fale com a gente.