Plataforma de PLD-FT: entity resolution, grafos e IA

Há um padrão de falha que se repete em projetos de plataforma de PLD-FT: a organização compra ou constrói capacidade de detecção por aprendizado de máquina antes de resolver quem é quem na própria base. O modelo entra em produção, aponta anomalias, e os analistas descobrem que metade dos alertas envolve a mesma pessoa aparecendo como quatro clientes diferentes. O problema não era de detecção.

Este artigo trata da arquitetura: quais módulos existem, em que ordem eles rendem e quais controles a entrada de IA torna obrigatórios. É o aprofundamento da seção de tecnologia do programa de PLD-FT.

A ordem importa: dados antes de modelo

Nenhum controle funciona melhor do que a qualidade dos dados que o alimenta. Essa frase é repetida com frequência e raramente tratada como restrição de projeto. Na prática, ela define uma ordem de construção:

1. Ingestão confiável — dados chegam completos, no prazo e com origem registrada.
2. Resolução de entidade — a mesma pessoa ou empresa é uma só no sistema.
3. Vínculos — relações entre entidades resolvidas ficam navegáveis.
4. Detecção — regras primeiro, modelos depois, sobre dados já resolvidos.
5. Investigação e caso — o analista trabalha com contexto, não com linhas soltas.
6. Relatório explicável — a decisão é reconstituível meses depois.

Inverter os passos 2 e 4 é o erro mais caro, porque ele não aparece como defeito técnico. Aparece como "o modelo gera muito falso positivo", e a equipe passa a recalibrar modelo quando o problema está na camada abaixo.

Entity resolution: o módulo que sustenta os outros

Entity resolution é o processo de determinar se registros diferentes representam a mesma pessoa ou entidade. O exemplo canônico:

Registro	Informação
A	João da Silva
B	JOAO SILVA
C	João A. da Silva
D	CPF 123.456.789-00

Decidir se esses quatro registros são uma entidade, duas ou quatro é a pergunta que organiza a plataforma inteira. A comparação pode considerar nome normalizado, CPF ou CNPJ, data de nascimento, endereço, telefone, e-mail, participações societárias e, quando permitido e necessário, nome da mãe.

A regra prática: correspondência apenas por nome tem baixa confiabilidade, especialmente com homônimos. É o mesmo princípio que torna o screening de sanções e PEP um problema de identificação de entidade, e não de busca textual — os dois módulos resolvem a mesma questão com consequências diferentes.

Os dois erros de resolução, e qual deles dói mais

Erro	O que acontece	Consequência
Sub-agrupamento (falha ao unir)	Uma entidade aparece como várias	O grafo não enxerga a estrutura; monitoramento subestima volume e concentração
Super-agrupamento (unir indevidamente)	Entidades distintas viram uma	Atribui a alguém movimentação de terceiro; contamina alerta, score e dossiê

O super-agrupamento é o mais grave, porque produz uma afirmação falsa sobre uma pessoa e se propaga silenciosamente para o relatório. Por isso a decisão de unir registros deve ser auditável: qual atributo decidiu, com que confiança, e com possibilidade de revisão. Resolução de entidade não é um passo de limpeza — é uma decisão que precisa de trilha, como qualquer outra decisão do programa.

O grafo de vínculos

Resolvida a identidade, o grafo de conhecimento representa entidades e seus relacionamentos: pessoas físicas, pessoas jurídicas, sócios, administradores, endereços, telefones, contas, dispositivos e contrapartes financeiras. Ele revela conexões que a análise isolada não mostra — por exemplo, que quatro empresas destinatárias de um mesmo fluxo compartilham administrador e endereço.

Três usos pagam a construção do grafo:

• Enriquecimento do alerta. O analista recebe o alerta já com a vizinhança da entidade, em vez de montá-la à mão.
• Detecção estrutural. Padrões que só existem em rede — circularidade, concentração de contrapartes, hubs de endereço — não são expressáveis em regra por transação.
• Propagação de risco. Exposição de uma entidade a uma contraparte de risco elevado é computável a uma ou duas arestas de distância.

