Agentes de IA para Conformidade: O seu projeto-piloto é real ou apenas uma excelente demonstração?

No início do nosso webinar recente sobre “desenvolver vs. comprar”, fizemos uma pergunta simples aos participantes. Em que ponto a sua organização está com agentes de IA? 

A maioria (62%) disse que está testando um ou dois projetos-piloto.

Jonathan Awad, cofundador e CEO da Baselayer, não deixou essa passar em branco. "Dizer que está testando um ou dois agentes é uma resposta que serve apenas como desculpa", afirmou ele, ao vivo, para uma sala cheia de pessoas que tinham acabado de escolher essa opção. 

Ele tinha um ponto válido, e o restante do painel passou a hora confirmando isso. Jason Chorlins (Financial Services Advisory, Kaufman Rossin) e o nosso Saurabh Bajaj (Chief Product Officer) juntaram-se a ele, com Phil Goldfeder (American Fintech Council) na moderação.

Em resumo: a maioria dos projetos-piloto de agentes passa no teste da demonstração, mas falha no teste operacional. Abaixo estão cinco mitos que as equipes de conformidade contam a si mesmas sobre seus projetos-piloto, e o que o painel respondeu. Considere este artigo a sua dose de desmistificação da IA de agentes. 

Resumo: o que separa um piloto de agente de IA que funciona de um que fica estagnado?

Um agente eficaz muda a rotina diária da sua equipe, move os números que o seu CCO acompanha e se mantém atualizado quando os seus procedimentos mudam. Um piloto estagnado produz resultados que impressionam em uma demonstração, mas não mudam nada em um dia normal de trabalho. Os cinco mitos, em síntese:

• "Estamos rodando um piloto" não diz quase nada. O teste real é saber se a sua equipe sentiria falta se o agente desaparecesse.

• Bons resultados visuais não são prova. Peça a um investigador experiente para refazer uma amostra das decisões do agente.

• Seus analistas geralmente não são o gargalo. O problema são seus dados e seus processos.

• Desenvolver internamente só sai mais barato se tudo for feito com perfeição. Para a maioria das equipes, comprar primeiro e desenvolver depois é o caminho mais seguro.

• O primeiro agente funcional não é a linha de chegada. Regras, listas e produtos mudam, e o agente precisa acompanhar o ritmo.

Qual é a diferença entre o padrão de demonstração e o padrão operacional?

O padrão de demonstração avalia se o agente parece impressionante em uma apresentação. O padrão operacional avalia se ele se sustenta na sua fila de trabalho, no seu volume habitual, todos os dias. Saurabh deu um número sobre a frequência com que as equipes confundem os dois.

"Nove em cada dez projetos de agentes passam no padrão de demonstração, mas falham no padrão operacional." Saurabh Bajaj, Chief Product Officer, Oscilar

Como saber de que lado da linha o seu piloto está?

Cada um dos cinco mitos abaixo é uma forma de confundir o padrão de demonstração com o operacional, e cada um traz uma verificação rápida para você aplicar ao seu próprio piloto.

Mito 1: "Estamos testando alguns agentes em um piloto."

O ponto de Jonathan foi a sinceridade. Rodar um piloto pode significar ter um agente fazendo trabalho real e confiável, ou apenas "coisas muito simples e rápidas que não têm tanto impacto". Na maioria das vezes, segundo ele, é a segunda opção.

Ele descreveu a IA de agentes no setor bancário como um haltere. A maioria das instituições financeiras nem encosta em agentes. Um pequeno grupo, geralmente com grandes equipes dedicadas, usa agentes para quase tudo. O exemplo citado foi o JPMorgan, que recentemente bloqueou agentes externos de interagir com suas contas enquanto constrói seus próprios agentes.

Saurabh vê o meio desse haltere começando a se preencher. Há um ano, a maioria dos clientes em potencial com quem conversava não sabia por onde começar. Hoje, conversas soltas de prova de conceito estão se transformando em um ou dois agentes nos quais as equipes realmente confiam.

