LGPD
A Hummand é operadora; o cliente é o controlador. Dado biométrico é sensível,
e o desenho responde a isso: nada de imagem ou template depois do ato.
A pessoa consente por etapa, com texto versionado; a Hummand guarda hashes, não dados; e o que precisa morrer, morre por destruição de chave, registrada. Os direitos do titular que ainda não conseguimos atender estão escritos aqui.
Hash é um código que identifica um dado sem revelá-lo; destruir a chave de um registro torna o dado ilegível para sempre.
O registro de tratamento e o relatório de impacto foram preenchidos pelo encarregado de dados em 2026-09-21, e os prazos de retenção valem em produção. O canal do titular é [email protected].
Consentimento
Descrição
Duas camadas, na ordem certa: geral antes de qualquer coisa, biométrico antes de qualquer captura. Sem o biométrico, o resultado não é liberado.
1.0Geral e biométricodisponível
Textos versionados. Cada aceite grava o instante, o hash do texto e a versão, e o recibo os carrega. O consentimento geral nunca desbloqueia biometria.
2.0Transparência do contextodisponível
Antes de consentir, a pessoa vê o que está autorizando: o contexto que o cliente mandou, em claro só para ela. No registro fica o hash e a lista das chaves lidas pela política.
3.0Escopo do mandatodisponível
No mandato a agente e no mandato de pessoa, o aceite ao escopo é uma camada própria, distinta do consentimento da jornada, e vai no recibo do mandato.
4.0Textos e revisão
Os textos são versionados por camada: geral v1-2026-08, biométrico v1-2026-06 e escopo do mandato v1-2026-09, em português e inglês. A revisão jurídica, quando vier, muda a versão, nunca o histórico.
Minimização
Descrição
Só o necessário entra, e o que entra é hash ou cifra. Imagem e template não persistem depois do ato. Hash com segredo é pseudonimização, não anonimização: reduz a exposição e segue sendo dado pessoal, com as obrigações que isso traz.
1.0Nenhuma imagem, nenhum template depois do atodisponível
A presença viva e o match rodam, devolvem o resultado, e a imagem capturada e o template são descartados. A imagem de referência do cliente fica cifrada só enquanto o ato está aberto, até 30 dias, e é apagada quando ele termina. Biometria retida depois do ato igual a falso é invariante do produto, não configuração.
2.0Referências em hashdisponível
A referência que o cliente dá à pessoa entra como HMAC com segredo por cliente; a imagem de referência, quando há, como hash; o contexto, como hash mais a lista de chaves lidas.
Isso é pseudonimização (art. 13, §4º), não anonimização: o segredo por cliente impede reverter por enumeração, e ainda assim o dado continua pessoal. É a mesma distinção que o verificador e a página do recibo fazem.
Ver Recibo3.0Identidade civil minimizadaem credenciamento
Da fonte de identidade civil só o veredito persiste, cifrado; a resposta bruta nunca sai do adapter.
Ver Fontes4.0Envelope e isolamentodisponível
Chave de dados por registro, isolamento por cliente no banco, trilha de decifragem com cadeia de hash.
Ver Segurança5.0Transferência internacional
Parte do tratamento acontece fora do Brasil: a hospedagem e os backups na União Europeia; a presença viva, a comparação facial, o módulo de chaves e os segredos na AWS, nos Estados Unidos; a borda e os sites na rede global da Cloudflare; e a telemetria com a Grafana Labs, empresa estrangeira, com stack em São Paulo. O mecanismo de transferência de cada fornecedor, nos termos do art. 33 da LGPD, está descrito no registro de tratamento, que o cliente recebe na contratação.
Mitigações: nenhum quadro retido, opt-out de uso para treino de IA aplicado, e cifragem com chave sob controle da Hummand para o que fica em repouso. A residência nacional por acordo está em Segurança: o que fica em repouso já pode ser nacional, e uma fonte nacional de presença viva está em vista.
Ver onde os dados ficamDireitos do titular
Descrição
O que atendemos hoje, e o que ainda não: portabilidade e apagamento por CPF não existem, e dizemos por quê.
1.0Apagamento a pedidodisponível
Pelo ato, pela referência opaca do cliente ou pelo veredito de uma validação avulsa: destruição da chave, síncrona, com a resposta dizendo quantos registros foram afetados e um registro de quem apagou e quando, salvo ato sob preservação, que o cliente declara e libera.
Apagar tem escopo próprio, que nenhuma integração recebe por padrão; na prática, o titular pede ao cliente, e o cliente apaga pelo painel.
2.0Retenção por prazodisponível
Veredito e CPF cifrados: 90 dias. Evidência de consentimento e trilha de eventos: cinco anos. Varredura automática a cada seis horas. O cliente pode guardar a parte cifrada de um tipo por mais tempo, até 20 anos, só com base legal declarada. A política em vigor é lida da configuração do serviço, não declarada por escrito: se o prazo mudar, a resposta muda junto.
3.0Portabilidade e apagamento por CPFarquitetura-alvo
Não existem. O gateway não guarda CPF em claro e não sabe ligar um CPF a atos sem decifrar registro por registro. O alvo do apagamento é o ato ou a referência que o próprio cliente atribuiu.
4.0Validações avulsas de documentodisponível
As validações documentais feitas fora de um ato gravam o CPF cifrado sem ligação com ato nenhum. Desde a 0.13.0 do gateway o apagamento a pedido também as alcança, e desde a 0.15.0 pelo veredito que o cliente recebeu; antes, elas só morriam pelo prazo.
5.0Documentos e canal
Os prazos de retenção estão implementados e valem em produção, com apagamento por destruição de chave. O registro de tratamento e o relatório de impacto foram preenchidos pelo encarregado em 2026-09-21 e acompanham cada mudança de fluxo de dados; a transferência internacional e os suboperadores seguem os instrumentos descritos no registro de tratamento. A Hummand é operadora; o cliente é o controlador.
Encarregado de dados: Vinícius Lisboa, identificado na Política de privacidade. Canal do titular e do encarregado: [email protected].
Escrever para dados@Verificar um recibo
Cole o JSON e a chave pública. Sem conta, sem envio: roda no seu navegador.
Abrir verificador