Última atualização: setembro de 2026
Qualquer fornecedor que venda automação para uma área de crimes financeiros dirá que há um humano no processo (human-in-the-loop). Nenhum deles está mentindo. A expressão apenas passou a ser tão exigida que já não diz a única coisa que você precisa saber, que é quem tem permissão para fazer o quê.
A resposta curta: "human-in-the-loop" não é uma chave que você ativa. É uma atribuição por decisão de direitos específicos — quem pode recomendar, quem pode aprovar, quem pode encerrar, quem pode encaminhar, quem pode reportar — e você deve saber dizer qual papel detém cada um deles, em cada tipo de decisão, antes de um analista mexer em uma fila ativa.
Resumo
"Human-in-the-loop" significa que nenhuma ação acontece sem uma pessoa. "Human-on-the-loop" significa que o sistema age e uma pessoa supervisiona, fazendo amostragens em vez de confirmar cada caso.
O rótulo que um fornecedor usa não diz quase nada. Ambos descrevem um espectro e nenhum especifica uma posição exata nele.
"Um humano" não é um papel único. Recomendar, aprovar, encerrar, encaminhar e reportar são cinco direitos distintos, e as instituições reguladas já os dividem entre pessoas diferentes.
A profundidade da revisão deve acompanhar o nível de risco da decisão, não uma configuração geral da plataforma. Uma mesma instituição desejará, por motivos óbvios, uma revisão completa em due diligence aprimorada e um fluxo mais rápido em uma faixa de rotina.
Uma confirmação só tem valor se a pessoa que confirma puder chegar a uma conclusão diferente — o que define um limite mínimo para o que deve estar na tela no momento da decisão.
Não há um manual de supervisão para isso. A diretriz de risco de modelo revisada, publicada em abril de 2026, deixa a IA agêntica explicitamente fora de seu escopo, portanto essa posição precisa ser definida internamente, documentada e defendida.
"In-the-loop" e "on-the-loop" não são alternativas. São etapas consecutivas, e a transição entre elas é conquistada por meio de evidências.
Por que "human in the loop" deixou de significar alguma coisa
Da forma como costuma ser dita, a afirmação não pode ser contestada. Um sistema onde um analista clica em "confirmar" em quatrocentas recomendações por turno tem um humano no processo. Um sistema onde dois diretores de controle precisam concordar de forma independente antes de alterar a classificação de risco de um cliente também tem. Esses não são o mesmo modelo operacional, e a expressão não os diferencia.
Quem trabalha na área já percebeu isso. Algumas das discussões mais calorosas sobre o tema acontecem em fóruns que argumentam que o "humano no processo" é uma história que contamos a nós mesmos — o que é algo incomum de se ver sob uma pergunta de definição, e um sinal claro de que as respostas publicadas não estão satisfazendo ninguém.
A pergunta por trás disso tem uma resposta. Nesta fila, neste nível de confiança: quem pode recomendar uma decisão, quem pode aprová-la, quem pode encerrar o alerta, quem pode encaminhá-lo e quem pode reportá-lo. Esses são cinco direitos diferentes, e nem sempre pertencem à mesma pessoa.
Uma observação sobre o escopo, para que ninguém leia o texto errado. Trata-se de como funciona a revisão dentro de uma única decisão. Se a prevenção a fraudes e o PLD (prevenção à lavagem de dinheiro) devem ficar na mesma plataforma, e o que cada função mantém quando isso acontece, é uma discussão separada com uma resposta separada.
O que "human-in-the-loop" e "human-on-the-loop" realmente significam
Human-in-the-loop significa que o sistema gera uma recomendação e uma pessoa age sobre ela. Nenhuma ação chega ao cliente, ao caso ou ao relatório sem a decisão de alguém. O resultado do sistema é um insumo para a decisão humana, nunca um substituto dela. O termo vem do aprendizado de máquina (machine learning), onde originalmente descrevia pessoas rotulando dados de treinamento e corrigindo os resultados do modelo; no contexto de risco, passou da rotulagem para a tomada de decisão.
Human-on-the-loop significa que o sistema age e uma pessoa supervisiona. O trabalho é concluído sem aprovações individuais, e o humano analisa amostras, monitora o comportamento geral e intervém quando algo parece errado. A supervisão é real, mas retrospectiva, e cobre um grupo de casos em vez de um caso individual.
Há uma terceira configuração que a dupla deixa de fora, e no trabalho regulado ela é a mais importante: o sistema se recusar a agir e direcionar intencionalmente para uma pessoa. Falaremos mais sobre isso abaixo, pois ela se comporta de forma diferente de qualquer um dos rótulos.
As diferenças que importam e a que não importa
Human-in-the-loop | Human-on-the-loop | |
|---|---|---|
Quem inicia a ação | A pessoa, agindo com base em uma recomendação | O sistema, dentro dos limites configurados |
O que acontece se não houver ninguém | Nada. O trabalho acumula na fila | O trabalho é concluído e acumulado para revisão |
O que o registro mostra | Uma decisão, com um tomador de decisão identificado por caso | Uma confirmação de comportamento em um grupo de casos |
Onde fica o ponto de falha | No volume. A revisão perde qualidade e vira mera aprovação automática | Na latência. Um padrão incorreto é executado antes que alguém perceba |
Custo por decisão | Atenção humana em cada caso | Atenção humana em uma amostra, mais o custo de uma detecção tardia |
Duas dessas linhas fazem o trabalho pesado. A diferença arquitetônica é se a ausência de uma pessoa impede a ação. A diferença de governança é se o registro mostra uma decisão ou uma confirmação, e é sobre isso que um auditor vai perguntar.
A diferença que não importa é o rótulo que o fornecedor usa. Ambos os termos descrevem um espectro e não uma posição fixa nele, de modo que dizer "somos human-in-the-loop" ou "somos human-on-the-loop" é igualmente compatível com quase qualquer configuração real que você possa construir.
Aqui está o ponto central. Nenhuma instituição implementa apenas um destes modelos — ela acaba tendo respostas diferentes para filas diferentes e, frequentemente, respostas diferentes para a mesma fila em diferentes níveis de confiança.
Portanto, não existe um agente "human-in-the-loop" no abstrato. A profundidade da revisão é mais bem modelada como um atributo por agente, com valores como: analista revisa o resultado, totalmente automatizado ou configurável — sendo este terceiro valor o mais realista. O que significa que o recurso útil não é um rótulo, mas sim um mapeamento.
Os cinco direitos que um humano pode ter sobre a decisão de um agente
Divida a expressão em partes e ela deixará de ser vaga. Em qualquer decisão de fraude ou PLD, existem cinco direitos distintos, e cada um pode ser atribuído a um papel diferente.
Recomendar. Propor uma decisão, com a justificativa por trás dela. Quem detém esse direito precisa de acesso ao caso e às evidências. Este é o direito que um agente pode ter, e o único que ele deve ter.
Aprovar. Aceitar a recomendação e torná-la a posição oficial da instituição. Quem aprova precisa ter informações suficientes para discordar — veja a próxima seção, pois é aqui que a maioria dos modelos de revisão falha.
Encerrar. Finalizar o caso e atualizar o registro. Encerrar não é o mesmo que aprovar: uma decisão aprovada que ninguém encerra é um caso ainda aberto, e um encerramento sem aprovação é um problema de auditoria.
Encaminhar. Direcionar o caso para cima ou para os lados — para uma due diligence aprimorada, para uma função de controle ou para um comitê. Quem faz isso precisa conhecer os gatilhos de encaminhamento e poder acionar um deles sem precisar pedir permissão.
Reportar. Enviar um relatório a uma autoridade. Este é o direito mais restrito em qualquer programa de conformidade e o menos negociável.
Essas divisões não são hipotéticas. Em uma gravação, um diretor de conformidade de crimes financeiros de um banco descreveu quem pode alterar a classificação de risco de um cliente em sua instituição: o direito é restrito a duas funções de controle, o líder de crimes financeiros e o diretor de conformidade. Os analistas não fazem a alteração — eles encaminham o caso para uma fila para que a mudança seja confirmada, e ele retorna para aprovação como uma etapa de controle de qualidade. Recomendar e aprovar são dois direitos distintos, mantidos por dois grupos diferentes de pessoas, em um processo que já existia antes de qualquer agente de IA chegar.
Essa divisão também já existia nas normas antes dos agentes de IA. Os controles baseados em funções em programas de conformidade já garantem que o analista que prepara um relatório de atividade suspeita não pode ser a mesma pessoa que o envia — o requisito padrão de segregação de funções, o mesmo conceito que os controles bancários há muito chamam de princípio de quatro olhos. Preparar e enviar sempre foram direitos diferentes de pessoas diferentes. O agente de IA simplesmente ocupa mais uma cadeira em uma cadeia que já tinha várias.
É também por isso que a nossa postura é declarada de forma clara e objetiva, e não como um slogan. Os agentes da Oscilar nunca encerram ou encaminham alertas de forma autônoma — cada recomendação é revisada e confirmada por um analista humano antes de qualquer ação ser tomada. Esse é um compromisso muito mais útil do que apenas dizer "human-in-the-loop", porque especifica quais direitos o agente não possui.
Um direito que este texto deliberadamente não define: quando a prevenção a fraudes e o PLD compartilham a mesma plataforma, qual área detém a decisão de reportar. Essa é uma questão de responsabilidade organizacional, e não de decisão individual, e merece um artigo próprio.
Quais filas recebem qual configuração e por que a profundidade acompanha o risco
Explicando como quem trabalha na área diria, a pergunta de configuração é esta: para quais tipos de alerta uma recomendação de falso-positivo de alta confiança é suficiente para uma dispensa com um clique, e para quais o agente deve sempre sinalizar para revisão, independentemente do nível de confiança?
Essa pergunta tem respostas diferentes dependendo do trabalho. Fraudes de varejo de baixo valor com uma pontuação de confiança muito alta são candidatas para uma confirmação rápida. Qualquer caso que envolva invasão de conta ou valores altos deve ter uma revisão ativa da justificativa, não importa o que indique o nível de confiança. Uma classificação de risco periódica de rotina não é a mesma decisão que uma due diligence aprimorada e não deve ter a mesma profundidade de revisão.
O princípio organizador é mais fácil de entender vindo de um profissional do que de um fornecedor. Um líder de risco em uma fintech, descrevendo seu próprio programa em uma gravação, disse que eles utilizam muito o "human-in-the-loop" em todas as classificações de risco e acham que isso é o correto para due diligence aprimorada, clientes de alto risco e setores que exigem isso — e, ao mesmo tempo, disse que gostaria de reduzir o tempo gasto na faixa de rotina. Uma instituição, duas posições, um sistema. Não há inconsistência nisso.
Portanto, a resposta não é uma configuração geral da plataforma. É o apetite ao risco e o procedimento operacional padrão definidos por fila, e você deve planejar documentar isso em vez de aceitar o padrão de um produto. Os agentes que atuam nessas filas podem ser configurados de qualquer uma das formas; os limites são seus.
O local ideal para essa documentação é na fase de prova de conceito, onde os limites são definidos em filas reais antes que qualquer coisa rode sem supervisão. Como devem ser esses limites e quais critérios de aceitação devem ser aplicados a um projeto-piloto é um trabalho à parte que vale a pena ser feito com calma.
O que um revisor precisa ver para assumir a responsabilidade pelo resultado
Uma confirmação só tem valor se a pessoa que confirma puder chegar a uma conclusão diferente. Esse é o teste definitivo, e ele estabelece o mínimo que deve estar diante dela no momento da decisão: os insumos, a justificativa, as evidências, as tipologias consideradas e o nível de confiança.
A versão dos órgãos reguladores para esse teste é mais rigorosa do que a da maioria dos fornecedores. O chamado "desafio eficaz" (effective challenge), dizem as diretrizes, é realizado por pessoas com a experiência técnica adequada para fazer uma contestação crítica e objetiva, independência suficiente para manter a imparcialidade e — a condição que as pessoas costumam esquecer — "a posição organizacional e a influência necessárias para realizar qualquer alteração". Um revisor que não pode mudar o resultado falha na terceira condição. Ele não está fazendo uma revisão de verdade.
Isso muda a perspectiva sobre para que serve uma trilha de auditoria. Sua característica mais útil não é registrar o que o agente fez, mas sim facilitar a comprovação, caso a caso, de onde os humanos tomaram as decisões. Uma trilha que registra a justificativa do agente, as evidências e as tipologias por trás de cada recomendação, junto com cada ação tomada por um agente ou analista com justificativas e marcações de data/hora, é um registro da camada humana, e não apenas da máquina.
A abrangência importa tanto quanto a profundidade. Os agentes avaliam cada item que entra em uma fila configurada, e não apenas uma amostra, de modo que nenhum caso é ignorado silenciosamente — o que é uma afirmação diferente de "revisamos muitos alertas" e muito mais fácil de comprovar.
O que essa trilha precisa guardar, quem pode configurá-la e quem aprova uma alteração no modelo por trás dela são questões de estrutura de controle, e não de revisão. Elas são detalhadas em governança de agentes de IA para equipes de risco.
Quando o agente se recusa a decidir
Às vezes, a melhor decisão é não decidir. Quando faltam dados essenciais — como data de nascimento, endereço ou nacionalidade confirmada —, o comportamento correto é sinalizar as lacunas específicas e recomendar uma revisão manual, em vez de forçar uma decisão. Descartar um caso automaticamente com base em evidências fracas é o caminho mais rápido para aumentar o risco regulatório.
O processo que se segue é simples. O agente roda primeiro e aponta o que está faltando. Uma solicitação de informações é enviada. O agente roda novamente assim que os dados retornam e, geralmente, consegue gerar uma recomendação com um nível de confiança muito maior do que na primeira vez.
Isso traz uma consequência para o que você deve esperar de um projeto-piloto. A taxa de automação reflete a qualidade dos dados tanto quanto a qualidade do modelo, de modo que um resultado abaixo do esperado pode ser apenas um problema de dados disfarçado de falha da IA. Antes de concluir que o agente teve um desempenho ruim, verifique qual proporção de casos ele recusou devido à falta de dados.
Essa é uma terceira posição no espectro, e é a que uma instituição regulada deveria querer com mais frequência. Ter mais participação humana aqui significa que o sistema está funcionando, e não falhando.
Ainda não há um manual de supervisão regulatória para isso
Esta é a parte que explica por que todo fornecedor pode afirmar que tem um humano no processo sem que um contradiga o outro.
Em 17 de abril de 2026, as agências bancárias federais dos EUA publicaram diretrizes revisadas sobre gestão de risco de modelos. Elas substituem as diretrizes anteriores e também as declarações sobre gestão de risco para sistemas de PLD. Se a sua política de risco de modelo cita os documentos antigos, ela está baseada em normas revogadas.
As novas diretrizes deixam de lado a questão central deste artigo. "Os modelos de IA generativa e IA agêntica são novos e estão evoluindo rapidamente. Sendo assim, não estão no escopo destas diretrizes", afirmam os órgãos reguladores. Eles planejam publicar uma consulta pública sobre o uso de IA pelos bancos, mas ela ainda não foi lançada.
Seja preciso sobre o que isso significa. O framework de risco de modelo atualmente não alcança o agente de IA. No entanto, as obrigações fundamentais sobre a decisão em si não mudaram nada — o dever de reportar, a manutenção de registros e a expectativa de que uma decisão tenha um responsável identificado e uma base defensável continuam exatamente os mesmos. O que falta é uma resposta regulatória sobre quanta participação humana a decisão de um agente exige.
E esse é todo o objetivo desta página. Você não vai encontrar essa resposta pronta. A posição precisa ser definida internamente, documentada e defendida — por fila, por tipo de decisão e por direito.
Uma observação sobre a aplicabilidade: as diretrizes revisadas mencionam que devem ser mais relevantes para organizações bancárias com ativos totais acima de US$ 30 bilhões. No entanto, "mais relevante para" não significa "aplica-se apenas a", e muitas instituições menores ainda serão questionadas por auditores sobre como as decisões de seus agentes são controladas.
De confirmar tudo à amostragem: o que justifica a mudança
Os dois modelos de trabalho não são uma escolha que você faz na hora da compra. Eles são etapas consecutivas, e tratá-los como alternativas excludentes é o erro mais comum em toda essa discussão.
O caminho real tem três etapas. Primeiro, rode o agente com cobertura total, com um analista revisando cada recomendação durante um período de monitoramento inicial. Use a trilha de justificativas para validar as decisões do agente em relação aos resultados conhecidos e confirmar se ele se comporta como o esperado. Depois, passe da revisão de cada caso para um controle de qualidade periódico por amostragem, que é como a garantia de segunda linha já funciona para todo o resto.
O que justifica essa mudança são as evidências, e não o calendário. Não há um prazo fixo para isso — o ritmo é definido pela validação e pela segurança de cada instituição —, e a trilha de auditoria e a clareza das explicações são o que tornam a mudança defensável perante um auditor quando ela acontece. Se for inevitável estimar um prazo, o mais realista é falar em semanas, não em meses.
Ajuda saber como são as evidências de validação quando elas começam a aparecer. Um banco em fase de implementação mostra 92% de concordância do agente com a equipe de analistas nas decisões de alertas, com uma redução de 75% no tempo de revisão por caso. Veja isso como uma prova de que a medição funciona, e não como um número exato a ser esperado: cada cenário é único, e a taxa de concordância é a métrica certa porque mede se a camada humana está de fato alterando os resultados ou apenas confirmando-os.
Portanto, "in-the-loop" e "on-the-loop" são onde você começa e onde você pode conquistar o direito de chegar. Não é uma decisão tomada de uma vez por todas em um documento de contratação.
Onde o modelo falha
Quatro pontos de falha e um desafio que ainda ninguém resolveu.
Revisão de fachada. Um revisor com uma fila maior do que o turno de trabalho acaba apenas confirmando em vez de decidir. Isso falha no teste de "desafio eficaz" mesmo preenchendo todos os requisitos dos relatórios, porque o painel conta confirmações e não sabe diferenciar uma análise real de um clique automático. Se a sua taxa de revisão é de 100% e a taxa de discordância é quase zero, isso é um sinal de alerta, não uma conquista.
Gargalo na faixa errada. Exigir revisão completa em uma fila que não precisa dela consome exatamente a atenção que a faixa de alto risco deveria receber. A automação "human-in-the-loop" aplicada de forma uniforme não é uma postura conservadora ou segura. Ela apenas desloca o risco para um lugar menos visível.
Direitos atribuídos à função errada. Se a pessoa que pode encerrar um alerta não tem autoridade ou independência para revertê-lo, o controle existe apenas no papel. Vale a pena aplicar o teste do "desafio eficaz" no organograma da sua própria empresa.
Correções invisíveis. Quando um humano diverge da recomendação do agente e essa divergência não é mostrada para o próximo revisor, duas pessoas chegam a conclusões diferentes com base no mesmo registro. Registrar e dar feedback sobre essas divergências é um problema diferente de distribuir os direitos, e merece atenção própria.
Por fim, o desafio ainda não resolvido. O agente roda em uma infraestrutura que a instituição pode não possuir, e o modelo de revisão precisa funcionar sobre os sistemas de gestão de casos que já existem. Os agentes podem rodar como uma camada independente sobre a sua infraestrutura atual ou como parte de uma plataforma unificada — mas, de qualquer forma, a tela do revisor, a trilha de auditoria e o fluxo de encaminhamento precisam se integrar com sistemas que não foram desenhados para as recomendações de um agente de IA. Se você está adicionando agentes a uma estrutura de risco existente, essa conciliação é o verdadeiro trabalho, e não a integração técnica.
Perguntas frequentes
O que é human-in-the-loop?
Significa que uma pessoa toma ou confirma a decisão, e nenhuma ação acontece sem ela. O sistema gera uma recomendação com sua justificativa; o humano avalia e decide. No contexto de fraudes ou PLD, isso significa que um agente de IA pode propor uma decisão, mas não pode encerrar, encaminhar ou reportar por conta própria.
Qual é a diferença entre human-in-the-loop e human-on-the-loop?
A diferença prática: no "human-in-the-loop", a ausência de uma pessoa impede a ação, então o trabalho espera. No "human-on-the-loop", o sistema age dentro de limites configurados e uma pessoa supervisiona por amostragem e intervenção. O primeiro gera um registro de decisões com um responsável identificado por caso; o segundo gera um registro de supervisão sobre um grupo de casos.
O que "human-in-the-loop" significa especificamente em fraudes e PLD?
Significa identificar quem detém cada um dos cinco direitos em uma decisão: recomendar uma decisão, aprová-la, encerrar o alerta, encaminhar o caso e reportar a uma autoridade. Esses direitos costumam pertencer a papéis diferentes, e um agente de IA deve ter apenas o primeiro. Um fornecedor que não sabe dizer quem detém qual direito em cada fila não respondeu à pergunta.
Quem aprova uma decisão automatizada de fraude ou PLD?
Depende de qual direito você está se referindo. Um analista pode recomendar uma alteração na classificação de risco de um cliente, mas apenas uma função de controle — como o líder de crimes financeiros ou o diretor de conformidade — pode aprová-la. Aprovação, encerramento e envio de relatórios costumam ser feitos por três pessoas diferentes, e o aprovador precisa ter a justificativa e as evidências diante de si para poder discordar.
Um agente de IA pode encerrar um alerta por conta própria?
Não no modelo da Oscilar. Nossos agentes nunca encerram ou encaminham alertas de forma autônoma; cada recomendação é revisada e confirmada por um analista humano antes de qualquer ação ser tomada. Se outro sistema permite isso, é uma pergunta que vale a pena fazer diretamente, pois a expressão "human-in-the-loop" por si só não impede que isso aconteça.
Quem envia um relatório de atividade suspeita quando o agente rascunhou o texto?
O direito de envio permanece com a função que detém a obrigação legal, e o auxílio na redação não transfere essa responsabilidade — os controles internos geralmente impedem que a mesma pessoa que preparou o relatório seja quem o envia. Quando as áreas de fraude e PLD compartilham a mesma plataforma, a decisão de quem envia o relatório é uma questão de responsabilidade organizacional. Confirme as exigências específicas da sua instituição com a sua equipe jurídica.
Manter um humano no processo atrasa as decisões?
Isso altera a distribuição do custo em vez de eliminá-lo. A revisão completa de todos os casos consome a atenção humana de forma igualitária, e é por isso que uma configuração uniforme tende a sobrecarregar a faixa de rotina e deixar a faixa de alto risco sem a atenção necessária. O mapeamento por faixa de risco é como você decide onde investir esse tempo: revisão rigorosa onde as consequências são graves, e confirmação rápida onde uma recomendação confiável em um caso simples é de fato suficiente.
Como é auditada a revisão humana de uma decisão do agente?
Por meio de uma trilha que registra os dados de entrada, a justificativa e as evidências do agente, o nível de confiança e cada ação posterior do agente ou analista com marcações de data/hora — facilitando a comprovação de onde os humanos tomaram as decisões. Como os agentes rodam para todos os itens da fila e não apenas para amostras, nenhum caso é excluído silenciosamente desse registro. O que a trilha deve guardar e quem pode alterá-la são questões de governança.
Isso pode funcionar com os sistemas de risco que a instituição já possui?
Sim. Os agentes podem rodar como uma camada independente sobre a infraestrutura atual ou como parte de uma plataforma unificada. O ponto que exige mais atenção não é a integração técnica, mas sim a conciliação: a tela do revisor, a trilha de auditoria e o fluxo de encaminhamento precisam funcionar de forma integrada com o sistema de gestão de casos que já existia antes do agente de IA.
Se você está definindo onde deve passar a linha de revisão nas suas próprias filas, essa conversa é muito mais produtiva com um tipo de decisão real do que no plano abstrato. Fale conosco sobre uma prova de conceito de uma semana em uma única fila, com o modelo de revisão definido antes de qualquer execução.

Equipe Oscilar
A equipe da Oscilar é formada por especialistas em diversas áreas de gestão de risco. Estes artigos refletem pontos de vista e conhecimentos de várias fontes e colaboradores de toda a organização.


