LGPD na prática: erros silenciosos que expõem empresas e sistemas

Conformidade com a LGPD não se resume a contratos e banners de cookies. Entenda quais práticas criam riscos e como transformar proteção de dados em controles reais.

Por que uma empresa pode parecer adequada à LGPD sem estar protegida

Uma empresa pode ter política de privacidade, cláusulas contratuais e aviso de cookies e, ainda assim, tratar dados pessoais de maneira incompatível com a Lei Geral de Proteção de Dados Pessoais. A conformidade depende do que acontece durante todo o ciclo da informação: coleta, acesso, uso, compartilhamento, armazenamento, correção e descarte. Documentos são necessários, mas precisam corresponder às operações e aos sistemas usados diariamente.

O primeiro erro costuma ser tratar a LGPD como uma obrigação exclusivamente jurídica. A legislação também produz requisitos para processos, arquitetura de software, segurança da informação, atendimento ao titular e gestão de fornecedores. Se uma aplicação coleta campos sem finalidade definida, mantém permissões excessivas ou não oferece meios para localizar os dados de uma pessoa, o problema não será resolvido apenas com a revisão dos termos de uso.

A pergunta central não é se a empresa possui documentos de LGPD, mas se consegue demonstrar como e por que cada categoria de dado pessoal é tratada. Essa demonstração exige inventário dos dados, definição de responsabilidades e registros coerentes com a operação. A profundidade dos controles deve considerar o contexto, a natureza das informações, a escala do tratamento e os riscos envolvidos.

Quais erros cotidianos criam riscos de proteção de dados

Compartilhar planilhas por canais sem controle, reutilizar listas de contatos e conceder acesso amplo a sistemas são exemplos de práticas que merecem revisão. O risco não decorre apenas da ferramenta empregada, mas da ausência de critérios sobre finalidade, necessidade, autorização e retenção. Uma planilha pode ser adequada para uma atividade restrita e controlada, mas se torna problemática quando é duplicada, enviada a pessoas sem necessidade de acesso ou mantida indefinidamente.

Outro equívoco é presumir que todo tratamento depende de consentimento. A LGPD prevê diferentes bases legais, e a escolha precisa refletir a finalidade e as condições da operação. O consentimento não deve ser usado como justificativa genérica quando não for a base apropriada. Da mesma forma, uma lista obtida legitimamente para determinada finalidade não fica automaticamente liberada para qualquer campanha, análise ou compartilhamento posterior. A mudança de uso exige uma nova avaliação jurídica e operacional.

Também são frequentes a coleta de campos “para usar no futuro”, a ausência de prazos de retenção, o emprego de dados reais em ambientes de teste e o reaproveitamento informal de credenciais entre integrantes da equipe. Sistemas antigos ampliam a dificuldade quando não registram acessos, não separam perfis de usuário ou não permitem excluir e corrigir informações sem intervenções manuais. Minimização de dados significa coletar e conservar apenas o que possui finalidade justificável, e não simplesmente acumular informações porque o armazenamento está disponível.

Como avaliar sistemas, fornecedores e incidentes

Uma revisão técnica deve começar pelo fluxo dos dados, e não pela tela da política de privacidade. O mapeamento precisa identificar quais informações entram em cada sistema, de onde vêm, para onde seguem, quem pode consultá-las, por quanto tempo permanecem armazenadas e como são eliminadas. Também deve alcançar integrações, exportações, cópias de segurança, ambientes de desenvolvimento e rotinas realizadas fora do sistema principal.

A relação com fornecedores exige atenção semelhante. Contratar uma solução externa não transfere automaticamente todas as responsabilidades sobre o tratamento. A empresa precisa compreender quais dados são enviados, quais operações o fornecedor realiza, que acessos são permitidos e como serão tratadas solicitações, encerramentos contratuais e incidentes. Contratos ajudam a distribuir obrigações, mas não substituem controles de acesso, acompanhamento operacional e decisões conscientes sobre quais informações podem sair do ambiente da organização.

Em relação a incidentes, prevenção e resposta precisam coexistir. Autenticação adequada, privilégios mínimos, registros de atividade, criptografia quando aplicável, atualização de componentes e cópias de segurança reduzem determinados riscos, mas não eliminam falhas humanas ou técnicas. Um plano de resposta deve estabelecer como detectar, conter, investigar e documentar um evento, além de definir quem avalia os impactos e conduz as comunicações cabíveis. Um vazamento não é o único incidente relevante: acesso indevido, alteração não autorizada, perda e indisponibilidade também podem comprometer dados pessoais.

Como transformar conformidade em requisitos de software

A adequação se torna mais consistente quando cada obrigação é traduzida em requisito verificável. Se o atendimento ao titular exige localizar informações, o sistema precisa permitir busca confiável e controlar quem executa a operação. Se o acesso deve ser limitado por função, perfis e permissões precisam refletir atividades reais. Se existe um prazo interno de retenção, deve haver uma rotina de descarte, anonimização ou revisão, acompanhada dos registros necessários.

O desenvolvimento de um novo produto oferece a oportunidade de incorporar privacidade desde a definição do escopo. Campos de cadastro devem ter finalidade clara; permissões administrativas devem ser separadas; logs não devem registrar conteúdo pessoal sem necessidade; ambientes de teste podem trabalhar com dados fictícios ou adequadamente protegidos; exportações precisam ser rastreáveis. Em sistemas existentes, a adequação tende a exigir priorização. A empresa pode começar pelos dados mais sensíveis para o contexto, pelos acessos mais amplos e pelos fluxos que envolvem maior exposição.

A escolha entre adaptar um sistema legado e desenvolver uma solução sob medida depende do grau de limitação técnica, do custo de manutenção e da importância do processo para o negócio. Adaptar costuma preservar investimentos e reduzir mudanças operacionais, mas pode manter restrições estruturais. Reconstruir permite redesenhar permissões, rastreabilidade e retenção, embora exija migração cuidadosa, testes e gestão da mudança. Não existe uma resposta universal; a decisão deve comparar risco residual, esforço técnico e evolução esperada do produto.

Na experiência profissional da Phurshell, acumulada em mais de 15 anos de mercado e mais de 100 aplicativos entregues para empresas brasileiras, requisitos de privacidade funcionam melhor quando participam das decisões de produto e arquitetura, em vez de aparecerem apenas na revisão final. Essa abordagem não substitui a avaliação jurídica especializada. O papel da equipe de software é converter diretrizes aplicáveis em comportamentos concretos, testáveis e auditáveis dentro da solução.

Uma governança sustentável também precisa acompanhar mudanças. Novas integrações, campanhas, funcionalidades e perfis de acesso podem alterar a finalidade ou o risco do tratamento. Por isso, a revisão de LGPD não deve ser encarada como projeto encerrado depois da publicação de documentos. Conformidade é a capacidade contínua de relacionar finalidade, base legal, processo e controle técnico, corrigindo desvios antes que se tornem incidentes ou conflitos com titulares.