Reconhecimento facial sem guardar fotos: privacidade por design no GO Tatame

Toda academia perde tempo com chamada. Num jiu-jitsu com trinta alunos no tatame, são três a cinco minutos por aula só para saber quem veio — tempo que sai do aquecimento e não volta. A solução parece óbvia: uma foto da turma, reconhecimento facial, presença marcada em segundos.

Aí vem a pergunta difícil — e ela merece uma resposta honesta, não uma de marketing: “vocês vão guardar o rosto dos meus alunos num banco de dados?”

No GO Tatame — plataforma de gestão de academias desenvolvida por nós — a resposta honesta tem duas partes. O reconhecimento facial da chamada não guarda nenhuma foto: ele transforma cada rosto num descritor matemático e descarta a imagem na hora. Existe, sim, uma foto de perfil do aluno no sistema — mas ela é cadastrada com o consentimento do aluno ou do responsável, serve para o professor reconhecer quem é quem (não para a chamada automática) e pode ser removida a qualquer momento. Este artigo é sobre a primeira parte: reconhecer rostos sem reter imagens — e por que essa restrição produziu uma arquitetura melhor.

O problema não é técnico, é de confiança

Dado biométrico é dado sensível. A LGPD (art. 11) coloca biometria numa categoria especial, que exige base legal clara — em geral, consentimento explícito — e cuidado redobrado no tratamento. Na prática, guardar fotos de rosto cria um passivo enorme: um vazamento deixa de ser um incidente de segurança e vira um incidente de imagem, com pessoas reais expostas.

A maioria dos sistemas de reconhecimento facial trata isso como detalhe e mantém um banco de imagens de rosto para comparar. É aí que mora o risco — e é exatamente o que a chamada do GO Tatame não faz.

A virada: guardar o embedding, não a foto

Um modelo de reconhecimento facial não compara pixels. Ele converte um rosto em um embedding: um vetor de números que captura as características distintivas daquela face. Reconhecer alguém é comparar vetores — medir a distância entre o embedding da foto nova e os embeddings já conhecidos.

A consequência é a chave de tudo: depois de extrair o embedding, a foto não serve para mais nada. Então o fluxo descarta a imagem e mantém apenas os números. O que fica armazenado é uma lista de valores associada a um aluno — não uma imagem. Você não “vê” um rosto a partir disso.

Como funciona na prática

1. O professor tira uma foto da turma (upload ou webcam).
2. O sistema detecta cada rosto na imagem e extrai um embedding por rosto.
3. Cada embedding é comparado com os embeddings cadastrados dos alunos daquela turma.
4. O resultado é classificado em três níveis, com limiares de confiança configuráveis:
   • alta confiança — marca presença automaticamente;
   • em dúvida — pede confirmação ao professor;
   • desconhecido — sugere cadastro ou marcação manual.
5. O professor revisa e confirma antes de salvar qualquer presença. A IA sugere; a pessoa decide.
6. A foto da turma é descartada após o processamento. Permanece apenas o registro de presença e os embeddings — que já existiam do cadastro.

O “humano no loop” não é detalhe de UX: é o que mantém a responsabilidade da decisão com quem conhece a turma, e evita que um falso positivo vire um dado errado no histórico do aluno.

As decisões que a privacidade forçou — e que melhoraram o sistema

O mais interessante é que a restrição não atrapalhou a engenharia. Ela a deixou mais enxuta:

• Descartar a foto significa menos armazenamento, menos superfície de ataque e menos custo. Privacidade e simplicidade andaram na mesma direção.
• Até cinco embeddings por aluno, reforçados ao longo do tempo conforme ele aparece nas fotos, fazem o reconhecimento melhorar com o uso — sem nunca acumular mais imagens.
• Opt-in de verdade: aluno sem cadastro simplesmente não é sugerido, e sua presença é marcada à mão. Ninguém é arrastado para dentro do sistema.
• Direito ao esquecimento embutido: apagar o aluno apaga os embeddings e a foto de perfil que ele consentiu em cadastrar. Nada fica esquecido num bucket para vazar depois.
• Os embeddings são tratados como qualquer outro dado pessoal sensível, com a mesma proteção.

Por que isso vale além de academias

O padrão por trás dessa decisão é geral: processe o dado sensível, guarde só o mínimo derivado, descarte o bruto. Ele se aplica a qualquer sistema que toca informação delicada — documentos, voz, localização, saúde.

Minimização de dados não é só conformidade. É uma arquitetura que envelhece bem: o dado que você não guarda não vaza, não precisa ser criptografado e não vira passivo jurídico. A regulação, aqui, não foi obstáculo — foi a pergunta que levou ao desenho certo.

O resultado

• A chamada caiu de três a cinco minutos para menos de trinta segundos.
• A presença vira dado consistente, base para conversas de retenção — saber quem está sumindo antes de o aluno sumir de vez.
• E a biometria da chamada não retém nenhuma imagem — só descritores matemáticos.

É assim que a Dravit constrói: privacidade e arquitetura como fundação, não como remendo no fim do projeto. Tem um sistema que precisa tratar dado sensível sem virar um passivo? Vamos conversar.