Resposta direta
A resposta é separar exclusão de desaparecimento. Todo registro apagado precisa deixar um evento com cinco campos: qual registro, quem apagou, quando, por qual canal e com que justificativa. O conteúdo anterior também fica guardado, em tabela ou arquivo separado, com acesso restrito. Sem isso, a trilha registra o fato mas não permite reconstruir o dado. A decisão de implementação é de responsabilidade, não de ferramenta: definir quem pode excluir, quem aprova e quem consulta o histórico. O restante é padronizar o registro do evento em todos os pontos que apagam dados, inclusive rotinas automáticas e integrações.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a exclusão como evento a ser instrumentado em todos os pontos de escrita, não só na tela, e separa a decisão de responsabilidade da escolha de ferramenta.
Os campos que tornam a exclusão rastreável
Uma linha de log com a frase registro excluído não serve para nada. Para reconstruir o que aconteceu, o evento precisa carregar o identificador do registro, o estado anterior dos campos, o usuário ou processo responsável, a data e hora com fuso, o canal de origem e o motivo declarado. Quando um desses campos falta, a investigação para no meio.
O estado anterior é o ponto mais esquecido. Guardar só o identificador obriga a cruzar com backup, que pode não existir ou já ter sido sobrescrito. Uma cópia do registro no momento da exclusão, em tabela de histórico ou arquivo imutável, permite reconstruir o dado sem depender de rotina de restauração.
Onde guardar o histórico e quem pode alcançá-lo
A trilha não pode ficar na mesma base que o operador acessa. Se quem apaga tem permissão para alterar o histórico, o histórico não vale. O desenho mínimo separa três papéis: quem executa a exclusão, quem aprova casos sensíveis e quem lê a trilha. Em muitos sistemas esses três papéis convivem na mesma conta de administrador, o que anula o controle.
Retenção é decisão de negócio e de obrigação legal, não padrão técnico. O prazo precisa ser escrito, com critério por tipo de dado, e o expurgo da própria trilha também deve gerar evento. Sem isso, o histórico desaparece junto com o sistema que ele deveria vigiar.
O que a trilha não impede
A trilha registra o que aconteceu. Não impede que alguém apague, não corrige permissão ampla demais e não devolve dado que nunca foi guardado. Também não substitui controle de acesso: se qualquer usuário pode excluir em massa, o problema está antes do registro.
Há casos em que a abordagem não se aplica. Quando existe obrigação de eliminar o conteúdo, o evento continua sendo registrado, mas o dado anterior não pode ser retido. E se os relógios dos sistemas não estão sincronizados, a ordem dos eventos fica duvidosa e a trilha perde valor como prova. Nesses cenários, o trabalho é de infraestrutura e de política, não de log.
Recurso prático
Fluxo de implantação da trilha de exclusão
- Listar todos os pontos que apagam registro: telas, rotinas agendadas, integrações, comandos manuais e expurgo por retenção.
- Definir o conjunto mínimo do evento: identificador do registro, estado anterior, usuário ou processo, data e hora com fuso, canal de origem e motivo declarado.
- Decidir o que é exclusão lógica e o que é expurgo físico, com critério por tipo de dado.
- Gravar a trilha em base separada, com permissão de escrita controlada e leitura restrita a quem investiga.
- Instrumentar cada ponto da lista e testar com registro fictício, conferindo se o evento aparece e se o estado anterior foi preservado.
- Atribuir responsabilidade: quem aprova exclusão de dado sensível e quem revisa a trilha periodicamente.
O erro mais comum é instrumentar apenas a tela de exclusão e esquecer rotinas automáticas, cargas de integração e comandos diretos na base. Esses caminhos apagam mais e não deixam nada.
Conceitos usados nesta página
- Trilha de auditoria — Trilha de auditoria é o conjunto de registros que permite reconstruir quem fez o quê, quando e com qual dado — inclusive depois que o resultado já foi usado.
Sobre o que está escrito aqui
Conceitos relacionados: exclusão lógica · trilha de auditoria · registro de evento · política de retenção · permissão de escrita. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Falhas silenciosas em integrações: como perce… — falhas silenciosas
- Cadastros duplicados: como descobrir e consol… — cadastros duplicados
Páginas relacionadas
O mesmo problema em outro objetivo
- Registro excluído sem trilha: o que ainda dá para reconstruir — Diagnosticar
- Registro excluído sem trilha: o que reconstruir depois — Organizar um processo
- Registro excluído sem trilha: o que comparar antes de decidir — Comparar alternativas
- Registro excluído sem trilha: como medir o que já sumiu — Explicar medição
- Exclusão sem trilha: o que exigir antes de contratar — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Alteração sem registro: o que precisa virar histórico — Descreve como implementar registro de alterações: quais campos entram no histórico, onde capturar a gravação e qual o limite desse registro.
- Volume de dados sem retenção: o que avaliar antes de contratar — O que verificar no contrato de armazenamento quando não há política de retenção: escopo, prazos, descarte, cópias e responsabilidade.
- Alteração sem registro: o que ainda dá para reconstruir — O que ainda pode ser reconstruído quando a alteração não foi registrada: fontes de rastro, limites da reconstrução e o que registrar daqui em diante.
- Cadastro sem chave única: o que exigir na contratação — O que exigir de um fornecedor de cadastro sem chave única: critérios de avaliação, responsabilidade sobre duplicidade e o que medir antes de assinar.
- Integração sem identificador de execução: o que comparar — Comparação de três formas de rastrear uma execução de integração quando não existe identificador próprio, com o custo de manutenção e os limites de cada uma.