LGPD no software: o que o sistema precisa fazer

A empresa contratou uma consultoria, publicou a política de privacidade, nomeou o encarregado e colocou um banner de cookies no site. Aí chega o primeiro pedido de um titular querendo saber quais dados a empresa tem sobre ele, e ninguém consegue responder sem abrir cinco sistemas, duas planilhas e a caixa de e-mail do comercial.

A Lei Geral de Proteção de Dados (Lei 13.709/2018) é escrita em linguagem jurídica, mas boa parte do que ela exige só se cumpre dentro do software. Este texto traduz a lei em requisitos de engenharia. Não é orientação jurídica e não promete que um sistema, sozinho, deixa a empresa em conformidade. O que ele mostra é o que o sistema precisa fazer para que o trabalho do jurídico e do encarregado não fique só no papel.

LGPD não é só política de privacidade no rodapé

A política de privacidade descreve o que a empresa diz que faz. O sistema é onde ela de fato faz. Quando os dois divergem, a política vira um documento que ninguém consegue sustentar diante de um titular, de um cliente corporativo em auditoria ou da Autoridade Nacional de Proteção de Dados (ANPD).

Vale separar as responsabilidades desde o início:

• Jurídico e encarregado definem bases legais, finalidades, prazos de retenção, textos de consentimento e o relacionamento com a ANPD. O encarregado, previsto no art. 41, é o canal de comunicação com titulares e com a autoridade.
• A equipe técnica garante que o sistema registre essas decisões, execute as regras de forma automática e produza evidência do que aconteceu.
• A diretoria decide o apetite de risco e patrocina a mudança de processo, porque privacidade quase sempre mexe no jeito de trabalhar, não só no código.

Um sinal comum de que a adequação ficou só no papel: as regras de retenção existem num documento, mas nenhum dado jamais foi apagado.

Mapeando dados pessoais e sensíveis no sistema

Não dá para proteger o que você não sabe que guarda. O primeiro requisito técnico é um inventário de dados pessoais que acompanhe o código, não um documento feito uma vez e esquecido.

Na prática, cada campo que contém dado pessoal recebe uma classificação no próprio modelo de dados:

• Identificação: nome, CPF, e-mail, telefone, endereço.
• Dado pessoal sensível, conforme a definição do art. 5º: origem racial ou étnica, convicção religiosa, opinião política, filiação sindical, dado referente à saúde ou à vida sexual, dado genético ou biométrico. O tratamento desses dados tem hipóteses mais restritas, previstas no art. 11.
• Dados de crianças e adolescentes, que têm regras próprias no art. 14.
• Dados financeiros e de localização, que não são sensíveis pela definição legal, mas cujo vazamento causa dano real e merecem proteção equivalente.

Com a classificação no esquema, várias coisas passam a ser automáticas: mascarar o campo em telas e logs, excluir do ambiente de testes, incluir na resposta ao titular e aplicar a regra de retenção.

O princípio da necessidade (art. 6º, III) é o requisito mais barato de cumprir e o mais ignorado: colete só o que a finalidade exige. Cada campo obrigatório no formulário deveria ter uma resposta para a pergunta "para que usamos isso?". Dado que não é coletado não vaza, não precisa ser retido e não entra no pedido de exclusão.

Não se esqueça dos lugares onde dado pessoal se esconde: logs de aplicação, filas de mensagens, anexos em PDF, cópias de banco em máquinas de desenvolvedores e exportações para planilha.

Finalidade, base legal e consentimento registrados

Todo tratamento de dado pessoal precisa de uma das bases legais do art. 7º (ou do art. 11, para dados sensíveis): consentimento, cumprimento de obrigação legal, execução de contrato, exercício regular de direitos, legítimo interesse, entre outras. Escolher a base é papel do jurídico. Registrar e aplicar a base é papel do sistema.

O que isso significa em requisito:

• Cada finalidade de tratamento (faturar, enviar comunicação de marketing, prestar atendimento, cumprir obrigação fiscal) é cadastrada com sua base legal e seu prazo de retenção.
• Quando a base é consentimento, o sistema guarda a prova: qual texto foi apresentado, em qual versão, quando, por qual canal e com qual resultado. Consentimento genérico não serve; a lei exige que seja para finalidades determinadas.
• Revogar precisa ser tão fácil quanto consentir e produzir efeito real. Se o titular revoga o consentimento para marketing, a próxima campanha já não pode incluí-lo, inclusive nas ferramentas externas integradas.
• O art. 37 exige que controlador e operador mantenham registro das operações de tratamento. Um cadastro de finalidades ligado ao inventário de dados é a base desse registro.

