Na primavera de 2024, um gerente de operações de um 3PL nos arredores de Dallas assinou um contrato para um sistema de inventário com IA baseado em drones. A demonstração havia sido espetacular: um drone deslizando sobre as estantes, relatórios de divergência gerados automaticamente. Ele assinou uma assinatura anual. Então a realidade chegou. O armazém rodava num WMS com uma década de idade, e a interface de dados personalizada de que a TI precisava já estava na fila há dois trimestres. A "precisão de reconhecimento" do contrato havia sido medida no próprio conjunto de testes do fornecedor — ninguém a tinha testado numa zona mista de paletes e caixas soltas. Um ano inteiro de mensalidades foi pago antes que o sistema se conectasse a uma única fonte de dados.
A tecnologia estava bem. O dono, não.
Já vi esse filme do outro lado também. Um projeto liderado pela TI, um sistema de IA de visão para inspeção no recebimento num armazém de médio porte. O diretor de TI fez tudo conforme o manual: chamou três fornecedores, comparou especificações de precisão, latência e protocolos de API, escolheu o que tinha os melhores números de laboratório. O que ele nunca fez foi percorrer a doca de recebimento com a equipe. Num armazém de verdade, a iluminação das estantes ofusca, as etiquetas são coladas tortas e o filme stretch reflete a luz. Nada disso aparece numa ficha técnica. Na primeira semana, os falsos positivos dobraram o tempo de verificação da equipe. O líder de recebimento me disse sem rodeios que a pistola de leitura era mais rápida. Em alguns meses, o turno da noite tinha parado de ligar o sistema.
Esta é a verdade incômoda sobre IA no armazém: a parte difícil nunca foi o modelo. São três perguntas — de onde vêm os dados, quem define o que conta como "correto" e quem responde pelo resultado. A TI não consegue responder as três sozinha. A operação não consegue responder as três sozinha. Um relatório da RAND publicado em 2024, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed", constatou que mais de 80 por cento dos projetos de IA não entregam o valor esperado, e as raízes geralmente estão na organização e nos dados, não nos algoritmos.
Até a Amazon, que pode gastar mais que todo mundo, se recusa a deixar o algoritmo fechar o ciclo sozinho. Em junho de 2024 a empresa anunciou o Project P.I. — "private investigator" — um sistema que combina IA generativa e visão computacional em túneis de imagem em vários centros de fulfillment na América do Norte para detectar produtos danificados e cores ou tamanhos errados antes do despacho. O detalhe que importa: os itens sinalizados pelo sistema são revisados por associados da Amazon, que decidem se o produto recebe desconto, é doado ou segue adiante. Humanos tomam a decisão final. Se a Amazon não deixa a máquina tocar o armazém sozinha, um 3PL de 50 pessoas certamente não deveria tentar.
A armadilha liderada pela TI e a armadilha liderada pela operação são a mesma armadilha
Os dois modos de fracasso parecem opostos, mas falham pelo mesmo motivo: um lado do prédio é dono de uma decisão que exige os dois lados.
Quando a TI conduz sozinha, o resultado é um brinquedo tecnológico. A demonstração recebe aplausos; o chão de fábrica contorna. A TI avalia o que consegue medir — precisão em dados limpos, disponibilidade, esforço de integração — e subestima o que decide a adoção: o reflexo no terceiro nível de uma estante, um processo que a equipe realmente siga às 2 da manhã, quem retreina o modelo quando o mix de produtos muda no quarto trimestre.
Quando a operação conduz sozinha, o resultado é um pedido de compra em busca de um projeto. A operação consegue descrever a dor perfeitamente e não consegue avaliar o caminho de entrega. O vendedor do fornecedor é pago para conseguir a assinatura, não para fazer o sistema funcionar — e o comprador liderado pela operação é a pessoa mais fácil de deslumbrar no prédio inteiro com uma demonstração que jamais sobreviverá ao contato com um WMS legado.
A solução que hoje recomendo a cada cliente é um modelo de dupla liderança: um líder de negócio e um líder de tecnologia, pares, compartilhando o resultado. Parece um clichê até você colocar no papel. O líder de negócio é dono de três coisas: definir o problema (contagens cíclicas lentas ou divergência alta — escolha um), comprometer as pessoas e as horas para o trabalho de dados, e aprovar a efetividade. O líder de tecnologia é dono de três coisas diferentes: seleção de fornecedor e arquitetura, integração com o WMS e o hardware, e segurança dos dados. A sobreposição no meio — a tradução — pertence a um papel de analista de negócios que não pode ser pulado.
Esse analista de negócios não é um funcionário de documentação. É alguém que fala as duas línguas: pode passar meia jornada com a equipe de contagem cíclica, voltar, e explicar ao fornecedor em termos técnicos que o terceiro nível de uma estante reflete a luz; pode ouvir o fornecedor dizer que o modelo precisa de milhares de imagens rotuladas e traduzir isso para "a equipe de contagem abre mão de três dias". Promova um supervisor sênior para o papel ou contrate um consultor externo — mas não execute o projeto sem um. Sem um tradutor, as reuniões de TI e operação são dois monólogos. Ou a TI cede a uma demanda de negócio irracional, ou a operação acaba forçada a usar uma ferramenta de que ninguém gosta.
Como conduzir o piloto sem queimar um ano
Monte o piloto enxuto, mas fixo: um analista de negócios, em tempo integral no projeto; um contraparte da TI, meio período está bem, mas tem que ser a mesma pessoa toda semana; dois operadores do chão de fábrica, fixos pela duração, sem rodízio — o jeito mais rápido de corromper um piloto é ficar trocando quem está sendo medido; e um especialista de implementação do fornecedor. Cadência: um standup de trinta minutos toda semana cobrindo apenas três coisas — o que os dados mostraram, o que está bloqueado, o que será testado em seguida — e uma revisão mensal de uma hora sobre a tendência. Minha regra prática: um piloto precisa chegar a um veredito em seis a oito semanas. Vai ou não vai. Pilotos que se arrastam além de três meses quase sempre morrem em silêncio, com o dinheiro e a boa vontade perdidos.
A aceitação é onde eu fico rigoroso. Uma página, duas linhas de assinatura. O líder de negócio assina pela efetividade: duas semanas consecutivas no ambiente real, em turnos reais, atingindo os números de taxa de falhas e falsos alarmes que foram escritos antes do início do projeto. O líder de tecnologia assina pela parte técnica: interfaces estáveis, dados fluindo de volta para o WMS, controles de acesso em vigor. Uma assinatura faltando significa que o projeto não está concluído. E os critérios de aceitação precisam existir antes do kickoff — critérios escritos no dia da aceitação são critérios que o fornecedor sempre vai passar.
O armazém de uma ou duas pessoas também consegue fazer isso
Operadores menores leem tudo isso e pensam: mal temos dois gerentes, de onde tiramos dupla liderança? A resposta é que quanto menor você é, mais leve — mas também mais literal — a estrutura precisa ser.
Resuma a um movimento: fixe o papel de tradutor numa única pessoa nomeada. Escolha o supervisor de armazém menos hostil aos sistemas, ou a pessoa da TI que realmente anda pelo chão de fábrica. Dê a ela um título pela duração do piloto — contraparte de negócio para este projeto de IA — e uma hora protegida por dia. Essa hora importa mais que a licença do software, porque nove em cada dez vezes, projetos de IA morrem de "ninguém no chão cooperou", não de "o modelo estava errado".
Na seleção, resista ao pacote. Comece com exatamente um ponto de dor: divergência de contagem, busca de endereço de armazenagem ou verificação de saída. Quando o fornecedor perguntar se você quer os módulos extras, diga não. Três cláusulas entram no contrato: pagamento atrelado aos resultados do piloto com saída incondicional se o piloto falhar; o trabalho de interface de dados e seu cronograma anexados por escrito; treinamento entregue aos operadores do chão de fábrica, não apenas aos supervisores. E três testes rígidos de aceitação: duas semanas no ambiente em produção, os números acordados antes do kickoff efetivamente atingidos, e — o que mais importa — os operadores ligam o sistema por vontade própria. O sistema mais preciso do mundo não vale nada se a equipe não quiser iniciá-lo.
Este é o exercício que eu faria amanhã. Pegue o projeto de IA que você está executando ou planejando, e escreva uma página: qual problema ele resolve, quais são os critérios de aceitação, e os nomes do líder de negócio e do líder de tecnologia — com duas linhas de assinatura em branco no final. Se você não consegue escrever essa página, ou se as duas linhas só podem levar o mesmo nome, você está olhando para a mesma configuração do equipamento coberto de poeira da minha história de abertura. Mate cedo. É muito mais digno do que queimar primeiro o orçamento.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
