LGPD em produtos digitais: o mínimo obrigatório para o seu sistema não virar passivo jurídico

A cena costuma ser assim: o sistema está pronto, o app está no ar, e alguém do jurídico ou um cliente grande pergunta "isso aqui está adequado à LGPD?". Silêncio na sala. Ninguém pensou nisso durante o desenvolvimento, o fornecedor diz que "isso é responsabilidade do cliente", e agora existe um produto em produção coletando CPF, telefone e endereço de milhares de pessoas sem que ninguém saiba dizer onde esses dados ficam, quem acessa e como apagar. Quem já passou por um projeto travado sabe do que estou falando: resolver isso depois custa muito mais do que teria custado durante.

Este artigo é o mapa mínimo. Não é parecer jurídico, é a visão de quem constrói e mantém sistemas que precisam passar por essa pergunta. O objetivo é que você saia daqui sabendo o que exigir do seu fornecedor, o que verificar no sistema que já existe e o que é exagero vendido como obrigação.

Por que a LGPD vira problema depois do lançamento

A Lei Geral de Proteção de Dados vale para qualquer empresa que trate dados pessoais no Brasil, do e-commerce de bairro ao banco. Não existe isenção por porte. O que existe é proporcionalidade: a ANPD trata diferente uma padaria com cadastro de clientes e uma fintech com dados financeiros de milhões de pessoas.

O problema estrutural é que a LGPD não é uma feature que se adiciona no final. Ela define decisões de arquitetura: onde o dado é armazenado, por quanto tempo, quem tem acesso, como é apagado. Quando o sistema é construído sem essas decisões, adequar depois significa mexer em banco de dados, em fluxos de cadastro, em integrações. Em projetos que a gente já resgatou, a adequação tardia consumiu entre 60 e 200 horas de desenvolvimento, algo entre R$ 12 mil e R$ 50 mil dependendo da complexidade. O mesmo trabalho feito durante a construção teria custado uma fração disso, porque as decisões certas não custam mais caro, só precisam ser tomadas na hora certa.

O que a LGPD exige de verdade em um produto digital

Deixando o juridiquês de lado, na prática um sistema adequado precisa responder bem a cinco perguntas. Antes de assinar qualquer contrato, pergunta isso ao fornecedor:

1. Quais dados vocês coletam e por quê?

O princípio da minimização é o mais barato de aplicar e o mais ignorado. Se o seu formulário de cadastro pede CPF, data de nascimento e endereço, mas o produto só precisa de nome e e-mail para funcionar, cada campo extra é risco sem retorno. Dado que você não coleta é dado que não vaza, não precisa ser protegido e não gera obrigação. No checkout do Revo App, nossa plataforma de eventos com mais de 40 mil usuários, cada campo do fluxo de compra existe por um motivo operacional ou fiscal. O resto foi cortado, e isso ajudou tanto na conversão quanto na conformidade.

2. Onde os dados ficam e quem acessa?

Você precisa saber em qual provedor os dados estão (AWS, Google Cloud, Supabase, servidor próprio), em qual região, e quem da equipe tem acesso ao banco de produção. "Está na nuvem" não é resposta. Acesso ao banco de produção deve ser restrito e registrado. Se qualquer desenvolvedor do fornecedor consegue exportar sua base de clientes sem deixar rastro, você tem um problema esperando para acontecer.

3. Como um usuário exerce os direitos dele?

A lei garante ao titular o direito de saber quais dados você tem, corrigir, e pedir exclusão. O sistema precisa suportar isso sem gambiarra. Exclusão é o ponto que mais pega: apagar um usuário não pode quebrar relatórios, pedidos antigos ou obrigações fiscais. A solução técnica comum é a anonimização, manter o registro da transação mas desvincular os dados pessoais. Isso precisa estar desenhado no modelo de dados desde o início.

4. Existe base legal para cada tratamento?

Nem tudo exige consentimento. Executar um contrato (entregar o produto que a pessoa comprou), cumprir obrigação legal (guardar nota fiscal) e legítimo interesse são bases válidas. O erro comum é o oposto: pedir consentimento genérico para tudo em um checkbox e depois usar os dados para finalidades que ninguém consentiu, como vender a base ou disparar marketing de terceiros. Consentimento para marketing deve ser separado, opcional e revogável.

5. O que acontece se vazar?

A lei exige comunicação à ANPD e aos titulares em caso de incidente relevante. Na prática, isso significa que o fornecedor precisa ter logs para saber o que aconteceu e quando. Sistema sem log de acesso é sistema onde um vazamento é invisível até aparecer no Twitter.

