Agentes Pontuais vs. Agentes de Risco Orquestrados

Última atualização: Setembro de 2026

Os agentes estão chegando às funções de risco um de cada vez. Um agente de triagem neste trimestre, um agente de triagem de alertas no próximo, cada um com seu próprio caso de negócios e seu próprio piloto. Agentes de risco orquestrados são a outra forma de comprar, e a diferença entre os dois não tem quase nada a ver com o número de agentes em execução.

O que os separa é o que os agentes compartilham. Um registro de cliente unificado, um log de decisões, um padrão para julgar se o agente está funcionando e uma pessoa responsável pelo resultado combinado. Ao comprar agentes de forma isolada, reconstrói-se, dentro da camada de agentes, a fragmentação pela qual você já está pagando na camada de fornecedores.

Resumo rápido

• Um conjunto de agentes focados em tarefas específicas é apenas isso. Ele só se torna uma capacidade real quando os agentes compartilham o registro do cliente, o log de decisões, o padrão de avaliação e um responsável direto.

• Nenhum desses quatro fatores é um problema de IA. São os mesmos desafios que a instituição já possui, que surgem novamente em uma nova camada.

• O custo é invisível no primeiro agente e se manifesta no segundo, razão pela qual um piloto bem-sucedido diz muito pouco sobre como será operar com três agentes.

• Não há regras de supervisão pré-definidas para isso. As diretrizes revisadas de risco de modelos publicadas em abril de 2026 colocam a IA agêntica explicitamente fora de seu escopo, portanto, o padrão deve ser elaborado internamente e defendido.

• O argumento mais forte contra a consolidação vem de profissionais experientes na área, e refere-se à dependência de fornecedores (vendor lock-in) em vez de limitações tecnológicas. É um ponto que merece uma resposta clara, e não apenas uma contestação rápida.

• Um único agente em uma única fila não precisa de nada disso. Parar por aí é uma opção válida e, muitas vezes, a melhor primeira implementação.

Agentes de risco orquestrados: a resposta rápida

Agentes de risco orquestrados são múltiplos agentes de IA atuando sobre um registro de cliente unificado, um único log de decisões e um mesmo padrão de avaliação, com um profissional responsável pela recomendação combinada. Agentes pontuais executam uma tarefa específica com os dados que recebem e enviam o resultado a uma pessoa ou fila. A diferença é muito mais operacional do que técnica: a orquestração é o que permite que um agente de fraudes, um de prevenção à lavagem de dinheiro (AML) e um de crédito gerem uma visão consolidada do cliente em vez de três relatórios isolados.

Por que precisamos da ferramenta número 21?

Uma líder de operações na área de crédito e cobrança de uma empresa de serviços financeiros digitais explicou como sua equipe está avaliando a decisão entre desenvolver internamente ou contratar um terceiro. Eles definiram os requisitos necessários para adaptar suas ferramentas internas, prepararam um comparativo em relação às soluções prontas do mercado e calcularam os custos de ambos os lados. A percepção dela sobre essa etapa foi: "Não acho que esse argumento será muito difícil de conduzir."

Em seguida, ela apontou o questionamento mais difícil que espera enfrentar: "O desafio maior é justificar algo como: 'Tudo bem, já temos 20 ferramentas diferentes. Por que precisamos da número 21?'"

Essa objeção serve tanto para agentes quanto para fornecedores, e os agentes estão chegando um a um. Portanto, a pergunta ideal para um líder de risco que avalia um terceiro agente não é quantos agentes colocar em operação, mas sim o que eles precisam compartilhar antes que rodar múltiplos agentes seja melhor do que rodar apenas um.

O que é um agente pontual e o que é uma camada de agentes orquestrados

Um agente pontual realiza uma única tarefa com base nos dados fornecidos e entrega o resultado a uma pessoa ou fila. Ele possui um escopo definido, uma fila e uma métrica de desempenho de sua tarefa. Não há nada de errado nisso. Inclusive, a maioria das primeiras implementações deve seguir exatamente este formato.

Já uma camada orquestrada não é apenas um conjunto maior de agentes pontuais. Trata-se de vários agentes operando a partir do mesmo registro de cliente, do mesmo log e sob o mesmo padrão de avaliação. A Oscilar descreve sua abordagem pública como agentes que mantêm o contexto entre alertas, conectando dados de fraude, crédito e conformidade, em vez de analisar cada alerta do zero.

