Última atualização: outubro de 2026
Uma plataforma de IA para AML precisa passar por todos os testes exigidos para qualquer sistema de AML, incluindo cobertura, gestão de casos, dados e custo. Ela também precisa passar por quatro testes que uma avaliação baseada em regras costuma subestimar: as evidências por trás de cada resultado, confirmação humana desde a concepção, controle de alterações em modelos e agentes, e resultados que um inspetor consiga ler. Execute todos os quatro testes com seus próprios dados antes de assinar o contrato.
Resumo do essencial
Uma plataforma de AML baseada em IA precisa de quatro testes adicionais em relação a uma avaliação geral de AML: as evidências por trás de cada resultado, confirmação humana desde a concepção, controle de alterações em modelos e agentes, e resultados que um inspetor consiga ler.
Peça, por escrito, os dados, a fonte e a justificativa por trás de qualquer recomendação individual. Um resumo fluente sem um caminho de volta às transações reprova no primeiro teste.
Mapeie cada ponto em que uma pessoa decide encerrar, escalar ou enviar um relatório, e pergunte quem definiu esses limites e com base em quais evidências.
As orientações interinstitucionais sobre risco de modelos de abril de 2026 (SR 26-2) cobrem modelos de aprendizado de máquina, mas deixam a IA generativa e de agentes fora do seu escopo. Inspetores e compradores ainda esperam testes e validações.
Execute os testes com seus próprios alertas históricos e, depois, em modo de simulação (shadowing) junto com seus analistas, antes que a plataforma impacte decisões em produção.
O que você deve testar em uma plataforma de AML baseada em IA?
Teste quatro pontos que uma avaliação de AML baseada em regras costuma subestimar: se a plataforma mostra as evidências por trás de cada resultado, se uma pessoa confirma cada recomendação desde a concepção, se as alterações em modelos e agentes são aprovadas e registradas, e se um inspetor consegue ler o que ela produz. Em seguida, execute todos os quatro testes com seus próprios dados.
Evidências por trás de cada resultado. Cada recomendação traz os dados utilizados, sua fonte e a justificativa, e o analista consegue acessar as transações subjacentes.
Confirmação humana desde a concepção. A plataforma mostra onde as pessoas tomam decisões, e nada é encerrado, escalado ou enviado sem uma decisão que a instituição tenha configurado e consiga defender.
Controle de alterações em modelos e agentes. Toda alteração em um modelo, prompt ou configuração é versionada, testada e aprovada antes de afetar os alertas em produção.
Resultados que um inspetor consiga ler. A lógica e os registros de casos fazem sentido para alguém de fora da equipe de AML.
A pergunta por trás dessas quatro diretrizes é a primeira que os compradores fazem. Um diretor de compliance de uma empresa de pagamentos, criando um programa do zero, colocou desta forma: "Como vou saber se os sistemas estão funcionando como deveriam? Como sei que os sistemas de IA estão funcionando?"
Um motor de regras responde a parte disso por sua própria estrutura: a mesma entrada aciona a mesma regra, e a regra pode ser lida. Um modelo de linguagem não funciona assim.
Um líder de operações de compliance para integração de clientes em um banco disse que os modelos de linguagem parecem ter dias bons e dias ruins, por isso a equipe eliminou o máximo de subjetividade do processo. Um gerente de entregas de TI de uma gestora de ativos descreveu um piloto anterior que analisava alertas de crimes financeiros com um prompt de modelo de linguagem de uso geral. Nada nele era auditável ou explicável, os resultados estavam incorretos e o sistema foi desligado após um curto período de teste.
Estes quatro testes somam-se a uma avaliação geral. Para cobertura, gestão de casos, dados e custo, comece com o guia geral do comprador de software de AML e uma estrutura de avaliação para plataformas de monitoramento de transações. Para entender a diferença entre um prompt e um agente que atua dentro de limites definidos, veja o que é um agente autônomo de IA na gestão de riscos.
Teste 1: as evidências por trás de cada resultado
A pergunta a fazer: para qualquer recomendação individual, mostre-me por escrito os dados que o sistema usou, de onde veio cada informação e a justificativa que as conecta.
Um inspetor vai perguntar como a instituição chegou a uma conclusão, e apenas apontar para o sistema não é uma resposta. Um diretor de compliance e BSA de um banco comunitário descreveu o problema de forma direta: "se eu não tiver isso por escrito, não vou conseguir defender". Um líder de garantia de qualidade de AML em uma fintech pediu a mesma coisa sob a perspectiva da revisão: documentação que pudesse mostrar a um inspetor indicando de onde o sistema tirou cada informação.
O analista também precisa conseguir acessar as evidências. O mesmo diretor disse que, por mais que gostem de IA, não confiam totalmente nela e precisam conseguir voltar e pesquisar um alerta por conta própria. Uma plataforma que mostra um resumo, mas não as transações por trás dele, deixa o analista sem condições de verificar o trabalho.
Investigue dois modos de falha de propósito:
Fatos inventados no texto redigido. Um chefe de estratégia de plataforma de produtos de uma empresa de pagamentos disse que, se uma ferramenta de redação alucinar, enviar um relatório à FinCEN com poucas palavras erradas já seria um problema gravíssimo.
Evidências do lugar errado. Um vice-presidente de subscrição de pagamentos, risco e compliance de um banco perguntou como um fornecedor impediria que um resumo de investigação citasse atividades que pertencem a um portfólio diferente.
Uma resposta fraca aqui é um texto bem-acabado sem link de volta para os registros, ou um rastro de justificativa que cita dados que o analista não consegue abrir. Os auditores já pedem comprovações para conclusões documentadas: um gerente de compliance de uma instituição de crédito ao consumidor disse que essa foi a exigência após a auditoria mais recente de BSA/AML. Para testar isso em uma demonstração, escolha um caso encerrado que você conheça bem, peça à plataforma para mostrar suas evidências e cruze cada fato citado com seus próprios sistemas.
Teste 2: confirmação humana desde a concepção
A pergunta a fazer: mostre-me cada ponto onde uma pessoa confirma, escala ou envia um relatório, e me mostre o que, se houver algo, pode acontecer sem a intervenção de uma pessoa.
Os órgãos reguladores esperam que a instituição demonstre supervisão. Um MLRO de uma empresa de pagamentos disse que, ao apresentar um sistema de IA a um regulador, precisaria explicar onde as pessoas tomam as decisões finais de escalonamento e de envio de SAR, além de conseguir demonstrar esses pontos de decisão. A plataforma deve facilitar a geração desse mapeamento.
Em seguida, pergunte o que pode ser encerrado sem revisão, quem configurou essa regra e com base em quais evidências. Um líder de IA aplicada a compliance em um banco descreveu a ordem que seguiria antes de permitir qualquer encerramento sem revisão: acumular histórico de alertas, rodar testes paralelos para mostrar que o agente funciona como esperado e só então avançar, em sintonia com o ciclo de vida interno de revisão de modelos do banco. Essa decisão cabe à instituição, e a plataforma deve registrá-la como tal.
Pergunte também se o comportamento do sistema muda sozinho. Um membro da equipe de BSA de uma cooperativa de crédito disse que presumia que o sistema aprenderia com os alertas que a equipe encerrava repetidamente e começaria a encerrá-los por conta própria. O comportamento deve mudar apenas por meio de uma alteração aprovada e registrada, o que nos leva ao Teste 3.
As travas de segurança ao redor do modelo importam tanto quanto o próprio modelo. O gerente de entregas de TI da gestora de ativos explicou de forma simples: "você precisa de travas de segurança determinísticas na entrada. Precisa do LLM no meio e de travas determinísticas na saída". Pergunte quais etapas são regras fixas, quais são saídas do modelo e onde há a validação de uma pessoa.
Uma resposta fraca descreve a revisão humana como uma opção que o cliente pode desativar, ou não sabe dizer quem definiu os limites. Para entender onde a validação humana se encaixa em todo o programa, veja o que a IA muda em um programa de AML.
Teste 3: controle de alterações em modelos e agentes
A pergunta a fazer: mostre-me o histórico de cada alteração de modelo, prompt e configuração, quem a aprovou e como eram os resultados antes e depois.
Uma plataforma de AML baseada em IA muda em mais pontos do que um motor de regras: modelos são retreinados, prompts são editados e as instruções dos agentes são revisadas. Cada mudança pode alterar quais alertas recebem atenção e o que consta no arquivo do caso. O líder de IA em compliance do banco disse que o processo ponta a ponta precisa ser defensável em uma auditoria interna de risco de modelos, o que significa ser capaz de mostrar "o histórico dos prompts ou o histórico dos resultados, o que mudou ao longo do tempo".
As equipes de BSA já trabalham dessa forma para as regras. Um diretor de BSA de um banco comparou os dois lados da instituição: as equipes de fraude alteram as regras primeiro e as enviam para revisão de risco de modelos depois, enquanto as alterações de regras de BSA passam por revisão antes de entrarem em vigor. Um responsável por programa de BSA em uma cooperativa de crédito descreveu a mesma obrigação da perspectiva de gestão: explicar como o sistema gera alertas e, nos pontos em que mudou durante o período, como garantiram que a alteração era consistente.
Três pontos a solicitar:
Aprovação antes do uso em produção. Toda alteração em um modelo, prompt ou configuração que afete alertas de AML deve ser aprovada pela instituição antes de ir para o ambiente de produção.
Trilhas de auditoria para execuções de teste. Durante uma prova de conceito em um banco, a equipe de avaliação perguntou se existiam trilhas de auditoria para execuções de teste, e não apenas para decisões em produção. Elas devem existir.
Documentação do modelo que especifique suas entradas. Um líder de risco e compliance de um banco perguntou como seria a documentação do modelo — por exemplo, um registro mostrando que o agente foi configurado a partir dos procedimentos próprios do banco e das regras trazidas do sistema anterior.
Como estão as orientações sobre risco de modelos
Em 17 de abril de 2026, o Federal Reserve (SR 26-2), o OCC (Boletim 2026-13) e o FDIC (FIL-15-2026) emitiram orientações interinstitucionais revisadas sobre gestão de risco de modelos. Elas substituem a SR 11-7 e a declaração interinstitucional de 2021 sobre gestão de risco de modelos para sistemas de BSA/AML. Modelos de aprendizado de máquina usados em AML estão cobertos por elas. O boletim do OCC é explícito sobre onde a norma para: "Modelos de IA generativa e IA baseada em agentes são novos e evoluem rapidamente. Dessa forma, não estão no escopo desta orientação."
Os órgãos reguladores afirmaram que pretendem emitir um pedido de informações sobre gestão de risco de modelos, considerando em especial o uso de IA pelos bancos. Até outubro de 2026, isso ainda não havia sido emitido.
Os inspetores continuam exigindo testes. Um oficial sênior de compliance de sanções em um banco disse que todo sistema passa por validação sob sua política de risco de modelos e que a IA, por ser mais recente, exige testes amplos para demonstrar ao regulador que a instituição está segura com o uso. O responsável pelo programa de BSA da cooperativa de crédito mencionou que a validação independente de modelos é uma orientação e não uma lei, mas que hoje parece uma exigência que os inspetores vão cobrar se estiver ausente.
Uma resposta fraca é um cronograma de lançamentos do fornecedor tendo as notas de versão como único registro, onde ninguém na instituição aprova as alterações que modificam seus alertas.
Teste 4: resultados que um inspetor consiga ler
A pergunta a fazer: exporte sua lógica e o registro completo de um caso e entregue a alguém fora da equipe de AML. Essa pessoa consegue acompanhar ambos?
O diretor de compliance da mesma fintech descreveu o processo de transformar as regras em um documento de política que lista cada regra e sua função, para que um inspetor com conhecimento geral de negócios, mas sem especialização em AML, pudesse entender. Esse é o padrão exigido para uma plataforma de AML com IA: lógica e registros de casos escritos para um leitor que não utiliza o produto no dia a dia.
Resultados legíveis também protegem a compreensão da própria instituição. O diretor de compliance e BSA do banco comunitário disse que um sistema que a equipe não consegue entender seria muito difícil de defender, pois "os reguladores gostam de saber que você entende como o sistema funciona".
A integridade das informações faz parte da legibilidade. O MLRO da empresa de pagamentos disse que os pontos criticados pelos reguladores são informações ausentes e números que não batem: se um alerta cobre um conjunto de transações, a análise descritiva deve cobrir cada uma delas. Verifique se o registro do caso na plataforma bate exatamente com o alerta.
Por fim, pergunte ao fornecedor quais pontos os inspetores questionaram em outras instituições que usam a plataforma. O líder de risco e compliance do banco fez exatamente essa pergunta, incluindo se a documentação de validação tinha sido solicitada. Uma resposta fraca é ter uma lógica compreensível apenas dentro do produto, ou explicações escritas em termos técnicos do modelo que um inspetor não consiga cruzar com o caso.
Visão geral dos quatro testes
Teste | Solicite | Uma resposta fraca | Uma resposta forte |
|---|---|---|---|
Evidências por trás de cada resultado | Dados, fonte e justificativa para uma recomendação, por escrito | Um resumo bem redigido sem caminho para as transações | Cada fato citado direciona para o registro de origem |
Confirmação humana desde a concepção | Um mapa de cada ponto onde uma pessoa decide | Revisão descrita como uma opção que pode ser desligada | Pontos de decisão exibidos, indicando quem configurou cada um |
Controle de alterações em modelos e agentes | Histórico de alterações com aprovações e resultados de antes e depois | Notas de versão como único registro | Alterações versionadas e aprovadas pela instituição antes do uso em produção, com trilhas de auditoria dos testes |
Resultados que um inspetor consiga ler | Lógica exportada e um registro completo de um caso | Lógica compreensível apenas dentro do produto | Alguém de fora da área consegue acompanhar as regras e o caso, e os números batem |
Use a tabela como um guia de avaliação durante a prova de conceito, analisando uma linha para cada teste.
Como executar os testes com seus próprios dados
Uma demonstração com os dados do fornecedor mostra apenas o melhor cenário dele. O diretor de compliance e BSA do banco comunitário disse que, como os processos são customizados e adaptados para a instituição, uma prova de conceito com dados próprios era um requisito obrigatório antes da compra.
Defina os critérios de aceitação com antecedência. Decida o que é considerado aprovação para cada um dos quatro testes antes de transferir qualquer dado.
Faça testes retroativos com alertas históricos. Execute a plataforma com alertas já encerrados e resultados conhecidos e compare o que ela recomendou com o que seus analistas decidiram.
Rode em modo de simulação (shadowing). Coloque a ferramenta para rodar em paralelo com os analistas em alertas reais, sem impactar as decisões finais, e acompanhe a taxa de concordância ao longo do tempo. Analise cada divergência, além da taxa geral.
Pergunte quem faz os ajustes e quem testa. O diretor de compliance da empresa de pagamentos disse que o monitoramento e os testes sob a perspectiva de compliance regulatório são exaustivos, porém essenciais, e queria saber se a instituição ou o fornecedor ajusta as regras.
Pergunte como são testados vieses, alucinações e desvios (drift). Um gerente sênior de compliance da mesma instituição de crédito ao consumidor perguntou como o fornecedor evita vieses, alucinações e desvios para que a empresa não enfrente problemas regulatórios por práticas abusivas (UDAP). O líder de risco e compliance do banco perguntou como o fornecedor valida sua governança de IA, incluindo vieses. Peça para ver os resultados desses testes.
Envolva seu regulador no processo. Um líder de gestão de riscos em um banco parceiro descreveu que rodar a IA em paralelo com os processos existentes é a melhor forma de deixar os reguladores seguros ao longo do tempo.
Erros comuns em uma avaliação de AML com IA:
Testar com dados de exemplo do fornecedor em vez dos seus próprios alertas.
Tratar um resumo simples como evidência.
Aceitar a promessa de que o sistema aprende sozinho sem perguntar quem aprova cada alteração.
Definir critérios de aceitação só depois que a prova de conceito já começou.
Se você supervisiona programas de fintechs
Os mesmos quatro testes se aplicam a todos os programas que você supervisiona, com uma pergunta a mais: você consegue ver os alertas, evidências e alterações de cada parceiro em um só lugar, e mostrar a um inspetor qual lógica de qual programa mudou e quando? Um diretor de tecnologia e risco em um banco parceiro disse que um inspetor cobrou fortemente a validação de dados, a validação de IA e a validação de modelos em uma instituição anterior, motivo pelo qual essas perguntas agora vêm em primeiro lugar.
Um chefe de tecnologia e garantia de programas de BSA/AML em um banco parceiro descreveu a inclusão de uma camada de testes independentes entre as operações e a auditoria, para que o banco possa mostrar aos inspetores os testes temáticos e direcionados que já realizou. Para ver como um banco parceiro estrutura essa supervisão, confira supervisão de AML em bancos parceiros para programas de fintechs.
Perguntas frequentes
Uma plataforma de AML com IA é diferente de um software de AML que usa aprendizado de máquina?
Uma plataforma de AML baseada em IA geralmente vai além de um modelo de aprendizado de máquina que pontua transações. O monitoramento de transações com IA, em que um modelo pontua ou prioriza alertas, é apenas uma parte. O restante é a IA aplicada à investigação em si: coletando evidências, resumindo atividades e redigindo recomendações ou análises para revisão do analista. É nessa segunda parte que as evidências, a confirmação humana e o controle de alterações exigem testes próprios.
Qual trilha de auditoria uma plataforma de AML com IA deve manter para os inspetores?
Para cada decisão, a trilha de auditoria deve mostrar os dados utilizados e sua fonte, a justificativa, a recomendação, a pessoa que confirmou ou alterou a decisão, e a versão do modelo, prompt ou configuração que a gerou. Ela também deve registrar os testes executados e cada alteração com sua respectiva aprovação. Um inspetor deve ser capaz de reconstruir qualquer decisão usando apenas o registro do sistema.
As orientações de gestão de risco de modelos se aplicam a plataformas de AML com IA?
Em parte. As orientações interinstitucionais revisadas, emitidas em 17 de abril de 2026 (SR 26-2, OCC Bulletin 2026-13, FIL-15-2026), cobrem modelos de aprendizado de máquina e substituem a SR 11-7 e a declaração de risco de modelos de BSA/AML de 2021. O OCC declara que modelos de IA generativa e de agentes não estão no seu escopo, e o pedido de informações que os órgãos pretendem fazer sobre gestão de risco de modelos — com foco em IA — ainda não havia sido emitido até outubro de 2026. As instituições continuam validando e testando esses sistemas porque os inspetores exigem isso.
Como uma plataforma de AML com IA pode reduzir a revisão manual e manter a validação humana?
A plataforma reúne as evidências entre os sistemas e redige uma recomendação, enquanto o analista revisa e toma a decisão. Qualquer mudança no que precisa de revisão é uma escolha da instituição, feita após testes retroativos e simulação (shadow running), e registrada como uma alteração aprovada. O tempo economizado vem do trabalho de coleta de dados, enquanto a palavra final continua com as pessoas.
Onde a Oscilar se encaixa
Os agentes da Oscilar podem rodar como uma camada autônoma sobre a infraestrutura que você já possui ou como parte da plataforma unificada. Eles são desenvolvidos para que uma pessoa confirme cada recomendação: o agente reúne as evidências e faz a recomendação, e o analista toma a decisão. A Oscilar mantém uma trilha de auditoria completa por decisão, com as justificativas salvas, e inclui a validação humana em todas as etapas desde a sua concepção.
A plataforma foi projetada para se adequar às orientações interinstitucionais de gestão de risco de modelos. Como essa orientação deixa a IA generativa e de agentes fora de seu escopo, nenhuma garantia de adequação se estende diretamente aos agentes: aplique à camada de agentes os mesmos quatro testes acima, usando seus próprios dados.
Para ver como isso se aplica ao programa de AML de um banco, leia sobre a solução de AML da Oscilar para bancos.

Saurabh Bajaj
Diretor de Produto
Há quase duas décadas, Saurabh desenvolve e expande plataformas de risco baseadas em inteligência artificial para bancos, fintechs, comércios, governos e instituições financeiras inovadoras. Desde o combate a golpes e invasões de contas até a modernização de infraestruturas de crédito, prevenção a fraudes e antilavagem de dinheiro, ele tem ajudado os ecossistemas financeiros mais complexos do mundo a transformar suas operações com IA — e, agora, com IA Generativa.