Evite o erro de pedir consentimento para tudo. Quando o tratamento é necessário para executar o contrato ou cumprir obrigação legal, pedir consentimento cria uma expectativa falsa: se o titular revogar, a empresa não poderá parar de tratar aqueles dados.

Direitos do titular sem trabalho manual

O art. 18 garante ao titular, entre outros, os direitos de confirmação da existência de tratamento, acesso, correção, anonimização, bloqueio ou eliminação de dados desnecessários, portabilidade, informação sobre compartilhamento e revogação do consentimento. O art. 19 prevê que a confirmação e o acesso sejam fornecidos imediatamente em formato simplificado, ou por declaração completa em até 15 dias contados do requerimento.

Se cada pedido vira uma caça manual em vários sistemas, esse prazo é apertado e o risco de resposta incompleta é alto. O sistema precisa de:

1. Um identificador de titular que ligue os registros da mesma pessoa entre módulos, mesmo quando o CPF não está presente em todos.
2. Uma rotina de exportação que monte, a partir do inventário, tudo o que existe sobre aquele titular, em formato legível e estruturado.
3. Um fluxo de solicitação com registro de quando o pedido chegou, como a identidade foi verificada, quem respondeu e o que foi entregue.
4. Exclusão com regra, não com um DELETE apressado. Parte dos dados precisa ser mantida por obrigação legal, como documentos fiscais e trabalhistas. O sistema elimina o que pode, bloqueia o que precisa ser guardado e registra a justificativa.

A verificação de identidade merece atenção própria. Um canal de atendimento que entrega todos os dados de um CPF a quem pedir por e-mail transforma o direito de acesso num vetor de vazamento.

Retenção, descarte, anonimização e pseudonimização

O art. 16 determina que os dados sejam eliminados após o término do tratamento, com exceções como o cumprimento de obrigação legal e o uso exclusivo do controlador com os dados anonimizados. Em engenharia, isso vira três mecanismos.

Política de retenção executável. Cada finalidade tem um prazo, e uma rotina periódica identifica os registros que venceram e aplica a ação definida: excluir, anonimizar ou arquivar com acesso restrito. Essa rotina deixa registro do que fez.

Anonimização de verdade. Pelo art. 12, dado anonimizado não é considerado dado pessoal, salvo quando o processo pode ser revertido com esforços razoáveis. Trocar o nome por "Cliente 123" e manter CPF, data de nascimento e CEP não é anonimização: a combinação desses campos continua identificando a pessoa. Para relatórios e análises, prefira agregar e generalizar (faixa etária em vez de data, região em vez de endereço).

Pseudonimização onde a identidade não é necessária. Substituir identificadores diretos por um código, mantendo a chave de reidentificação separada e com acesso restrito. É útil para ambientes de homologação, análises e integrações que não precisam saber quem é a pessoa. Dado pseudonimizado ainda é dado pessoal, mas o impacto de um vazamento cai muito.

E lembre dos backups. A exclusão feita no banco principal continua existindo nas cópias. O plano razoável é que os backups tenham prazo de expiração coerente com a política e que, numa restauração, as exclusões pendentes sejam reaplicadas.

Controle de acesso e registro de quem viu o quê

O art. 46 exige medidas de segurança técnicas e administrativas aptas a proteger os dados de acessos não autorizados e de situações acidentais ou ilícitas. Na prática de sistemas empresariais, a maior parte do risco não vem de um ataque sofisticado, e sim de acesso excessivo interno: todo mundo com perfil de administrador, exportação da base inteira liberada para qualquer usuário, atendente que consulta dado de saúde sem necessidade.

Os requisitos mínimos:

• Perfis de acesso pelo princípio do menor privilégio, com escopo por unidade, carteira ou cliente.
• Campos sensíveis mascarados por padrão e revelados só para quem precisa, com registro.
• Trilha de auditoria de leitura, não só de escrita, para dados sensíveis: quem abriu o prontuário, quem exportou a lista de clientes.
• Exportações em massa com permissão específica, limite e registro.
• Criptografia em trânsito e em repouso, com chaves fora do código-fonte.