A tabela acima resume todo o argumento: cada linha representa um aspecto que pode ser desconsiderado enquanto houver apenas um agente, mas que se torna indispensável a partir do momento em que existem dois.

Uma questão que esta análise deixa de fora intencionalmente são os padrões de orquestração, frameworks e topologias. A execução sequencial ou simultânea, o design do fluxo de transição e qual framework adotar são escolhas que cabem ao time que desenvolve o sistema de agentes. Não são decisões que a equipe de risco precisa tomar ao adquirir um.

As quatro coisas que os agentes precisam compartilhar

Um registro de cliente unificado. Dois agentes devem analisar o mesmo cliente, com o mesmo histórico integrado, no mesmo instante.

Um único log de decisões. A sequência de recomendações dos agentes e as confirmações humanas de um cliente devem contar uma história contínua e ordenada, mesmo meses depois.

Um padrão de avaliação único. A definição de "agente funcionando" deve ser a mesma para fraudes e AML, caso contrário, não será possível compará-los ou decidir qual expandir.

Um ponto de decisão humana claro. A responsabilidade pela recomendação final combinada deve ser atribuída a alguém específico, e essa função precisa ser definida antes do segundo agente entrar em operação.

Nenhum desses pontos é um problema técnico de IA. Todos eles são desafios operacionais que a empresa já enfrenta com fornecedores, dados e comitês, e que ressurgem sob uma nova roupagem.

Registro compartilhado: o agente não pode decidir sobre um cliente que enxerga apenas em parte

Se dois agentes consultarem dados parciais diferentes, eles vão divergir, e nenhum deles estará incorreto do seu ponto de vista. Um agente de fraudes que analisa o histórico do dispositivo e das transações e um agente de conformidade que avalia os dados de cadastro podem chegar a conclusões opostas sobre a mesma conta — e ambos estarem certos com base em suas respectivas informações. Essa divergência gera uma necessidade de mediação que ninguém consegue resolver facilmente.

O registro tem um dono e, em empresas maiores, não é a plataforma de agentes. Um diretor de P&D de uma plataforma global de pagamentos detalhou esse desafio na prática: "Nossas listas não são usadas apenas no fluxo [da plataforma de risco]. Elas são distribuídas para diferentes equipes em certos casos. Por isso, a [plataforma de risco] não pode ser a base única oficial de dados das listas. Ela precisa ser uma cópia sincronizada da nossa base de dados oficial."

Essa é a realidade de um registro compartilhado em grandes organizações. Trata-se de uma cópia sincronizada, o que transforma o fluxo de atualização de dados, o controle de informações obsoletas e a reconciliação em um trabalho real de arquitetura, e não em uma simples configuração de sistema. Estruturar esse registro é um projeto à parte, com seus próprios riscos de falha, e merece atenção dedicada.

Log compartilhado: como reconstruir uma decisão que passou por três agentes

O histórico de auditoria individual de cada agente explica o que ele fez, mas não o que a instituição decidiu no final. Quando um agente de triagem aponta um problema, o agente de análise recomenda uma ação e o analista confirma, o registro necessário para auditorias ou reguladores deve ser a sequência completa do processo, e não arquivos avulsos que tratam do mesmo cliente.

A posição pública da Oscilar sobre isso é precisa: a plataforma registra o raciocínio por trás de cada recomendação, facilitando a demonstração aos órgãos reguladores de onde as decisões humanas foram tomadas. Isso é tão importante para o registro das ações humanas quanto para o dos agentes, e é o ponto que realmente importa quando várias etapas geram um único resultado. O que esse histórico precisa manter, quem pode alterá-lo e seu tempo de retenção são questões de conformidade detalhadas no artigo sobre governança de agentes de risco.

Os agentes nunca encerram ou escalam alertas de forma totalmente autônoma; cada recomendação é revisada e confirmada por um analista humano antes de qualquer ação. Com múltiplos agentes, isso gera várias validações por profissionais potencialmente diferentes, e essas confirmações precisam ser registradas de forma linear para permitir a reconstituição exata do processo.

Padrão único: três componentes sob a ótica do mesmo regulamento

