Última atualização: Setembro de 2026
Quando um analista anula um agente de IA, a instituição acaba de gerar uma prova e a maioria dos sistemas a deita fora. Um modelo champion-challenger é o controlo que lhe permite guardá-la. Os dados de anulação treinam uma versão candidata do agente, a versão que toma decisões em tempo real permanece intocada e a promoção da candidata requer provas e um ser humano nomeado. Esta página utiliza o termo para se referir a duas versões da mesma lógica de decisão, e não a dois fornecedores concorrentes. Se errar na organização, o ciclo de feedback deixa de melhorar o agente e passa a codificar os hábitos de uma equipa como política.
Resumo
A anulação de um analista é uma prova, não uma instrução. Indica que um humano discordou. Não indica que o humano tinha razão.
Encaminhe as anulações para um challenger. Mantenha-as afastadas da versão que está atualmente a tomar decisões.
Uma taxa de anulação isolada é impossível de interpretar. Registe em cada decisão e em cada anulação a versão que a produziu, e o número torna-se numa comparação que pode responder se a sua última alteração ajudou.
Registe a discordância, não apenas a correção. Guarde o valor do agente, o valor do humano e um motivo. Uma anulação armazenada como uma edição destrói o sinal no momento em que é criado.
Avalie os seus analistas uns em relação aos outros antes de avaliar qualquer um em relação a um agente. A consistência entre humanos é o limite máximo do que um ciclo de feedback pode aprender com eles.
Mantenha uma pessoa na fase de promoção e apresente provas nessa fase. Uma alteração que resolve o caso à sua frente pode degradar silenciosamente todos os casos para os quais não está a olhar.
Aprender com as anulações dos analistas: a resposta curta
Como deve uma equipa de risco utilizar as anulações dos analistas para melhorar um agente de IA? Trate uma anulação como uma prova, não como uma instrução. Registe-a como um evento que contém o valor do agente, o valor do humano e um motivo, para que a discordância sobreviva em vez de ser substituída. Envie esse sinal para um challenger — uma versão candidata avaliada com as mesmas entradas ao mesmo tempo sem agir sobre nada — e não mexa no champion, a versão que toma as decisões em tempo real. A promoção é então uma troca deliberada que requer provas numa série de casos e uma pessoa com autoridade para a aprovar. É isso que impede que um ciclo de feedback transforme silenciosamente os hábitos de uma equipa em política.
O botão sobre o qual ninguém está de acordo
Um cliente que estava a criar o seu próprio processo de revisão fez-nos uma pergunta que resume todo o problema. O botão de anulação manual faz com que a verificação seja executada novamente ou fecha o caso? Trata-se de eventos opostos, e um sistema que não os consegue distinguir aprende disparates com ambos. Um é um pedido de uma segunda opinião. O outro é uma resposta final.
A mesma ambiguidade surge mais à frente. Um diretor de conformidade de crimes financeiros num banco, que já tinha desenhado um processo de anulação e ainda não tinha terminado de refletir sobre o assunto, expôs o que ainda estava em aberto: "Como é que se faz isso? Durante quanto tempo se guarda? Como é que muda? E deve alguma vez voltar a subir?"
Estas são as perguntas certas, e quase nada do que foi publicado sobre testes champion e challenger lhes responde. Um ciclo de feedback baseado em dados de anulação pode tornar um agente visivelmente melhor ou pode, silenciosamente, transformar os hábitos de alguns revisores em política institucional. De fora, estes dois resultados parecem iguais durante muito tempo.
Esta página aborda o que pode fazer com os dados de anulação depois de os obter e o que impede que essa resposta se torne num novo treino descontrolado. Notar que o acordo entre o seu agente e os seus analistas se alterou é uma tarefa distinta e enquadra-se na monitorização de desvio do modelo.
O que significam aqui champion e challenger
O champion é a versão que está a tomar decisões em tempo real. O challenger é uma versão candidata executada em paralelo com a mesma informação de entrada, produzindo resultados sobre os quais ninguém age. A promoção é a decisão de transformar o challenger no champion. Os modelos champion e challenger são um padrão estabelecido na gestão de risco de modelos, e os testes de champion-challenger de modelos de crédito são onde a maioria das instituições reguladas se depara com isso pela primeira vez.
Um esclarecimento, porque a expressão é muito utilizada. Na externalização e no risco de terceiros, uma estratégia champion-challenger significa manter um segundo fornecedor de prevenção para garantir a honestidade do primeiro. Trata-se de uma tática de aquisição e de um assunto diferente. Aqui, tanto o champion como o challenger são seus.
O padrão adequa-se ao feedback de anulação porque o challenger é o local onde deve estar um sinal em que ainda não confia. Uma anulação é esse tipo de sinal: informação real, gerada por quem estava a analisar o caso, de fiabilidade desconhecida até ter analisado muitos deles em conjunto. Enviá-lo para um challenger não lhe custa nada e não o compromete com nada.
O que as abordagens existentes ao padrão ignoram é a parte humana. Todas as abordagens de champion e challenger promovem um challenger com base em métricas de modelo face a dados retidos. Nenhuma delas pergunta o que fazer quando quem discorda do champion é uma pessoa, com discernimento, um volume de trabalho e uma leitura diferente de provas ambíguas da do analista da secretária ao lado.
O ciclo de vida da anulação, tal como um banco o desenhou na realidade
O design de anulação mais completo que já vimos veio de uma função de conformidade que o debateu em voz alta. Vale a pena reproduzi-lo porque é um ciclo de vida real de quatro estados e porque o que deixa de fora acaba por ser o aspeto essencial.
O direito de anulação é um controlo e não uma capacidade geral. Nesta instituição, a alteração da classificação de risco de um cliente estava restrita a duas funções: o responsável por crimes financeiros e o responsável pelo BSA. Os analistas tinham um direito mais limitado. Podiam recomendar. Uma alteração iniciada por um analista era encaminhada para uma fila de espera, era aí confirmada e voltava para uma função de controlo para aprovação como etapa de controlo de qualidade.
Esta distinção é mais importante do que parece. Uma recomendação e uma anulação aprovada são dois eventos diferentes, e apenas o segundo é uma decisão que a instituição irá defender. Um ciclo de feedback que os trata como a mesma coisa está a aprender com o evento errado. Qual a função que deve ter qual o direito de revisão é uma questão mais ampla do que esta página resolve; este artigo assume a divisão como adquirida e pergunta o que esta faz aos dados.
A aprovação funciona em ambos os sentidos. Qualquer anulação passava pelo mesmo processo, quer aumentasse ou diminuísse o risco. As reduções recebiam o mesmo escrutínio que os aumentos, o que é o oposto do instinto da maioria das instituições e o melhor design, porque uma anulação para baixo é a que tem algo a esconder.
A anulação persiste através da nova classificação. O modelo continuou a classificar na sua cadência trimestral normal e a decisão humana continuou a prevalecer até que um humano a retirasse. A classificação continuou a funcionar; a faixa não se moveu. Como referiu o diretor de conformidade, uma anulação aplicada com justificação deve "estar ativa até querermos removê-la", em vez de ser apagada pelo ciclo seguinte.
Reabre com uma alteração de estado e não com uma data. O que faz com que uma anulação volte a ser revista é uma alteração material no comportamento, como uma nova via de pagamento ou um grande desvio na atividade. A libertação ocorria numa revisão anual agendada, onde alguém perguntava se o motivo original ainda se mantinha.
Estado | Introduzido por | Quem decide | Condição de saída |
|---|---|---|---|
Recomendado | Um analista deteta algo que a classificação ignora | O analista abre; uma fila de espera confirma | Aprovado por uma função de controlo, ou rejeitado |
Ativo | Aprovação por uma função de controlo, em qualquer direção | Responsável por crimes financeiros ou responsável pelo BSA | Substituído, reaberto ou libertado |
Reaberto | Uma alteração material no comportamento do cliente | De volta ao mesmo processo de aprovação | Reaprovado a um novo nível, ou libertado |
Libertado | A revisão anual agendada conclui que o motivo já não se aplica | Função de controlo | A classificação reverte para o resultado do modelo |
Os quatro estados pelos quais uma anulação passa e quem é responsável em cada um deles.
Governação sem medição
O que essa conversa inteira nunca abordou foi a medição.
Não existia uma taxa de anulação. Não havia taxa de acordo entre o agente e os analistas. Nenhuma métrica de comportamento de anulação de qualquer tipo, e ninguém levantou a possibilidade de que as anulações pudessem ser inconsistentes entre analistas. Todos os controlos de consistência descritos eram processuais: restringir o direito, encaminhar recomendações através de uma fila de espera, exigir aprovação em ambas as direções, apresentar o indicador ao revisor seguinte.
Trata-se de bons controlos que respondem a uma pergunta diferente. O controlo processual diz-lhe quem pode anular. Apenas a medição diz se as anulações são suficientemente consistentes para aprender com elas.
Esta não é a história de uma instituição negligente. Tinha desenhado mais o ciclo de vida da anulação do que a maioria, e a lacuna é estrutural: não há instrumentação padrão para a consistência da anulação, nenhuma referência publicada e nada na categoria que a acompanhe. É por isso que o resto desta página existe.
A procura é real e não é a preocupação de apenas um banco. Um líder de conformidade de um segundo banco listou "como as anulações são tratadas, como são apresentadas, como são geridas em estados de alteração" entre as suas perguntas em aberto antes de assinar qualquer documento. Um revisor de conformidade num terceiro perguntou se uma pontuação poderia ser reduzida "e documentado o motivo". Note o que surge no mesmo instante que a anulação: o motivo.
Uma anulação é uma prova, não uma instrução
A maioria dos sistemas trata uma anulação como uma edição. O valor do humano substitui o do agente, o valor antigo desaparece e o registo mostra uma decisão sem qualquer vestígio de que algo tenha sido contestado. A discordância, que é a única informação genuinamente nova em toda a transação, é destruída no momento em que é criada.
O design que deve exigir é o de um evento apenas de adição que contenha três coisas: o valor do agente, o valor do humano e um motivo. Manter ambos os valores é o que transforma a própria discordância em dados. Pode contá-la, agrupá-la e compará-la entre versões. Nada disto funciona num campo que foi substituído.
O campo do motivo não é decorativo. É a única parte do registo que distingue uma anulação correta de uma inconsistente. Dois analistas que chegam a conclusões opostas com o mesmo código de motivo é um problema de treino; a mesma conclusão por motivos diferentes é algo diferente. Como mostram as citações acima, isto é também o que os compradores pedem de forma espontânea.
Em seguida, apresente-o. O próximo analista a abrir esse cliente precisa de um indicador de que existe uma anulação manual em vigor, porque a anulação é o contexto para a sua decisão e não apenas uma correção da decisão do modelo. Se o ocultar, dois revisores chegarão a conclusões diferentes a partir do mesmo registo, que é a inconsistência que esta página pretende resolver. Um agente que já mostra as entradas, o seu raciocínio e o resultado final em cada alerta está a meio caminho, e a anulação tem de estar integrada nesse percurso e não fora dele.
Um aspeto sobre o estado disto. Tratar uma anulação como um evento imutável é uma posição arquitetónica, não uma funcionalidade de produto que alguém possa comprar hoje em dia. Trate-o como um princípio de design a exigir a qualquer fornecedor, inclusive a nós.
Uma disposição diz-lhe o que um humano pensou. Um resultado diz-lhe quem tinha razão.
Uma disposição é um julgamento registado no momento: o analista fechou o alerta, encaminhou-o, registou-o. Um resultado é o que realmente aconteceu, como a transação que se revelou fraudulenta ou o cliente que se revelou ser o que o analista suspeitava.
Estes não são o mesmo sinal, e a diferença decide se vale a pena construir o seu ciclo de feedback. Um ciclo de feedback treinado apenas em disposições aprende a concordar com os analistas. Isso produz uma melhoria mensurável no acordo e nenhuma melhoria na precisão. Também se auto-reforça, porque o viés de automatização significa que um revisor que confia no agente aprova-o sem questionar, o que aumenta o acordo, o que parece que o ciclo está a funcionar.
Os dados de resultados podem ser introduzidos através das mesmas interfaces utilizadas para invocar uma decisão em primeiro lugar, como assinalar uma transação que foi aprovada na semana passada como suspeita, assim que se saiba mais sobre ela. Isso transforma um teste retrospetivo de "a decisão teria sido diferente" em algo sobre o qual uma instituição pode agir: teria recusado estes casos específicos e esta proporção deles era genuinamente suspeita.
A instrução prática é curta. Instrumente ambos e nunca deixe que um número de acordo funcione isoladamente como prova de qualidade.
Uma única taxa de anulação não lhe diz nada. Uma comparação diz-lhe algo.
Uma taxa de anulação isolada não pode ser interpretada. O mesmo valor pode descrever um excelente agente revisto por analistas cuidadosos, ou um agente medíocre revisto por analistas passivos, e nada no número distingue os dois. As instituições partilham estes números entre si de qualquer forma, e é assim que uma métrica deixa de conter informação.
Torna-se interpretável no momento em que se transforma numa comparação. Registe em cada decisão e em cada anulação a versão da configuração e as instruções que a produziram, e a pergunta passa a ser uma a que pode responder: a última alteração ajudou? Isso é muito mais útil do que perguntar se oito por cento é um bom número.
A segunda medição que vale a pena desenvolver prende-se com o formato e não com o volume. As anulações dispersas por casos não relacionados são o discernimento do revisor a fazer o seu trabalho. As anulações agrupadas numa característica partilhada, como o mesmo tipo de cliente, a mesma tipologia ou a mesma lacuna de dados, são um padrão que o agente está a errar sistematicamente. Defina o limiar de agrupamento a partir do seu próprio volume. Não existe um número do setor defensável para isso, e deve desconfiar de quem lhe oferecer um.
Pode estabelecer a linha de base mais importante antes de comprar o que quer que seja. Meça o acordo dos seus analistas entre si nos mesmos casos, de forma cega. A consistência entre humanos é o teto para o que qualquer ciclo pode aprender com eles, e a maioria das instituições nunca analisou isso. Se dois dos seus revisores concordam um com o outro setenta por cento das vezes, um agente que concorda com eles oitenta e cinco por cento das vezes não é o que precisa de ser corrigido primeiro.
Para ter uma noção de como são os números na prática, um banco em fase de implementação apresenta 92% de acordo do agente com a sua equipa de analistas na disposição dos alertas e menos 75% de tempo por revisão. Leia isto ao contrário e verá que se trata de uma taxa de desacordo de 8%, que é o sinal de anulação de que trata esta página. Trate isto como uma implementação única e não como uma referência a esperar; a parte útil é o formato da medição e não o valor. As taxas de anulação devem estar na mesma área que os seus outros KPIs de resultados medidos por segmento, porque uma taxa que parece boa no agregado e terrível num segmento é o caso normal.
Encaminhe o sinal para um challenger, não para o modelo ativo
Todo o argumento se resume a uma regra. Os dados de anulação alteram um challenger. Nunca alteram a versão que está atualmente a tomar decisões.
A promoção requer então três coisas. Provas num conjunto de dados e não num único caso, porque uma alteração justificada por um único alerta não é de todo uma alteração. Uma comparação direta com o champion com base nas mesmas entradas. E uma pessoa nomeada com autoridade para aprovar a troca.
Nesta última condição, a linguagem do regulador é melhor do que a nossa. A orientação interinstitucional revista sobre a gestão do risco de modelos, emitida em 17 de abril de 2026 como SR 26-2 na Reserva Federal, Boletim 2026-13 no OCC e FIL-15-2026 no FDIC, mantém o conceito de "desafio eficaz" e é específica sobre quem o pode realizar: indivíduos com "a experiência adequada para realizar um desafio crítico e objetivo, independência suficiente para manter a objetividade, bem como a posição organizacional e influência para efetuar qualquer alteração". Um revisor que não pode alterar o resultado falha a terceira condição. Isto descreve as duas funções de controlo que o banco acima tinha escolhido, e é um teste viável para quem detém a sua decisão de promoção. O registo de auditoria que uma decisão deste tipo deixa tem os seus próprios requisitos, abrangidos no que um percurso de governação para um agente de risco de IA tem de suportar.
Dois pontos de precisão sobre essa orientação, porque é fácil interpretá-la em demasia. Refere que se "espera que seja mais relevante para organizações bancárias com mais de 30 mil milhões de dólares em ativos totais", o que é mais brando do que aplicar-se apenas a elas. Também coloca os modelos de IA generativa e de agentes fora do seu próprio âmbito, estando apenas planeado um pedido de informação sobre a utilização da IA pelos bancos. Portanto, nenhum enquadramento de supervisão lhe diz atualmente quanta intervenção humana é necessária para a decisão de um agente. Não pode procurar a resposta. Tem de a decidir, escrevê-la e ser capaz de a defender, razão pela qual vale a pena acertar nisto em vez de o tratar como uma formalidade de conformidade.
Uma suposição que vale a pena desmistificar. Aprender com as anulações parece ser o mesmo que voltar a treinar um modelo, e para um agente normalmente não o é. O refinamento diário é uma alteração de versão da configuração e das instruções, e não do modelo subjacente, o que é mais fácil de auditar e de reverter. O nome académico para a ideia adjacente, aprendizagem ativa em machine learning, descreve a seleção de pedir a um humano para rotular os casos em que um modelo tem menos certezas. Os dados de anulação são o mesmo instinto vindo da outra direção, espontâneo e já associado a uma decisão real.
O aspeto ideal, numa linha: o processo tem um humano na fase de promoção e essa fase tem provas associadas.
Porque é que a correção de um caso pode piorar tudo
O mecanismo por trás do receio é concreto. Adicionar contexto para corrigir um caso pode diminuir a qualidade em todo o conjunto de dados. A alteração que resolve o alerta à sua frente, quer se trate de mais uma instrução, mais um elemento de contexto ou mais uma exceção, pode degradar casos para os quais não está a olhar, e nada lho dirá a menos que esteja a medir o conjunto de dados e não o caso.
O mesmo raciocínio explica por que razão o trabalho crítico para a exatidão não deve permitir que um modelo decida quais as tipologias a considerar. Uma tipologia em falta não pode ser justificada a um responsável de conformidade após o facto, e o contexto tangencial reduz visivelmente a qualidade do resultado. O restrito e determinístico vence o amplo e inteligente quando alguém tem de defender o resultado.
Portanto, a sequência tem de decorrer por esta ordem, e vale a pena escrevê-la como perguntas de aquisição:
Agregar. Recolha as anulações como eventos, com ambos os valores e o motivo, num volume suficiente para perceber o formato.
Apresentar o padrão a uma pessoa. Um grupo é uma hipótese e não uma correção, e vai para alguém que o possa avaliar, não para um trabalho de novo treino.
Deixar a pessoa decidir se deve alterar algo. A maioria dos grupos não deve resultar em qualquer alteração.
Implementar a alteração com versão, com um registo de quem a alterou, quando, porquê e a partir de que eventos subjacentes.
Condicioná-la a uma etapa de avaliação em relação a um conjunto de casos retidos, nunca em relação ao caso que a motivou.
Duas regras que vale a pena adotar agora como perguntas a fazer a um fornecedor sobre qualquer automatização futura desse processo: o sistema propõe e um humano aprova, e nada é implementado sem passar por uma etapa de avaliação. Nenhuma delas é uma alegação de produto. É a restrição que qualquer pessoa que construa isto honestamente acaba por aceitar.
O que pode medir hoje e o que ainda não pode
Três coisas estão disponíveis sem novas ferramentas. O percurso de raciocínio em cada recomendação, que é o que torna uma anulação interpretável em vez de meramente registada. Agentes a correr em toda a fila de espera em vez de apenas numa amostra, o que significa que o denominador de qualquer taxa de anulação é o real. E as suas próprias disposições históricas, que são uma linha de base que já possui e que provavelmente nunca mediu.
Agora o limite, exposto claramente: não existe uma referência publicada para a consistência da anulação, e esta página não vai inventar uma. O que lhe pode dizer é quais as comparações que têm significado, nomeadamente o mesmo agente em duas versões, os seus analistas uns contra os outros e um grupo contra a dispersão. Também lhe pode dizer quais as que não têm, nomeadamente qualquer taxa única apresentada sem o seu denominador ou a sua versão.
Algumas destas coisas ainda não são um produto. Avaliar a adesão à anulação face ao seu próprio procedimento escrito em escala é uma direção ativa de desenvolvimento e não algo disponível hoje em dia. Uma classificação, ou seja, um sinal de aprovação ou desaprovação no resultado de um agente, é um sinal mais fraco do que uma anulação, porque regista a insatisfação sem registar qual teria sido a resposta certa. Recolha-o, mas não construa um processo com base nele.
Duas coisas que esta página descarta deliberadamente. Detetar que o acordo se alterou, o que significa que a sua taxa de anulação está a aumentar e precisa de saber porquê, é o problema de monitorização e desvio, e surge antes de tudo o que está aqui. Os limiares com os quais se compromete antes do início de uma implementação, incluindo a taxa de acordo que irá aceitar e o que fará se não a atingir, pertencem aos critérios de avaliação que definiu no início e não ao design de feedback que construirá depois.
Perguntas frequentes
O que é um modelo champion challenger?
Um modelo champion challenger executa duas versões de um modelo ou agente em simultâneo: o champion toma decisões em tempo real e o challenger avalia as mesmas entradas sem agir sobre nada. A promoção é a decisão de os trocar e deve exigir provas em muitos casos, além de um aprovador humano nomeado. Na externalização e no risco de terceiros, a mesma expressão significa manter um segundo fornecedor de prevenção, o que é uma prática diferente.
Qual é a diferença entre uma anulação e um erro de modelo?
Uma anulação é uma decisão humana de se afastar do resultado do modelo. Um erro do modelo é o facto de o modelo estar errado. Sobrepõem-se sem ser a mesma coisa: uma anulação pode ser o erro de um humano, a deteção correta de um erro genuíno ou uma decisão de julgamento num caso genuinamente ambíguo. Qual delas foi é uma pergunta a que responde por medição, e a existência da anulação não lhe responde.
Como distinguir uma anulação correta de uma inconsistente?
Dois sinais fazem a maior parte do trabalho: o código do motivo e o agrupamento. As anulações dispersas por casos não relacionados com motivos variados são o discernimento do revisor a funcionar normalmente. As anulações agrupadas numa característica partilhada apontam para um padrão que o agente está a errar, e códigos de motivo idênticos que produzem conclusões opostas apontam para inconsistência entre os revisores e não para uma falha no agente.
Durante quanto tempo é válida uma anulação?
Responda a isto com uma alteração de estado e não com uma duração. Uma anulação deve persistir através dos ciclos normais de nova classificação até que um humano a retire, reabrir quando o comportamento do cliente se alterar materialmente, como uma nova via de pagamento ou um grande desvio na atividade, e surgir para libertação numa revisão programada onde alguém verifica se o motivo original ainda se mantém. Uma data de expiração fixa é mais fácil de implementar e não lhe diz nada sobre se o motivo ainda se aplica.
Devem as anulações dos analistas voltar a treinar o modelo automaticamente?
Não. Os dados de anulação devem alterar um challenger, nunca a versão que está atualmente a tomar decisões em tempo real, e a promoção desse challenger deve ser uma decisão humana apoiada por provas ao nível do conjunto de dados. O novo treino automático baseado em anulações treina o sistema para concordar com os seus revisores, o que aumenta o acordo sem melhorar a exatidão. Significa também que uma alteração que corrige um caso pode degradar casos para os quais ninguém está a olhar.
O que tem de ser verdade antes de um challenger ser promovido a champion?
Três coisas. Provas num conjunto de casos e não no caso que motivou a alteração. Uma comparação direta com o champion nas mesmas entradas durante o mesmo período. E um aprovador com a experiência, a independência e a posição organizacional para efetuar realmente a alteração, além de um registo de quem a aprovou, quando e com que provas.
Quem autoriza a promoção de um modelo que aprendeu com as decisões dos analistas?
A orientação interinstitucional atual sobre a gestão do risco de modelos descreve a norma através do "desafio eficaz": a pessoa deve ter a experiência adequada, independência suficiente para manter a objetividade, e a posição organizacional e influência para efetuar a alteração. Na prática, isto aponta para uma função de controlo e não para a equipa que construiu ou opera o agente. Um revisor que não pode alterar o resultado não cumpre a terceira condição.
Como impedir que um ciclo de feedback codifique os hábitos de um analista como política?
Quatro controlos, por ordem. Restrinja quem pode gerar uma anulação autorizada, para que nem todos os juízos dos revisores entrem no sinal de treino. Registe um motivo com cada uma delas. Meça o conjunto de dados e não o caso, para que o efeito de uma alteração em tudo o resto permaneça visível. E condicione a promoção a uma decisão humana com provas associadas, para que nenhum hábito chegue à produção sem que alguém o escolha.
Pode o feedback de anulação funcionar com os sistemas de risco existentes de uma instituição?
Sim, e normalmente tem de o ser. Os agentes podem ser executados como uma camada autónoma sobre a infraestrutura que já possui, ou como parte de uma plataforma unificada, e a captura de anulações funciona da mesma forma em ambos os casos: um evento apenas de adição que contém o valor do agente, o valor do humano e um motivo, registado com a versão que produziu a decisão. O que importa é que as anulações fiquem em algum lugar passível de consulta, juntamente com as decisões que contestam, e não que toda a estrutura seja substituída.
Por onde começar
A vertente de governação deste problema é bem compreendida e a vertente de medição não o é. As instituições sabem como restringir quem pode anular e como encaminhar uma aprovação. Quase nenhuma delas sabe dizer se as suas anulações são consistentes. Se está a desenhar um processo de anulação agora, o que deve adicionar é a instrumentação que lhe diz se os controlos estão a produzir um sinal com o qual vale a pena aprender.
Comece com o que já possui: o acordo dos seus analistas entre si, as suas disposições históricas e a decisão de registar as anulações como eventos que contêm ambos os valores e um motivo desde o primeiro dia, em vez de fazer uma adaptação posterior. Para ver como é um percurso de decisão construído para isso, os agentes de IA da Oscilar mostram a entrada, o raciocínio e o resultado em cada alerta, que é a matéria-prima de que uma medição de anulação necessita.

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.


