Como o Valid trata dados pessoais.

O Valid está em fase de protótipo, para demonstração e validação com o cliente. O ambiente publicado é semeado com CPF sintético de fixture (faixa 000.000.000-XX, que não fecha dígito verificador e não corresponde a pessoa alguma). Nenhum dado de titular real foi carregado neste ambiente até a data desta versão.

Isso muda o risco de hoje, não o desenho. As seções abaixo descrevem o tratamento que o produto realiza quando dado real entrar, e as lacunas que precisam estar fechadas antes disso.

Levver Ltda (a operadora). CNPJ 63.299.766/0001-39
R. da Consolação, 2302, 9º andar · Consolação · São Paulo · SP · 01301-000
Contato: contact@levver.ai

A operadora executa o Valid por conta de quem decide a finalidade do tratamento. Ela não define quem é elegível, não define o critério da campanha, não define a vigência da regra e não decide para que o resultado é usado. Ela executa a decisão contra a regra que o cliente cadastrou, sobre o dado que a fonte informou.

Quem tende a ser controlador. A empresa que define a campanha e seus critérios, e a plataforma de origem que informa o status da pessoa. Elas decidem finalidade e elementos essenciais do tratamento, e é isso que define a figura do controlador. A ANPD já orientou que rotular alguém como operador em contrato não muda o papel que a parte de fato exerce, e tratou também da hipótese de controladoria conjunta, quando dois ou mais controladores decidem finalidades comuns ou convergentes sobre o mesmo tratamento.

Lacuna declarada. A atribuição formal de quem é controlador de cada dado, e como as partes a documentam entre si, ainda não está fechada. Enquanto não estiver, esta página não nomeia empresa alguma como controladora, porque atribuir o papel numa página pública antes do acordo seria criar compromisso jurídico onde não há. Fechada a atribuição, esta seção nomeia as partes e o contrato correspondente.

O Valid guarda seus registros em oito coleções, todas descritas no catálogo de dados interno (o registro das operações de tratamento do art. 37). O que cada uma guarda:

• 2.1 Leituras de fonte. O CPF (só dígitos), a campanha, os indicadores que o critério usa (por exemplo volume de viagens no mês e tempo de cadastro ativo na plataforma de origem), quem informou, sob qual contrato, em qual lote, quando a fonte apurou o número e quando o Valid recebeu.
• 2.2 Decisões. O protocolo, o CPF, a campanha, o resultado (atende, não atende, desatualizada), o critério aplicado, a versão da regra, o número apurado que sustentou a decisão, e até quando ela descreve o fato.
• 2.3 Direitos. Chaveados por CPF e campanha, com o estado (disponível, reservado, consumido, revogado), os prazos e o histórico das transições.
• 2.4 Links de acesso do titular. Guardamos o hash do token, nunca o token, mais o protocolo da decisão e os instantes de emissão e de expiração. Quem lê um despejo do banco não ganha acesso a tela nenhuma.
• 2.5 Contestações. O protocolo próprio, o protocolo da decisão contestada e o texto livre que o titular escreveu (até 1000 caracteres). Texto livre pode conter qualquer dado que a pessoa decida incluir, e é tratado como conteúdo, a categoria de maior sensibilidade deste produto.
• 2.6 Revogações em lote. O protocolo, a campanha, o instante, o autor do ato e o motivo declarado. É a trilha de governança de quem derrubou quais direitos, e por quê.
• 2.7 Leads. O caso de venda que nasce de uma reserva confirmada: protocolo, CPF, campanha, estado e instante.
• 2.8 Registros técnicos. Logs de aplicação do provedor de nuvem, para diagnóstico e segurança.

2.9 O que o produto NÃO trata. O Valid não guarda conta de titular, senha, nome, email ou telefone da pessoa avaliada. Não guarda dado de crédito, renda ou documento de financiamento, que são de outra parte e de outro processo. Não guarda o valor do benefício. Não há chat com agente neste produto: a superfície do assistente está desligada por configuração, e nenhum dado de titular é enviado para inferência de modelo. Este site não usa cookies de análise, cookies de publicidade nem rastreadores.

A preferência de tema (claro ou escuro) fica no armazenamento local do seu navegador e não sai dele. Como não usamos cookies de análise nem de publicidade, não há banner, porque não há nada que dependa de consentimento para carregar.

Atenção ao que isso não significa. A ausência de banner é sobre navegação. O consentimento do titular sobre o próprio dado é outra coisa, e está na seção 4.