Então, como é quando realmente "funciona"? A resposta de Jonathan foi simples. O agente entra na rotina diária, ajudando a equipe a zerar a fila de pendências e apoiando o treinamento de novos contratados. Funciona quando, nas palavras dele, "você já não consegue mais imaginar a rotina sem ele".

Ele também apontou a barreira da confiança. Quase nenhuma equipe deixa o agente concluir nada sozinho, nem mesmo falsos positivos evidentes. O objetivo descrito por ele é ter uma fila matinal organizada pelo nível de certeza do agente, para que os analistas saibam exatamente onde focar primeiro com mais atenção.

"Dizer que está testando um ou dois agentes é uma resposta que serve apenas como desculpa." Jonathan Awad, cofundador e CEO da Baselayer

Avalie o seguinte: Se você desligasse o seu agente na sexta-feira, alguém notaria na segunda-feira?

Mito 2: "Os resultados parecem ótimos."

Este é o padrão de demonstração em sua forma mais pura. O alerta de Saurabh: "Muitas pessoas estão lançando o que chamo de LLM aplicado a uma interface qualquer e chamando isso de agente". Ele pode até escrever um resumo bem feito e impressionar na apresentação, mas não muda a forma como a equipe realmente trabalha.

Ele também ressaltou que produzir um texto de IA com boa aparência hoje é fácil e barato. Qualquer um consegue gerar páginas de pesquisas e recomendações, mas muito disso acaba se tornando documentos que ninguém lê (ou que alguém pede para outra IA resumir). Isso eleva a régua para o que realmente tem valor.

Em outras palavras, um diretor de conformidade não julga um agente pelo estilo de escrita. Saurabh listou o que eles realmente acompanham:

• Tempo de resolução de alertas

• Precisão das decisões

• Tempo para se adaptar a novas estratégias e tipologias

• Ganho real para a equipe com o uso do agente

Ele deu um exemplo prático. Se um analista leva cerca de 60 minutos para elaborar um relatório de atividade suspeita ou cerca de 50 minutos em uma triagem inicial de alertas, a questão é se o agente consegue reduzir esse tempo a um quinto. Jason acrescentou o teste em que mais confia: pegue uma amostra de casos reais analisados pelo agente, entregue a um investigador experiente e peça para ele reproduzir as decisões. Onde houver divergência, faça os ajustes no agente e rode o teste novamente.

"Esse é um teste de maturidade muito melhor do que apenas perguntar se os resumos parecem bons." Jason Chorlins, Kaufman Rossin

A Kaufman Rossin aplica esse mesmo critério aos seus próprios agentes. Jason contou que sua equipe opera três ou mais agentes na análise inicial de alertas e que, antes de confiar neles, a equipe definiu exatamente o formato que cada resposta deve ter e os padrões mínimos de qualidade que devem ser cumpridos. 

O agente de revisão de alertas de PLD da Oscilar segue a mesma lógica: ele sugere uma decisão acompanhada da justificativa, e o analista toma a decisão final.

Avalie o seguinte: Entregue 25 análises recentes ao seu investigador mais experiente. Quantas decisões ele mudaria?

Mito 3: "Nossos analistas são o gargalo."

Comentário do chat: Um participante resumiu de forma direta. Quando um analista precisa checar 15 itens em sistemas desorganizados, a lentidão acaba sendo atribuída à pessoa, e não ao sistema. A maioria das equipes, completou ele, não percebe o quão complicados os seus próprios processos podem se tornar.

Saurabh vinha destacando esse mesmo ponto durante o painel. Um procedimento padrão típico para monitoramento de transações em PLD ou triagem de sanções costuma dizer algo como "verifique estes 15 itens". Fazer isso exige navegar por diferentes sistemas e descobrir se é sequer possível extrair esses dados. Esse é um desafio de orquestração de dados, e as bases de dados bancárias costumam ser complexas. Um agente colocado sobre essa estrutura herda toda a desorganização.

Jason descreveu o que muda quando essa camada funciona bem. Ele chama isso de inverter a proporção. Os analistas costumavam passar cerca de 80% do tempo reunindo informações para revisar um alerta e apenas 20% investigando de fato. Com os agentes assumindo a coleta de dados, essa dinâmica se inverte, permitindo que o tempo do analista seja focado em decidir se a atividade faz sentido para aquele cliente.

