Por que pilotos de IA falham

A resposta curta

A maioria dos pilotos de IA não falha. Eles têm sucesso, nos termos que receberam, e nunca chegam em produção. Esse é um problema diferente e mais frustrante, porque não existe fracasso para apontar nem um momento em que alguém decidiu parar.

A causa quase sempre é que o piloto foi desenhado para ganhar aprovação, não para responder se aquilo rodaria no seu ambiente. São experimentos diferentes, e só um deles te diz alguma coisa.

O limbo do piloto, definido

O estado em que uma prova de conceito comprovadamente funciona, todo mundo concorda que foi valiosa, e ela não sai do lugar há dois trimestres. Não foi cancelada. Está num roadmap. Ninguém se dispõe a dizer que morreu.

O sinal é a conversa ter migrado do que aquilo faz para o que seria preciso. Essa migração significa que o trabalho real, a integração e a titularidade, nunca esteve no escopo, e agora está sendo descoberto como um segundo projeto que ninguém orçou.

Motivo um: otimizou para a demo

Um piloto feito para impressionar escolhe as próprias entradas, roda sobre uma fatia curada de dado, e é apresentado por quem o construiu. Cada uma dessas escolhas remove justamente aquilo que a produção vai testar.

O resultado é um sistema que nunca viu registro malformado, fronteira de permissão, requisição concorrente ou usuário que escreve mal. Não é que o piloto mentiu. É que ele respondeu uma pergunta que ninguém precisava ver respondida.

Motivo dois: sem dono depois da demo

O time do piloto se dispersa. O patrocinador interno vai para a próxima iniciativa. Os engenheiros que construíram eram externos, ou emprestados de um time com roadmap próprio.

Produção exige alguém cujo trabalho é manter aquilo funcionando. Se o nome de ninguém está nisso desde o começo, o sucesso do piloto não cria obrigação nenhuma, e organização não adota órfão espontaneamente.

É por isso que tratamos a transferência como parte do trabalho, não como fase no fim. Um sistema que seu time não consegue operar é um sistema que para.

Motivo três: integração estava fora do escopo

Quase todo piloto conecta numa cópia do dado. Produção conecta no sistema de registro, com a auth dele, os rate limits dele, o processo de aprovação de mudança dele e o comportamento não documentado dele.

Essa lacuna costuma ser a maior parte do projeto real, e é invisível numa demo. É também por isso que prazo estimado a partir de piloto erra por um fator que surpreende todo mundo. Abrimos essa conta em quanto custa um agente de IA.

Motivo quatro: ninguém definiu sucesso

Se o objetivo do piloto era mostrar que IA poderia ajudar, ele vai ter sucesso, porque isso é praticamente infalsificável. Aí ninguém consegue dizer se aquilo mereceu produção, porque não havia limiar.

Um piloto precisa de um número decidido antes de começar e de uma regra para o que acontece de cada lado dele. Sem isso, a decisão de ir para produção vira política em vez de baseada em evidência, e decisão política empaca. O lado de medição disso é evals de LLM.

Motivo cinco: o dado não era de produção

Piloto roda sobre exportação: limpa, completa, estática, sem permissão. Dado de produção é vivo, parcial, contraditório e governado.

Sistema ajustado no primeiro degrada imediatamente no segundo. A falha parece problema de qualidade, é diagnosticada como problema de modelo, e é um problema de realidade do dado que foi desenhado para fora do experimento lá no começo.

O que um piloto deveria produzir

Três coisas, e uma demo funcionando não é nenhuma delas. Um sim ou não sobre a decisão valer a automação, medido contra o número que você definiu. Um plano de integração baseado em sistemas nos quais você de fato conectou, não nos que você supôs. E um preço de produção com prazo.

Se um piloto não consegue te dizer quanto custaria produção, não era piloto. Era exploração paga, que é uma coisa legítima de comprar, mas você deveria saber qual das duas comprou.

Como rodar um que atravessa

Restrinja a uma decisão, não a um tour de capacidades. Conecte em pelo menos um sistema real, mesmo com escopo estreito, porque é ali que mora o risco de cronograma. Use dado com formato de produção e permissão real. Nomeie quem será dono em produção antes de começar. Escreva o número de sucesso e a regra de encerramento.

E ponha prazo. Quatro a seis semanas bastam para responder a pergunta, e mais que isso normalmente significa que a pergunta nunca foi afiada. É assim que rodamos discovery, e termina com plano de produção e preço em vez de demo. É o mesmo raciocínio de construir ou comprar e de como construímos IA em produção, ponta a ponta.