• Consentimento do titular (art. 7º, I) para a avaliação de elegibilidade a partir do dado da plataforma de origem. No desenho do produto, o consentimento não é insumo da decisão, é condição de existência dela: sem autorização com data, escopo e canal, a decisão não deveria nascer, e a revogação do consentimento invalida decisão em aberto.
• Execução de contrato (art. 7º, V) para o registro do direito, da reserva e do lead decorrentes de uma decisão já emitida, na relação entre o titular e quem opera a campanha.
• Legítimo interesse (art. 7º, IX) para os registros técnicos e para a trilha de revogação, na medida necessária à segurança e à auditoria do produto.
• Obrigação legal (art. 7º, II) para atendimento a requisições de autoridade competente.

Lacuna declarada, e ela é a mais séria desta página. O código de hoje não registra o consentimento. Não existe coleção, campo nem tela que guarde data, escopo, canal e revogação da autorização do titular, e não existe trava que impeça uma decisão de nascer sem ela. O que existe é o controle de titularidade, que é outra coisa: o link do titular confirma que quem está do outro lado abriu o próprio caso (seção 5 da página de Segurança), não que ele autorizou o tratamento.

Enquanto o registro de consentimento não existir, a base legal do art. 7º, I é desenho e não é demonstrável pelo produto. Fechar essa lacuna é pré-requisito para carregar dado de titular real, e ela está escrita aqui em vez de escondida.

O que tem prazo definido em código, hoje:

• Link de acesso do titular. Vale 15 minutos. O registro do link já vencido é descartado 24 horas depois do vencimento (a carência existe para a tela conseguir dizer "peça outro link" em vez de "isso não existe").
• Reserva de direito. Expira sozinha em 30 minutos. Expirar é mudança de estado, não eliminação do registro.
• Registros técnicos de acesso. Seguem a retenção padrão do provedor de nuvem (Google Cloud Logging, hoje 30 dias).

O que está PENDENTE de definição, e por quê. Os dados de elegibilidade (leituras de fonte, decisões, direitos, contestações, revogações e leads) não têm prazo de retenção definido, e hoje não são eliminados por nenhuma rotina. Eles permanecem enquanto o registro existir.

Este prazo não é decisão de engenharia. O prazo de guarda do dado de origem é regra de negócio de quem controla o tratamento, e passa pelo jurídico das partes envolvidas. Escolher um número aqui seria inventar compromisso, então esta página declara o pendente em vez de preenchê-lo.

O que já está decidido sobre o desenho, e falta implementar: vencido o prazo de guarda, o dado pessoal de origem sai e a decisão permanece na trilha com o critério aplicado, sem o dado pessoal atrás dela. É a forma de manter a auditabilidade da decisão sem manter a pessoa. Nem o prazo nem a rotina de expurgo existem em código hoje.

• Google Cloud / Firebase. Hospedagem da aplicação (App Hosting) e banco de dados (Firestore), onde todas as coleções da seção 2 vivem.
• Google Vertex AI. Contratado no produto, porém não recebe dado de titular hoje: a superfície do assistente está desligada e nenhum caminho do Valid envia CPF, leitura, decisão ou contestação para inferência. Se e quando o assistente que explica a decisão existir, esta seção muda junto com o código.

A saída de lead para o sistema comercial do cliente é transferência entre as partes do tratamento, e ocorre sob o contrato que as vincula. Não comercializamos dados pessoais e não compartilhamos dados com terceiros para publicidade.

O ambiente do protótipo roda em infraestrutura do Google Cloud na região us-central1, nos Estados Unidos. Ou seja, o dado tratado neste ambiente está fora do Brasil. Essas transferências ocorrem sob as salvaguardas do art. 33 da LGPD, incluindo cláusulas contratuais do provedor com obrigações equivalentes à legislação brasileira.

Dito com todas as letras: residência de dado em solo brasileiro é a postura prevista para produção, e não é o que está no ar hoje. Se o tratamento de dado real exigir solo brasileiro, isso é mudança de infraestrutura a combinar antes da carga, não configuração a acertar depois.

Conforme art. 18 da LGPD, você pode solicitar a qualquer momento:

