A pergunta do auditor não é mais “vocês têm regra para PEP?”. É “me mostre a decisão tomada em 16 de março às 14h27 sobre o cliente X. Quem aprovou? Que regra disparou? Qual versão do modelo estava em produção? Qual base de dados foi consultada? Tem print da tela?”.
Quem ainda trata PLD como um motor de regras está cinco anos atrasado. PLD em 2026 é um sistema de evidências. A regra existe há décadas. O que mudou é a obrigação de reconstruir, em qualquer momento, a cadeia completa que produziu aquela decisão, com a mesma precisão de um log de transação financeira.
Esse texto desmonta o que torna um programa de PLD efetivamente auditável, do ponto de vista de engenharia, não de marketing.
1. Linhagem do dado (data lineage)
Toda decisão de PLD tem um input. Esse input vem de algum lugar: um cadastro, uma transação, uma lista restritiva, um documento. Auditoria moderna exige que você responda, para cada decisão:
- De onde veio cada dado que alimentou a decisão?
- Quando esse dado foi capturado ou recebido?
- Versão da base externa (lista, bureau, fonte governamental) no momento da consulta?
- Se mudou depois da decisão, qual o impacto retroativo?
Programas frágeis dependem de “consulta no momento” sem versionar o resultado. Quando o regulador pede a evidência três meses depois, a lista já mudou. O cliente que era PEP em março pode não estar mais na lista hoje. A resposta certa não é “consultamos hoje”, é “consultamos em 16/03 com a versão 2026-03-15 da lista ONU, e aqui está o snapshot armazenado”.
Implementação correta: cada chamada a fonte externa retorna um payload completo (não só o resultado boolean) que é armazenado com hash, versão e timestamp. A decisão referencia o ID desse snapshot, não a consulta em tempo real.
2. Versionamento de modelo e regras
PLD evolui. Regras mudam. Modelos são retreinados. Thresholds são recalibrados. Quando o regulador pergunta “como vocês decidiram esse caso?”, a resposta correta nunca é “essas são as regras atuais”, é “essas eram as regras vigentes naquela data, na versão X, aprovada pelo comitê Y em Z”.
Componentes mínimos:
- Cada regra tem versão semântica (v1.0.0, v1.1.0) e data de promoção a produção.
- Cada modelo de scoring tem hash de pesos, dados de treino e dataset de validação registrados.
- Cada threshold tem owner, data de mudança, justificativa e backtest de impacto.
- Trilha de aprovação com nome, função e timestamp de quem promoveu cada mudança.
Não é sobre fazer commit no Git. É sobre ter, no banco de dados de produção, um ID estável que aponta para a versão exata que decidiu cada caso, recuperável anos depois.
3. Explicabilidade da decisão
A pergunta que destrói programas opacos: “por que esse cliente foi classificado como alto risco?”
Resposta inaceitável: “o modelo retornou score 87”.
Resposta aceitável: “score 87 = 30 pontos por PEP indireto (sócio de empresa X), + 25 pontos por país de operação em lista cinza, + 15 pontos por valor da operação acima do perfil habitual, + 17 pontos por padrão temporal atípico”.
Cada componente é nomeado, pesado e justificado contra uma fonte. Modelos modernos suportam isso via SHAP values, regras destiladas ou árvores de decisão interpretáveis. Black box não passa em auditoria. Não importa quão preciso seja.
Em termos práticos, cada saída do motor deve carregar:
- Score final
- Top-N fatores contribuintes (com pesos)
- Versão do modelo
- Regras determinísticas que dispararam
- Sinais críticos (PEP, sanção, lista interna)
Se você não consegue mostrar isso em uma tela de caso, o programa não é auditável.
4. Trilha de auditoria imutável
A trilha de auditoria não é um log nice-to-have. É o produto que você entrega ao regulador. Tudo o que acontece em torno de uma decisão precisa estar em um log:
- Alerta gerado (quando, por qual regra, com qual score)
- Caso aberto (atribuído a quem, em que fila)
- Dossiê montado (que dados, quais fontes)
- Análise feita (por quem, por quanto tempo, com que justificativa)
- Decisão (qual ação, com qual motivo categorizado)
- Comunicação ao COAF (se aplicável, com número de protocolo)
- Encerramento (data, condições)
Esse log precisa ser imutável. Editar registros depois de fechado não pode ser tecnicamente possível. Soluções comuns: write-once storage, append-only databases, hash em cadeia (estilo blockchain leve), assinatura criptográfica.
A Lei 9.613/98 estabelece a obrigação de manter registros de operações suspeitas e comunicações ao COAF. A BACEN Resolução 4.557/2017 reforça gerenciamento de risco operacional e exige trilha de evidências. A Circular 3.978/2020 detalha as obrigações específicas de PLD/FT para instituições reguladas, e a Resolução BCB 360/2023 atualizou requisitos de gestão de riscos com foco em rastreabilidade.
5. Reprodutibilidade temporal
Cenário real: auditor pede a posição de risco de 15.000 clientes em 30 de junho do ano passado. Você precisa reconstruir o snapshot completo daquela data, não a posição atual.
Isso exige:
- Event sourcing ou time-travel queries no banco de risco.
- Snapshots periódicos salvos com integridade verificável.
- Replay capability: rodar o motor atual contra dados históricos para validar consistência.
- Backtest contínuo: a cada mudança de regra, rodar contra histórico e medir impacto retroativo.
Programa que só sabe responder “essa é a situação hoje” tem problema. Programa que responde “em 30/06, esses eram os 15.000 clientes com risco médio ou alto, com este score breakdown” passa em qualquer inspeção.
6. Revisão independente e governança
A última peça é organizacional. Modelos e regras não podem ser alterados por quem opera o motor sem revisão independente. A matriz típica:
- Analista de risco/compliance: propõe mudança em regra ou threshold.
- Time de modelagem: roda backtest, mede impacto contra dados reais.
- Supervisor: valida o backtest e aprova promoção ao staging.
- Comitê de risco: aprova promoção a produção (especialmente se impacto material).
- Auditoria interna: revisa periodicamente a documentação.
Cada uma dessas funções precisa estar registrada na trilha. Quem propôs, quem testou, quem aprovou, quem revisou. Nada de “todo mundo é responsável”, responsabilidade nominal.
Os erros que matam programas em auditoria
Vimos consistentemente esses padrões em mesas que tropeçaram em inspeção:
-
“Decisão automática” sem registro de versão. O cliente foi bloqueado. Quem decidiu? “O sistema”. Qual versão do sistema? “Atual”. E em março? “Era o mesmo sistema”. Sem versão, sem evidência.
-
Listas consultadas em tempo real sem snapshot. Cliente saiu da lista PEP entre a consulta e o pedido do auditor. A evidência some.
-
Logs em texto livre. “Analista Maria revisou e aprovou”. Que dados Maria viu? Qual o caminho que ela percorreu? Sem dossiê reproduzível, é palavra contra palavra.
-
Regras editadas direto em produção. Sem ambiente staging, sem revisão. Mudança virou produção sem ninguém saber.
-
Backtest “vou rodar quando der”. Modelo está em produção há 18 meses sem nunca ter sido testado contra dados reais. Quando o regulador pergunta a acurácia atual, ninguém sabe.
-
Comunicação ao COAF como tarefa avulsa. Um e-mail, um anexo, um clique. Sem integração ao sistema de casos. Auditor pede a comunicação de junho do ano passado. Onde está? “Vou procurar no e-mail.”
A questão real
A pergunta deixou de ser “vocês fazem PLD?”. É “vocês conseguem provar como fazem PLD, caso a caso, com clareza técnica e jurídica?”.
PLD auditável não é um produto que se compra. É uma arquitetura que se desenha. Engenharia de dados rigorosa, governança de modelo séria, trilha imutável de eventos, explicabilidade nativa e processo organizacional com responsabilidade nominal.
O programa que sobrevive em 2026 não é o que tem as regras mais sofisticadas. É o que, quando o regulador chegar, conseguir entregar em minutos a evidência defensável de cada decisão dos últimos cinco anos.
A Guardline foi desenhada desde o dia zero com essa premissa: cada decisão gera evidência, cada modelo tem versão, cada dado tem linhagem, cada análise é reproduzível. Se você quer ver isso funcionando contra um cenário real do seu negócio, fale com a gente.