Por que os agentes de risco precisam de uma memória compartilhada dos clientes

Última atualização: Setembro de 2026

A memória partilhada para agentes de risco de IA é um registo de cliente único, resolvido, com permissões e auditável do qual cada agente lê e no qual escreve no momento da decisão. Não se trata de uma janela de contexto maior nem do perfil de cliente 360 que uma equipa de dados reúne para relatórios. Sem isso, um agente de fraude e um agente de AML podem olhar para a mesma pessoa, ler os seus próprios dados corretamente e, ainda assim, chegar a conclusões contraditórias.

Resumo do artigo

• Dois agentes de risco que discordam sobre o mesmo cliente representam, normalmente, um problema de registo, não de modelo. Cada agente lê uma fração diferente e raciocina corretamente a partir dela.

• Três conceitos distintos são chamados de memória: a janela de contexto de um agente, o perfil de cliente 360 de um armazém de dados e um registo de risco regulado. Apenas o terceiro é o que uma função de risco necessita.

• Um registo partilhado tem três pré-requisitos que o vocabulário esconde. As identidades têm de ser resolvidas, as definições de campo têm de ser acordadas e o registo tem de ter um proprietário designado.

• Esse proprietário não costuma ser a plataforma de agentes. Na maioria das instituições, a camada partilhada é uma cópia sincronizada de um registo que reside noutro local, o que torna as decisões de design sobre a gravação de dados, a caducidade e a reconciliação fundamentais.

• Nenhuma orientação de supervisão indica o que deve conter o registo de um cliente de um agente. A orientação revista sobre risco de modelo, publicada a 17 de abril de 2026, deixa a IA de agentes fora do seu próprio âmbito, pelo que cabe à instituição decidir e, posteriormente, defender essa decisão.

Memória partilhada para agentes de risco de IA: a resposta curta

A memória partilhada para agentes de risco de IA significa que todos os agentes que trabalham com um cliente leem e escrevem no mesmo registo, e esse registo resolve-se numa única identidade, inclui definições acordadas para cada campo e regista o que cada agente e cada humano lhe fizeram. O teste não é a quantidade de informação que um agente consegue reter num único prompt. É saber se o agente de fraude, o agente de AML e o agente de crédito estão a raciocinar sobre o mesmo cliente, e se alguém consegue reconstruir posteriormente o que cada um deles viu.

Dois agentes, um cliente, duas respostas

Um agente de fraude sinaliza uma conta como de baixo risco, enquanto um agente de AML considera que a mesma pessoa deve ser escalada. Nenhum dos dois está errado do ponto de vista em que se encontra. O agente de fraude tem o histórico do dispositivo e das transações para um produto; o agente de AML tem dados de contrapartes e de geografia para outro.

A divergência não é um problema de modelo. Ambos os agentes leram as suas entradas de dados corretamente e raciocinaram de forma sensata. Leram registos diferentes, e nenhum dos sistemas sabe que o outro existe.

Cada agente adicionado a uma função de risco torna isto mais provável em vez de menos, o que é o oposto do que a compra do segundo agente deveria fazer. A própria posição de produto da Oscilar assenta em agentes orquestrados que "transportam o contexto entre alertas, ligam os pontos entre dados de fraude, crédito e conformidade, e escalam de forma inteligente". Transportar o contexto entre alertas só significa algo se houver um único local para esse contexto residir.

Três coisas chamadas memória, e apenas uma delas é esta

Três coisas distintas partilham a palavra memória nas conversas sobre agentes de risco de IA, e confundi-las é a forma como um projeto de plataforma de dados é vendido como um projeto de agente.

A tabela descreve três camadas que respondem a três perguntas diferentes, e apenas a terceira responde a "o que é que esta instituição sabe sobre este cliente neste exato momento".

Os repositórios de vetores, as estratégias de recuperação e a taxonomia de memória episódica versus semântica ficam de fora disto. Essas questões pertencem a uma equipa que desenvolve um agente. Uma função de risco que implementa vários agentes tem um problema diferente, que é o facto de o registo do seu cliente estar disperso por sistemas que nunca foram concebidos para estar em sintonia.

