Critérios de Aceitação para uma Prova de Conceito de Agente de Risco de IA

Última atualização: setembro de 2026

Uma prova de conceito de IA só vale a pena ser realizada se puder falhar. Antes de um agente tocar em um único alerta, quatro coisas devem estar por escrito: o limite que cada medição deve atingir, os dados contra os quais o exercício será executado, as pessoas que assinarão confirmando que os limites foram atingidos e o que acontece se não forem. Defina isso e um exercício curto gera uma decisão. Deixe em aberto e você terá algumas semanas de resultados interessantes seguidos por mais uma reunião.

Esta página é a lista para definir antes da primeira semana, escrita sob a perspectiva do comprador. A maior parte das orientações publicadas sobre a execução de uma POC de IA vem de empresas que gostariam de executá-la para você, e é por isso que tão pouco disso ensina como definir um número que pode dar errado.

Resumo prático

• Critérios de aceitação definidos depois que os resultados chegam não são critérios. O exercício deixa de ser um teste e se torna uma história sobre o que aconteceu.

• Velocidade é a coisa mais fácil de demonstrar e a menos informativa. Um agente que é mais rápido e está errado é pior do que a fila que você já tem.

• Três coisas devem estar por escrito antes da data de início: um cronograma fixo, critérios de sucesso assinados por ambos os lados e um executivo que já tenha declarado que atingi-los significa seguir em frente.

• A escolha dos dados decide o que você pode provar. Sem as decisões registradas de seus analistas, não há como obter um número de concordância, por melhor que seja o resultado do exercício.

• Defina limites para concordância, discordância inexplicável, integridade da população, suficiência de evidências, tempo de revisão, comportamento diante de dados ausentes e auditabilidade. Defina o limite para verdadeiros positivos perdidos separadamente, e de forma rigorosa (baixo).

• Essas dimensões se enquadram em quatro grupos: qualidade da decisão, adequação operacional, viabilidade comercial e uma regra de decisão por escrito. Mude os números, mas mantenha os quatro grupos.

• Ninguém pode dizer quais números escolher. Não há uma referência publicada para limites de aceitação de agentes, portanto, meça sua própria linha de base primeiro, incluindo a frequência com que seus analistas concordam entre si. O exemplo prático nesta página é o conjunto de uma equipe, escolhido antes de verem qualquer resultado, e não um número para ser copiado.

• Escreva o caminho de falha. Uma prova de conceito sem consequências acordadas em caso de falha não tem como falhar.

A prova de conceito que passa e não muda nada

Os compradores raramente pedem uma prova de conceito por curiosidade. Eles pedem porque a última compra não correu bem. Um stakeholder responsável por contratos e exposição regulatória em uma instituição expressou o motivo claramente: a solução atual não é o que a equipe queria, e ninguém quer passar novamente pela experiência de iniciar a implementação para só então descobrir que havia coisas que simplesmente não podiam fazer. Um líder de engenharia na mesma instituição disse que o patrocinador executivo queria a comprovação da mesma coisa, porque não queria estar na posição em que a equipe já se encontrava.

Vale a pena ter esse motivo em mente, pois ele explica por que os critérios importam mais do que a demonstração. O exercício é uma garantia contra a repetição de erros, por isso deve ser capaz de retornar um resultado negativo.

A falha da qual ele precisa se proteger está no outro extremo. Ambas as equipes passam semanas na configuração, as medições acordadas dão certo e, mesmo assim, o patrocinador executivo decide continuar com o fornecedor atual. Descrevemos isso como correr em direção a um sinal vermelho, e quando apresentamos isso a um líder de engenharia em uma negociação real, a resposta veio imediatamente: isso era justo, e eles já tinham visto isso acontecer muitas vezes.

Há dois mecanismos por trás disso, e eles são, na verdade, o mesmo mecanismo duplicado. Critérios escolhidos depois que os resultados aparecem não têm como falhar. Critérios que medem apenas a velocidade também não, porque um agente sempre será mais rápido do que uma pessoa lendo um alerta. Em ambos os casos, o exercício não pode falhar, o que significa que não pode embasar uma decisão.

O que é uma prova de conceito de agente de risco de IA, e o que ela não é