O terceiro uso exige cuidado explícito: propagar risco por vizinhança, sem limite de distância e sem peso por tipo de aresta, transforma o grafo em máquina de contaminar clientes legítimos. Dois graus de separação em um grafo que inclui endereço de coworking conectam meio mercado.

Modelar o grafo é, antes de tudo, decidir o significado de cada tipo de nó e de aresta — um problema de ontologia, tratado em ontologias para organizar conhecimento e inteligência.

Os doze módulos e o que cada um resolve

Módulo	Pergunta que ele responde
Data ingestion	Os dados chegaram completos, no prazo e com origem registrada?
Entity resolution	Quem é quem, de verdade, nesta base?
KYC e KYB	Quem é o cliente, pessoa ou empresa, e o que ele declara fazer?
UBO engine	Quem controla a entidade em última instância?
Sanctions screening	A contraparte está sujeita a restrição?
PEP screening	O relacionamento exige procedimento específico?
Transaction monitoring	O comportamento desvia do esperado para este perfil?
Risk scoring	Onde concentrar capacidade de análise?
Graph intelligence	Que estrutura existe entre as entidades envolvidas?
Investigation management	O analista tem contexto, trilha e prazo?
Case management	O caso tem dono, estado, histórico e encerramento?
Explainable reporting	É possível reconstituir a decisão meses depois?

Duas observações sobre essa lista. O módulo de UBO costuma ser subestimado: identificar beneficiário final exige percorrer participações indiretas e controle exercido por outros meios, e é trabalho de grafo, não de consulta cadastral. E os módulos 10 e 11 são distintos de propósito — gestão de investigação cuida do trabalho analítico, gestão de caso cuida do ciclo de vida e da prestação de contas.

Regras e modelos convivem

A escolha entre monitoramento baseado em regras e aprendizado de máquina costuma ser apresentada como disputa. Na operação, cada abordagem cobre o que a outra não cobre:

Aspecto	Regras	Aprendizado de máquina
Explicabilidade	Alta — a condição está escrita	Variável, exige técnica própria
Auditoria	Simples	Exige versionamento de dado, modelo e features
Padrão desconhecido	Não detecta o que não foi previsto	Pode apontar o não previsto
Falso positivo	Tende a ser alto	Pode reduzir com priorização
Manutenção	Revisão de limiares	Retreino, validação e monitoramento de deriva
Resposta a tipologia nova	Rápida — escreve-se a regra	Lenta — depende de dado rotulado

As técnicas usuais do lado estatístico são isolation forest, agrupamento, modelos supervisionados, detecção de anomalias e análise de séries temporais. A última linha da tabela explica por que as regras não desaparecem: quando surge uma tipologia nova, escrever a regra leva horas, enquanto treinar modelo depende de casos rotulados que ainda não existem.

Há um paralelo direto com o lado defensivo da segurança, onde a mesma convivência entre regra determinística e detecção estatística é discutida em detection engineering — inclusive o hábito saudável de testar a regra contra casos construídos antes de confiar nela.

Medir o que importa

Precisão — proporção de alertas relevantes sobre alertas analisados — é o indicador mais citado e o mais fácil de usar mal. Precisão alta com cobertura baixa descreve um sistema que só olha onde já sabe olhar. Ela precisa vir acompanhada de uma estimativa de casos relevantes que não geraram alerta, obtida por amostragem independente ou por teste com casos construídos. Sem isso, o painel mede conforto, não efetividade.

Os nove controles obrigatórios de IA

Inteligência artificial ajuda em detecção de anomalias, extração de informação de documentos, identificação de beneficiários finais, resolução de entidades, correlação de pessoas e empresas, classificação de notícias, análise de redes, priorização de alertas e produção de resumos investigativos. Em troca, exige nove controles:

