GDPR e proteção de dados
A Veridia não afirma estar em conformidade com o GDPR, e esta página não é uma avaliação jurídica. Ela descreve o que o sistema faz com dados pessoais para que você e seu jurídico possam fazer a sua.
Várias coisas das quais um programa de GDPR normalmente depende ainda não existem aqui. Elas estão listadas, em vez de deixadas para você descobrir depois.
Note que o GDPR normalmente não é o regime aplicável ao mercado latino-americano que a Veridia atende principalmente — a LGPD no Brasil, a Ley 25.326 na Argentina e a lei paraguaia têm, cada uma, seus próprios requisitos. A mecânica descrita abaixo é a mesma independentemente do regime que se aplique a você; as obrigações não são. Qual delas te obriga é uma questão para o jurídico.
Quais dados pessoais são tratados
| Categoria | Campos | Origem |
|---|---|---|
| Imagens de rosto | Selfie; frames do desafio de prova de vida | Captura pela câmera |
| Imagens do documento | Frente, e verso quando exigido | Câmera ou galeria |
| Campos de identidade | Nome completo, número do documento, data de nascimento, nacionalidade, tipo de documento | OCR do documento |
| Avaliação | Veredito, confiança, scores por verificação, flags | O pipeline de verificação |
| Vínculo | Seu userRef, se você enviar um | Você |
| Contexto da requisição | Endereço IP, user agent, tempos | A requisição |
Imagens de rosto tratadas com a finalidade de comparar uma pessoa com um documento são geralmente consideradas dados biométricos, com requisitos mais rigorosos associados. Confirme essa caracterização e suas consequências com o jurídico — não é uma determinação que esta página possa fazer por você.
Para onde vão os dados
- O navegador ou app mobile captura as imagens e as envia para a API da Veridia — não diretamente para o armazenamento de objetos. Veja Segurança.
- A API grava as imagens no armazenamento de objetos e enfileira a verificação.
- Um pipeline de backend executa OCR, comparação facial, avaliação de prova de vida e screening de sanções, gravando os resultados em um banco de dados MySQL.
- Se você tiver configurado um webhook, o resultado — incluindo os campos de identidade — é entregue ao seu endpoint.
- As imagens são apagadas conforme o cronograma de retenção. A linha do banco de dados é mantida. Veja Retenção de dados.
Seu endpoint se torna um repositório de dados pessoais
O payload do webhook inclui fieldsExtracted: nome completo, número do documento, data de nascimento, nacionalidade, tipo de documento.
Isso tem consequências que a maioria dos integradores só percebe depois. Se o seu handler registra em log os corpos brutos das requisições, ou encaminha erros para um serviço terceirizado de rastreamento de erros, ou grava payloads em uma fila com retenção própria, então PII de identidade foi copiada para cada um desses sistemas. Inclua-os no seu próprio inventário de tratamento e no seu plano de retenção.
Residência de dados
Não existe garantia documentada de residência de dados, e nenhuma lista formal de suboperadores publicada hoje. O tratamento abrange a infraestrutura de edge da Cloudflare e um host de backend que roda o pipeline de ML e o banco de dados. Se sua avaliação depende de conhecer os locais de tratamento e os suboperadores envolvidos, pergunte antes de integrar, em vez de inferir a partir desta página.
Direitos do titular: o que existe
Esta é a seção para ler com atenção, porque a resposta honesta para a maioria dos direitos é "nenhum mecanismo".
| Direito | Situação |
|---|---|
| Acesso | Parcial. GET /v1/verify/{id} com uma chave secreta retorna o status, o veredito, os scores e as flags da verificação. Não é uma exportação completa de tudo o que se guarda sobre uma pessoa, e é indexado por verificação, não por pessoa. |
| Exclusão | Nenhum mecanismo. Nenhum endpoint, nenhum controle no painel. Uma solicitação significa uma operação manual no banco de dados e no armazenamento, feita por um operador. |
| Portabilidade | Nenhum mecanismo. Nenhum formato estruturado de exportação é produzido. |
| Retificação | Nenhum mecanismo. Os campos extraídos não podem ser corrigidos pela API. |
| Restrição / oposição | Nenhum mecanismo. |
| Decisão automatizada | Veja abaixo. |
Não existe caminho self-service para nenhum desses direitos, e nenhum prazo de atendimento comprometido para um caminho manual. Se suas obrigações incluem responder a solicitações dentro de um prazo fixo, essa restrição é sua para administrar, e você deve levantá-la antes de depender disso.
Exclusão entra em conflito com retenção
Vale sinalizar porque surpreende as pessoas: um pedido de exclusão e uma obrigação de retenção para AML podem apontar em direções opostas. Apagar um registro que você é legalmente obrigado a reter cria um problema diferente de mantê-lo. Qual obrigação prevalece é uma questão jurídica — o sistema não vai resolver isso por você, e deliberadamente não apaga linhas do banco de dados no cronograma de retenção por essa razão.
Decisão automatizada
Uma verificação produz um de três vereditos: approved, review ou rejected. Dois deles podem ser alcançados sem um humano.
Duas coisas limitam isso:
- Uma falha grave nunca aprova automaticamente, por mais alto que seja o score de confiança.
- Uma correspondência forte de sanções nunca rejeita automaticamente. Ela força a verificação para
review, para que uma pessoa decida. Veja SEPRELAD.
O veredito review é roteado para uma fila humana no painel, e a decisão é registrada com a identidade do revisor, o horário e a nota.
Se o seu uso desses vereditos constitui decisão automatizada com efeito jurídico ou similarmente significativo — e o que você, portanto, deve ao titular em termos de informação, intervenção humana ou contestação — depende do que você faz com o veredito, não do que a Veridia faz. Se você condiciona o acesso à conta a ele, presuma que a questão se aplica a você e busque orientação.
Consentimento
Não existe tela de consentimento, nem checkbox, nem aceite registrado, nem horário de qualquer concordância em lugar nenhum do widget ou da API. O fluxo de captura começa quando o usuário o inicia.
Se a sua base legal exige consentimento — e para tratamento biométrico ela comumente exige — você precisa obtê-lo e registrá-lo você mesmo, antes de montar o widget. A Veridia não guarda nenhuma evidência de que o consentimento foi dado, e não consegue produzir nenhuma se ela te for exigida.
Da mesma forma, nenhum aviso de privacidade é apresentado ao usuário final pelo widget. Tudo o que a pessoa precisa saber sobre quem está tratando seu rosto e seu documento, e por quê, tem que ser dito pela sua interface.
Contrato de tratamento
Nenhum contrato de tratamento de dados é oferecido hoje. Não existe modelo de DPA, nem pacote de cláusulas contratuais padrão, nem termos assinados de operador.
Se o seu programa exige um contrato escrito com um operador antes de dados pessoais poderem ser compartilhados — o que é a posição normal —, essa lacuna está entre você e a produção. Levante isso comercialmente, em vez de supor que o documento existe.
Notificação de incidentes
Não existe procedimento documentado de resposta a incidentes ou de notificação de vazamentos, e nenhum prazo contratual de notificação. Se você precisa de um, ele precisa ser acordado, e não presumido.
Resumo das lacunas
Para checklists de avaliação:
- Sem DPA ou termos de operador
- Sem captura de consentimento ou aviso de privacidade no widget
- Sem mecanismo de exclusão, portabilidade ou retificação
- Sem residência de dados documentada ou lista publicada de suboperadores
- Sem procedimento ou prazo documentado de notificação de vazamentos
- Sem criptografia em nível de aplicação nas colunas de identidade (Segurança)
- Endereço IP e user agent retidos indefinidamente sem mecanismo de expurgo (Retenção de dados)
- Sem auditoria externa ou certificação de qualquer tipo