Trilha de auditoria: o que é e por que sua empresa precisa

Trilha de auditoria é o registro imutável de quem fez o quê, quando, de onde e sobre qual dado, dentro do sistema. Não é log técnico de erro: é registro de negócio, feito para ser lido por um gestor, um auditor ou um advogado meses depois do fato. Sem ela, qualquer discussão sobre "quem cancelou esse pedido" ou "quem alterou esse valor" termina em palavra contra palavra.

Os três problemas que ela resolve

Conflito interno. Um desconto de 40% foi aplicado num contrato e ninguém assume. Um cadastro de fornecedor mudou de conta bancária às vésperas do pagamento. Um pedido sumiu do sistema. Com trilha de auditoria, isso é uma consulta de dois minutos. Sem ela, é uma reunião de duas horas sem conclusão.

Fiscalização e conformidade. A LGPD, no artigo 37, exige que os agentes mantenham registro das operações de tratamento. Auditorias contábeis, certificações e questionários de segurança de clientes corporativos pedem rastreabilidade de alteração. Empresa que não consegue mostrar o histórico assume um risco desnecessário.

Detecção de acesso indevido. Um usuário exportou a base inteira de clientes numa sexta à noite. Um funcionário demitido acessou o sistema depois do desligamento. Um perfil de leitura virou administrador. Esses padrões só aparecem se estiverem registrados, e valem alerta automático, não só consulta posterior.

O que registrar

O critério é simples: registre o que alguém pode precisar provar depois.

Cada evento precisa de: quem (identificador do usuário, não só o nome, que pode mudar), o quê (ação e entidade), quando (data e hora em UTC), onde (IP e agente do navegador), sobre o quê (identificador do registro) e o que mudou (valor anterior e novo).

O par "valor anterior e novo" é o que transforma o registro em prova. "Fulano alterou o pedido 1042" ajuda pouco. "Fulano alterou o desconto do pedido 1042 de 5% para 40% em 12/05 às 22h14" resolve a conversa.

Como armazenar

Somente inserção. Nada de UPDATE ou DELETE na tabela de auditoria. No PostgreSQL, isso se garante no nível de permissão: o usuário da aplicação recebe apenas INSERT e SELECT naquela tabela.

Separado dos dados operacionais. Schema próprio ou banco próprio. Além de proteger, facilita aplicar uma política de retenção diferente.

Particionada por período. Tabela de auditoria cresce rápido. Partição por mês mantém a consulta rápida e permite descartar períodos antigos sem apagar linha por linha.

Indexada pelas consultas reais. Você vai buscar por usuário, por período e por registro afetado. Índices em (usuario_id, criado_em) e (entidade, entidade_id, criado_em) cobrem quase tudo.

Sem dado que não deveria estar ali. Senha, token, número completo de cartão. O registro de auditoria vira alvo justamente por concentrar informação.

Para requisitos mais rígidos, existe encadeamento por hash: cada linha guarda o hash da anterior, e alterar uma quebra a cadeia toda. É desproporcional para a maioria dos sistemas, mas resolve quando alguém questiona a integridade do próprio registro.

Duas formas de implementar

Na aplicação. O código dispara o evento com contexto de negócio: "aprovou o orçamento", "cancelou por falta de estoque". É o mais legível e o que produz melhor relatório. O risco é esquecer de instrumentar um caminho novo.

No banco, por gatilho. Um trigger em cada tabela registra qualquer alteração, inclusive as feitas por script ou por acesso direto ao banco. Não escapa nada, mas o registro fica em linguagem técnica e sem intenção, você vê o campo que mudou, não o motivo.

A combinação costuma ser o melhor arranjo: gatilho como rede de segurança, evento de aplicação para o que precisa de significado.

Tornar a trilha útil, não só existente

Registro que ninguém consegue consultar é peso morto. Três coisas transformam a trilha em ferramenta:

1. Tela de consulta para o gestor, com filtro por usuário, período e registro, sem precisar chamar o desenvolvedor.
2. Histórico dentro do próprio registro. Uma aba "histórico" no cadastro do cliente ou no pedido, mostrando a linha do tempo de alterações. É onde a auditoria é realmente usada no dia a dia.
3. Alertas automáticos para padrões que merecem atenção: exportação em massa, login fora do horário, elevação de privilégio, muitas falhas de senha seguidas.

Retenção: quanto tempo guardar

Não guarde para sempre por hábito, registro de auditoria contém dado pessoal e entra na lógica de necessidade e finalidade da LGPD. Um esquema comum:

• Autenticação e acesso: 12 a 24 meses
• Alterações de dado de negócio: 5 anos, alinhado a prazos fiscais e cíveis
• Operações financeiras e fiscais: conforme obrigação legal específica
• Registros sob litígio: preservados até o fim do processo

Os prazos exatos dependem do setor e do tipo de documento. Defina a tabela com o contador e valide com advogado, a orientação aqui é de projeto, não jurídica.

Por onde começar

Se hoje o sistema não tem nada, comece pelo que resolve mais rápido: login, mudança de permissão e alteração de valor financeiro. Esses três cobrem a maior parte das perguntas que aparecem na prática. Depois amplie para dado pessoal e para os cadastros centrais.

Implementar auditoria em sistema já em produção é trabalho de dias, não de meses. O que não dá para fazer é gerar retroativamente o registro do que já aconteceu, por isso a data de começar importa mais do que a perfeição do desenho.