Publicado em
Adequação à LGPD: o que seu sistema precisa implementar
A adequação do sistema à LGPD não começa no rodapé do site. Do mapeamento de dados às APIs de direitos dos titulares: o caminho técnico e a ordem de prioridade.
Ouça comendo cookies.
0:000:00
A adequação do sistema à LGPD não começa com uma política de privacidade no rodapé do site. A lei determina como sistemas capturam, armazenam, processam e eliminam dados pessoais, o que significa que a conformidade real começa no banco de dados e no código, não no contrato. Quem tem um sistema empresarial rodando hoje precisa saber exatamente o que mudar e em qual ordem.
Este artigo traça um caminho técnico estruturado para a adequação do sistema à LGPD: do mapeamento de dados até os contratos com fornecedores, passando pelos controles que todo sistema conforme precisa implementar.
Sistemas construídos com privacidade desde a arquitetura, como os que a Plils desenvolve, tornam esse processo significativamente mais simples do que adaptar um legado depois que o problema já cresceu.
Por que a adequação à LGPD muda a arquitetura do sistema, não só os contratos
Conformidade com a lei não é responsabilidade exclusiva do jurídico ou do RH. A LGPD impõe requisitos que afetam diretamente banco de dados, APIs, fluxos de consentimento e controles de acesso. Sem mudanças no código e na infraestrutura, nenhum contrato resolve o problema real.
Bases legais e o que cada uma exige tecnicamente
O art. 7º da LGPD prevê dez bases legais para o tratamento de dados pessoais. As mais comuns em sistemas empresariais são consentimento, execução de contrato e cumprimento de obrigação legal, e cada uma tem implicações técnicas distintas.
Consentimento exige que o sistema capture, registre e permita a revogação do aceite, com trilha imutável da versão do texto exibido ao usuário. Execução de contrato dispensa esse fluxo, mas impõe minimização: o sistema deve limitar a coleta ao estritamente necessário para entregar o serviço contratado. Já a obrigação legal impõe prazo mínimo de retenção que não pode ser ignorado nas rotinas de limpeza automática: aqui, a exclusão de dados precisa aguardar o vencimento do período exigido pela norma aplicável.
O impacto prático é que o modelo de dados precisa associar cada atributo a uma finalidade e a uma base legal. Isso evita a coleta por precaução e fundamenta qualquer decisão sobre retenção, descarte e acesso.
A diferença prática entre controlador e operador
Sua empresa é a controladora dos dados dos seus clientes: você define a finalidade e toma as decisões sobre o tratamento. O provedor de nuvem que hospeda o banco de dados é o operador: trata os dados conforme suas instruções. Essa distinção determina quem responde perante a ANPD em caso de incidente e quais obrigações cada parte precisa assumir, tanto contratualmente quanto tecnicamente. Confundir os dois papéis é um dos erros mais comuns na prática.
O controlador é responsável por fiscalizar o operador, por garantir que as instruções dadas sejam seguidas e por comunicar incidentes às autoridades. Terceirizar a hospedagem não transfere a responsabilidade pela proteção dos dados.
Mapeamento de dados pessoais: o ponto de partida obrigatório para a adequação do sistema à LGPD
Não é possível proteger o que não se conhece. Antes de implementar qualquer controle técnico, a empresa precisa saber quais dados pessoais seus sistemas coletam, onde ficam armazenados, por qual finalidade e com quem são compartilhados. Essa etapa é pré-requisito para tudo que vem depois.
Como documentar os fluxos de dados na aplicação
O inventário funciona em duas camadas: uma lista tabular dos dados tratados e um diagrama de fluxo que mostra como cada dado circula pelo sistema. Os pontos de entrada mais comuns são formulários de cadastro, login, APIs de terceiros, SDKs de analytics e cookies. O objetivo é rastrear cada dado desde a coleta até o descarte, sem lacunas.
Os campos que não podem faltar no inventário
Cada item no inventário deve registrar os seguintes atributos:
- Nome do dado e categoria (pessoal, sensível ou transacional).
- Titular, finalidade e base legal.
- Origem e sistemas que processam o dado.
- Local de armazenamento, quem acessa e compartilhamentos externos.
- Prazo de retenção e critério de descarte.
Para sistemas web e mobile, vale incluir também identificadores de dispositivo, permissões solicitadas pelo aplicativo e SDKs de terceiros que possam coletar dados de forma independente.
Esse documento não é um exercício burocrático. Ele é a base para definir políticas de retenção e eliminação, priorizar controles de segurança e responder a solicitações dos titulares dentro do prazo.
Medidas técnicas para a adequação do sistema à LGPD
A LGPD exige medidas técnicas e organizacionais proporcionais ao risco do tratamento. Para sistemas empresariais típicos, SaaS B2B, plataformas de e-commerce, CRMs e ERPs, os controles esperados seguem as diretrizes das normas ABNT NBR ISO/IEC 27001 e dos guias de segurança da informação publicados pela ANPD. O conjunto abrange criptografia, controle de acesso, trilhas de auditoria e gestão de consentimento.
Criptografia, controle de acesso e trilhas de auditoria
Criptografia em repouso e em trânsito é o ponto de partida: TLS/HTTPS em todos os endpoints e criptografia dos campos sensíveis no banco de dados. O controle de acesso baseado no menor privilégio garante que cada usuário ou serviço acesse apenas o necessário para sua função. Para acessos administrativos, a autenticação multifator é fortemente recomendada pela ANPD como medida de segurança proporcional ao risco.
Logs de acesso, alteração e falha precisam registrar quem acessou, quando, o que alterou e o resultado da operação. Logs sem prazo de retenção definido enfraquecem a capacidade de demonstrar conformidade em uma investigação.
Os guias de boas práticas da ANPD indicam que a política de retenção dos registros de auditoria deve ser definida em conjunto com a política dos dados que eles protegem. Estabeleça esse prazo antes de colocar qualquer rotina de limpeza em produção.
Consentimento, retenção e eliminação segura
Gestão de consentimento significa muito mais do que um banner de cookies. O sistema precisa registrar onde o consentimento foi capturado, qual versão do texto foi exibida, quando ocorreu e qual o escopo aceito. A revogação precisa ser tecnicamente possível e, ao ser acionada, interromper os fluxos de tratamento que dependiam daquele aceite.
Políticas de retenção são regras de negócio codificadas: o sistema precisa saber quando cada dado vence e executar a eliminação de forma auditável. Marcar um registro como “deletado” sem remover os dados efetivos costuma ser insuficiente para atender ao direito de eliminação, a menos que exista um processo documentado de anonimização ou exclusão aplicado também a réplicas, caches e backups.
Anonimização é uma alternativa aceita quando a exclusão física não for tecnicamente viável, desde que o dado resultante não permita mais a identificação do titular.
Como implementar os direitos dos titulares diretamente no sistema
A LGPD garante ao titular direitos que vão de acesso e retificação até portabilidade e eliminação. O sistema precisa ser capaz de atendê-los dentro de prazos razoáveis. Isso não é funcionalidade opcional: é obrigação legal que exige design intencional de APIs e fluxos internos.
APIs de exportação, retificação e eliminação de dados
Os três direitos mais técnicos exigem endpoints dedicados. Para portabilidade, o endpoint de exportação deve entregar os dados em formato estruturado (JSON ou CSV), separando dados fornecidos pelo titular de dados inferidos pelo sistema. Para retificação, a atualização precisa propagar a alteração para sistemas dependentes e registrar o valor anterior, o novo valor e o momento da mudança. Para eliminação, o fluxo deve verificar a base legal de retenção antes de executar a exclusão efetiva, cobrindo réplicas e caches.
Um modelo simples e funcional para esses endpoints é:
- POST /privacidade/exportacoes: cria a solicitação de exportação.
- GET /privacidade/exportacoes/{id}: consulta o status do processamento.
- GET /privacidade/exportacoes/{id}/download: baixa o pacote exportado.
- PATCH /eu/perfil: retificação dos dados do titular.
- DELETE /eu/dados: solicita eliminação com verificação de retenção legal.
Rastreabilidade, prazos e confirmação de identidade
Cada solicitação de direito precisa de um fluxo operacional mínimo: recebimento em canal oficial, verificação de identidade, classificação do pedido, execução com revisão quando necessário e registro de evidência do atendimento. Para bases grandes, exportações assíncronas evitam tempo esgotado de requisição e melhoram a experiência sem comprometer a segurança. O sistema gera um identificador de solicitação, processa em segundo plano e notifica o titular quando o arquivo estiver disponível.
Fornecedores, contratos e por que a escolha de infraestrutura muda a equação
Todo sistema empresarial depende de fornecedores: provedores de nuvem, serviços de e-mail, gateways de pagamento, ferramentas de analytics. Cada um desses fornecedores é um operador dos seus dados. A lei exige que essa relação seja formalizada em um contrato com cláusulas específicas, e fiscalizar o cumprimento delas é responsabilidade do controlador.
Cláusulas indispensáveis em um contrato de proteção de dados com operadores
Um contrato adequado precisa responder a oito perguntas: o que será tratado, por que, quem pode tratar, onde os dados ficam, como são protegidos, como incidentes são comunicados, o que acontece com suboperadores e como os dados saem ou são eliminados no fim do contrato.
As cláusulas essenciais cobrem definição de papéis, limitação de uso à finalidade contratada, dever de confidencialidade, medidas técnicas de segurança equivalentes às exigidas pela LGPD, comunicação imediata de incidentes, regras para subcontratação com autorização prévia, direito de auditoria e obrigação de eliminar ou devolver os dados ao término do contrato. A ausência de qualquer uma dessas cláusulas é um risco regulatório direto.
Revisar o instrumento antes de integrar qualquer fornecedor ao fluxo de dados é uma prática indispensável. Os guias de contratação da ANPD recomendam essa revisão como parte do processo de governança de dados.
Infraestrutura própria: quando ela reduz a exposição a terceiros
Para empresas dos setores de saúde, jurídico e financeiro, hospedar dados em servidor próprio reduz uma camada significativa de riscos relacionados a provedores externos. Quando dados sensíveis ficam em infraestrutura controlada internamente, a dependência de operadores de nuvem diminui: há menos contratos a fiscalizar, menos risco de suboperadores não declarados e mais clareza sobre a localização dos dados.
Vale registrar, porém, que essa escolha não elimina todos os riscos: ISPs, fornecedores de hardware, equipes internas e rotinas de backup off-site continuam no escopo de governança e exigem controles técnicos e contratuais próprios.
A Plils desenvolve sistemas que podem ser hospedados integralmente no servidor do cliente, com a arquitetura de conformidade construída desde o primeiro ciclo de desenvolvimento. Para empresas com exigências de adequação à LGPD e compliance setorial, essa escolha de infraestrutura simplifica o caminho de forma concreta.
Checklist de prioridades para planejar o cronograma de adequação do sistema à LGPD
A conformidade com a lei não acontece de uma vez. O caminho mais eficiente é separar controles que podem ser ativados rapidamente dos que exigem desenvolvimento ou refatoração planejada.
Controles imediatos, que podem ser implementados sem alterar a arquitetura do sistema:
Mudanças estruturais, que exigem desenvolvimento planejado:
Antes de fechar o cronograma, o time técnico e os gestores precisam responder a seis perguntas:
Adequação do sistema à LGPD é um projeto de engenharia
Adaptar um sistema à LGPD não é um exercício de conformidade de papel. Os controles descritos aqui, do mapeamento de dados às APIs de direitos dos titulares, existem para proteger pessoas reais e reduzir o risco regulatório da empresa. O checklist é o ponto de partida; o cronograma é o compromisso com a execução. Cada mês sem mapeamento é um mês de risco regulatório acumulado. A melhor decisão é iniciar pelo inventário de dados ainda esta semana, mesmo que seja uma versão incompleta. Conhecer o que se tem é a base de qualquer plano realista de adequação.
O mapeamento inicial frequentemente revela lacunas que vão além do que uma equipe interna consegue resolver sozinha, seja pela ausência de endpoints de direitos, por contratos de fornecedores desatualizados ou por sistemas legados sem trilhas de auditoria.
Se a sua empresa está planejando construir um sistema novo ou modernizar um legado, a Plils oferece uma avaliação inicial gratuita para mapear as necessidades do seu negócio e propor uma arquitetura construída com conformidade desde o primeiro dia.