Uma prova de conceito de IA é um exercício com prazo determinado que testa se um agente pode fazer um trabalho específico com seus dados, seguindo um padrão que você acordou antes do início do trabalho. Para um agente de risco, esse trabalho costuma ser um julgamento, em vez de uma tarefa simples: definir a resolução de um alerta, reunir as evidências de um caso ou decidir o que um revisor precisa ver a seguir.

Os termos correlatos costumam ser usados de forma intercambiável, mas levam a conclusões diferentes.

A distinção que decide tudo o que vem depois é a última. Uma prova de conceito pergunta se a solução pode funcionar. Uma prova de valor pergunta se vale a pena. A maioria dos exercícios decepcionantes foi vendida como o primeiro e julgada como o segundo, e a lacuna aparece no final, quando os critérios foram atendidos e a decisão ainda não chega.

Uma prova de conceito de machine learning tem um objetivo mais simples do que uma de agente. Nela, você pergunta se um modelo faz previsões boas o suficiente em relação a um resultado rotulado. Com um agente de risco, você pergunta se um julgamento é bom o suficiente para um analista agir com base nele, e essa pergunta não tem resposta até que você tenha algo com o que comparar esse julgamento. Tudo na seção de dados abaixo decorre disso.

Um limite antes dos critérios. A questão de quais dimensões um agente deve ser julgado é um exercício separado, abordado em como avaliar um agente de risco de IA antes da produção. Esta página começa um passo depois, nas condições de aprovação que essas dimensões precisam.

Quando vale a pena executar uma, e quando não vale

Execute uma quando três condições se confirmarem: você tem decisões históricas para comparar, sua fila tem volume suficiente para produzir uma amostra representativa e uma pessoa específica assumirá a responsabilidade pela resposta.

Não execute uma quando os critérios forem genéricos. O líder de crescimento de uma equipe de compras descreveu com precisão a própria lacuna ao ser questionado se tinham um documento de requisitos de negócios para a funcionalidade em avaliação: eles tinham um muito genérico, e foi assim que identificaram que precisavam de alguém dedicado para assumir isso, pois era necessário ser mais específico sobre a tolerância ao risco e sobre quais controles queriam aplicar. Essa pessoa ainda não havia sido contratada, portanto, os stakeholders do lado deles ainda eram desconhecidos e o resultado estava indefinido antes de qualquer início. Eles identificaram o problema e o estavam corrigindo na ordem certa, o que é mais do que a maioria das equipes consegue fazer.

Não execute uma quando ninguém tiver autoridade para agir após uma aprovação. Esse é o sinal vermelho, e a resposta certa é adiar em vez de prosseguir com cautela.

Não execute uma ainda se sua fila estiver gerando ruídos que o agente processará fielmente. Um agente direcionado a uma fila cheia de duplicatas apenas provará que as duplicatas existem. A higienização básica das regras vem em primeiro lugar.

A pergunta de diagnóstico é curta. Se o agente tiver o desempenho exato que você espera, qual decisão acontece na próxima semana e quem a toma? Se não houver resposta para isso, os critérios não estão prontos.

Três coisas para definir antes da primeira semana

Antes de iniciar qualquer prova de conceito, três coisas precisam existir.

Um cronograma fixo. Uma data de início, uma data de término e um evento definido ao final. Uma intenção de encerrar em algumas semanas não é um cronograma.

Critérios de sucesso acordados mutuamente, com signatários definidos de ambos os lados. A palavra-chave aqui é mútuo. Critérios que apenas um lado escreveu são uma lista de desejos ou um roteiro de vendas, dependendo de quem os escreveu. Nomeie as pessoas que dirão que os critérios foram atingidos e registre seus nomes antes que o primeiro alerta seja carregado.

Alinhamento executivo prévio. O patrocinador declara, antes do início do trabalho, que o cumprimento desses critérios significa seguir em frente. A maioria dos compradores trata isso como uma etapa posterior. Este é o pré-requisito essencial que evita o sinal vermelho, pois converte um resultado técnico em uma decisão com a qual alguém já se comprometeu.

Dois acréscimos devem constar na mesma página.

Defina os preços antes de executar o exercício, e não depois. Uma prova de conceito que tem sucesso técnico e depois morre devido a uma surpresa no orçamento falhou, e os insumos que uma proposta precisa são conhecidos de antemão: volumes esperados por linha de negócio e eventos de integração esperados. Esperar semanas em um exercício para obter informações financeiras é a receita para fazer um bom resultado estagnar.

