Quando vi a notícia no Olhar Digital sobre a ANPD mandando o Paraná suspender o reconhecimento facial de alunos, minha primeira reação como dev foi: “demorou”. Não pelo moralismo, mas pelo aspecto técnico. Implementar biometria facial em crianças, em rede escolar pública, com dados sensíveis, é um prato cheio para vazamento. Vou destrinchar o que aconteceu, o que está por trás da decisão e, principalmente, o que dev e empresas de tech precisam aprender com isso.
O que aconteceu, sem enrolação
A Autoridade Nacional de Proteção de Dados (ANPD) determinou a suspensão imediata do uso de reconhecimento facial para registrar frequência de alunos na rede pública do Paraná. A medida proíbe coleta, consulta, comparação, uso e compartilhamento de dados biométricos de crianças e adolescentes até nova deliberação.
O governo estadual tem dez dias úteis para comprovar que parou de usar a biometria. Caso contrário, o caso vai para a área de sanções do órgão. Segundo a Secretaria de Educação do Paraná (Seed-PR), o sistema era um projeto-piloto e já tinha sido descontinuado em julho de 2026 com o fim do contrato com a fornecedora. Mas piloto ou não, o estrago regulatório já estava feito.
Os três motivos que a ANPD apontou são, na minha leitura, didáticos para qualquer dev que trabalhe com dados sensíveis:
- Falta de base legal para tratar dado biométrico (categoria especial sob a LGPD).
- Sem comprovação de segurança adequada no pipeline de processamento.
- Falhas de controle de acesso às imagens dos alunos.
Por que esse caso é um alerta técnico, não só jurídico
Biometria facial não é um “upload de foto”. Quando você captura a face de uma criança, você está extraindo um template biométrico — um vetor numérico que representa características únicas e irreversíveis. Diferente de uma senha, a face não pode ser trocada. Se vazar, acabou. Não existe “reset de face”.
E é aqui que mora o problema que a maioria das empresas ignora: muitos sistemas de reconhecimento facial em ambiente escolar foram implementados por integradores que tratam o pipeline como se fosse um CRUD comum. Não é. Você está lidando com dado que identifica unicamente uma pessoa para o resto da vida.
Na minha experiência revisando código de terceiros, os erros mais grotescos aparecem em três camadas:
- Edge sem criptografia forte: câmeras enviando frames para um servidor central sem TLS ou com certificados autoassinados expirados.
- Storage aberto: imagens e templates guardados em buckets S3 com permissões públicas ou em pastas sem controle de versionamento.
- API sem rate limiting e sem autenticação robusta: endpoints que devolvem matching biométrico com base em tokens simples ou, pior, sem token nenhum.
O aspecto legal que todo dev precisa entender
No Brasil, a LGPD (Lei 13.709/2018) classifica dado biométrico como dado sensível. Isso muda radicalmente as regras do jogo. Você só pode tratar esse tipo de dado quando se enquadra em uma das dez bases legais do artigo 11, e nenhuma delas é “porque facilita a gestão”.
Para crianças e adolescentes, existe ainda uma camada extra: o artigo 14 determina que o tratamento só pode ocorrer em interesse da criança, com consentimento específico e destacado de pelo menos um dos pais ou responsável legal. E o tratamento tem que ser limitado, no melhor interesse do menor.
Em outras palavras: se você é dev e está numa squad que vai implementar reconhecimento facial em escola, hospital pediátrico ou qualquer ambiente com menores, a primeira pergunta a fazer não é “qual biblioteca usar”. É: existe base legal real para isso? Se a resposta for “vamos pedir consentimento”, respire fundo e releia o artigo 11.
Na Prática: como reconhecimento facial funciona (e onde quebra)
Para entender o tamanho do risco, deixa eu mostrar um pipeline simplificado de detecção facial em JavaScript usando a biblioteca face-api.js. Não estou defendendo o uso em produção — pelo contrário. Estou mostrando o quão simples é montar um protótipo, o que explica por que tantas empresas acham que estão “prontas” para tratar esse dado.
// pipeline básico de detecção facial - NUNCA use em produção com menores
import * as faceapi from 'face-api.js';
async function carregarModelos() {
await faceapi.nets.tinyFaceDetector.loadFromUri('/models');
await faceapi.nets.faceLandmark68Net.loadFromUri('/models');
await faceapi.nets.faceRecognitionNet.loadFromUri('/models');
}
async function detectarRosto(videoElement) {
const deteccao = await faceapi
.detectSingleFace(videoElement, new faceapi.TinyFaceDetectorOptions())
.withFaceLandmarks()
.withFaceDescriptor();
if (!deteccao) return null;
// deteccao.descriptor = Float32Array com 128 valores únicos
// ESTE é o template biométrico - irrecuperável, irreversível
return {
descriptor: Array.from(deteccao.descriptor),
timestamp: Date.now(),
};
}
// comparação entre duas faces
function compararFaces(descriptorA, descriptorB) {
const distancia = faceapi.euclideanDistance(descriptorA, descriptorB);
// threshold típico: 0.6 = mesma pessoa
return distancia < 0.6;
}Repare no descriptor: 128 números float que representam a "impressão digital" daquela face. Esse array é o que vai pro banco de dados. Se alguém exfiltrar essa tabela, acabou. Você não consegue invalidar essa impressão. A criança vai carregar esse identificador biométrico comprometido pelo resto da vida.
E o pior: muitos sistemas armazenam tanto o template quanto a imagem original, multiplicando o vetor de ataque. A ANPD não está sendo paranoica — ela está sendo realista sobre o estado da arte de segurança em projetos-piloto educacionais.
Erros Comuns que devs cometem em sistemas biométricos
Depois de revisar dezenas de repositórios sobre o tema, compilei os deslizes mais frequentes. Salva essa lista para o próximo code review:
- Confundir autenticação com identificação: autenticação é "quem diz ser". Identificação é "quem é, independente do que diz". Reconhecimento facial em escola é identificação em massa — sempre. Tratar como autenticação é minimizar o risco.
- Armazenar imagens brutas junto com templates: duplica a superfície de ataque sem necessidade técnica real. O template sozinho já é suficiente para matching.
- Não implementar rotação e expiração de chaves criptográficas: dado biométrico encriptado com chave estática por 5 anos é um desastre esperando vazamento.
- Logar dados sensíveis: já vi sistema que gravava o descriptor completo no log de aplicação para "debug". Logs vazaram, processo judicial começou.
- Treinar modelo com faces de alunos sem anonimização: vira problema de proteção desde a concepção (Privacy by Design), e a ANPD pode alegar falha grave.
- Achar que "é só projeto-piloto": piloto com dado real é produção. LGPD não distingue. Não existe "ambiente de homologação com biometria de criança".
- Esquecer o direito de revogação: o titular pode pedir exclusão. Mas como você "deleta" um template se ele já foi usado para treinar modelo? Resposta: não dá. Por isso o princípio da necessidade.
Alternativas reais para controle de frequência escolar
Sistema de presença não precisa ser biométrico para funcionar bem. Existem abordagens menos invasivas e juridicamente mais seguras:
- Cartão RFID/NFC com chip próprio do aluno — identificador pseudonimizado, facilmente revogável.
- QR Code dinâmico gerado por app institucional, com rotação a cada 30 segundos.
- Totem com PIN + selfie descartável: a selfie é descartada após matching local, sem persistência.
- Reconhecimento facial on-device: processamento 100% local no dispositivo, sem envio para servidor. Reduz drasticamente o risco, mas ainda exige cuidado com armazenamento local.
- Geolocalização + check-in manual: simples, barato, LGPD-friendly para ensino remoto.
O ponto não é "biometria é ruim". O ponto é: o risco da implementação típica supera o benefício operacional. Para controle de frequência, onde existe alternativa menos invasiva, a LGPD exige que você escolha a menos invasiva. Isso está no artigo 6º, princípio da necessidade.
O que o ecossistema de tech precisa absorver desse caso
Quando a ANPD publica uma decisão como essa, o efeito cascata atinge todo o mercado. Integradoras que vendem "solução de frequência com IA" para prefeituras vão precisar revisar contratos, cláusulas e arquitetura. Fornecedores de modelo de visão computacional precisam começar a entregar provas de segurança e conformidade, não só acurácia.
Na minha rotina como dev, isso muda três coisas imediatamente:
- Code review de feature biométrica passa a exigir DPO (Data Protection Officer) acompanhando desde o PRD, não só no fim.
- Refatoração de sistemas legados que coletaram biometria sem base legal clara: deletar é a única saída, mesmo que doa.
- Critérios de aceite em projeto precisam incluir perguntas como "qual a base legal?" e "existe alternativa menos invasiva?" antes da linha de código ser escrita.
FAQ — Perguntas que devs reais fariam
Reconhecimento facial é proibido no Brasil?
Não é proibido em si. É dado sensível sob a LGPD, então só pode ser tratado com base legal específica (consentimento destacado, interesse público, exercício regular de direitos, entre outros) e com todos os cuidados de segurança, finalidade e minimização. Em ambiente escolar com menores, a barreira é altíssima.
Posso usar reconhecimento facial só internamente, sem compartilhar com terceiros?
Compartilhamento é só uma das etapas vetadas pela ANPD no caso paranaense. O uso, a coleta e a comparação também foram suspensos. O problema não é só para onde vai o dado, é o tratamento em si.
Qual a diferença entre dado biométrico e dado pessoal comum na prática?
Dado pessoal identificável pode ser trocado (você muda de e-mail). Dado biométrico é permanente e único. Se vazar, não tem reset. É como se a "senha" do usuário fosse a própria biologia dele.
OpenCV ou face-api.js podem ser usadas em projetos comerciais com crianças?
A biblioteca em si não é o problema. O tratamento do dado coletado por ela é. Você pode usar a ferramenta tecnicamente, mas a responsabilidade jurídica recai sobre quem define a finalidade, o armazenamento e o ciclo de vida do dado.
Se eu apagar o template biométrico, o dado realmente some?
Depende. Se o template foi usado para treinar um modelo, o resíduo informacional pode persistir nos pesos da rede neural. Por isso existe o conceito de "machine unlearning", ainda em evolução. A saída mais segura é nunca ter coletado sem base legal clara.
Como cobrar do cliente que ele não precisa de biometria?
Mostra o TCO real: custo de adequação à LGPD, custo de auditoria, risco reputacional de vazamento, custo de rescisão em massa se a ANPD intervenir. Em geral, a conta fecha mais barata com RFID ou QR Code. E ninguém processa você por usar um cartão.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.