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.
Registro de tratamento, política de retenção e relatório de impacto existem como esqueletos com marcações para o encarregado de dados, a fechar antes do primeiro cliente real. O canal do titular é dados@hummand.com.br.
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 mandatoarquitetura-alvo
Quando houver mandato, 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 em uso são a versão 2026-08. A revisão com o encarregado de dados é uma decisão pendente do plano; 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 em momento algum.
1.0Nenhuma imagem, nenhum templatedisponível
A presença viva e o match rodam, devolvem o resultado, e a imagem e o template são descartados. Biometria retida 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.
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çaDireitos 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 ou pela referência opaca do cliente: destruição da chave, síncrona, com a resposta dizendo quantos registros foram afetados e um registro de quem apagou e quando.
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. 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 documentoarquitetura-alvo
As validações documentais feitas fora de um ato gravam o CPF cifrado sem ligação com ato nenhum; o apagamento a pedido não as alcança, e elas morrem pelo prazo. Fechar esse caminho é dívida registrada.
5.0Documentos e canal
Registro de tratamento, política de retenção e relatório de impacto existem como esqueletos com marcações para o encarregado, a fechar antes do primeiro cliente real. A Hummand é operadora; o cliente é o controlador.
Canal do titular e do encarregado: dados@hummand.com.br.
Escrever para dados@Verificar um recibo
Cole o JSON e a chave pública. Sem conta, sem envio: roda no seu navegador.
Abrir verificador