Auditoria de integridade de bancos de dados SQL: o que a perícia revela quando os dados não batem

O banco de dados é o coração de qualquer sistema. Quando os dados não batem — valores que sumiram, registros que mudaram, timestamps que não fazem sentido —, a disputa pode ser trabalhista (horas alteradas em um sistema de ponto), comercial (saldos manipulados) ou contratual (dados corrompidos por software defeituoso).

O que o perito examina

A análise começa pela estrutura do banco (DDL) e avança para os dados (DML):

• Logs de transação: o transaction log ou o binlog registra cada operação — INSERT, UPDATE, DELETE — com timestamp e, em muitos casos, com o usuário que executou;
• Triggers e stored procedures: código que executa automaticamente e pode alterar dados sem que o operador perceba;
• Constraints e foreign keys: se estão presentes (integridade garantida pelo banco) ou ausentes (o sistema confia que o aplicativo não vai errar);
• Backups e snapshots: comparar o estado do banco em datas diferentes para identificar quando e o que mudou.

Manipulação versus defeito

Nem toda inconsistência é fraude. O assistente técnico precisa distinguir entre: (a) manipulação intencional (alguém executou um UPDATE direto no banco, fora do sistema); (b) bug do software (o sistema escreveu o dado errado por uma falha de lógica); e (c) falha de infraestrutura (perda de dados por crash sem backup adequado). A causa muda completamente a responsabilidade jurídica — e a prova é técnica.

Traduzindo para o juízo

O laudo não diz "houve um UPDATE na tabela tb_saldo na coluna vl_total". Diz: "em 14/03/2024, às 22:47, o saldo da conta X foi alterado diretamente no banco de dados, fora do sistema, por um usuário com credenciais de administrador — o que é incompatível com uma operação normal do sistema e sugere intervenção manual". Isso o juiz entende.