Controle	Como ele se verifica na prática
Rastreabilidade dos dados	Para qualquer saída, é possível listar os dados que a produziram
Explicabilidade	A classificação vem com os fatores que mais pesaram
Falsos positivos e negativos	Ambos medidos, com meta e série histórica
Deriva do modelo	Distribuição de entrada e de saída monitorada, com gatilho de revisão
Validação humana	Decisão relevante tem revisor identificado e registro da discordância
Proteção de dados pessoais	Finalidade, necessidade, retenção e segurança definidos por conjunto de dados
Controle de acesso	Acesso por função, incluindo ao histórico de casos
Auditoria de alterações	Toda mudança de regra, limiar, modelo ou feature deixa registro
Testes de efetividade	Exercício periódico com casos conhecidos e com casos construídos

O quinto controle é o que sustenta os outros oito. Decisão de risco com efeito sobre uma pessoa ou empresa precisa de supervisão humana efetiva — revisor que pode discordar, com a discordância registrada — e não de aprovação formal de uma saída que ninguém consegue explicar.

O oitavo merece destaque de segurança, não só de compliance. Quem pode alterar um limiar sem deixar registro pode criar um ponto cego sob medida. O motor de regras é um ativo a proteger com a mesma seriedade de um sistema de produção, e a classificação da base de KYC e dos dossiês segue a mesma lógica discutida em classificação e estados dos dados.

Sobre assistentes que resumem investigação ou respondem com base no acervo interno, vale a ressalva: recuperação sobre documento interno não substitui controle de acesso nem dispensa citação de fonte, como detalha RAG e LangChain aplicados à segurança. Um resumo investigativo sem procedência é uma conveniência que enfraquece o dossiê.

Explainable reporting: o módulo tratado como acessório

Dos doze módulos, o de relatórios explicáveis é o que mais costuma ser deixado para a última sprint e o que mais determina se o programa resiste a uma supervisão. A razão é simples: ele é a única parte da plataforma que um auditor externo realmente examina em profundidade.

Um relatório explicável precisa responder, para um caso encerrado há oito meses:

• qual regra ou modelo gerou o alerta, em qual versão;
• quais dados entraram na avaliação e de onde vieram;
• quais entidades foram unidas pela resolução de identidade, e com base em quê;
• qual era o score e quais fatores mais pesaram nele;
• quais listas foram consultadas, em qual versão e data;
• o que o analista verificou, o que o cliente respondeu e o que não foi possível explicar;
• quem decidiu o encerramento e com qual fundamento.

Observe que quase todos esses itens são dados que a plataforma já possui — e perde, por não persistir a versão do que foi usado. Guardar o resultado sem guardar o contexto que o produziu é o que transforma um sistema auditável em um sistema que apenas parece auditável.

Essa é também a diferença entre coletar evidência na origem e reconstruí-la na véspera da auditoria, a lógica de conformidade contínua. O custo de persistir contexto é de armazenamento. O custo de não persistir aparece de uma vez, quando alguém pergunta por que aquele caso foi encerrado.

Perguntas Frequentes

Conclusão

A sequência que funciona é ingestão confiável, resolução de entidade, vínculos, detecção, investigação e relatório explicável. Quem começa pela detecção acaba recalibrando modelo para compensar um problema de identidade — e paga duas vezes pelo mesmo trabalho.

Se o programa já está em operação e precisa de um próximo passo, dois diagnósticos rendem mais do que qualquer aquisição. Primeiro: medir quantos clientes distintos na base são, de fato, a mesma entidade. Segundo: pegar um caso encerrado há seis meses e tentar reconstituir a decisão — versão da regra, versão da lista, fatores do score, o que o cliente respondeu. O que não for possível reconstituir é exatamente a lacuna que uma supervisão vai encontrar.

E o princípio que atravessa os nove controles de IA não é técnico: a IA apoia a investigação e não converte correlação estatística em acusação. Modelo aponta onde olhar. Quem conclui é uma pessoa, com nome registrado no caso.