Agente de IA de crédito muda só o harness: o gate aprovou 144 de 7449 alterações

Um agente LLM autodidata em um pipeline de crédito consegue se adaptar a uma nova interpretação das regras. Mas, se ele reescreve a si mesmo, o órgão supervisor perde aquilo que precisa verificar: uma alteração nomeada, um teste registrado e uma assinatura de aprovação. Os autores de um novo trabalho no arXiv propõem uma restrição rígida. Só o harness do agente pode evoluir, e os pesos do modelo ficam congelados. Na simulação, de 7449 edições candidatas, o gate de admissão aprovou 144, e nenhuma piorou o erro no histórico retido (holdout). A versão de controle, com a verificação que um sistema irrestrito aplicaria, deixou passar 309 alterações prejudiciais.

O que exatamente pode ser alterado

O harness, no artigo, tem três camadas: o texto das instruções, a lógica de chamada de ferramentas e a composição de primitivas. Todo o resto é intocável. A ideia é que qualquer adaptação vire um diff com motivo e teste associado. O revisor não precisa analisar o comportamento do modelo: ele lê uma edição concreta.

Um motor de dois ciclos foi construído sobre essa restrição. Todos os candidatos passam por um único gate de admissão, que grava um registro em cadeia de hashes antes do deploy. Não é possível alterar o registro retroativamente sem quebrar a cadeia. Para o auditor, isso é um rastro pronto: o que mudou, por quê e com base em qual teste a alteração foi aprovada.

O que a simulação mostrou

A principal ressalva: o gate foi medido em um agente simulado, e as edições foram propostas não por um modelo de linguagem, mas por uma busca com semente fixa. Trata-se de um teste do mecanismo de admissão, não do comportamento de LLMs reais. O desenho do experimento: três famílias de reinterpretação supervisória das regras, três níveis de severidade e 10 execuções por célula, ou seja, 90 execuções por configuração.

• O gate aprovou 144 de 7449 alterações candidatas.
• Nenhuma das edições aprovadas piorou o erro no histórico retido (holdout).
• Em todas as células de severidade baixa e média, a taxa de falsos positivos voltou ao nível do oráculo, sem aumento de flags perdidos.
• Ao trocar o gate por uma verificação convencional ("menos erros em traces recentes"), 309 alterações prejudiciais foram aprovadas.
• Nesse modo, os flags perdidos passaram de 10% em 49 das 90 execuções.

O último ponto mostra a mecânica da falha. Os falsos positivos nesse sistema caíram não porque o agente ficou mais preciso. Ele simplesmente afrouxou o filtro, e os erros em traces recentes diminuíram ao custo de casos problemáticos que passaram despercebidos.

Há também um resultado pouco óbvio. Se os candidatos forem avaliados com a rotulagem anterior à mudança, o gate rejeita todos. A nova interpretação das regras precisa ser codificada como uma regra que reclassifica o histórico. Caso contrário, a verificação compara o agente com uma verdade desatualizada e bloqueia edições corretas.

Onde o gate encontra seu teto

O agente corrigiu localmente os desvios paramétricos e os de escopo de aplicação. O desvio estrutural só foi resolvido com a substituição de uma primitiva. No nível mais alto de severidade estrutural, a tolerância fixa do gate bloqueou a substituição correta em metade das execuções. A conservadorismo que protege contra edições prejudiciais aqui custa as úteis. Pelo visto, a tolerância precisará ser ajustada separadamente para mudanças estruturais.

Os autores também relacionam os mecanismos aos requisitos do EU AI Act para scoring de crédito de alto risco. Eles observam ainda que as diretrizes americanas de gestão de risco de modelos, de abril de 2026, excluem a IA agêntica de seu escopo. O arcabouço regulatório para esses sistemas nos EUA continua vazio, e a auditabilidade precisa ser construída pelas próprias empresas.

Como aplicar isso na prática

A equipe que implanta agentes em scoring ou compliance deve definir de antemão a fronteira do que é mutável: instruções, ferramentas e composição de primitivas no repositório, com os pesos fora da zona de edição. Cada alteração deve ter motivo, teste e registro em um log imutável antes do rollout. O critério de admissão deve ser calculado sobre o histórico reclassificado pela nova regra, com monitoramento separado dos flags perdidos, e não apenas dos falsos positivos.

A tolerância para a substituição de primitivas precisa ser calibrada à parte, e convém combinar antecipadamente quem decide quando o gate bloqueia uma edição correta. Os resultados vêm de uma simulação, portanto, antes de ir para produção, é necessário um teste com propostas de LLMs reais.