LGPD em sistemas sob medida: o que avaliar antes de contratar

A Lei Geral de Proteção de Dados (LGPD) já faz parte do dia a dia de qualquer empresa que trata dados pessoais — e um sistema sob medida, por definição, trata dados pessoais o tempo todo: cadastro de clientes, dados de funcionários, histórico de pedidos, informações de pagamento, localização, comportamento de uso. Quando esse sistema é desenvolvido sem considerar a LGPD desde o início, a conta chega depois, em forma de retrabalho, risco jurídico ou exposição de dados.

Este guia explica o que a LGPD exige na prática de um sistema sob medida, onde a conformidade costuma falhar, quais critérios usar para avaliar um fornecedor de desenvolvimento e como equilibrar velocidade de entrega com responsabilidade sobre dados pessoais.

Por que a LGPD importa na hora de contratar um sistema sob medida

Sistemas prontos (SaaS) geralmente já vêm com alguma camada de conformidade documentada, porque atendem muitos clientes e precisam responder por isso de forma padronizada. Um sistema sob medida não tem esse piso mínimo automático: a conformidade é resultado direto das decisões de arquitetura, banco de dados e processo tomadas durante o desenvolvimento.

Isso significa que a responsabilidade não desaparece por terceirizar o desenvolvimento. A empresa contratante continua sendo, na maioria dos casos, a controladora dos dados — quem decide a finalidade do tratamento. O fornecedor de tecnologia normalmente atua como operador, executando o tratamento conforme instruído. Os dois papéis têm obrigações diferentes, mas nenhum dos dois anula a exposição do outro.

Ignorar isso na fase de contratação é comum, porque a LGPD entra na conversa como "requisito jurídico" e não como "requisito técnico". Na prática, ela deveria ser tratada como parte do escopo do sistema, no mesmo nível que performance, segurança de acesso e integração com outras ferramentas.

O que a LGPD exige de um sistema que trata dados pessoais

Não é preciso decorar a lei inteira para contratar bem. Alguns princípios, no entanto, precisam aparecer no desenho técnico do sistema.

Bases legais para tratamento de dados

Todo dado pessoal coletado precisa ter uma base legal que justifique aquele tratamento — consentimento, execução de contrato, cumprimento de obrigação legal, legítimo interesse, entre outras previstas na lei. Um sistema bem desenhado registra essa base junto com o dado, não apenas na política de privacidade publicada no site.

Minimização e finalidade

O sistema deve coletar apenas o que é necessário para a finalidade declarada. Um formulário de cadastro que pede CPF, endereço completo e data de nascimento para uma newsletter é um exemplo clássico de coleta desproporcional — e um risco que poderia ter sido evitado na etapa de modelagem de dados.

Segurança técnica e organizacional

Criptografia de dados sensíveis, controle de acesso por perfil, registro de quem acessou o quê e quando, e um plano de resposta a incidentes fazem parte do que a lei chama de medidas técnicas e administrativas de segurança. Isso não é um adicional de última hora: é decisão de arquitetura.

Direitos do titular

O sistema precisa ser capaz de responder, na prática, a pedidos de acesso, correção, exclusão ou portabilidade de dados. Se os dados estão espalhados em planilhas paralelas, integrações não documentadas ou backups sem controle, atender esse tipo de pedido dentro do prazo legal se torna operacionalmente difícil.

Onde a conformidade costuma falhar em sistemas sob medida

Na prática, os problemas não aparecem como falhas óbvias — aparecem como decisões que pareciam razoáveis no momento em que foram tomadas.

Coleta de dados sem finalidade clara

Campos "para o caso de precisar depois" se acumulam ao longo do desenvolvimento, principalmente quando o escopo muda no meio do projeto. Cada campo novo é um dado pessoal adicional que a empresa passa a ser responsável por proteger.

Ausência de controle de acesso e trilha de auditoria

Sistemas internos, por serem usados só pela própria equipe, costumam receber menos atenção nesse ponto — como se o risco fosse menor por não estar "voltado para fora". Na prática, acesso interno mal controlado é uma das causas mais comuns de vazamento, e a lei não faz essa distinção.

Retenção de dados sem prazo definido

Guardar dados indefinidamente "porque pode ser útil" contraria o princípio de necessidade da LGPD e aumenta o volume exposto em caso de incidente. Um sistema maduro define, para cada tipo de dado, por quanto tempo ele precisa existir.

Integrações com terceiros sem cláusulas de proteção de dados

Quando o sistema sob medida troca dados com um CRM, uma ferramenta de automação ou um gateway de pagamento, essa integração também precisa de tratamento contratual e técnico adequado — não basta que o sistema principal esteja em conformidade se os dados saem dele sem controle equivalente.

Critérios para avaliar a conformidade de um fornecedor de sistemas

Antes de fechar contrato com uma software house ou equipe de desenvolvimento, vale usar critérios objetivos em vez de aceitar a palavra "estamos em conformidade" sem detalhamento:

• O fornecedor consegue explicar, em termos técnicos, como o sistema vai tratar consentimento e base legal por tipo de dado?
• Existe modelagem de dados que separa dados sensíveis dos demais, com controle de acesso proporcional?
• Há plano de resposta a incidentes documentado, não apenas prometido verbalmente?
• O contrato define claramente quem é controlador e quem é operador dos dados tratados pelo sistema?
• O fornecedor tem experiência anterior tratando esse tipo de dado (financeiro, saúde, dados de menores, por exemplo, que exigem cuidado adicional)?
• Existe processo formal para atender pedidos de titulares de dados dentro do sistema, ou isso ficaria manual?

