Em 2022, eu estava num armazém 3PL em Ontario vendo um fornecedor rodar um POC de contagem cíclica baseada em visão. No local, a demo atingiu 98,6% de acurácia — escanearam um rack, os números na tela batiam. O gerente do armazém queria assinar na hora. O contrato só dizia "payment due upon acceptance". Três meses depois o sistema entrou em produção, e nos racks reais a acurácia caiu para 84%. Caixas com filme retrátil refletivo nos níveis altos? Metade irreconhecível. O gerente me perguntou o que fazer. Eu disse que o contrato nunca definiu como a aceitação seria medida, então numa disputa ele não recuperaria um centavo. Em projetos de IA, oito em cada dez minas estão enterradas no contrato.
Antes de o dinheiro sair, crave a régua de medição
Um POC não é uma demo — é onde você define a régua. São três réguas, e as três precisam estar escritas num anexo do contrato antes de assinar. Sem exceções.
Régua um: métricas de eficácia. Responde a "acerta?". Não escreva só "accuracy" — defina o numerador e o denominador. Para contagem por visão, algo assim: "500 SKUs do conjunto de teste, escaneados em racks reais por 5 dias consecutivos, acurácia de reconhecimento ≥97% (um acerto válido exige SKU e quantidade corretos)". As métricas de eficácia também precisam de um orçamento de erros: quais erros são toleráveis (caixas danificadas) e quais são de tolerância zero (SKUs de alto valor — um erro conta como falha).
Régua dois: métricas de engenharia. Responde a "roda de forma confiável?". Três números são os mais importantes: disponibilidade (uptime ≥99% por 30 dias consecutivos, excluindo janelas de manutenção programada), latência (resposta de um reconhecimento ≤2 segundos no percentil 95) e taxa de falsos positivos (≤1%; cada falso positivo desconta pontos da nota de aceitação). Muitos fornecedores fazem a demo na velocidade da luz e caem no momento em que a rede tropeça. Se as métricas de engenharia não estiverem no contrato, você só vai assistir o sistema cair três vezes por semana sem recurso algum.
Régua três: métricas de negócio. Responde a "vale o dinheiro?". No fim do POC você precisa produzir dois números: horas de mão de obra economizadas (ex.: o tempo de contagem cíclica por pessoa-dia cai de 6 horas para 1,5, em média sobre 10 ciclos de contagem) e um portão de ROI (o contrato estabelece: se a economia anualizada de mão de obra < 1,5× o custo total do projeto, o cliente pode desistir da compra sem penalidade). A métrica de negócio é a linha de fundo do chefe — e sua licença para matar um projeto ruim.
Os três truques favoritos dos fornecedores
Primeiro: eles só testam o caminho feliz. O rack da demo tem caixas padrão, iluminação perfeita, códigos de barras de frente. Exija isto: o conjunto de teste é você quem monta, amostrado dos SKUs que realmente giram no seu armazém — caixas danificadas, filme refletivo, pilhas tortas, tudo incluído. O contrato deve dizer que o conjunto de teste é fornecido pelo cliente e que o fornecedor não pode ver as amostras específicas com antecedência.
Segundo: contaminação do conjunto de teste. O fornecedor ajusta o modelo nos seus dados de teste antecipadamente, então claro que tira nota alta. A defesa: prepare dois conjuntos de teste. Um é revelado na assinatura para ajuste; o outro fica lacrado e só é revelado no dia da aceitação. Escreva assim: "A aceitação usa um conjunto de teste cego, lacrado pelo cliente, que o fornecedor nunca viu".
Terceiro: os dados de aceitação não correspondem ao seu ambiente real. O POC rodou lindo no Prédio 1, mas você vai implantar no Prédio 5 — iluminação diferente, alturas de rack, mix de SKUs. O contrato precisa dizer "ambiente de aceitação = ambiente final de implantação", ou no mínimo "a aceitação é conduzida em duas ou mais zonas designadas pelo cliente".
O manual de aceitação: quem testa, quanto tempo dura, quem ganha uma discussão
Cada métrica do contrato segue o mesmo modelo em cinco partes: linha de base (o que o trabalho manual ou o sistema atual alcança hoje), valor-alvo (específico com uma casa decimal), método de medição (quem fornece os dados, com que ferramentas se mede), janela de medição (quantos dias consecutivos, quantas rodadas por dia) e a regra de aprovado/reprovado (a barra, a política de reteste, quantas falhas contam como um POC fracassado). Se faltar uma das cinco, a aceitação vira briga de grito.
Este é o manual que costumo usar: os testes são liderados pelo cliente com apoio do fornecedor, e as exportações do WMS são o sistema de registro para dados de terceiros. A janela de medição dura 14 dias consecutivos, pelo menos 3 turnos por dia. Qualquer das partes pode contestar um resultado em até 48 horas, o que dispara um reteste; o resultado do reteste é final. Se o reteste continuar falhando, o cliente pode rescindir sem condições e o fornecedor reembolsa as taxas do POC já pagas. Escreva a resolução de disputas como reteste-não-discussão — essa é a cláusula que importa.
Mais uma coisa das trincheiras: os fornecedores aceitam verbalmente as métricas de aceitação na hora de vender, e começam a enrolar quando chega a hora de escrevê-las no anexo do contrato. Minha experiência é simples — quem leva o modelo primeiro tem a vantagem. Prepare uma folha de aceitação em branco com o modelo de cinco partes e mande para eles preencherem. Isso é sair na frente. Se você esperar o fornecedor redigir, cada métrica que te favorece volta como "to be mutually agreed" — quatro palavras que não significam nada.
Esta é a verdade honesta: antes de assinar, você tem toda a vantagem num POC. Depois de assinar, tudo o que você tem é esperança. Amanhã, faça uma coisa: pegue o contrato de qualquer projeto de IA que você esteja negociando e confira se o anexo de aceitação tem as cinco — linha de base, alvo, método de medição, janela de medição, regra de aprovado/reprovado. Se faltar alguma peça, devolva e faça o fornecedor preencher; para o que você não tiver certeza, siga o contrato e a documentação oficial do fornecedor. Esse anexo é a única apólice de seguro real que você terá no projeto inteiro. E uma pergunta que vale a pena fazer com honestidade: se esse sistema sumisse no próximo trimestre, sua operação notaria a diferença? Se a resposta for não, o POC nunca precisou acontecer.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