O mínimo técnico que qualquer sistema deveria ter

Essa é a lista que usamos internamente como piso, não como teto:

• HTTPS em tudo. Não existe exceção em 2026. Certificado é gratuito.
• Senhas com hash forte (bcrypt ou argon2), nunca em texto puro ou criptografia reversível.
• Acesso ao banco de produção restrito a quem precisa, com credenciais individuais, nunca uma senha compartilhada no grupo do WhatsApp da equipe.
• Backups criptografados e com retenção definida. Backup eterno de dado pessoal também é passivo.
• Logs de acesso a dados sensíveis, com quem acessou o quê e quando.
• Política de privacidade real, que descreve o que o sistema de fato faz, não um template copiado que menciona funcionalidades que não existem.
• Fluxo de exclusão de conta funcional. As lojas de aplicativos já exigem isso para aprovar o app, então não é nem opcional.

Repare que nada disso é exótico ou caro. É trabalho de engenharia bem feito. Quando um fornecedor cobra um adicional pesado por "módulo LGPD", desconfie: boa parte da conformidade é fazer o básico direito, não instalar um produto à parte.

O que é exagero: onde você não precisa gastar agora

O barato que sai caro aqui é o seguinte: com medo da multa, empresas pequenas contratam pacotes de adequação desproporcionais ao risco real. Alguns pontos de calibragem honesta:

• DPO dedicado em tempo integral não é exigência para a maioria das empresas pequenas. É preciso ter um encarregado nomeado, mas pode ser alguém interno acumulando a função ou um serviço terceirizado pontual.
• Certificações como ISO 27001 fazem sentido quando um cliente enterprise exige, não como ponto de partida.
• Criptografia de ponta a ponta em tudo é necessária para dados de saúde ou financeiros sensíveis, não para um cadastro de nome e e-mail. Criptografia em trânsito e em repouso, que os provedores de nuvem já oferecem, cobre a maioria dos casos.
• Banner de cookies agressivo que bloqueia o site inteiro resolve menos do que parece. O que importa é não carregar rastreadores de terceiros antes do aceite, e muitos sites pequenos nem usam rastreadores que exijam isso.

Não existe resposta única, mas existe conta certa: o investimento em conformidade deve ser proporcional ao volume e à sensibilidade dos dados que você trata. Uma base de 500 e-mails pede uma postura; uma base de 100 mil CPFs com dados de pagamento pede outra.

Como cobrar isso do fornecedor sem virar refém do tema

Se você está contratando um sistema agora, inclua no contrato uma cláusula simples: o fornecedor declara que o sistema será entregue seguindo as práticas mínimas de segurança e privacidade (a lista da seção anterior serve de anexo). Peça que o modelo de dados preveja anonimização e exclusão desde o início. Isso não encarece o projeto de forma relevante, só formaliza o que um time sério já faria.

Se o sistema já existe, o caminho é um diagnóstico: um levantamento de quais dados são coletados, onde ficam, quem acessa e quais das cinco perguntas acima o sistema não responde. Em sistemas de porte pequeno e médio, esse diagnóstico leva de uma a duas semanas e por si só já reduz risco, porque transforma incerteza em lista de pendências priorizável.

Esse é o tipo de trabalho que a gente faz na OCA, tanto em sistemas que construímos do zero quanto em produtos que herdamos de outros fornecedores. Por operarmos nossos próprios produtos em produção, como o Revo App e o sistema de gestão para imobiliárias, que lida com contratos e dados financeiros de inquilinos e proprietários, essas práticas não são um checklist teórico: são o que a gente aplica no que roda com o nosso nome em cima. Você pode ver outros casos no portfólio de projetos da OCA.

Próximo passo: o diagnóstico que você faz sozinho hoje

Antes de contratar qualquer coisa, faça o exercício gratuito: abra uma planilha e liste cada dado pessoal que seu sistema coleta, em qual tela, para qual finalidade e onde ele é armazenado. Se você não consegue preencher a coluna "finalidade" de algum campo, esse campo provavelmente deveria sumir. Se você não sabe preencher a coluna "onde fica", essa é a primeira pergunta para o seu fornecedor atual.

E se o resultado do exercício mostrar que o sistema precisa de ajustes, ou se você está contratando um produto novo e quer que a privacidade entre no projeto desde o desenho, a conversa é rápida e sem compromisso.

Converse com a OCA sobre o seu sistema