A cada poucos anos, surge uma nova tecnologia de prevenção a fraudes que promete facilitar o trabalho. Primeiro vieram as regras, depois a análise em lote e, em seguida, o aprendizado de máquina — cada uma dessas tecnologias torna as plataformas antifraude mais poderosas. Mas cada uma delas também exige mais das pessoas que as operam.
Inevitavelmente, o resultado é um fosso cada vez maior entre as pessoas que desenvolvem plataformas de prevenção de fraudes e as equipas antifraude que as utilizam. Agora que a IA desencadeou uma nova vaga tecnológica no setor, impõe-se a pergunta: irá este fosso aumentar ainda mais?
Principais conclusões: por que a plataforma está ganhando, mas sua equipe não
- Cada grande onda tecnológica nas plataformas antifraude, desde regras até aprendizado de máquina, ampliou a distância entre as equipes que desenvolvem essas plataformas e as que as utilizam, pois os fornecedores restringem o acesso aos seus dados e ao conhecimento sobre a plataforma.
- A lacuna entre quem desenvolve plataformas antifraude e quem as utiliza tem duas causas principais. A primeira é a falta de acesso direto à plataforma antifraude, incluindo acesso a SQL e ao data warehouse. A segunda é a falta de conhecimento sobre a plataforma do fornecedor de soluções antifraude, abrangendo esquemas de dados, definições de atributos e o funcionamento dos modelos.
- Agentes de IA que atuam como middleware de IA antifraude revertem essa tendência ao traduzir solicitações simples dos analistas para as definições exatas da plataforma, realizar verificações de sensibilidade da pontuação de fraude e criar regras diretamente a partir dos padrões observados, sem o envolvimento do fornecedor.
- O teste prático para qualquer avaliação de compra de uma plataforma antifraude é perguntar ao fornecedor quanto da plataforma sua equipe conseguiria operar sem a ajuda dos funcionários dele. A resposta revela se você está diante de uma ferramenta ou de uma dependência.
A lacuna entre quem desenvolve e quem utiliza plataformas antifraude
Toda plataforma antifraude envolve dois grupos de pessoas. Os desenvolvedores projetam os dados, as funcionalidades, o mecanismo de regras e os modelos. Os profissionais são os analistas e gestores de fraude que usam a plataforma diariamente para monitorar, investigar e implementar decisões.
Quando os desenvolvedores e os profissionais trabalham na mesma empresa, um analista que não entende como a plataforma calcula um dado pode perguntar ao engenheiro que a criou e, geralmente, receber uma resposta no mesmo dia.
Mas, quando a plataforma é fornecida por um fornecedor, o analista é um cliente pagante. Ele não pode se sentar ao lado da equipe de engenharia do fornecedor, e o fornecedor tem bons motivos para manter em sigilo alguns detalhes sobre seus dados e modelos. Esse é o seu segredo do negócio.
Assim, em muitos casos, as empresas pagam pela plataforma inteira, mas acabam usando apenas as partes que sua equipe realmente entende. E, ao observar como o setor de prevenção a fraudes evoluiu, é possível perceber que isso só piorou com o tempo.
As primeiras ferramentas antifraude eram ecrãs de análise. Mostravam ao investigador quem estava por detrás de uma transação ou de um pedido de adesão e o que essa pessoa estava a tentar fazer, e registavam a decisão de aprovar ou recusar. O software apresentava informações, e o investigador recorria ao seu próprio discernimento para cruzar os dados e analisá-los antes de decidir o que fazer com o evento.
Mais tarde, as equipas de combate à fraude transformaram esse discernimento em regras, que um motor de regras aplica a cada evento em tempo real. Para impedir um padrão através de uma regra, um analista passou a ter de saber como esse padrão se manifesta nos dados da plataforma. Isso implica saber que variáveis existem (uma variável é um dado individual calculado pela plataforma, como o número de contas associadas a um dispositivo), o que significa cada uma delas e como combiná-las.
Com análises avançadas, os analistas podiam agendar tarefas executadas em lote no final do dia ou da semana. Entre elas estavam a deteção de anomalias, o agrupamento de contas em redes e a elaboração de relatórios sobre padrões demasiado complexos para serem calculados enquanto uma transação aguarda uma decisão. Quem quisesse executar estas tarefas internamente enfrentava um nível de exigência ainda maior. Era necessário compreender o esquema de dados (a forma como a plataforma organiza e armazena os seus dados). Também era preciso escrever as tarefas em SQL, a linguagem padrão para consultar bases de dados, ou em código executado de acordo com um agendamento.
Em seguida, os fornecedores adicionaram modelos de aprendizagem automática que atribuem uma pontuação de risco a cada evento. Perceber por que motivo um determinado evento recebeu uma pontuação elevada é a parte mais fácil, mas decidir o que fazer com essa pontuação é mais difícil. É necessário definir um limiar, ou seja, a pontuação acima da qual a plataforma recusa ou analisa um evento. Como um único limiar raramente se adequa a todos os produtos, regiões e tipos de utilizador, a maioria das equipas precisa de vários.
Definir limites por segmento exige acesso aos dados e as competências necessárias para os consultar. Também é preciso saber em que variáveis o modelo se baseia e realizar análises de sensibilidade, que avaliam quantos utilizadores legítimos são recusados e quanta fraude é detetada à medida que o limite é ajustado. Para isso, são necessários conhecimentos especializados do setor, competências técnicas e acesso aos dados.
Mas uma análise realista do setor levaria à conclusão de que a maioria das equipes de combate a fraudes não dispõe desses recursos, a menos que tenha desenvolvido sua própria plataforma.
Geração | O que a ferramenta faz | O que isso exige da equipe antifraude |
Telas de revisão | Mostre ao investigador quem está por trás de uma transação ou solicitação e o que essa pessoa está tentando fazer; em seguida, registre a decisão de aprovar ou recusar. | Julgamento. O investigador cruza os dados e analisa manualmente cada evento |
Regras | Aplique as decisões da equipe como regras a cada evento em tempo real | Saber quais funcionalidades existem, o que cada uma significa e como combiná-las |
Análises avançadas | Execute tarefas em lote agendadas para deteção de anomalias, agrupamento de contas e relatórios demasiado pesados para processamento em tempo real | Compreender o esquema de dados e escrever as tarefas em SQL ou em código agendado |
Aprendizado de máquina | Atribua uma pontuação de risco a cada evento | Escolher limites por segmento, o que exige acesso aos dados, habilidades de consulta, conhecimento dos recursos usados pelo modelo e verificações de sensibilidade |
O conhecimento essencial sobre a plataforma fica restrito ao fornecedor
Quando pensamos no que falta às equipes de combate a fraudes, geralmente nos concentramos em competências técnicas, como SQL e programação. Mas uma empresa pode capacitar sua equipe nessas áreas ou contratar profissionais que já tenham essas competências. Há dois outros requisitos muito mais difíceis de uma equipe de combate a fraudes atender: acesso irrestrito aos dados do fornecedor e conhecimento do funcionamento interno da plataforma.
A maior ironia no combate à fraude é que grande parte daquilo pelo qual uma empresa paga a um fornecedor de soluções antifraude consiste em dados que a sua própria equipa não consegue consultar. Isso inclui atributos calculados pelo próprio fornecedor, sinais obtidos junto de prestadores especializados, como serviços de inteligência de e-mail ou de dispositivos, e dados de consórcio agregados a partir dos seus outros clientes.
Ao mesmo tempo, as equipes de prevenção a fraudes muitas vezes não têm o conhecimento essencial para operar a própria plataforma. Conhecer a plataforma significa entender como o fornecedor organiza seus dados e cria suas variáveis, como seus modelos calculam as pontuações de risco e como suas regras são executadas. Sem esse conhecimento, até mesmo uma equipe com acesso total aos dados fica de mãos atadas.
Velocidade são um bom exemplo de funcionalidades. Elas contabilizam a frequência com que algo acontece dentro de um intervalo de tempo, como as tentativas com cartão feitas a partir de um único dispositivo na última hora. O facto de esse intervalo ser móvel (sempre os últimos 60 minutos) ou fixo (reiniciado no início de cada hora) altera a forma como deve definir uma regra. Uma sequência de 10 tentativas que abranja a mudança de hora parece corresponder a duas sequências menores numa janela fixa, pelo que uma regra concebida a pensar numa janela móvel pode não a detetar.
Ou considere um padrão que um analista identifica em novos cadastros: endereços de e-mail formados por um nome, a primeira letra de um sobrenome e dois dígitos, como johnd42 e sarahk17. O analista precisa então determinar se uma funcionalidade detecta esse padrão, se é necessária apenas uma funcionalidade ou uma combinação de várias e se essas funcionalidades precisam de uma definição específica para funcionar no mecanismo de regras. Cada resposta depende de como o fornecedor desenvolveu a plataforma.
Poder-se-ia argumentar que os bons fornecedores disponibilizam aos seus utilizadores documentação abrangente, sessões de formação e apoio em tempo real para responder a questões pontuais. E seria correto afirmá-lo. Mas a documentação e a formação simplesmente não são suficientes em sistemas tão complexos.
De fato, há anos os fornecedores tentam disponibilizar esse conhecimento aos usuários por meio de painéis, relatórios, documentação, treinamentos e equipes de sucesso do cliente. Mas cada uma dessas iniciativas esbarra no mesmo dilema: oferecer informações de menos ou em excesso.
As ferramentas que dão acesso aos dados não conseguem acompanhar a procura. A fraude varia de empresa para empresa e muda de semana para semana, pelo que as equipas de combate à fraude precisam constantemente de uma nova vista, segmento ou filtro que os painéis existentes não apresentam. Todas as empresas têm uma longa lista de perguntas que querem fazer, e nenhum fornecedor consegue criar um relatório para cada pergunta, muito menos para cada cliente.
A documentação enfrenta o problema oposto. Um fornecedor pode documentar todos os seus 2.000 pontos de dados, mas um analista que esteja a criar uma regra precisa apenas de um deles, e encontrá-lo e compreendê-lo é difícil, mesmo com boas ferramentas de pesquisa e filtragem.
Como resultado, as equipes de combate a fraudes recebem muitas instruções e treinamentos, mas têm pouquíssimo acesso direto aos dados ou ajuda para interpretá-los, justamente o que mais precisam para tomar decisões claras.
O middleware de IA agêntica inverte a tendência
Dada a distância cada vez maior entre quem desenvolve e quem usa, seria razoável esperar que a IA acrescentasse mais uma camada de complexidade, piorando ainda mais a situação. Mas, na realidade, a IA agêntica inverte essa tendência.
Os fornecedores criaram os primeiros recursos de IA em plataformas antifraude com base na própria documentação, na forma de assistentes aos quais os usuários podiam perguntar como a plataforma funcionava. Os usuários passaram a obter respostas melhores com mais rapidez, e os fornecedores perceberam que a IA poderia atuar como uma camada de “middleware” entre a plataforma e as pessoas que a utilizavam.
Mas os agentes de IA também podem dar aos utilizadores acesso a áreas que, até agora, lhes estavam completamente vedadas. Ao assumirem um papel alargado de «middleware» numa plataforma, permitem que os utilizadores comuniquem com ela e a utilizem de forma mais eficaz. Os agentes traduzem uma pergunta ou necessidade expressa em linguagem comum nas definições exatas exigidas pela plataforma e, em seguida, devolvem uma decisão, um relatório ou os dados necessários. Também conseguem tratar de pedidos pontuais e específicos de cada empresa para os quais nenhuma equipa de produto conseguiria criar um painel de controlo.
Exemplo A: criação de regras antifraude por IA com base em um padrão de cadastro
Considere a analista que identificou cadastros com endereços de e-mail como johnd42 e sarahk17. Ela encontrou algumas dessas contas e quer impedir que outras sejam criadas.
Um agente de análise de dados pega nas contas que ela sinalizou e faz duas coisas com elas. Procura mais contas que correspondam ao mesmo padrão, o que lhe dá mais dados com que trabalhar e um conjunto mais amplo de contas sobre as quais agir. Também consulta o esquema de dados para encontrar as características e os valores exatos que descrevem o padrão, para que a sua descrição informal (primeiro nome, inicial do apelido, dois algarismos) se transforme numa definição precisa no próprio «vocabulário» da plataforma.
Em seguida, um agente de criação de regras transforma essas conclusões numa regra para o motor de regras em tempo real da plataforma. Esta é uma tarefa diferente de escrever uma consulta à base de dados, porque, em tempo real, estas características teriam convenções de nomenclatura diferentes e algumas poderiam até estar totalmente ausentes. O agente também pode ajudar a ajustar a regra para detetar o máximo de fraude, recusando o menor número possível de utilizadores legítimos, o que mantém os falsos positivos num nível baixo.
A IA fornece as duas coisas que o analista não consegue obter por conta própria: acesso aos dados do fornecedor e conhecimento de como a plataforma os representa.
Na Sardine, o Agente Assistente de Regras e o Agente Analista de Dados realizam esse trabalho dentro da plataforma. Veja como nossos agentes de IA ajudam as equipes de combate a fraudes.
Exemplo B: Definição do limiar da pontuação de fraude por segmento
A mesma abordagem funciona para utilizar o aprendizado de máquina de forma mais eficaz. Digamos que um gestor de fraudes queira saber como definir os limites de recusa para o seu modelo. Ele pode pedir a um agente de análise de dados que divida a base de usuários em seus principais segmentos, como fluxo do produto (cadastro, finalização da compra, saque), região, forma de pagamento e tipo de conta.
Para cada segmento, o agente realiza uma análise de sensibilidade e identifica o limiar que melhor atende ao objetivo escolhido pelo gestor. Esse objetivo pode ser uma determinada taxa de recusa, um nível de precisão ou um nível de revocação. Também é possível solicitar a mesma análise para três níveis de apetite ao risco, do conservador ao agressivo, e receber uma tabela com os limiares recomendados para compará-los lado a lado.
Antes, essa análise exigia conhecimento do esquema de dados, experiência na realização de análises de sensibilidade e, acima de tudo, acesso ao data warehouse do fornecedor da solução antifraude — algo que a maioria das equipes simplesmente não tem. Portanto, ela ficava fora de alcance ou precisava ser solicitada ao fornecedor, geralmente mediante pagamento. Mas, com um agente, a própria equipe antifraude realiza a análise, toma a decisão e pode repeti-la todos os meses, à medida que os padrões de fraude mudam, sem precisar esperar pelo fornecedor.
Quais recursos de IA procurar
Cada onda tecnológica anterior aumentou a distância entre as plataformas de combate à fraude e as equipes que as utilizam. Agora, os agentes estão começando a reduzir essa distância, e seu maior impacto até o momento é ajudar as empresas a aproveitar muito mais as plataformas pelas quais já pagam.
Isso também muda o que os desenvolvedores podem oferecer, pois eles podem adicionar mecanismos de detecção mais sofisticados sem exigir mais das pessoas que os operam.
Os riscos são reais. O estudo da Trustpair sobre as tendências de fraude para 2026 revelou que 58% dos decisores financeiros seniores acreditam que os autores de fraudes evoluem agora mais depressa do que os seres humanos conseguem reagir.
Para quem está a escolher uma plataforma de combate à fraude, confirmar que dispõe de IA é o ponto de partida óbvio, mas também é demasiado genérico. A questão seguinte é saber se essas capacidades ajudam a sua equipa a tirar maior partido da plataforma ou se esta continua a ser uma caixa negra: quando a sua equipa não consegue aceder aos respetivos dados, não consegue perceber como funciona nem transformar essas informações em decisões claras.
Segundo essa definição, muitas plataformas antifraude com modelos bem explicados ainda são caixas-pretas.
Uma das principais características a procurar é uma IA que dê à sua equipe acesso aos dados e ao funcionamento interno da plataforma. Uma forma simples de avaliar isso em uma reunião com um fornecedor é perguntar quanto da plataforma sua equipe conseguiria operar sem a ajuda dos funcionários do fornecedor.
A resposta dirá se você está comprando a plataforma inteira ou apenas os 10% que sua equipe consegue acessar.
Saiba mais sobre Como implementar agentes de IA confiáveis para combater crimes financeiros e dar à sua equipe antifraude independência de plataforma.
Perguntas frequentes
O que é o problema da caixa-preta nas plataformas antifraude?
Uma plataforma antifraude é uma caixa-preta quando a equipe que paga por ela não consegue acessar seus dados, entender como seus modelos atribuem pontuações aos eventos nem transformar esse entendimento em regras ou decisões funcionais sem a ajuda do fornecedor. O problema se agrava com o tempo, pois cada nova camada tecnológica — de regras e análises em lote a aprendizado de máquina — exige mais conhecimento técnico e mais domínio específico da plataforma para ser operada com eficácia.
O que é middleware de IA antifraude e como ele ajuda?
O middleware de IA para fraude é uma camada de agentes de IA que funciona como intermediária entre uma equipa de combate à fraude e a plataforma do fornecedor, convertendo pedidos em linguagem natural nas definições internas da plataforma, consultando diretamente os dados do fornecedor e fornecendo regras funcionais, relatórios ou recomendações de limiares. Permite às equipas de combate à fraude aceder às partes da plataforma que anteriormente só estavam ao alcance dos próprios colaboradores do fornecedor.
Como funciona, na prática, a criação de regras antifraude por IA com base em padrões?
Um analista de fraude identifica um padrão suspeito, como endereços de e-mail criados a partir de uma fórmula previsível, e o descreve em linguagem simples a um agente de análise de dados. O agente pesquisa os dados da plataforma em busca de outras contas que correspondam ao padrão, identifica as características e os valores exatos que o definem no esquema da plataforma e encaminha essas conclusões a um agente de criação de regras, que produz uma regra funcional para o mecanismo de regras em tempo real, incluindo o ajuste de falsos positivos da regra de fraude para minimizar o impacto sobre usuários legítimos.
O que é a configuração do limite da pontuação de fraude e por que ela requer acesso aos dados?
Definir um limiar de pontuação de fraude significa escolher a pontuação acima da qual a plataforma recusa ou analisa um evento. Como um único limiar raramente é adequado a todos os produtos, regiões e tipos de utilizador, a maioria das equipas precisa de vários, cada um exigindo uma análise de sensibilidade da pontuação de fraude que mostre quantos utilizadores legítimos são recusados e quanta fraude é detetada à medida que o limiar é ajustado. Esta análise requer acesso ao armazém de dados do fornecedor e conhecimento do esquema de dados da plataforma — precisamente aquilo a que a maioria das equipas de combate à fraude não tem acesso sem o envolvimento do fornecedor.
Como posso avaliar se uma plataforma antifraude dará verdadeira autonomia à minha equipe?
Pergunte diretamente ao fornecedor quanto da plataforma a sua equipa conseguiria operar sem a intervenção dos funcionários dele. Uma plataforma que depende do fornecedor para consultas de dados, ajuste de regras, definição de limites e interpretação de funcionalidades representa um risco de dependência do fornecedor, não uma ferramenta. Já uma plataforma em que agentes de IA dão à sua equipa acesso direto à plataforma antifraude, acesso a SQL e conhecimento ao nível do esquema é uma plataforma que a sua equipa consegue realmente operar à velocidade exigida pelo combate à fraude.
Entre em contato com a equipe da Sardine para descobrir quanto da sua configuração atual poderia funcionar sem a presença do fornecedor.