Em 17 de abril de 2026, o Federal Reserve, o FDIC e o OCC emitiram novas diretrizes conjuntas sobre gestão de risco de modelos (SR 26-2 no Fed, Bulletin 2026-13 no OCC e FIL-15-2026 no FDIC). Esse documento substitui as orientações anteriores de 2011 e o comunicado de 2021 sobre risco de modelos em sistemas de Prevenção à Lavagem de Dinheiro (BSA/AML). Documentos internos e materiais que ainda mencionam as regras anteriores estão desatualizados.

A nova diretriz também restringe a definição do que é considerado um modelo. Ela o descreve como "um método, sistema ou abordagem quantitativa complexa que aplica teorias estatísticas, econômicas ou financeiras para processar dados de entrada em estimativas quantitativas". Avaliar se uma ferramenta de regras se enquadra nessa definição é uma análise técnica para sua própria equipe de risco de modelos.

No que tange aos agentes, o texto é direto: "Modelos de IA generativa e IA agêntica são novos e evoluem rapidamente. Portanto, não estão no escopo destas diretrizes". Os órgãos reguladores planejam solicitar informações sobre o uso de IA pelos bancos, incluindo a IA agêntica, mas, até setembro de 2026, essa consulta ainda não havia sido publicada.

Assim, uma operação de risco que utiliza regras fixas, modelos de score e agentes de IA lida com três componentes em posições regulatórias diferentes. Ninguém fornecerá um padrão pronto para a IA agêntica. A instituição precisa estruturá-lo, aplicá-lo uniformemente e defendê-lo. Esse é o desafio por trás da avaliação de um agente de risco antes da produção e do monitoramento de eventuais desvios de desempenho pós-implementação. O padrão precisa ser o mesmo em ambos os momentos para garantir a consistência das comparações.

As diretrizes preservam o princípio do "desafio eficaz" (effective challenge), cuja definição é um ótimo teste para qualquer padrão estabelecido. Ele deve ser conduzido por pessoas com "a competência necessária para realizar avaliações críticas e objetivas, independência suficiente para manter a imparcialidade, além de relevância organizacional e influência para implementar mudanças". Quem audita as decisões dos agentes precisa preencher esses três requisitos. Um revisor sem autonomia para alterar o resultado final não cumpre o terceiro ponto.

Um detalhe importante: a circular do Federal Reserve indica que as regras são "mais relevantes para organizações bancárias com ativos totais acima de US$ 30 bilhões". "Mais relevante para" não significa aplicável exclusivamente a essas instituições, e empresas menores não devem ver esse limite como uma isenção automática.

Responsabilidade compartilhada: quem responde quando a recomendação vem de múltiplas fontes

Validar a recomendação de um único agente é algo que o analista já faz rotineiramente. Validar uma cadeia de recomendações automatizadas é um processo diferente, e poucas empresas já designaram um responsável para isso. O resultado do primeiro agente alimenta a decisão do segundo, o analista confirma a última etapa, mas a responsabilidade pelo processo integrado muitas vezes fica dispersa.

Existe uma forma clara de medir o valor do trabalho humano. Um banco em fase de implantação registrou 92% de concordância dos agentes com a equipe de analistas na resolução de alertas e uma redução de 75% no tempo de análise. Embora seja o resultado de um caso real e não um padrão garantido para todos, mostra os dois principais indicadores a serem acompanhados: a frequência de concordância entre o agente e o analista e o custo operacional dessa revisão.

A pergunta essencial a ser respondida antes de ativar um segundo agente é direta: Quem é o responsável pela recomendação final e o que essa pessoa pode alterar caso discorde dela?

Agente único ou múltiplos: como saber o que sua operação realmente precisa

Um único agente rodando em uma fila isolada não precisa desses quatro pilares. Ele lê as informações fornecidas, executa sua tarefa e envia o resultado a uma pessoa. Esta é uma opção viável para começar e o caminho recomendado para a maioria dos primeiros projetos.

A necessidade de compartilhar esses quatro pontos surge com o segundo agente, razão pela qual o custo operacional costuma passar despercebido durante a fase piloto. Um piloto tem apenas um banco de dados, um destino final de saída, uma métrica de sucesso e um responsável evidente — tudo implícito. O segundo agente transforma cada um desses tópicos em uma dúvida, e resolver quatro dilemas estruturais sob a urgência de uma entrega de projeto é muito mais difícil do que planejá-los com antecedência.