Requisito um: as identidades têm de ser resolvidas

Um registo partilhado é inútil se a fraude, o AML e o crédito tiverem uma chave diferente para a mesma pessoa. A resolução de entidades é o pré-requisito e tem de acontecer antes que qualquer etapa posterior faça sentido. Uma visão única do cliente reunida a partir de três identificadores não correspondidos constitui, na verdade, três visões de cliente numa só tabela.

A resolução é um julgamento e falha em duas direções. Uma correspondência perdida esconde uma relação que existe, fazendo com que o agente raciocine sobre um fragmento. Uma fusão falsa cria uma relação que não existe, fazendo com que o agente raciocine sobre uma pessoa que não existe. Num contexto de risco, a fusão falsa é pior, porque a decisão que produz é confiante e está errada sobre um cliente real.

Esta página não faz qualquer alegação sobre a taxa de correspondência de nenhum produto específico, incluindo o da Oscilar, porque nenhum valor desse tipo está verificado. Pergunte a qualquer fornecedor como foi medida a sua taxa de correspondência, em que população e qual foi a taxa de fusão falsa na mesma execução. Isto pertence à lista de outras perguntas que vale a pena fazer antes de implementar um agente de risco.

Requisito dois: as definições têm de ser acordadas, não apenas os dados

Consolidar valores não define o seu significado. Um responsável pelas operações numa empresa digital de serviços financeiros descreveu o problema diretamente: "equipas diferentes definem uma métrica específica de forma ligeiramente diferente, e é por isso que ter uma ferramenta centralizada vai ser tão importante para nós. Dessa forma, os cálculos acontecem consistentemente da mesma forma em toda a empresa, em todas as equipas."

Dois agentes podem ler o mesmo campo e mesmo assim discordar, porque o campo significa algo diferente para a equipa que o preenche. Um cliente marcado como revisto por uma equipa pode significar que os documentos foram verificados; para outra, pode significar que o caso foi encerrado. Nenhum dos agentes consegue saber qual a versão que está a ler.

Esta é a razão mais clara pela qual um perfil de cliente 360 de um armazém de dados não é suficiente para o trabalho de risco. Consolida valores sem definir significados, e os significados são aquilo sobre o qual o agente raciocina.

O mesmo orador referiu o custo de os deixar indefinidos: sem uma fonte central fiável, "muito do trabalho subsequente que acontece em segundo plano" é gasto a validar informação recolhida de múltiplos armazéns de dados.

Requisito três: o registo tem um proprietário, e provavelmente não é a plataforma de agentes

Partilhado não significa que seja propriedade de alguém. Um diretor de I&D numa plataforma global de pagamentos, ao descrever uma implementação real, foi explícito sobre onde se encontra a cópia principal: "as nossas listas não estão a ser utilizadas apenas para o processo [da plataforma de risco]. Estão a ser propagadas para equipas diferentes nalguns casos. Por isso, não podemos fazer com que a [plataforma de risco] seja a fonte de verdade para a gestão de listas. Precisa de ser uma cópia da nossa fonte de verdade."

Na maioria das instituições de dimensão considerável, a camada partilhada é uma cópia sincronizada de um registo que reside noutro local. Listas, registos principais de clientes e hierarquias de contas são consumidos por equipas que nada têm a ver com risco, e essas equipas não aceitarão uma plataforma de risco como o sistema de registo definitivo. Esta é a mesma restrição que rege o que um agente precisa dos sistemas de risco que já possui: o agente lê a partir desses sistemas, não os substitui.

Isso transforma a gravação de dados, a caducidade e a reconciliação em decisões de design e não em meros detalhes de implementação. Se um agente escreve uma decisão na cópia partilhada, algo tem de decidir se isso se propaga para o original, quanto tempo a cópia pode atrasar-se e o que acontece quando as duas divergem.