Em seguida, combine quais fluxos de trabalho internos serão executados em paralelo, pois essa tensão não se resolve sozinha. Um líder de engenharia em uma negociação foi direto: um mês ou dois de integração de fornecedores e trabalho de base é razoável, mas eles não iniciariam esse processo ou pediriam a assinatura da diretoria antes que a equipe pudesse provar que conseguiria usar a solução.

O interesse do fornecedor vai na direção oposta, já que terminar o exercício e depois descobrir que a contratação leva mais seis semanas adiciona um trimestre ao calendário. Nenhum dos lados está errado. Decida explicitamente quais revisões começam agora e quais aguardam.

Calibrado ou cego: a escolha de dados que decide o que você pode provar

Comece definindo o escopo, porque definir o escopo e escolher os dados são a mesma decisão. Critérios escritos com base em um escopo vago geram discussões mais tarde, e a discussão chega na terceira semana, quando custa caro. Esta página traz um exemplo prático do início ao fim: um agente na triagem de alertas de nível um de PLD (Prevenção à Lavagem de Dinheiro) e, nesse exemplo, o escopo é definido primeiro.

A linha que as equipes mais costumam pular é a terceira. Se você já utiliza uma ferramenta de inteligência de dispositivos, declare claramente que o exercício não avaliará sinais de dispositivos; caso contrário, perde-se duas semanas comparando o agente com uma funcionalidade que você já possui. Uma exclusão escrita no início é muito mais fácil de defender do que uma discutida na terceira semana.

Em seguida, a escolha dos dados. É a decisão mais impactante do projeto e a que mais costuma ser tomada por acaso.

Um exercício calibrado roda com seus alertas históricos juntamente com a justificativa de decisão que seus analistas registraram na época. Como as decisões passadas estão presentes, a concordância torna-se mensurável: para cada alerta, você pode perguntar se o agente chegou à mesma conclusão que sua equipe e, se não, o porquê.

Um exercício cego roda sem essas decisões prévias. Você ainda vê a análise completa do agente em cada item, mas não consegue produzir um número de concordância, por melhor que seja o desempenho. A comparação não tem um parâmetro de referência.

A armadilha está na combinação. Um comprador que não fez essa escolha de forma consciente geralmente concorda com um exercício cego esperando um resultado calibrado. O que acontece depois é previsível: a equipe julga o agente com base no fato de o raciocínio parecer sensato. Isso é apenas uma demonstração com um tempo de execução maior.

Uma terceira opção é legítima e, muitas vezes, correta. Se suas decisões estão em notas não estruturadas, você pode esperar até que sejam capturadas em formato estruturado como parte da rotina e rodar o exercício calibrado mais tarde, com uma base de referência mais limpa. Escolher isso deliberadamente é um resultado melhor do que rodar um exercício cego e chamá-lo de calibrado.

Dados sintéticos têm seu valor, mas o espaço deles é mais limitado do que parece. Formatados no seu próprio esquema, eles eliminam totalmente o trabalho de integração, permitindo que um exercício comece sem demandar tempo da sua equipe de engenharia, e as telas se parecem com o que você veria ao vivo. Seja exato sobre o que isso prova: que o processo lida com o formato dos seus dados, não que o julgamento corresponde ao dos seus analistas.

O conjunto de 1.200 casos no exemplo acima é como se parece uma execução calibrada completa ao final. Os insumos necessários para começar uma são simples:

• Cerca de 25 alertas históricos para começar, ou 25 a 50 com a justificativa correspondente, se essa justificativa estiver em documentos em vez de campos de dados.

• 60 a 90 dias de histórico de transações para as entidades nesses alertas, de acordo com seu próprio procedimento.

• Dados básicos de entidade e identidade.

• Uma sessão de cerca de 45 minutos observando como seus analistas trabalham nos alertas hoje.

Esse último passo é o mais ignorado, mas é nele que toda a medição se apoia. Você não pode definir um limite de concordância com seus analistas sem antes observar o que eles fazem.

Os critérios de aceitação, por dimensão