Um teste prático antes de contratar o segundo agente: aponte o registro de dados lido por ambos, indique o log que armazena os dois resultados, defina o padrão que avalia os dois e determine o profissional que valida o resultado final integrado. Se algum desses pontos estiver ausente, você estará operando dois agentes de forma isolada e deve planejar seus recursos de acordo.

O diretor de gestão de fraudes de uma empresa global de pagamentos e cartões pré-pagos destacou seu requisito inegociável: "Um dos meus critérios essenciais para qualquer solução de orquestração ou de decisão é a capacidade de receber qualquer dado que eu envie, padronizá-lo e utilizá-lo de forma fluida nas operações." Ele não pedia mais agentes, modelos complexos ou maior precisão; pedia apenas consistência no tratamento dos dados, pois sua empresa cresce via aquisições e precisa integrar sistemas legados constantemente.

O argumento contra a consolidação, por quem viveu a experiência

O mesmo diretor optou por desenvolver seu próprio sistema de orquestração em vez de contratar uma solução pronta, e seus argumentos contra a consolidação são muito consistentes: "Eu avalio o risco além da prevenção à fraude. Também preciso considerar o risco de fornecedores e a exposição ao mercado... Para nós, era vital manter a autonomia sobre as integrações e garantir que nenhum fornecedor fosse implementado de forma a tornar sua substituição inviável."

Ele chamou o cenário oposto de "um casamento indesejado com um parceiro externo". Ao ser questionado sobre a adoção de uma plataforma unificada desse tipo, foi claro: "Sob a ótica de negócios, é uma movimentação de alto risco."

Essa é uma postura técnica legítima de um profissional de gestão de riscos. Centralizar todos os fluxos em um único fornecedor reduz a flexibilidade para substituí-lo futuramente. Ignorar essa realidade não é o caminho.

Existem duas abordagens para essa questão. A primeira é o teste de saída que você mesmo deve aplicar: se esse fornecedor precisasse ser substituído em dezoito meses, o que seria necessário reconstruir? Você possui o controle das integrações e dos dados necessários para isso? Faça essa pergunta antes da contratação, e não depois.

A segunda abordagem é o escopo de atuação. Os agentes podem rodar como uma camada isolada sobre a infraestrutura existente ou integrados a uma plataforma unificada — e a primeira opção mantém os fluxos de integração exatamente onde já estão.

Essa escolha também traz custos, como ele próprio admitiu. O sistema central desenvolvido por sua equipe faz a distribuição de dados para fornecedores e parceiros e centraliza o retorno das decisões, existindo "um ponto de conexão central para todos os nossos processos internos ao qual, um dia, todos estarão integrados". Atualmente, cerca de trinta plataformas aguardam essa integração na fila de desenvolvimento. Criar essa estrutura internamente mantém a autonomia das conexões, mas gera uma fila de trabalho medida em plataformas a integrar, e não mais em agentes.

Onde essa abordagem pode falhar

Consolidar a camada de agentes não resolve a inconsistência na camada de dados de origem. Se três sistemas trazem informações divergentes sobre o mesmo cliente hoje, um processo de agentes orquestrados receberá esses mesmos dados e herdará a divergência. A estruturação das bases de dados é um projeto de longo prazo que continua sendo necessário.

Um padrão de avaliação único e mal estruturado é pior do que quatro padrões locais diferentes, pois agora ele será o único referencial. Um padrão que avalia os agentes apenas pela conclusão das tarefas em vez da qualidade das decisões será aplicado de forma homogênea a todos, mas estará estruturalmente incorreto.

Esta análise não defende necessariamente a compra em vez do desenvolvimento próprio. O diretor mencionado anteriormente optou por desenvolver sua própria tecnologia, e sua estrutura funciona. Essa escolha tem variáveis específicas e uma análise dedicada em outra seção.

Além disso, não existem dados públicos consolidados sobre a frequência de divergências entre agentes de risco em ambientes reais de produção. Se algum fornecedor apresentar esses números, vale questionar como foram obtidos e com base em qual perfil de clientes.

Perguntas frequentes

O que são agentes de risco orquestrados?

