Um sistema de DP e RH concentra decisões que precisam ser explicáveis depois: quem alterou um salário, quem aprovou um afastamento, quem acessou o holerite de um terceiro. A trilha de auditoria é o que transforma "acho que foi assim" em "foi isto, por esta pessoa, nesta data". E ela é uma expectativa concreta da LGPD, não um extra que só empresas grandes precisam ter.
O que a LGPD espera
A LGPD trabalha com o princípio da responsabilização e prestação de contas (art. 6º, X): o controlador precisa ser capaz de demonstrar que adotou medidas eficazes de proteção, não apenas afirmar que adotou. Na prática, isso inclui manter registro das operações de tratamento de dados pessoais (art. 37) e adotar medidas de segurança aptas a proteger os dados (art. 46). Uma trilha que mostra autor, data e o que mudou é a forma mais direta de cumprir isso, porque responde exatamente à pergunta que uma fiscalização, um colaborador ou um processo judicial pode fazer meses depois: quem fez isso, e quando.
Por que a trilha precisa ser imutável
Um registro de alterações que pode ser editado ou apagado por quem operou o sistema não serve como prova, porque a mesma pessoa que teria motivo para esconder um erro é quem controlaria o registro desse erro. O valor da trilha está em ela ser append-only: cada evento é adicionado, nada é reescrito. Quando um gestor corrige um horário de ponto, por exemplo, o ajuste é gravado como ajuste, com o valor anterior preservado, sem substituir o registro original. Assim, quando alguém perguntar por que o horário daquele dia é diferente do que o colaborador bateu originalmente, a resposta está no próprio histórico, não na memória de quem fez a correção.
Esconder um botão não é bloquear o acesso
O erro de segurança mais comum em sistemas de gestão é este: a tela esconde uma aba ou um botão para quem não deveria ver aquilo, mas a consulta por trás continua respondendo normalmente. Quem sabe montar a requisição direto na API vê o dado assim mesmo, porque a interface só decidiu não mostrar um link, e não impediu a pergunta de chegar ao banco. Isso costuma passar despercebido justamente porque, no dia a dia, ninguém tenta contornar a tela, então o problema fica invisível até uma auditoria de segurança ou um incidente real revelar a falha.
O controle de acesso real precisa estar na camada de dados, não na interface. No modelo de segurança em nível de linha (RLS), cada consulta ao banco carrega a identidade de quem pergunta, e a política decide o que aquela pessoa pode ver e alterar, independentemente do que a tela mostra ou esconde. Holerite de terceiro, dados de outro setor, folha de outra competência: o bloqueio vale mesmo para o acesso via API, o que é a diferença entre uma restrição de UX e uma restrição de segurança de fato.
Acesso mínimo e finalidade
A LGPD exige que o acesso a dados pessoais tenha finalidade e proporção (art. 6º). Conceder a um prestador externo, como um contador ou uma consultoria, apenas o acesso mínimo necessário, com trilha de todas as suas ações, é o comportamento esperado de um operador de dados. Credencial compartilhada é o oposto disso: some a identidade de quem fez o quê, e uma trilha que registra "operador financeiro fez X" quando três pessoas diferentes usam esse login não cumpre a mesma função de uma trilha que aponta uma pessoa real.
O que uma boa trilha evita, na prática
Além do cumprimento formal da LGPD, uma trilha de auditoria bem feita evita três situações desgastantes que aparecem com frequência em empresas que não têm esse controle:
- A disputa sem prova. Um colaborador questiona um valor no holerite, ou alega que nunca foi avisado de uma mudança de horário, e sem registro a discussão fica no "sua palavra contra a minha".
- A investigação lenta. Quando algo dá errado, como um cadastro alterado de forma indevida, reconstruir o que aconteceu sem trilha depende de perguntar pessoa por pessoa, o que é lento e nem sempre confiável.
- A responsabilidade diluída. Sem autor claro em cada alteração, é difícil separar um erro de operação de uma ação deliberada, o que torna qualquer correção de processo mais difícil de direcionar.
O que sustenta a trilha
No ActaOne, toda alteração relevante é registrada com autor, data e o que mudou, em uma trilha imutável. O ajuste de ponto grava o valor anterior; o espelho, o fechamento e o PDF assinado usam sempre o dado congelado, nunca um valor que possa ter sido reescrito depois. O acesso é controlado por RLS no banco: uma aba escondida na interface não significa acesso liberado por trás dela. As permissões são granulares por módulo (ver, editar, excluir), o convite de operador define o mínimo necessário para a função, e a suspensão invalida a sessão ativa na hora, sem depender de um próximo login para valer.
Trilha de auditoria não é sobre desconfiar da equipe. É sobre conseguir provar, meses depois, o que aconteceu: para a empresa, para o colaborador e para a autoridade de proteção de dados.
Essa prova só existe se duas coisas forem verdade ao mesmo tempo: o registro não pode ser editado por quem operou o sistema, e o controle de acesso precisa estar na camada de dados, não só escondido na tela. Um sistema que cumpre apenas uma das duas dá a sensação de segurança sem entregar a proteção real que a LGPD espera.