Vale a pena definir limites para oito dimensões, que se dividem em quatro grupos: qualidade da decisão, o que o agente precisa acertar; adequação operacional, se alguém de fato consegue usá-lo; viabilidade comercial, se vale a pena comprar; e uma regra de decisão por escrito para a revisão.

Mude os números, mas mantenha os quatro grupos. Um conjunto que omite um deles tem um modo de falha previsível: sem critérios de qualidade de decisão, você discute se o resultado foi bom; sem critérios operacionais, você tem um exercício que funciona, mas nunca é implementado; sem critérios comerciais, a compra trava em compras; sem regra de decisão, você ganha um adiamento.

Foque em menos critérios do que você acompanha. Três ou quatro que realmente mudem sua resposta são melhores do que uma dúzia que produz uma avaliação que ninguém usa. Se a ausência de um critério não altera a decisão, ele é apenas uma métrica: meça, mas não condicione a aprovação a ele.

Compartilhe os critérios antes do pontapé inicial. O valor está em trazer à tona as discordâncias enquanto elas ainda custam pouco. Se o líder de risco e o líder de operações definirem metas diferentes na primeira linha, essa é uma conversa que vale a pena ter na semana zero, em vez de uma discussão na quinta semana.

Aqui está a entrega esperada. Defina um limite para cada dimensão, por escrito, antes de o exercício começar. A terceira coluna é onde está o trabalho real, pois nenhum desses números pode ser entregue pronto para você.

Seis dessas oito linhas avaliam a qualidade da decisão e as evidências por trás dela; tempo por revisão e auditabilidade medem a adequação operacional. A viabilidade comercial não tem nenhuma linha nessa tabela, o que é a omissão mais comum das quatro e a que costuma travar exercícios bem-sucedidos.

O teste mais prático de todo este conjunto veio de um comprador, não de um fornecedor. Um líder de engenharia propôs rodar a mesma população de dados no sistema atual e no candidato para compará-los, com analistas observando como cada caso se desenvolve e evolui. Isso é mensurável, não depende do fornecedor para definir e se aplica a qualquer agente. Exija isso.

Duas coisas ficam de fora do escopo desses limites. Quem detém qual direito de revisão quando o agente estiver ativo é uma questão de design separada, definida por fila em relação ao seu próprio procedimento, e não durante o exercício.

A segunda é o que você faz com os dados de divergência após a implementação, à medida que os ajustes manuais se acumulam e padrões começam a aparecer. Durante o exercício, as divergências são uma métrica. Depois, tornam-se um ciclo de feedback, que precisa de um responsável dedicado.

Ao definir o limite de evidências, verifique o que um agente anexa a cada recomendação. A questão útil é se o raciocínio, as evidências e as tipologias chegam em um formato no qual o revisor possa agir, e não apenas se a recomendação em si está correta.

Agora, a parte realista. Não existe uma referência publicada para limites de aceitação de agentes, seja em orientações de supervisão ou em qualquer outro lugar que tenhamos buscado, incluindo esta página. Podemos dizer em quais dimensões definir limites. Não podemos dizer qual número escolher, e quem fornecer um número sem conhecer sua fila estará apenas adivinhando.

Portanto, meça sua própria linha de base primeiro. Descubra com que frequência dois de seus analistas chegam à mesma decisão no mesmo alerta, pois esse número é o teto do que a concordância com um agente pode significar. Se seus próprios analistas concordam entre si menos do que a meta que você está prestes a definir para um agente, essa meta será inconsistente em vez de ambiciosa.

Uma implementação real mostra o formato que um limite assume quando alguém o define. Um banco em fase de implementação apresenta 92% de concordância do agente com sua equipe de analistas na resolução de alertas e 75% menos tempo por revisão. Encare isso como uma prova de conceito real, não como uma regra geral: trata-se de uma instituição específica, com suas próprias filas, procedimentos e definições de correspondência.

A razão para analisar isso é a combinação de fatores. Uma taxa de concordância e um número de tempo juntos dizem algo que o tempo sozinho não consegue expressar.

Um exemplo prático: triagem de alertas de nível um de PLD

O que se segue são os critérios de uma equipe para o escopo definido anteriormente nesta página, detalhados porque uma lista de dimensões é mais fácil de aprovar do que de aplicar. Cada valor é uma meta neste exemplo, escolhida antes de a equipe ver um único resultado. Os 92% acima e os 85% abaixo não são a mesma coisa: um é uma medição real de uma implementação, o outro é um limite que alguém definiu antecipadamente para sua própria fila. Foque nas colunas, não nos valores.

