Uma abordagem prática ao direito de eliminação: mais do que apertar delete
Segundo o Art. 7 da Lei 21.719 (que altera a Lei 19.628), toda pessoa tem direito a solicitar a eliminação de seus dados pessoais. Suponha que estamos em 1º de dezembro de 2026, a norma entra em vigor e um dos seus usuários exerce o direito de eliminação. Como você resolveria isso?
Em organizações corporativas, eliminar os dados pessoais de um usuário não é trivial. Isso porque quase sempre existem sistemas distribuídos, microsserviços e múltiplas fontes de dados.
Nishant Bhajaria, autor de Data Privacy, mostra em um de seus cursos, na imagem a seguir, como os dados viajam depois de coletados
Ela evidencia que a reatividade das organizações na implementação de ferramentas de privacidade tira efetividade dessas ferramentas, porque a essa altura os dados coletados já foram transferidos para diferentes sistemas: serviços de analytics, terceiros, data lakes etc.
Portanto, eliminar esse dado que hoje pode estar armazenado em diferentes fontes de informação é um “cacho”, como diríamos no Chile: um baita problema.
Você poderia tentar resolver isso manualmente, pedindo a cada área ou Data Owner (responsável pelo dado) que execute a eliminação do usuário em seus sistemas e envie a evidência correspondente.
As equipes responsáveis vão ter muito medo de fazer isso. Não há nada mais difícil do que executar um DELETE.
Você concorda que essa opção não é escalável ao longo do tempo: geraria uma carga operacional indeterminada para todas as equipes envolvidas (mas serve para a organização aprender como proceder).
Você poderia então criar um (micro) serviço com a conectividade e os usuários com as permissões necessárias para acessar cada banco de dados e executar a operação DELETE diretamente.
Do ponto de vista da arquitetura de software, isso geraria um acoplamento indevido, já que os demais microsserviços perderiam o controle sobre as regras de negócio que governam seus próprios dados. Além disso, não só encarece a manutenção como aumenta o risco de erros.
O que fazer, então? Neste artigo vamos revisar mais algumas definições para entender melhor o problema da eliminação e conhecer uma solução proposta por Nishant B.
O que significa realmente eliminar dados
Pela minha experiência, existem dois mecanismos válidos para cumprir a exigência da Lei, cada um com implicações técnicas distintas:
1. Eliminação física ou lógica
A eliminação física implica a destruição definitiva dos dados. É a forma mais direta, mas nem sempre é viável em sistemas complexos.
A eliminação lógica, por sua vez, consiste em marcar os dados como eliminados (por exemplo, com flags como is_deleted). Essa abordagem é comum em sistemas que exigem rastreabilidade ou recuperação. O problema é que, do ponto de vista legal, isso sozinho pode não ser suficiente. Por isso é preciso aplicar uma técnica de anonimização para não incorrer em descumprimento.
2. Anonimização
Segundo a lei, um dado anonimizado é aquele que não pode ser vinculado a uma pessoa natural e cuja anonimização é irreversível.
Isso implica que:
Não deve existir nenhuma chave que permita reidentificar o usuário
Não devem restar combinações de dados que permitam inferir a identidade
Não deve existir informação auxiliar que permita reconstruir o vínculo
Por exemplo:
Remover o RUT mas manter data de nascimento, município e gênero pode permitir a reidentificação
O hashing simples pode ser reversível na prática. Ou seja, mesmo que você transforme um dado (como um RUT) em outro valor aparentemente irreconhecível, alguém poderia reconstruir o original testando combinações conhecidas.
Manter tabelas de correspondência — ou seja, listas que vinculam o dado original à sua versão transformada — quebra completamente a anonimização, já que permite voltar diretamente à identidade da pessoa.
Existem diferentes técnicas de anonimização; o importante é reduzir os riscos de identificação.
A imagem a seguir resume como as diferentes técnicas de anonimização não são infalíveis para mitigar todos os riscos
Explicação dos níveis de risco:
Sim: a técnica não mitiga o risco de forma eficaz e precisa ser combinada com outras técnicas para melhorar a proteção.
Às vezes: a técnica pode mitigar o risco em certas circunstâncias ou até certo ponto. É importante considerar o contexto específico em que ela será aplicada.
Não: a técnica é eficaz para mitigar o risco associado, oferecendo uma proteção robusta contra o tipo de risco especificado.
Ainda que as técnicas de anonimização não sejam infalíveis, pode haver casos em que atendam ao que a lei exige. Teremos mais clareza quando a Agência se pronunciar a respeito.
Em muitos casos, técnicas como a anonimização ou a eliminação lógica são usadas para cumprir esse objetivo, desde que os dados já não permitam identificar uma pessoa.
Onde os dados devem ser eliminados
Os dados pessoais costumam estar distribuídos em vários lugares:
Bancos de dados relacionais e não relacionais
Sistemas de arquivos (documentos, imagens, exportações)
Sistemas de mensageria e logs
E-mails
Chats
Sistemas de terceiros
Outros
É tarefa da organização identificá-los e apagar os dados em todos eles.
Quanto eliminar
O direito de eliminação nem sempre implica apagar todas as informações. Na prática, existem pelo menos dois cenários:
Eliminação parcial: o usuário solicita eliminar determinados atributos específicos.
Eliminação total: elimina-se toda a informação associada ao titular dos dados.
No entanto, o que efetivamente pode ser eliminado não depende apenas da solicitação do usuário, mas também das obrigações legais e regulatórias da organização. Por exemplo, certos dados — como registros de dívidas ou informações contábeis — podem precisar ser conservados por lei.
Isso implica que os sistemas devem ser capazes de eliminar considerando tanto a solicitação do titular dos dados quanto as restrições legais aplicáveis.
Ordem de eliminação
Os dados podem reaparecer por causa de replicação ou sincronização. Por isso, a ordem recomendada é:
Sistemas fonte
Sistemas replicados ou derivados
Essa ordem minimiza inconsistências e evita a regeneração de dados eliminados. É importante considerar que muitas vezes os sistemas fonte ou os sistemas replicados podem ser terceiros (fornecedores)
Com essas definições, vamos ao desenho principal do sistema de eliminação proposto. A ideia é inspirada no livro Data Privacy: A runbook for engineers de Nishant Bhajaria, no capítulo 7.
Destroyer
O Destroyer, na sua concepção mais básica, é um serviço central que dá suporte à eliminação de dados pessoais de diferentes fontes de informação diante de uma solicitação de eliminação de um usuário. Isso é feito por meio da orquestração dos serviços de eliminação dos diferentes sistemas.
O Destroyer é o serviço encarregado de:
Orquestrar a eliminação em múltiplos sistemas
Manter a rastreabilidade do processo
Executar validações prévias
Garantir consistência
Ele não elimina dados diretamente. Coordena os sistemas que fazem isso.
Antes de eliminar qualquer dado, é obrigatório validar se existe uma razão legal para mantê-lo. Isso inclui:
Retenções legais (produtos ativos)
Obrigações regulatórias (envio de informações a instituições)
Processos judiciais (Ley papito corazón)
Para isso, entra em cena um serviço especializado (Holden, na imagem), que centraliza essas validações.
O fluxo é simples:
Se houver razão legal para mantê-lo → não se elimina
Se não houver → é possível prosseguir
Esse passo é crítico para evitar descumprimentos legais por eliminação indevida.
Uma vez validado que o usuário não está sujeito a retenção legal, o mecanismo de eliminação deve ser iniciado.
Para isso, os donos dos serviços de cada sistema, responsáveis pela administração dos bancos de dados que contêm os dados pessoais, devem registrar seus serviços de eliminação no Destroyer, junto com os dados pessoais a serem eliminados.
Serviços de eliminação
Cada sistema deve criar 3 serviços de que o Destroyer precisará para executar a eliminação:
GET_TEST_USER: Retorna um user_id para testar a eliminação. O usuário retornado deve ter dados suficientes para testar todo o fluxo de eliminação.
Observação: depois dos testes, considere fazer o “un-delete” dos dados gerados pelo usuário.
DELETE: O serviço principal que executa a eliminação. Vai desde a eliminação completa até o uso de alguma técnica de anonimização.
IS_DELETED: Determina se os dados de um usuário foram eliminados ou não.
O fluxo de teste deveria ser:
Gerar um usuário de teste com GET_TEST_USER
Verificar que ele não está eliminado com IS_DELETED -> false
Executar a eliminação com DELETE
Confirmar que foi eliminado com IS_DELETED -> true
Isso deve ser repetido para cada sistema registrado no Destroyer. Vamos ver, então, como organizar a eliminação
Plano de eliminação
Quando o Destroyer recebe uma solicitação de eliminação, o sistema deve gerar um plano de acordo com o que o usuário pediu. Uma eliminação total não é a mesma coisa que uma parcial (por exemplo, apagar apenas o e-mail).
Daí a importância de ter um bom contrato de registro dos sistemas no Destroyer (neste caso, “contrato” se refere a uma definição técnica de como um sistema funciona: quais dados ele trata e como outros sistemas podem interagir com ele)
No mínimo, esse contrato deve incluir:
Quais dados pessoais cada sistema armazena
As URLs dos três serviços definidos anteriormente
O método de autenticação
Quais sistemas são fonte e quais replicam dados (pode haver vários sistemas replicando de uma mesma fonte)
Se a eliminação é síncrona ou assíncrona (alguns sistemas não conseguirão eliminar em tempo real e responderão depois)
Se exige aprovação manual
Com essas informações, monta-se o plano de eliminação.
O plano consiste em executar a eliminação dos dados de forma ordenada por níveis, do nível 0 até o nível N:
No nível 0 estão os sistemas fonte (a origem dos dados)
No nível 1 estão os sistemas que replicam dados do nível 0 e, por sua vez, alimentam outros
E assim sucessivamente até o nível N
Essa ordem é importante para manter a integridade da informação e evitar que os dados eliminados voltem a aparecer por processos de replicação. Além disso, todos os sistemas que estão em um mesmo nível podem executar a eliminação em paralelo, o que torna o processo mais eficiente.
Antes de encerrar este post, mostro como imagino que poderia ser exibida a execução da eliminação de uma solicitação feita por um usuário
Tudo isso não apenas permite executar corretamente a eliminação dos dados, mas também deixar evidência rastreável do que foi feito, quando e em quais sistemas.
Isso é fundamental, porque, diante de uma eventual fiscalização, a sua organização deve ser capaz de demonstrar como implementa o direito de eliminação na prática.
Nesse contexto, a Agencia de Protección de Datos Personales provavelmente ficaria surpresa ao receber uma auditoria dessa qualidade da sua organização.
Palavras finais
O direito de eliminação é, em essência, um problema de arquitetura. Ele obriga a responder perguntas complexas: onde os dados realmente vivem, como se propagam e como garantir que sejam eliminados de forma efetiva.
Implementá-lo corretamente exige pensar em orquestração, consistência distribuída e contratos entre sistemas.
Em outras palavras, não é um requisito legal isolado, e sim uma oportunidade de projetar sistemas mais conscientes, controlados e responsáveis com os dados que gerenciam.
A solução proposta nem sempre será viável de imediato, mas aponta um objetivo claro para onde avançar. Adotá-la, mesmo de forma parcial ou progressiva, já representa um salto importante na forma como uma organização entende e gerencia seus dados e o direito de eliminação.
