No outono passado, eu assessorava um armazém 3PL no Inland Empire — cerca de 120,000 pés quadrados — que acabara de implantar um modelo de IA para previsão de reposição. O termo de aceite estava assinado. A equipe do fornecedor saiu na terceira semana. No dia 96, o gerente do armazém me ligou: "Lao Mi, acho que o sistema quebrou. As sugestões de reposição estão ficando mais malucas a cada semana."
Fiz três perguntas. Qual foi a precisão de previsão do modelo na semana passada? Ele não sabia. Para onde vão os e-mails de alerta? Ele foi verificar — e descobriu que continuavam chegando à caixa de correio que a equipe de projeto do fornecedor havia configurado. Essa equipe havia sido desfeita dois meses antes. Os alertas caíam numa caixa de entrada que ninguém abria. Terceira pergunta: quem definiu os limiares de deriva? Silêncio do outro lado da linha.
Não é uma história isolada. Vi vários projetos de IA morrerem assim nos últimos anos — não na seleção, não no desenvolvimento, mas nos três meses após o go-live. Quando você aceita um equipamento, uma empilhadeira não muda de faixa sozinha. A IA é diferente. Ela consome dados novos todo dia, e quando os dados mudam, o modelo muda junto. Sem ninguém vigiando, o "sistema de IA" que você possui três meses depois já não é aquele que você aprovou.
O dia do go-live é o dia mais arriscado do projeto
Aqui vai uma visão contraintuitiva: para um projeto de IA, a assinatura do aceite marca o começo, não o fim.
Os testes de aceite acontecem em condições estáticas. Os dados foram limpos pelo fornecedor de antemão, o conjunto de teste foi selecionado a dedo, e o mix sazonal foi escolhido manualmente. É claro que o fornecedor quer que as métricas do aceite fiquem bonitas — o pagamento final está em jogo. Isso não é desonestidade; é natureza humana.
Mas quando os dados reais começam a fluir, tudo muda. Novos clientes trazem novos padrões de pedido. O mix de SKUs muda. As especificações de embalagem são trocadas. As temporadas de pico e de baixa se alternam. Estes são os "dados sujos" que o modelo nunca viu durante o treinamento. Vi um armazém ir de 92% de precisão de previsão no aceite para 78% dois meses depois. A causa raiz era quase cômica: os dados de treinamento não tinham combinações de SKU da temporada de pico do Q4, então o modelo começou a adivinhar loucamente assim que a temporada de pico chegou.
Meu veredito é direto: os critérios de aceite devem incluir uma cláusula de reteste aos 90 dias. Assine duas vezes — uma no go-live para confirmar que o sistema está funcionando, e outra no dia 90 para confirmar que o modelo ainda se sustenta diante de dados reais. Se falhar no segundo teste, o pagamento final fica na mesa e o fornecedor volta para ajustar. Uma cláusula no contrato supera dez métricas extras no dia do aceite.
Muitos compradores têm medo de pedir isso. Preocupam-se de que o fornecedor entenda como desconfiança. Eu vejo ao contrário: um fornecedor disposto a assinar essa cláusula é um que realmente acredita no seu modelo.
Modelos não morrem de repente. Ficam mais burros devagar.
Esta é a maior diferença entre a operação de IA e a operação tradicional de TI. Uma queda de servidor é repentina — o alarme toca e todo mundo sabe. A deriva do modelo é uma doença crônica. Um pouco pior hoje, um pouco pior amanhã, e três meses depois você percebe que ele se tornou silenciosamente inútil.
A deriva tem dois sabores, em termos simples. Primeiro, os dados mudaram: você expedía 8,000 pedidos por dia, agora são 12,000. O cliente A representava 60% do volume; agora o cliente B domina. O modelo aprendeu os padrões dos dados antigos, e os dados novos não os seguem. Segundo, as relações mudaram: "finais de semana são agitados" costumava ser verdade, depois os clientes mudaram seus hábitos de pedido e os finais de semana esfriaram. Os dados em si parecem iguais, mas o que os dados significam mudou.
O mais assustador não é a deriva em si — é que ninguém está olhando. Naquele armazém do Inland Empire, o sistema enviava alertas havia semanas. As métricas de deriva já estavam acima do limiar. Mas os alertas iam para uma caixa que ninguém lia, o que equivale a não ter alertas. É esse o vácuo operacional de que falo: o sistema está falando e ninguém escuta.
Como preencher? A matriz de responsabilidades precisa ser definida antes do aceite, e precisa nomear pessoas reais — "o cliente é responsável" não conta. Recomendo três camadas.
A operação do armazém acompanha as métricas de negócio diariamente. Ninguém sente a qualidade da previsão mais rápido que a operação — quando as sugestões de reposição não fazem sentido, os separadores reclamam primeiro. Deem-lhes uma regra simples: se as quantidades sugeridas se desviarem da realidade além de uma razão fixa por três dias seguidos, escalem. Não precisa de conhecimento de algoritmos. Basta ler os números.
A TI — ou o fornecedor — acompanha as métricas do modelo semanalmente. Pontuações de deriva, distribuições de features, confiança da predição. Precisa de alguém que saiba o que está olhando. Se você não tem essa pessoa em casa, compre suporte remoto do modelo do fornecedor no contrato; faturamento trimestral está bom. Não economize aqui. Se omitir, as centenas de milhares que você já gastou podem ir pelo ralo.
A gestão revisa a tendência mensalmente. A curva de precisão está subindo ou descendo? Quanto custou o retreinamento e valeu a pena? Trinta minutos bastam, mas a reunião precisa acontecer. Caso contrário, você descobre na revisão trimestral que o modelo está quebrado há três meses. Tarde demais.
Quem define os limiares de deriva? Minha resposta: o fornecedor propõe, o comprador decide. O fornecedor conhece o modelo e o que conta como flutuação normal. O comprador conhece o negócio e qual nível de erro é inaceitável. Definam juntos, escrevam no POP (procedimento operacional padrão) e colem na parede.
Um handover que não está no contrato não aconteceu
Este é o buraco mais fundo em que já caí. Num armazém, num projeto de inspeção de qualidade com IA, o contrato dizia "o fornecedor fornecerá treinamento." Antes do aceite, o fornecedor de fato forneceu treinamento — uma apresentação de duas horas. Três meses depois o modelo deu problema, e o engenheiro de operação nem sabia onde ficava o pipeline de features. De qual tabela vinham os dados, em qual servidor estavam os arquivos do modelo — três perguntas, zero respostas. Ele ligou para o fornecedor. A equipe de projeto havia sumido. Um representante de suporte disse que eles poderiam "abrir um ticket de suporte pago."
Então agora faço os compradores checar item por item de uma lista de handover antes de assinar o aceite. Quatro itens. Faltar um, não assina.
Primeiro, documentação do modelo. Qual é a lista de features, qual versão dos dados de treinamento foi usada, em que premissas a modelagem se baseou — coisas como "assume que o número de SKUs permanece constante" ou "assume que a estrutura de pedidos é estável." Essas premissas são suas futuras linhas de alerta de deriva. No momento em que uma premissa quebra, o modelo precisa de retreinamento. Os documentos não precisam ser elegantes. Precisam ser legíveis.
Segundo, configuração de alertas. Quem recebe os alertas, quem está em cópia, com que frequência são revisados, quem escala. Escreva cada endereço de e-mail, e envie um alerta de teste no dia do aceite para confirmar que chega. Não ria — já vi um projeto em que o endereço de alerta estava escrito errado e ninguém descobriu até depois do go-live.
Terceiro, o processo de retreinamento. Quem dispara o retreinamento, quais são as condições de disparo, quem executa e quem paga. O retreinamento não é grátis — preparação de dados, computação e validação custam dinheiro. Se você não acerta isso de antemão, os dois lados começam a apontar o dedo quando algo quebra. Vi uma disputa se arrastar por quatro meses. O modelo simplesmente ficou ali apodrecendo por quatro meses.
Quarto, o plano de rollback. Quando o modelo se comporta mal, como você volta para o motor de regras antigo com uma única chave? Onde está a chave, quem tem permissão para virá-la, e como o negócio continua funcionando depois da troca? Este é o mais omitido, mas quando as coisas dão errado, é o que salva você.
O contrato precisa de mais duas cláusulas: suporte remoto do fornecedor por 6 a 12 meses após a saída da equipe, com tempos de resposta por escrito; e propriedade dos dados — os dados de treinamento, os arquivos do modelo, o pipeline de features — o comprador recebe uma cópia completa de tudo. O fornecedor pode sair. Os ativos ficam.
Aqui está a conclusão. Um projeto de IA difere da compra de equipamento em algo fundamental: o equipamento é uma entrega única, mas a IA é algo que continua evoluindo. O que você aceita não é uma máquina. É algo vivo que precisa de alimentação contínua. Se o contrato não diz quem alimenta, é só questão de tempo até morrer de fome.
Uma pergunta para deixar você: se seu projeto de IA entrar em go-live amanhã, você consegue nomear a caixa de entrada de quem os e-mails de alerta vão no dia 90 — e quem é responsável por abri-los? Se não, ainda não assine o termo de aceite.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