Qualidade da decisão: o que o agente precisa acertar. O parâmetro de referência são as decisões históricas dos seus analistas, e não uma taxa de precisão genérica do fornecedor, que descreve um fluxo de alertas de outra empresa.

A segunda linha tem um zero absoluto, porque a tolerância desta equipe para falhas de alto risco era genuinamente zero. Declarar isso no início é o que evita discussões sobre médias no momento da revisão.

Adequação operacional: se qualquer pessoa consegue usar. É aqui que um exercício costuma parecer excelente e mesmo assim falha na implementação. Um agente que gera recomendações excelentes onde os analistas não trabalham não produz resultado nenhum.

Esse último teste é intencionalmente difícil e vale a pena manter. A questão não é se existe um registro. É se esse registro responderá à pergunta de um auditor daqui a onze meses, quando o analista que tratou do caso já tiver mudado de equipe.

O caso comercial: se vale a pena comprar. Ignorar isso é o motivo pelo qual exercícios tecnicamente bem-sucedidos travam antes da contratação.

A segunda linha merece uma análise direta antes do exercício, e não depois. Em volumes baixos de casos e com um custo de tratamento manual barato, um agente pode custar mais por ação do que o trabalho que ele substitui, e se essa conta não fechar no seu volume, você terá sucesso técnico e fracasso comercial, o que desperdiça o tempo de todos.

A terceira linha importa mais do que parece. Eficiência não é um resultado palpável após seis meses. Já a redução de um atraso de nível dois de três semanas para cinco dias é.

Termine a primeira semana com uma tabela como essa organizada, uma linha por fila. Quais tipos de alerta permitem que uma recomendação de alta confiança seja liberada com um clique, e quais sempre exigirão revisão manual, é uma questão de apetite ao risco, não de tecnologia. Definir esses limites faz parte da preparação do exercício, não é um resultado dele, e um planejamento que deixa isso para depois falha em entregar o que foi prometido.

As fases e as etapas de decisão entre elas

Peça a qualquer fornecedor a mesma estrutura em quatro partes: preparação dos dados, um teste histórico com seus alertas passados, uma execução em modo sombra e uma apresentação dos resultados. Essa é a estrutura de uma avaliação séria antes da produção, e vale a pena exigi-la por nome para que você possa identificar se o que está sendo oferecido contempla todas as etapas.

Os pontos de transição importam mais do que a sequência. Cada passagem precisa de uma condição de saída escrita com antecedência.

• A preparação dos dados se encerra quando a amostra acordada é carregada e as decisões históricas estão presentes ou a equipe aceitou de forma consciente realizar um exercício cego.

• O teste histórico se encerra quando os números de concordância e de verdadeiros positivos perdidos existem e foram avaliados em relação aos limites definidos, e não com base em impressões subjetivas.

• A execução em modo sombra se encerra quando o agente analisa dados reais de produção sem gerar alertas, casos ou qualquer ação operacional posterior, e sua resposta foi comparada com o que seus analistas de fato decidiram nos mesmos itens.

• A apresentação de resultados encerra o exercício, e apenas quando resulta em uma decisão e em um cronograma de implementação.

Pergunte também sobre os estágios que o agente passa a caminho de uma decisão ativa. O formato exigido deve ser gradual: testado isoladamente, depois rodado em modo sombra com dados reais de produção sem disparar alertas ou casos, em seguida um teste real alocando parte do volume para a nova versão em relação a um grupo de controle, e finalmente ativo. Trate isso como uma pergunta a ser feita a qualquer fornecedor, e não como uma premissa óbvia, e obtenha a resposta por escrito, pois a execução em modo sombra e a transição por versões são a diferença entre uma implementação controlada e uma mudança brusca.

Duas restrições sobre como estruturar isso. Não aceite um calendário semanal genérico como a base do plano: a estrutura lógica é a parte que se aproveita, enquanto um calendário reflete principalmente a disponibilidade de pessoal do fornecedor.

