Uma política de retenção e exclusão não é implementada com uma única instrução DELETE. Em uma aplicação PHP, as mesmas informações podem aparecer em várias tabelas, arquivos, caches, logs e serviços externos. Se o processo excluir apenas a linha principal, pode deixar cópias ativas; se apagar sem verificar as dependências, pode interromper operações ou excluir dados que deveriam ser mantidos.
O objetivo prático é transformar cada regra em um fluxo que identifique os dados afetados, aplique a ação adequada, trate exceções e deixe evidências verificáveis. A política deve ser acordada com as áreas responsáveis por produto, tecnologia e dados, e confrontada com as obrigações aplicáveis ao negócio. Não convém presumir prazos legais universais: eles dependem do contexto e devem ser validados antes de serem automatizados.
Comece pelas categorias e regras de retenção
Antes de projetar a exclusão, classifique as informações de acordo com sua finalidade e uso. Um perfil, um endereço necessário para uma operação pendente, um histórico de atividades e um registro contábil podem ter regras diferentes, mesmo que estejam relacionados à mesma conta.
Para cada categoria, documente pelo menos:
- Finalidade e responsável: por que os dados são armazenados e qual equipe decide sobre sua retenção.
- Evento que inicia a regra: por exemplo, encerramento da conta, término de uma relação ou solicitação validada.
- Prazo e condição: quando a ação é analisada ou executada, incluindo possíveis suspensões justificadas.
- Ação: excluir, anonimizar, manter com acesso restrito ou encaminhar para análise manual.
- Dependências: sistemas e processos que devem ser concluídos antes de o caso ser considerado resolvido.
“Manter” não significa conservar indefinidamente por conveniência. É preciso haver uma justificativa, um escopo e uma data ou condição de revisão. Se parte das informações precisar ser mantida por uma necessidade operacional, separe esse conjunto do restante e limite quem pode acessá-lo.
Faça o inventário de cópias, referências e sistemas conectados
O inventário deve acompanhar o percurso real dos dados, não apenas o esquema do banco de dados. Examine tabelas relacionadas, campos JSON, arquivos enviados, exportações, índices de busca, caches, filas, logs da aplicação e sistemas integrados. Inclua também os fluxos que geram cópias: relatórios, ferramentas de suporte, analytics ou processos de importação.
Para cada local, anote qual identificador permite encontrar os dados, quem é responsável, como eles são excluídos ou atualizados e o que acontece se o sistema estiver indisponível. Verifique as relações por meio de chaves estrangeiras e da lógica da aplicação: uma relação no banco de dados pode impedir a exclusão em cascata, enquanto uma exclusão em cascata pode apagar mais do que o previsto.
Trate os backups como um caso separado. Talvez não seja possível excluir um item individual sem restaurar o backup completo. Defina como o acesso a eles será limitado, por quanto tempo serão mantidos e qual procedimento impedirá que dados excluídos voltem aos sistemas ativos após uma restauração. Documente a decisão e valide-a com as pessoas responsáveis pela infraestrutura e pela conformidade.
Decida quando excluir, anonimizar ou manter
A exclusão física remove os dados de um sistema ativo, mas nem sempre é a opção correta para cada registro. A anonimização pode ser adequada quando é necessário manter informações estatísticas e é possível eliminar efetivamente a possibilidade de vinculá-las a uma pessoa. Substituir um nome por um identificador estável não é suficiente se houver outra tabela que permita reconstruir a relação.
A retenção com acesso restrito pode ser útil para os dados que ainda são necessários para uma operação ou uma obrigação validada. Mantenha esses itens separados, com permissões específicas e uma regra de revisão. Se não for possível determinar com segurança qual ação se aplica — por exemplo, devido a uma disputa, uma dependência desconhecida ou uma inconsistência de identidade —, encaminhe o caso para uma fila de revisão em vez de improvisar.
Também é preciso analisar as consequências funcionais: o que acontece com pedidos, assinaturas, tickets, chaves de API ou documentos compartilhados quando uma conta é removida. O comportamento deve ser explícito e coerente na interface, na lógica PHP e nos serviços conectados.
Implemente um fluxo idempotente e observável
Um processo de exclusão costuma ser executado em segundo plano, por meio de uma fila ou de uma tarefa agendada. Modele o caso com estados explícitos, por exemplo: solicitado, validado, em andamento, aguardando sistemas externos, concluído ou requer análise. Defina as transições permitidas e quem pode tentar novamente ou encerrar uma exceção.
A idempotência é essencial: repetir uma etapa não deve duplicar efeitos nem causar danos. Antes de excluir um arquivo, verifique se ele existe; ao processar uma solicitação, confira o estado atual; ao chamar um serviço externo, use mecanismos de idempotência, se disponíveis. Se não for possível garantir isso, registre a resposta e projete uma reconciliação antes de tentar novamente sem verificar.
Um esquema conceitual em PHP poderia separar a orquestração das ações por sistema:
foreach ($steps as $step) {
if ($step->isComplete($requestId)) {
continue;
}
$step->execute($subjectReference);
$step->markComplete($requestId);
}O exemplo não resolve transações distribuídas: um banco de dados e um provedor externo não necessariamente compartilham uma transação. Salve o progresso de forma confiável, trate os erros por etapa e permita retomar o trabalho. Se uma operação falhar no meio, o estado deve indicar o que falta; ela não deve ser apresentada como concluída.
Registre a execução sem criar outra cópia de dados pessoais
A rastreabilidade permite responder quem ou qual processo agiu, quando, sobre qual solicitação e com que resultado. Registre identificadores internos da operação, estados, etapas e códigos de erro úteis para diagnóstico. Evite copiar nomes, e-mails, documentos, conteúdo de arquivos ou payloads completos de API para os logs.
Um identificador pseudônimo de usuário ainda pode ser sensível se permitir identificar alguém novamente. Restrinja o acesso aos registros, limite seu período de retenção e, sempre que possível, separe as informações operacionais da identidade. As mensagens de erro devem ajudar a localizar o sistema afetado sem expor dados pessoais nas ferramentas de monitoramento.
Confira o resultado e prepare-se para as exceções
Os testes devem cobrir tanto o caso normal quanto as falhas parciais. Use dados de teste e verifique os locais identificados no inventário, não apenas a tabela principal. Inclua cenários como uma relação que impede a exclusão, um arquivo ausente, um provedor externo indisponível, uma nova tentativa e uma exceção que exige análise.
Uma lista operacional útil pergunta: cada cópia conhecida foi localizada? A ação prevista foi aplicada em cada categoria? Alguma etapa ficou pendente? Os sistemas externos confirmaram o resultado? Os logs contêm apenas as informações necessárias? Uma nova tentativa mantém a segurança do processo? Acrescente verificações periódicas para detectar novas tabelas, integrações ou caminhos de dados que não tenham sido incluídos no inventário.
Exemplo hipotético: encerramento de uma conta
Suponha que uma pessoa solicite o encerramento da conta em uma aplicação PHP. O fluxo valida a solicitação e consulta as regras definidas para o perfil, os arquivos, as atividades e as informações associadas a operações pendentes. O perfil e os arquivos elegíveis são excluídos; certos registros são mantidos com acesso restrito se houver uma justificativa aprovada; os dados destinados a análises só permanecem se tiverem sido efetivamente anonimizados.
A aplicação registra cada etapa sem incluir o e-mail nem o conteúdo dos arquivos. Se um serviço externo não responder, o caso fica pendente, e um processo posterior tenta novamente ou solicita intervenção, conforme a política. Ele só é marcado como concluído quando todas as ações necessárias tiverem sido confirmadas ou quando uma exceção formal estiver documentada e aprovada.
Antes de implementar, resolva as decisões que ainda estão em aberto: quais sistemas contêm os dados, quem autoriza exceções, o que significa “concluído” para cada destino, como os backups serão tratados e quem analisará as falhas. Essa definição transforma uma intenção de exclusão em um processo sustentável, verificável e seguro.