Ele também listou o que os projetos com dificuldades costumam ter em comum:

• Dados de clientes incompletos

• Critérios de investigação pouco claros

• Relatórios e justificativas que os analistas não conseguem rastrear até os registros de origem

Nenhum desses pontos é culpa do analista. O mesmo vale para outra questão levantada no chat: diversos fornecedores estão adicionando agentes de IA, mas os agentes não compartilham contexto. Fraude, cadastro, PLD e atendimento ao cliente se influenciam mutuamente; por isso, agentes isolados deixam cada equipe com uma visão incompleta.

"Contratar mais 100 pessoas não vai resolver o problema. É preciso descobrir como as 100 pessoas atuais conseguem fazer o trabalho de mil. Como podemos dar a elas a armadura do Homem de Ferro?" Saurabh Bajaj, Oscilar

Avalie o seguinte: Acompanhe 10 alertas do início ao fim. Quanto do tempo do analista foi gasto buscando informações e quanto foi dedicado a tomar a decisão?

Mito 4: "Vamos desenvolver por conta própria."

Phil perguntou a Jonathan se o tema "desenvolver vs. comprar" era o título certo para o painel. A resposta de Jonathan: a primeira decisão é como, onde e quando usar agentes. A decisão de “desenvolver vs. comprar” vem depois disso e depende de dois fatores: a cultura interna da organização e a quantidade de engenheiros disponíveis.

Se você ainda está buscando adesão interna, afirmou ele, desenvolver do zero é arriscado. Gerar expectativa na empresa sobre agentes e depois entregar algo feito às pressas ou com erros "pode gerar um retrocesso enorme para a equipe". Já para quem tem um time de engenharia robusto e a cultura adequada, criar algumas soluções internamente pode fazer sentido.

Saurabh sugeriu uma maneira simples de organizar essa escolha, dividindo o problema em dois eixos: a velocidade com que ele muda e de quantas fontes de dados ele se alimenta. Ferramentas pequenas, autossuficientes e com poucas alterações são ótimas candidatas para desenvolvimento interno. Qualquer coisa que mude rápido ou dependa de múltiplos sinais deve ser feita com um parceiro.

Apenas um quadrante pede desenvolvimento interno. Tudo o que muda rápido ou utiliza muitas fontes de dados deve ser direcionado a um parceiro.

O custo também foi tema da sessão de perguntas e respostas. Um participante perguntou sobre os principais riscos de desenvolver internamente, desde a segurança dos dados até a consistência dos resultados. Jonathan destacou que um fornecedor especializado absorve grande parte desse risco, já que esse é o negócio principal dele, e não um projeto paralelo. Desenvolver internamente sai mais barato? "Se for feito com perfeição, com certeza. Se der errado, com certeza não. Acaba custando muito mais caro."

Jason completou lembrando que muitos bancos comunitários e de menor porte não têm essa experiência internamente, o que torna a escolha do parceiro certo ainda mais importante.

Ainda na dúvida sobre como implementar seu próximo agente? Nosso diagnóstico de 2 minutos sobre desenvolver vs. comprar avalia a prontidão da sua equipe com base nas questões levantadas no painel.

Mito 5: "Assim que estiver no ar, terminamos."

Jason acompanhou iniciativas que deram certo e outras que estagnaram, notando um padrão claro. As equipes bem-sucedidas conhecem seus próprios processos em detalhes: o que caracteriza um alerta rotineiro versus uma escalada, quais dados são confiáveis e quem tem autoridade para decidir. Elas também contam com capacidade para manter integrações, testar mudanças e acompanhar o desempenho após o lançamento.

Já as equipes que estagnam encaram o primeiro agente funcional como a linha de chegada. Quando uma regra de PLD muda, uma lista de sanções é atualizada ou um novo método de pagamento traz novos comportamentos, o agente fica para trás. "Você nunca deve tratar isso como a etapa final", alertou Jason.