Defina uma questão antes de adicionar um segundo agente: qual o sistema que tem autoridade para cada campo. A resposta diferirá campo a campo, e escrevê-la constitui a maior parte do trabalho.

O que o registo tem de conter e por quanto tempo

Um registo sobre o qual vários agentes podem raciocinar contém quatro elementos. A identidade, incluindo as provas de como foi resolvida. As definições acordadas para cada campo. O histórico de decisões, incluindo que humano confirmou o quê. E o que cada agente escreveu de volta, atribuído a esse agente.

A gestão de permissões pertence ao próprio registo, e não a uma camada acima dele. Nem todos os agentes devem ler todos os campos, e um registo que não consiga expressar isso ou sofrerá fugas de informação ou terá o seu âmbito reduzido até deixar de ser partilhado.

O histórico não é opcional. Um agente que raciocina sobre uma relação com um cliente precisa do passado dessa relação, e carregá-lo é uma tarefa maior do que parece. O mesmo diretor de I&D listou as tarefas pendentes da sua implementação e colocou "o carregamento de dados históricos" entre elas, chamando-lhe "uma vertente mais estratégica do que especificamente tática para já".

Do lado da gravação de dados, a posição pública da Oscilar é clara e direta: os agentes nunca encerram ou escalam alertas de forma autónoma, e cada recomendação é revista e confirmada por um analista humano antes de qualquer ação ser tomada. O que fica gravado no registo é uma recomendação acompanhada de uma decisão humana, e não um agente a agir sozinho.

Por que esta é uma questão de governação e não de engenharia de dados

Nada nas orientações de supervisão atuais indica a uma instituição o que o registo de cliente de um agente deve conter. A 17 de abril de 2026, a Reserva Federal, a FDIC e o OCC publicaram conjuntamente orientações revistas sobre a gestão de risco de modelos (SR 26-2 na Reserva Federal, Boletim 2026-13 no OCC e FIL-15-2026 na FDIC), substituindo a SR 11-7 e a declaração interinstitucional sobre risco de modelos BSA/AML de 2021. Essas orientações colocam a IA de agentes fora do seu próprio âmbito: "Os modelos de IA Generativa e de IA de agentes são inovadores e estão a evoluir rapidamente. Como tal, não se encontram no âmbito destas orientações." As agências afirmam que planeiam publicar um pedido de informação que abranja a utilização de IA pelos bancos, mas até à data, este não foi emitido.

Por isso, cabe à instituição decidir o que o registo contém, redigir a decisão e defendê-la. Nada disso elimina as obrigações subjacentes de BSA/AML sobre a própria decisão, que permanecem inalteradas.

Já existe um teste utilizável nas orientações. A SR 26-2 mantém o "desafio eficaz" e define quem o pode realizar: indivíduos com competência para conduzir uma contestação crítica e objetiva, independência suficiente para se manterem imparciais e "posição e influência organizacional para implementar qualquer alteração". Aplique estas mesmas três condições ao registo. Conseguirá um revisor independente, com autoridade para alterar algo, reconstruir o que cada agente viu no momento em que fez a sua recomendação? Se a resposta depender de qual o sistema que decidir abrir, o registo não está a ser partilhado.

É também para isto que serve uma pista de auditoria. A plataforma da Oscilar regista o raciocínio por trás de cada recomendação, o que facilita mostrar aos reguladores onde os humanos tomam decisões. Isso só se aplica se houver um registo único ao qual associar o raciocínio, o que prova que o registo partilhado e a pista de governação que um agente de risco de IA tem de deixar são, afinal, o mesmo problema.

O aspeto que assume quando o registo está em falta

A falha manifesta-se como fricção operacional comum muito antes de alguém lhe chamar um problema de governação. Pessoas diferentes tratam o mesmo caso, as notas não são concentradas num só local e quem o está a analisar não está a olhar para o sistema correto.