E trate as dependências de integração como uma condição de escopo, não como um detalhe de menor importância. Se algo que você deseja provar depende de uma integração em tempo real com uma ferramenta de terceiros que ainda não existe, o exercício se prolongará ou o comportamento precisará ser simulado. Ambas as alternativas são aceitáveis; descobrir na segunda semana qual delas você terá não é. Pergunte quais dos seus critérios exigem conexões com terceiros antes que o cronograma seja fechado.

O que deixar de fora intencionalmente

Cada elemento adicional que você tenta provar atrai mais uma equipe, cujo tempo você precisará justificar.

Em uma negociação, o fornecedor defendeu que a gestão de casos de ponta a ponta ficasse de fora do exercício, justamente porque provar isso exigiria o envolvimento de toda uma equipe de operações que, de outra forma, não precisaria participar. O líder de engenharia descartou o item rapidamente: não era necessário, os usuários principais eram a equipe de conformidade, e provar o que essa equipe precisava já era o suficiente.

Note a direção desse argumento, pois ela é a parte mais útil. O fornecedor propôs reduzir o escopo. Um fornecedor que pressiona para provar tudo de uma vez está focando em tornar o exercício impressionante, não em tornar sua decisão prática.

A regra prática é: inclua o que o usuário principal precisa que seja provado e exclua o que você já sabe que funciona. Se uma demonstração já convenceu você de que algo funciona, não gaste o tempo do exercício provando isso novamente.

Algumas coisas funcionam melhor em etapas do que eliminadas de vez. Em um segundo caso, a avaliação de um agente específico foi adiada intencionalmente até que a plataforma em si fosse validada. Esse é o mesmo limite desenhado anteriormente: decidir quais dimensões avaliam o agente é um exercício, e as condições de aprovação nesta página são outro. Rodar as etapas na ordem errada prejudica ambas.

Uma coisa deve ser mantida, por mais que o escopo seja reduzido. Garanta uma visão geral clara na apresentação final para que todos na sala compreendam o que está sendo analisado. Os participantes não terão o mesmo nível de contexto, e um resultado que ninguém consegue acompanhar perde o valor.

Quem aprova e quais os próximos passos

A aprovação deve ser feita por uma lista de nomes acordada no início. Quem estiver na sala ao final do processo não conta como aprovador.

Para definir quem deve constar nessa lista, utilize o teste do próprio órgão regulador. As diretrizes de supervisão sobre gestão de risco de modelos foram atualizadas em 17 de abril de 2026, quando o Federal Reserve, o FDIC e o OCC emitiram conjuntamente as diretrizes revisadas como SR 26-2, Boletim OCC 2026-13 e FDIC FIL-15-2026, substituindo a SR 11-7 de 2011 e a declaração conjunta de 2021 sobre gestão de risco de modelos para sistemas de PLD. A diretriz revisada mantém o conceito de questionamento eficaz (effective challenge) e define quem pode realizá-lo: indivíduos com "a experiência adequada para conduzir um questionamento crítico e objetivo, independência suficiente para manter a imparcialidade, bem como posição organizacional e influência para efetivar qualquer mudança."

A terceira condição é a mais ignorada. Um revisor que pode levantar objeções mas não tem poder para alterar o resultado final não cumpre essa exigência, e essa é uma definição do regulador, não apenas uma opinião.

Vale a pena saber enquanto constrói sua lista: a diretriz revisada deixa a IA generativa e os agentes fora de seu escopo, declarando que tais modelos "não estão no escopo destas diretrizes", com uma consulta pública planejada sobre o uso de IA pelos bancos. Portanto, não há um modelo regulatório pronto sobre o nível de envolvimento humano que uma decisão automatizada precisa. Sua instituição deve decidir, documentar e defender suas escolhas, e é por isso que os critérios pertencem a você.

Nada disso anula as obrigações sobre a decisão em si. Como ficará sua posição quando o agente estiver ativo e o registro de auditoria que um agente de risco deixa para trás são os passos seguintes.

Encerre com uma apresentação de resultados. Repasse a lista acordada, aponte o que foi cumprido e o que não foi, e saia com uma decisão e um cronograma de implementação. Essa apresentação é o que valida o alinhamento executivo inicial, pois é o momento de honrar o compromisso assumido. Defina também o documento que registrará os resultados: um escopo escrito detalhando os casos de uso, volumes, elementos do processo e as integrações com terceiros envolvidas.