Esse tipo de avaliação vale tanto para contratar um sistema novo quanto para decidir entre manter desenvolvimento interno ou terceirizar parte da equipe técnica — a responsabilidade sobre os dados não muda conforme o modelo de contratação escolhido.

Trade-offs entre velocidade de entrega e conformidade

Um dos atritos mais reais nesse tema é prazo. Modelar dados com cuidado, implementar controle de acesso granular e documentar processos de resposta a incidentes leva mais tempo do que simplesmente criar um formulário e salvar tudo em uma tabela.

Isso não significa que todo projeto precise de um aparato de conformidade máximo desde o primeiro dia. Depende do tipo de dado envolvido e do estágio do negócio:

• Dado não sensível, volume baixo, fase de validação: um controle básico de acesso e uma política clara de retenção já reduzem boa parte do risco, sem travar o cronograma.
• Dado sensível (saúde, financeiro, biometria) ou grande volume: compensa investir mais tempo em modelagem e segurança desde o início, porque o custo de corrigir depois — incluindo o custo de migrar dados já coletados incorretamente — costuma ser maior do que o tempo poupado no início.

O erro mais caro não é levar mais tempo para tratar dados com cuidado. É tratar isso como algo que "se resolve depois" e descobrir, com o sistema em produção e dados reais de clientes, que corrigir a arquitetura de dados exige reescrever partes inteiras do sistema.

Riscos de ignorar a LGPD no desenvolvimento de sistemas

Os riscos não são só multas. Em ordem de frequência com que aparecem na prática:

1. Retrabalho técnico: corrigir modelagem de dados depois que o sistema já está em produção, com dados reais e integrações ativas, custa mais do que fazer certo da primeira vez.
2. Exposição em auditorias comerciais: empresas maiores, ao avaliar fornecedores ou parceiros, frequentemente pedem evidência de conformidade antes de fechar contrato — um sistema sem essa camada pode travar uma negociação comercial.
3. Incidentes de segurança com dados pessoais: além da obrigação legal de notificação, um vazamento afeta diretamente a confiança de clientes e parceiros.
4. Sanções administrativas: previstas na lei, variam conforme gravidade e reincidência, mas raramente são o primeiro risco a se materializar — os outros três costumam aparecer antes.

Checklist prático antes de contratar ou evoluir um sistema

Uma lista curta para revisar antes de aprovar o escopo de um novo sistema ou uma evolução relevante em um sistema existente:

• [ ] Cada dado coletado tem uma finalidade declarada e uma base legal associada.
• [ ] Existe controle de acesso por perfil, com trilha de auditoria de quem acessou o quê.
• [ ] Há prazo de retenção definido para cada tipo de dado, com processo de descarte.
• [ ] Integrações com terceiros (CRM, automação, pagamento) têm tratamento de dados equivalente ao sistema principal.
• [ ] O contrato com o fornecedor define claramente papéis de controlador e operador.
• [ ] Existe um caminho documentado para responder pedidos de acesso, correção ou exclusão de dados.
• [ ] Um plano de resposta a incidentes foi discutido antes do sistema entrar em produção, não depois de um problema acontecer.

Esse checklist também é útil ao planejar o roadmap de tecnologia de médio prazo: tratar conformidade como item recorrente de planejamento evita que ela vire um projeto emergencial mais caro no futuro.

Perguntas frequentes

LGPD se aplica a sistemas internos que não são voltados ao público?

Sim. A lei não distingue sistema interno de sistema público — o que importa é se há tratamento de dados pessoais, e sistemas internos quase sempre tratam dados de funcionários, fornecedores ou clientes, mesmo sem interface externa.

Quem responde legalmente se o sistema sob medida vazar dados?

Depende do contrato e de como as responsabilidades foram definidas entre controlador e operador. Normalmente, a empresa que decide a finalidade do tratamento (controladora) responde de forma mais ampla, mas o operador também pode ser responsabilizado se não seguiu as instruções contratuais ou não aplicou medidas de segurança adequadas. Por isso o contrato de desenvolvimento precisa deixar esses papéis explícitos.

Um sistema já em produção sem conformidade pode ser corrigido depois?

Pode, mas o custo é maior do que fazer certo desde o início, porque envolve migrar dados já coletados, ajustar integrações ativas e, em alguns casos, comunicar mudanças a usuários. Ainda assim, corrigir é sempre melhor do que manter uma exposição conhecida — vale priorizar os pontos de maior risco primeiro (dados sensíveis, controle de acesso, plano de resposta a incidentes) em vez de tentar resolver tudo de uma vez.

Terceirizar o desenvolvimento reduz a responsabilidade da empresa sobre a LGPD?

Não reduz — redistribui. A empresa contratante normalmente continua responsável como controladora dos dados, independentemente de o sistema ter sido desenvolvido internamente ou por um fornecedor externo. O que muda é a necessidade de um contrato bem definido, que estabeleça as obrigações de proteção de dados do fornecedor como operador.

Conclusão

Conformidade com a LGPD em um sistema sob medida não é uma camada que se adiciona no final — é uma decisão de arquitetura que precisa entrar no escopo desde a primeira conversa com o fornecedor de tecnologia. Isso vale tanto para quem está contratando um sistema novo quanto para quem está avaliando evoluir um sistema que já está em produção há anos.

Se a sua empresa está estruturando ou revisando um sistema que trata dados pessoais e quer ter certeza de que o desenho técnico já nasce alinhado com a LGPD, fale com a Clicksoft e avalie com nosso time os critérios de segurança e conformidade mais adequados para o seu caso, ou conheça nosso trabalho em desenvolvimento de sistemas sob medida.