A consequência não é apenas a ineficiência. Um responsável pelas operações numa empresa digital de serviços financeiros enquadrou a questão com base no local onde os registos têm, em última análise, de ser validados: "quero garantir que a nossa documentação e todos os nossos registos são claros, porque, por razões óbvias, não podemos comparecer em tribunal com informações em falta." Um agente que trabalhe mais depressa do que um humano aumenta essa lacuna, porque se acumulam mais decisões contra um registo que não as consegue justificar.

Existe uma versão mensurável na outra direção. Um banco em fase de implementação apresenta 92% de concordância dos agentes com a sua equipa de analistas na tomada de decisões sobre alertas e uma redução de 75% no tempo de cada revisão. A concordância só é mensurável porque o agente e o analista estavam a olhar para a mesma coisa, que é o que o registo partilhado oferece antes de tudo o resto. Trata-se de uma implementação específica e não de uma referência padrão.

Onde isto falha

Um registo partilhado não elimina as divergências. Torna as divergências significativas. Dois agentes podem continuar a chegar a conclusões diferentes sobre o mesmo cliente, e a vantagem é que agora consegue perceber o porquê, em vez de descobrir a contradição durante uma auditoria regulatória.

Consolidar o registo é uma tarefa mais demorada do que consolidar os agentes, e pode durar mais do que o programa de agentes que a motivou. Um diretor de gestão de fraude numa empresa global de pagamentos e cartões pré-pagos descreveu a versão interna deste exato trabalho: um sistema central que distribui dados para fornecedores e orquestra o que regressa, construído para que "algum dia, antes de eu morrer, todos estejam integrados" nele. A sua empresa tem "provavelmente 30 plataformas diferentes em lista de espera para tentar integrá-las no sistema consolidado de fraude." Trata-se de um sistema em funcionamento, descrito por quem o construiu, com uma fila de espera medida em plataformas.

Há duas lacunas reais que importa referir. Não existe qualquer medida publicada sobre a frequência com que os agentes de risco se contradizem entre si, na Oscilar ou em qualquer outro local. E esta página não faz qualquer alegação sobre a forma como qualquer produto, incluindo o da Oscilar, resolve identidades ou sincroniza registos, pois não existem dados validados que o comprovem.

Por onde começar

Escolha um cliente que esteja atualmente ativo em duas filas de espera diferentes e tente reunir o registo único manualmente. O tempo que isso demorar e o número de sistemas em que tocar será a sua métrica. Isto é mais informativo do que o diagrama de arquitetura de qualquer fornecedor.

Depois, determine o sistema que tem autoridade para cada campo antes de adicionar um segundo agente, e não depois. Os campos em que nenhum sistema tem uma autoridade óbvia são a origem das contradições futuras.

O que os agentes têm de partilhar além do registo do cliente, incluindo o estado da tarefa e as regras de escalamento, é uma questão diferente e um tema para outro artigo.

Uma restrição prática torna isto mais fácil do que parece. Os agentes podem funcionar como uma camada autónoma sobre a infraestrutura que já possui, ou como parte da plataforma unificada. A questão do registo é resolvida pela camada e não pela substituição dos sistemas proprietários dos dados.

Se preferir testar o argumento em vez do software, realize uma prova de conceito de um agente de uma semana focada no registo: um segmento de clientes, uma identidade resolvida e uma resposta por escrito sobre qual o sistema que tem autoridade para cada campo.

Perguntas frequentes

O que é a memória partilhada de clientes para agentes de risco de IA?

A memória partilhada de clientes é um registo de cliente único, resolvido, com permissões e auditável do qual cada agente de risco lê e no qual escreve no momento da decisão. Contém a identidade do cliente e as provas de como foi resolvida, as definições acordadas para cada campo, o histórico de decisões incluindo as confirmações humanas e o que cada agente escreveu. Trata-se de um registo regulado e não de uma cache ou de uma tabela de relatórios.

Por que razão os agentes de risco precisam de uma memória partilhada de clientes?