Em seguida, documente o caminho em caso de falha, no mesmo documento dos critérios e antes do início do exercício. É algo curto. Um responsável da lista de aprovadores assume a decisão final, e todos os caminhos são definidos antecipadamente.

Registrar o caminho em caso de falha é o que viabiliza uma análise honesta. Sem isso, um exercício abaixo do esperado costuma ser estendido de forma silenciosa em vez de concluído, e uma interrupção clara custa menos do que um terceiro adiamento. Uma prova de conceito sem caminhos de falha definidos é um projeto que ninguém pode dar como reprovado.

Quanto tempo deve levar e por que você ouvirá estimativas diferentes

Diferentes pessoas fornecerão estimativas de duração distintas, inclusive dentro do mesmo fornecedor. Vale a pena considerar duas visões, pois elas descrevem tipos de exercícios diferentes.

Uma prova de conceito pode rodar em cerca de uma semana quando realizada com dados históricos e com critérios de sucesso acordados antecipadamente. Uma avaliação de pré-produção completa, envolvendo preparação de dados, teste histórico, execução em modo sombra e apresentação dos resultados, exige cerca de quatro semanas, que é a duração assumida no exemplo prático acima.

O ponto chave não é qual estimativa está certa, mas entender que se trata de dois exercícios diferentes. Um comprador que espera a segunda opção e contrata um cronograma de uma semana se decepcionará, mesmo que o projeto seja bem-sucedido dentro do que se propôs. Portanto, o critério é simples e raramente registrado: defina qual das opções você está adquirindo, por escrito, antes da data de início.

Entenda o prazo de uma semana da forma correta. Ele só é realizável porque os critérios foram definidos com antecedência, o que reforça o argumento principal desta página sob outra perspectiva.

Por que esses projetos falham

Os dois mecanismos no topo desta página foram critérios definidos após os resultados e critérios focados apenas em velocidade. Vale destacar mais cinco modos de falha reais identificados em projetos que embasaram este texto:

• Ausência de um responsável definido. Observado na prática: requisitos vagos e a pessoa responsável por detalhá-los ainda não havia sido contratada.

• Um exercício cego avaliado como se fosse calibrado. A falha mais silenciosa e difícil de detectar depois do processo, pois os resultados apresentados ainda parecem impressionantes.

• Uma aprovação sem obrigatoriedade de ação. É assim que um exercício passa e nunca é implementado: ninguém combinou o que aconteceria após a aprovação, então passar ou falhar leva ao mesmo lugar: outra reunião.

• Inchaço do escopo. Um teste de duas semanas vira um trimestre de alinhamentos e consome a energia e a boa vontade que seriam necessárias na implementação real.

• Falta de autonomia na lista de aprovadores. Os critérios são atingidos, os revisores concordam, mas nada avança porque ninguém na sala tem poder para tomar a decisão.

Perguntas frequentes

O que é uma prova de conceito?

Uma prova de conceito é um exercício com prazo determinado que testa se uma solução específica pode realizar um trabalho sob suas próprias condições de operação, avaliado conforme critérios combinados antes do início do trabalho. Ela responde a uma pergunta de viabilidade técnica, não de valor financeiro. O resultado gerado é uma decisão sobre seguir em frente ou não, e não um produto final pronto.

Quais devem ser os critérios de aceitação para uma POC de agente de risco de IA?

Quatro grupos, por escrito, antes da data de início: qualidade da decisão, adequação operacional, viabilidade comercial e uma regra de decisão definindo quem decide e o que acontece se os critérios forem perdidos. Dentro desses grupos, defina limites para concordância com analistas na resolução, verdadeiros positivos perdidos, discordâncias inexplicáveis para o revisor, quanto da fila amostrada foi processado de ponta a ponta, se as informações dão base de ação para o revisor, tempo de revisão, comportamento diante de dados ausentes e se o histórico da decisão pode ser reconstruído depois. Estabeleça o limite de verdadeiros positivos perdidos separadamente e de forma rigorosa. Inclua também critérios não técnicos: signatários definidos e preços acordados.

Qual é a diferença entre uma prova de conceito e uma prova de valor?

Uma prova de conceito avalia se a solução funciona. Uma prova de valor avalia se o retorno justifica o investimento. Elas exigem critérios diferentes, e a maior parte das frustrações vem de um exercício que foi vendido sob a primeira ótica e julgado sob a segunda.