O desenho detalhado de perfis, segregação de funções e trilha imutável está em perfis de acesso e trilha de auditoria. E como boa parte dos vazamentos acontece por APIs que devolvem mais do que deveriam, vale ler também os erros mais comuns de segurança de APIs.

Operadores e integrações

Se o sistema envia dados para terceiros (gateway de pagamento, ferramenta de e-mail, plataforma de WhatsApp, provedor de nuvem), cada um é um operador ou um novo controlador, e o compartilhamento precisa estar registrado. Tecnicamente: envie só os campos necessários, mantenha um catálogo de integrações com os dados trafegados e garanta que exclusões e revogações se propaguem.

Incidentes de segurança: detectar, registrar e comunicar

O art. 48 obriga o controlador a comunicar à ANPD e ao titular a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante. O regulamento da ANPD sobre o tema (Resolução CD/ANPD nº 15/2024) define prazo curto, contado em dias úteis a partir do conhecimento do incidente, e o conteúdo mínimo da comunicação. Os detalhes e a decisão de comunicar são do encarregado e do jurídico; a equipe técnica precisa dar a eles condições de decidir rápido.

Isso exige que o sistema responda, em horas e não em semanas, a quatro perguntas:

1. O que aconteceu e quando começou? Logs centralizados, com retenção adequada e protegidos contra alteração.
2. Quais dados e quais titulares foram afetados? Aqui o inventário de dados paga o investimento: sem ele, a resposta é "talvez todos".
3. O incidente foi contido? Capacidade de revogar credenciais, derrubar sessões e bloquear integrações rapidamente.
4. Os dados podem ser recuperados? Backups testados e isolados, assunto de plano de recuperação de desastres.

Tenha um roteiro de resposta a incidente escrito antes de precisar dele, com quem é acionado, quem decide e onde se registra cada passo. O registro do incidente, inclusive dos que não foram comunicados, é evidência de diligência.

Quando o tema pesa mais

Todo sistema com dado pessoal está sujeito à LGPD, mas alguns cenários exigem cuidado redobrado desde a arquitetura:

• Saúde, em que quase tudo é dado sensível e o sigilo profissional se soma à LGPD. O cenário de clínicas está em sistema para clínica sob medida.
• Recursos humanos, com dados de saúde ocupacional, dependentes e, às vezes, biometria de ponto.
• Plataformas que atendem outras empresas, em que você é operador dos dados dos clientes delas e precisa isolar cada base.
• Tratamento em larga escala ou com decisões automatizadas, em que o art. 20 garante ao titular o direito de pedir revisão de decisões tomadas unicamente com base em tratamento automatizado.

Nesses casos, o relatório de impacto à proteção de dados pessoais, previsto no art. 38, costuma ser o ponto de encontro entre jurídico e engenharia.

Checklist técnico de LGPD para o seu sistema

• Inventário de dados pessoais e sensíveis classificado no modelo de dados.
• Cadastro de finalidades com base legal e prazo de retenção.
• Prova de consentimento versionada e revogação que produz efeito.
• Exportação dos dados de um titular gerada pelo sistema, não montada à mão.
• Exclusão com regra: eliminar, bloquear ou anonimizar, com justificativa registrada.
• Rotina automática de retenção e descarte, incluindo backups.
• Perfis de menor privilégio, mascaramento e trilha de leitura para dados sensíveis.
• Catálogo de integrações e dados compartilhados com terceiros.
• Logs centralizados e roteiro de resposta a incidente testado.
• Ambientes de teste sem dados pessoais reais.

Para medir o progresso, acompanhe o tempo para responder a um pedido de titular, a quantidade de sistemas consultados manualmente por pedido (a meta é nenhum) e se a rotina de retenção de fato elimina registros a cada ciclo.

Privacidade desde o desenho, sob medida

Na Pervian Tech, requisitos de privacidade entram na arquitetura desde o primeiro diagrama, junto com o encarregado e o jurídico do cliente, e não como remendo depois do lançamento. É parte do nosso trabalho de arquitetura de software: inventário de dados no modelo, retenção executável, trilha de auditoria e resposta a incidente planejada.

Cada projeto é sob medida, porque cada empresa trata dados diferentes com finalidades diferentes. O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito em que entendemos os seus sistemas e o que precisa mudar. Se a LGPD ainda vive só no documento, fale com a gente.