Um sistema de compras de 1998 resolveu o problema que hoje trava a aprovação de fornecedores por IA

O problema que Tiffany Masson nomeou

Na semana passada, a psicóloga e consultora Tiffany Masson publicou no LinkedIn um texto que dá nome a uma dor conhecida de quem trabalha com compras: o approval creep. Um fornecedor é aprovado uma vez, com um escopo definido. Depois, ele muda: ganha novas integrações, novos casos de uso, novos dados. A aprovação original não acompanha.

O comentarista Jon W. Hansen, FCIPS, reproduz a formulação de Masson no texto publicado no Procurement Insights em 3 de outubro de 2026 (fonte deste artigo). Segundo ele, é assim que se chega a uma situação em que a quadringentésima transação segue rodando sob a autoridade concedida no primeiro dia.

A ação 4.000 ainda está rodando com a autoridade do primeiro dia.

action 4,000 is still running on day-one authorityTiffany Masson, Psy.D.

Masson propõe três perguntas para toda renovação de contrato ou de acesso:

• O que mudou desde que isso foi aprovado?
• Quem reavalia o escopo no momento da renovação?
• O caso de uso de hoje passaria pela revisão original?

Hansen concorda que essas perguntas são necessárias, mas aponta um limite: toda renovação é só uma fotografia mais recente, não um tipo diferente de controle. Ela fecha a lacuna no dia da revisão, e a lacuna volta a se abrir no dia seguinte. Entre uma renovação e outra, o sistema continua agindo sob uma autorização que ninguém checou contra o que ele está realmente fazendo agora.

A decisão: um sistema de 1998 que recalculava a confiança a cada transação

Para argumentar que existe alternativa, Hansen recorre à própria experiência. Em 1998, com financiamento do programa canadense de Pesquisa Científica e Desenvolvimento Experimental (SR&ED), ele desenvolveu para o Departamento de Defesa Nacional do Canadá um sistema em que, segundo ele, o approval creep não tinha onde se instalar, porque a aprovação nunca foi um evento único.

O mecanismo central, que Hansen chama de Infinity Loopback, reconstruía a posição de cada fornecedor a cada transação, cobrindo todo o ciclo de vida do pedido, não apenas a compra:

Cada resultado dessas três fases realimentava a posição do fornecedor para o próximo pedido. Nada do que um fornecedor fazia depois da primeira compra ficava invisível ao sistema, então não havia intervalo entre a aprovação e a realidade para o creep crescer.

Um detalhe no desenho evita injustiça: um chamado de serviço que não se resolvia só pesava contra o fornecedor quando a causa vinha dele (peça errada, defeito de qualidade). Se o técnico tivesse diagnosticado errado o problema, o fornecedor não era penalizado, porque sua responsabilidade era entregar a peça certa, no lugar certo, na hora certa.

Quem decidia o peso era o comprador, não o algoritmo

Os algoritmos não escolhiam o que importava mais. Hansen descreve que cada comprador podia alterar os pesos conforme a prioridade do pedido: se entrega era o critério principal para uma necessidade específica, os fornecedores se reordenavam de um jeito; se custo fosse a prioridade, de outro. Uma função de supervisão, que ele chamava de train-yard manager, acompanhava o funcionamento geral do sistema.

Ou seja: a evidência se acumulava de forma contínua e automática, mas o critério de julgamento dessa evidência continuava sendo uma decisão humana, revista pedido a pedido.

O resultado contraintuitivo: o mais barato podia ficar em último

A consequência prática, segundo Hansen, surpreendia quem via o sistema pela primeira vez: o fornecedor mais barato podia ranquear em último lugar. Uma vez que histórico de entrega e de qualidade entravam na conta junto com o preço cotado naquele instante, preço baixo isolado deixava de vencer a disputa.

Isso inverte a lógica mais comum em processos de homologação de fornecedor, em que o preço da cotação pesa mais do que o comportamento real ao longo do contrato. No desenho de 1998, o comportamento real era justamente o que definia a posição seguinte.

O que fica para quem avalia IA e fornecedores hoje

Hansen conecta o caso de 1998 ao presente: modelos de IA, suas integrações e seu comportamento operacional também mudam entre uma revisão e outra, exatamente como o escopo de um fornecedor muda entre renovações. Para ele, a autoridade deveria se acumular a partir de evidência, não se erodir a partir de uma assinatura antiga.

Governança acontece todos os dias depois da assinatura.

Governance is every day after the signatureTiffany Masson, Psy.D.

A diferença, resume Hansen, está em uma frase: no exemplo de Masson, a ação 4.000 roda com a autoridade do primeiro dia; no sistema de 1998, a ação 4.000 rodava sobre a evidência acumulada das 3.999 anteriores, ponderada pelas prioridades que o comprador definiu. A pergunta que resta, segundo ele, é se a assinatura é a última evidência que o sistema olha, ou a primeira.

O que dá para levar para a prática

O modelo descrito por Hansen exige instrumentação pesada: captura de dado em cada etapa do pedido e verificação por terceiro na entrega, algo mais viável em compras recorrentes e de alto volume do que em aquisições pontuais. Para times de compras e de governança de IA, o recorte prático que o caso deixa:

• Trate aprovação e renovação como eventos que fecham uma lacuna temporária, não como controle permanente.
• Separe o que é evidência histórica do que é condição do pedido no momento, e pese as duas.
• Deixe explícito quem define a prioridade (custo, prazo, qualidade) a cada reavaliação, em vez de deixar isso implícito no processo.
• Audite a causa de uma falha antes de penalizar o fornecedor por ela.

Hansen cita ainda, como registro datado da própria trajetória do método, uma resposta de uma palestra de 2005 sobre por que o fornecedor mais barato podia perder a disputa, um post de 18 de março de 2008 descrevendo a abordagem com sua origem no SR&ED, e uma aplicação mais recente, de 6 de setembro de 2026, do mesmo método de rastreamento a um caso de tráfego. O fio entre os três é o mesmo: autoridade que se prova a cada transação, não autoridade que se presume depois de concedida uma vez.

Fonte: procureinsights.com