• Confirmação da existência de tratamento
• Acesso aos dados
• Correção de dados incompletos, inexatos ou desatualizados
• Anonimização, bloqueio ou eliminação de dados desnecessários, excessivos ou tratados em desconformidade
• Portabilidade dos dados
• Eliminação dos dados
• Informação sobre compartilhamento
• Revisão de decisão automatizada (art. 20)
• Oposição ao tratamento realizado sem consentimento, como os registros técnicos fundados em legítimo interesse (art. 18, §2º)

O que o produto já entrega sozinho. O titular vê o próprio dado: o link do seu caso mostra a decisão, o número apurado que a sustentou, o critério aplicado, a versão da regra e a data da leitura. A contestação da decisão é feita ali mesmo, pelo titular, e gera protocolo próprio.

O que passa por gente, e isso é lacuna declarada. Não existe exportação nem eliminação automatizada dos dados de elegibilidade. O coordenador de pedidos do titular que a plataforma da operadora possui atravessa os stores do esqueleto e não alcança as coleções do Valid. Portabilidade e eliminação, hoje, são processo manual.

Para quem mandar. Sendo a operadora quem executa, o pedido do titular é dirigido ao controlador, e a operadora atua sob as instruções dele. Se o pedido chegar aqui, ele é encaminhado ao controlador e você é informado disso. O canal é dpa@levver.ai, com resposta em até 15 dias, conforme art. 19 da LGPD.

A elegibilidade é decidida por regra determinística versionada, cadastrada como dado, com autor e vigência. Não há modelo de inteligência artificial produzindo a decisão, e nenhuma decisão sai sem data, protocolo, versão da regra e carimbo de quando a fonte foi lida.

Dado velho nunca vira negativa. Quando a leitura está mais velha que o limite tolerado pela campanha, a resposta é desatualizada, com a data à vista, e nunca "não atende". Negar por dado velho é indistinguível de negar por mérito, e o produto recusa fazer isso.

Toda decisão pode ser contestada pelo titular, pelo próprio link, com protocolo e revisão por pessoa da operação.

• Criptografia em trânsito (TLS) em todas as comunicações.
• Criptografia em repouso gerida pelo Google Cloud, padrão do provedor em todos os serviços que armazenam dados.
• Token do titular guardado como hash. O acesso do titular é por token opaco, não sequencial, de prazo curto, e o banco guarda apenas o hash.
• Acesso ao banco só pelo servidor. As regras que o repositório declara para o Firestore são deny-all: nenhum navegador lê essas coleções direto. Publicar as regras é passo separado do deploy da aplicação, e a página de Segurança registra essa ressalva.

E o que ainda não existe. As telas de operação do protótipo respondem sem autenticação, e não há conta nem separação por cliente no Valid. O detalhe honesto de cada controle, e de cada ausência, está na página de Segurança. Leia antes de carregar dado real.

Em caso de incidente de segurança envolvendo dados pessoais tratados pelo Valid, a operadora comunica o controlador imediatamente, para que ele avalie e cumpra a comunicação ao titular e à ANPD, conforme art. 48 da LGPD. A comunicação incluirá a natureza do incidente, dados afetados, medidas técnicas e administrativas em curso e os riscos envolvidos.

Responsável. João Prado

Email. dpa@levver.ai

O encarregado indicado aqui é o de Levver Ltda, na condição de operadora. O encarregado do controlador é indicado por ele, e será nomeado nesta página quando a atribuição de papéis da seção 1 estiver formalizada.

Esta política pode ser atualizada para refletir mudanças em legislação, no produto ou em fornecedores. Mudanças materiais serão indicadas no histórico de versões abaixo. A versão vigente é sempre a publicada nesta página.

• v3.0 (2026-08-16). Reescrita para descrever o Valid, corrigindo afirmações da v2.0 que não valiam para este produto. Quem opera o produto deixou de se declarar controladora e passou a se declarar operadora, com a atribuição formal de papéis registrada como pendente. Os dados tratados passaram a ser listados de fato, inclusive CPF, indicadores da fonte, decisões, direitos, leads e o texto livre das contestações. O consentimento entrou como base legal, junto da lacuna de que o produto ainda não o registra. Saiu a menção a conversas com o agente, que está desligado. A retenção dos dados de elegibilidade foi declarada pendente de definição com o cliente, sem número inventado. Entraram a seção de decisão automatizada, o estado de protótipo com dado sintético e a localização real da infraestrutura.
• v2.0 (2026-07-11). Template do esqueleto, escrito para um produto de conta e conversa. Descrevia tratamento que o Valid não faz e omitia o que ele faz.