Quanto tempo deve durar uma POC de agente de risco de IA?

Cerca de uma semana se executada com dados históricos e critérios de sucesso combinados antecipadamente. Uma avaliação de pré-produção completa, englobando preparação de dados, teste histórico, execução em modo sombra e apresentação dos resultados, exige cerca de quatro semanas. Como são exercícios diferentes, defina por escrito qual deles você está contratando antes do início.

Quais dados um fornecedor precisa para uma POC, e o que não deve ser compartilhado?

Para um exercício calibrado: cerca de 25 alertas históricos iniciais, 60 a 90 dias de histórico de transações dessas entidades e dados básicos de cadastro e identidade. Se as resoluções dos analistas estiverem em relatórios ou notas de texto em vez de campos estruturados, uma amostra de 25 a 50 alertas com suas justificativas é suficiente. Não é necessário conceder acesso direto à produção; dados sintéticos no seu formato demonstrarão se o processo lida bem com a estrutura das suas informações, embora não comprovem se a qualidade do julgamento se alinha à dos analistas.

Como definir um limite antes de ver os resultados?

Meça sua linha de base primeiro. Descubra o tempo médio de revisão atual e, principalmente, com que frequência dois analistas chegam à mesma conclusão no mesmo alerta. A concordância entre analistas é o teto máximo da concordância esperada com um agente; portanto, definir uma meta acima disso é incoerente em vez de ambicioso. Não há referências externas prontas para limites de aceitação, por isso a base precisa vir da sua própria operação.

O que medir além da velocidade?

A concordância com analistas, verdadeiros positivos perdidos, discordâncias que o revisor não consegue justificar, abrangência da população analisada, suficiência de evidências para tomada de ação, comportamento diante de campos obrigatórios ausentes e auditabilidade do processo meses depois. O acompanhamento de verdadeiros positivos perdidos merece um teto rígido e isolado, pois taxas de concordância gerais podem parecer excelentes enquanto os erros se concentram justamente nos casos mais críticos.

Quem valida que uma POC foi aprovada?

Uma lista de pessoas com nomes definidos no início do projeto, de ambos os lados. Siga o critério de questionamento eficaz das diretrizes de supervisão: conhecimento técnico adequado, independência para manter a imparcialidade e autoridade organizacional de fato para implementar mudanças. Essa última condição é a que mais costuma faltar e a que dá peso real à validação.

O que acontece se a POC falhar?

O que tiver sido acordado previamente: uma segunda rodada com escopo alterado, teste com outro fornecedor ou cancelamento da compra. Registre os caminhos no documento de critérios em formato de tabela simples (avançar se, prorrogar se, parar se) e defina o tomador de decisão. Um exercício sem caminhos claros de falha acaba não gerando consequência alguma.

Uma POC de agente de risco de IA pode rodar antes de migrarmos de plataforma?

Sim. Um exercício calibrado roda com dados históricos exportados e suas resoluções antigas, dispensando conexões em tempo real com o sistema que será substituído. A atenção deve ir para a base de referência: se os registros das resoluções estão em notas desestruturadas, separe uma amostra com as justificativas manuais ou assuma que rodará um teste cego, ajustando suas expectativas sobre o que será comprovado.

Registre por escrito antes da primeira semana

Tudo nesta página se resume a um hábito essencial. Os limites, a escolha dos dados, os responsáveis pela aprovação e os caminhos em caso de falha devem ser decididos antes do início, caso contrário serão definidos de acordo com o formato dos resultados obtidos. Uma prova de conceito que define seus critérios após a execução não tem como falhar, e um teste que não pode falhar não ensina nada.

Você não depende do fornecedor para estruturar essa etapa. Você pode desenhar a tabela de limites, definir os responsáveis e os caminhos de falha ainda esta semana, apresentar a lista a quem estiver avaliando e verificar se o exercício proposto atende a essas necessidades. Essa postura costuma revelar mais sobre o parceiro do que o próprio teste em si.

Se você prefere ver o agente tratando um alerta real antes de definir seus limites, os agentes de risco da Oscilar rodam uma prova de conceito de uma semana com seus dados históricos, com os critérios definidos primeiro.