Agentes de risco orquestrados são múltiplos agentes de IA que atuam a partir do mesmo registro de cliente, sob um único log de decisões e o mesmo padrão de avaliação, com um profissional responsável pela recomendação final combinada. O conceito define como os agentes se integram operacionalmente, e não a quantidade deles em execução. Sem essa integração, o conjunto de ferramentas operará de forma isolada.

Qual é a diferença entre agentes de IA pontuais e uma camada de agentes orquestrados?

Um agente pontual realiza uma única tarefa a partir dos dados que recebe e repassa o resultado para uma pessoa ou uma fila de trabalho. Uma camada orquestrada conecta múltiplos agentes às mesmas bases, logs, padrões de avaliação e profissionais responsáveis. A diferença prática aparece na introdução do segundo agente, quando os sistemas precisam concordar sobre o mesmo cliente e uma pessoa precisa assumir a responsabilidade pela recomendação consolidada.

A adoção de agentes isolados de fraude, AML e crédito recria as divisões de dados que uma plataforma deveria eliminar?

Sim, e esse processo costuma ocorrer de forma silenciosa. Agentes adquiridos isoladamente trazem suas próprias fontes de dados, canais de saída e critérios de sucesso, recriando velhas divisões. Evitar isso depende de estruturar os quatro elementos compartilhados antes de colocar o segundo agente em operação, e não dos agentes em si.

Agentes de risco orquestrados podem atuar de forma integrada aos sistemas de risco já existentes na empresa?

Sim. Os agentes podem rodar como uma camada independente por cima da infraestrutura atual ou como parte integrante de uma plataforma de decisão unificada. O ponto crítico a planejar é o registro de dados do cliente: na maioria das empresas, a base de dados oficial fica em outro sistema e a camada de agentes mantém uma cópia sincronizada, o que exige que o fluxo de atualização e a consistência das informações sejam planejados como parte da arquitetura, e não como simples configurações padrão.

Como gerenciar a revisão humana, auditoria e desempenho operando múltiplos agentes de IA?

Por meio de um log de decisões unificado. Como os agentes não tomam decisões de encerramento ou escalonamento de forma totalmente autônoma, cada recomendação é acompanhada por uma validação humana. Essas confirmações precisam ser registradas de forma linear para permitir futuras auditorias de todo o processo. Com as revisões regulatórias de abril de 2026 deixando a IA agêntica fora de seu escopo inicial, o padrão de avaliação deve ser construído internamente e aplicado de forma equivalente a todos os agentes.

Como definir se o projeto precisa de um único agente ou de múltiplos?

O ponto de partida deve ser a fila de trabalho, e não a quantidade de agentes. Um único agente atuando em uma fila dedicada com um responsável definido não exige infraestrutura compartilhada e é a abordagem recomendada para os primeiros passos. A transição para múltiplos agentes deve ocorrer apenas quando houver clareza sobre o registro de dados integrado, o log unificado que receberá os retornos, as métricas de avaliação comuns e o profissional responsável pela validação final consolidada.

Quais são os custos invisíveis de manter múltiplos agentes focados em tarefas isoladas?

Os principais custos estão ligados à reconciliação de informações, retrabalho nas análises humanas e falta de clareza na governança. Agentes que consultam dados incompletos ou diferentes geram divergências que demandam esforço humano para resolução caso a caso. Além disso, cada ferramenta traz suas próprias métricas de sucesso e, sem planejamento prévio, a recomendação final acaba ficando sem um responsável direto. Esses desafios não costumam aparecer na fase de piloto com um único agente.

Por onde começar

Antes de colocar o segundo agente em operação, estruture os quatro pilares essenciais: o registro de dados, o log de decisões, o padrão de avaliação e o profissional responsável. É uma análise rápida de planejamento que evita retrabalho futuro quando o sistema já estiver rodando. Caso o primeiro agente ainda não tenha sido implementado, o passo anterior deve ser mapear os dados de que o agente precisa a partir dos seus sistemas atuais.

Se preferir testar essa estrutura na prática, implemente um único agente em uma fila real de produção durante uma semana, definindo o registro de dados, o log de saída, os padrões de desempenho e o responsável com antecedência. Uma validação de conceito de uma semana é suficiente para entender quais dessas estruturas já estão prontas para apoiar seu processo.