Saurabh explicou por que acompanhar esse ritmo é mais difícil do que parece. Procedimentos operacionais padrão em PLD e prevenção a fraudes mudam com frequência. Se cada mudança depender de abrir chamados para a engenharia ou para o fornecedor, a equipe volta a depender de terceiros para qualquer atualização. Além disso, as saídas do agente precisam de regras bem definidas sobre o que fazer a seguir, como buscar mais dados ou encaminhar o caso. Ele não pode improvisar em um processo de conformidade.

"Os programas que vejo estagnarem são aqueles que tratam o primeiro agente em produção quase como a linha de chegada." Jason Chorlins, Kaufman Rossin

Mais dois pontos mudam depois que o agente entra no ar. Você precisa ter a certeza de que ele continua tomando as decisões certas em centenas de alertas, e não apenas um por um. E, quando um auditor questionar como uma decisão foi tomada, você precisa ser capaz de reproduzi-la com todas as evidências correspondentes. Saurabh destacou que fazer esse levantamento manualmente pode levar de um a dois meses para uma equipe.

Avalie o seguinte: Pense na última alteração de procedimento realizada. Quanto tempo levou para ela ser incorporada ao agente e quem fez essa alteração?

Como saber se um agente de IA para conformidade está realmente funcionando?

Faça as cinco perguntas abaixo. Se as suas respostas mais sinceras estiverem na coluna do meio, seu piloto ainda está restrito ao padrão de demonstração.

Levando seu piloto de IA de agentes além da demonstração

Nenhum dos participantes defendeu desacelerar, mas sim avançar com agilidade e consciência. Em resumo: escolha um processo de alto volume que você conheça a fundo. Meça os mesmos indicadores que o seu CCO acompanha. Peça a alguém de confiança para validar o trabalho do agente. Assim, você saberá com clareza se tem em mãos um piloto funcional ou apenas uma demonstração.

Quer conferir a conversa completa? Assista à gravação sob demanda.

Perguntas Frequentes (FAQs)

Como saber se um agente de IA para conformidade está funcionando?

Avalie se ele transforma o trabalho diário, e não apenas se os relatórios parecem bem escritos. Um agente eficaz integra a rotina da equipe, impacta métricas mensuráveis como tempo de análise e precisão de decisões, e comprova sua consistência quando um investigador experiente reproduz uma amostra de suas decisões.

Equipes de conformidade devem desenvolver ou comprar agentes de IA?

Isso depende da sua cultura, da capacidade da equipe de engenharia e da natureza do problema. Ferramentas pontuais, autossuficientes e que mudam pouco — como assistentes de políticas ou geradores de resumos — podem ser desenvolvidas internamente. Já demandas dinâmicas ou que dependem de múltiplas fontes de dados costumam se beneficiar de um parceiro especializado. Muitas equipes começam contratando uma solução e partem para o desenvolvimento próprio no futuro.

Quais métricas devem ser usadas para avaliar um agente de IA em conformidade?

Comece pelas métricas que um diretor de conformidade acompanha: tempo de resolução de alertas, precisão das decisões, velocidade de adaptação a novas regras ou tipologias e o ganho real de produtividade da equipe. Combine isso a auditorias por amostragem, nas quais um investigador sênior revisa e valida as decisões tomadas pelo agente.

Por que projetos-piloto de agentes de IA costumam estagnar?

Geralmente por fragilidades na base que sustenta o agente. Pilotos com dificuldades costumam sofrer com dados incompletos de clientes, regras de investigação pouco claras e justificativas que não se conectam aos registros originais. Outro motivo comum é tratar a primeira versão funcional como o fim do projeto, fazendo com que o agente fique desatualizado conforme regras e produtos evoluem.

Agentes de IA podem encerrar alertas de conformidade por conta própria?

Pouquíssimas equipes autorizam isso hoje, mesmo para sanções óbvias ou falsos positivos evidentes. O modelo mais comum envolve o agente reunir as evidências, sugerir uma resolução fundamentada e classificar os alertas por grau de certeza, deixando a decisão final a cargo do analista. A equipe de conformidade continua sendo a responsável final pela investigação e pela decisão de reportar atividades suspeitas.