Porque um agente não consegue raciocinar sobre um cliente se apenas vir uma fração do mesmo. Quando um agente de fraude e um agente de AML têm versões diferentes da mesma pessoa, ambos podem ler as suas informações corretamente e, ainda assim, chegar a conclusões contraditórias. Cada agente adicional acrescenta apenas outra visão parcial em vez de mais ajuda prática.

Qual é a diferença entre a janela de contexto de um agente e um registo de cliente partilhado?

Uma janela de contexto é a memória de trabalho de um agente para uma única tarefa e desaparece quando a tarefa termina. Um registo de cliente partilhado é persistente, é lido e escrito por todos os agentes e rege-se por regras sobre quem pode ler cada campo. Alargar a janela de contexto dá mais espaço a um agente, mas não dá nada aos restantes agentes.

O perfil de cliente 360 é o mesmo que a memória partilhada para agentes de risco?

Não. Um perfil de cliente 360 de um armazém de dados ou uma visão única do cliente é criado para relatórios e análises, sendo habitualmente reunido após os acontecimentos e não estando disponível com a latência exigida para decisões. Além disso, consolida valores sem definir o seu significado, que é a principal falha no que toca a agentes. Um registo de risco tem de permitir leitura e escrita no momento da decisão e deve conter definições acordadas.

Como se mantém a persistência da memória entre vários agentes de IA?

Fornecendo aos agentes um registo partilhado externo, em vez de tentar sincronizar as suas memórias individuais. Resolva o cliente numa única identidade, acorde a definição de cada campo, defina o sistema que tem autoridade por campo e exija que cada agente grave a sua decisão de volta com a devida atribuição. A persistência passa a pertencer ao registo e não a qualquer agente.

Como se governa e audita o que um agente recorda sobre um cliente?

Trate o registo como o objeto da auditoria. Registe o que cada agente leu, o que recomendou, que humano o confirmou ou alterou e o que foi gravado de volta, para que um revisor independente possa reconstruir o estado no momento da decisão. Aplique o teste do desafio eficaz da norma SR 26-2: o revisor precisa de competência, independência e autoridade para alterar o resultado.

A memória partilhada para agentes de risco de IA funciona com os sistemas de risco existentes de uma instituição?

Sim, e na maioria das instituições essa é a única solução viável. Os agentes podem funcionar como uma camada autónoma sobre a infraestrutura que já possui, ou como parte de uma plataforma unificada, pelo que o registo partilhado se posiciona acima dos sistemas proprietários dos dados subjacentes, sem os substituir. O trabalho de design consiste em decidir que sistema tem autoridade para cada campo e como são geridas a gravação de dados e a reconciliação.

Como são geridas a revisão humana, a auditabilidade e o desempenho quando os agentes partilham um registo?

A revisão humana permanece no fluxo de decisão: os agentes nunca encerram ou escalam alertas de forma autónoma, e cada recomendação é revista e confirmada por um analista humano antes de qualquer ação ser tomada. A auditabilidade advém do registo do raciocínio associado a cada recomendação num registo único, facilitando a demonstração aos reguladores do ponto em que os humanos tomam as decisões. O desempenho é medido com base nesse mesmo registo, o que dá verdadeiro significado às taxas de concordância entre agentes e analistas.

Um registo antes do próximo agente

Um agente não consegue raciocinar sobre um cliente se apenas vir uma fração do mesmo. A memória partilhada para agentes de risco de IA não é uma janela de contexto maior nem um perfil de cliente 360 para relatórios. Trata-se de um registo único, resolvido, com permissões e auditável, com definições acordadas e um proprietário designado e, enquanto este não existir, cada novo agente adicionará apenas outra visão parcial da mesma pessoa.

A ordem das etapas é importante. Resolva a identidade, acorde as definições, defina o proprietário de cada campo e só depois adicione o segundo agente. Se quiser ver como isto se aplica aos seus próprios dados, os agentes de IA da Oscilar são o ponto de partida ideal para a sua leitura, e uma prova de conceito de um agente de uma semana focada num único registo de cliente revelar-lhe-á muito mais do que qualquer demonstração.