Razão 1: começou pela ferramenta, não pela decisão
O piloto típico nasce de uma pergunta sobre tecnologia: "o que a gente pode fazer com IA?". É uma pergunta divertida e produz demos bonitas, mas ela não tem critério de parada — qualquer resultado é interessante e nenhum é suficiente.
A pergunta que sustenta um projeto é outra: qual decisão do negócio precisa melhorar, quem toma essa decisão hoje, com que informação, e o que muda se ela melhorar. Sem essa resposta, não existe como saber se o piloto deu certo.
Razão 2: ninguém definiu o que seria sucesso
Um piloto sem número de referência não tem como terminar. Ele fica em "promissor" indefinidamente, porque não existe patamar acordado que autorize alguém a dizer que está bom o bastante para ir ao ar.
O número não precisa ser sofisticado, precisa ser combinado antes: quantos por cento dos casos precisam ser resolvidos sem intervenção humana, qual erro é tolerável, quanto tempo de resposta é aceitável. Definido antes, o piloto vira teste. Definido depois, vira discussão.
Razão 3: o dado não aguentava sair do laboratório
No piloto, alguém exporta uma planilha, limpa à mão e roda o experimento. Funciona. Em produção, o mesmo processo precisa acontecer todo dia, sozinho, com dado que chega sujo, atrasado ou não chega.
É aqui que a maioria dos projetos descobre que o problema nunca foi de IA: era de engenharia de dados. A boa notícia é que isso não exige construir uma plataforma inteira antes de começar — exige construir a base que aquela decisão específica exige, o que é bem menos.
Razão 4: ninguém confiava na resposta
Modelo que responde com segurança algo que não pode justificar não entra em processo sério, e faz bem quem barra. Em contexto empresarial, resposta sem origem rastreável é passivo, não produto.
Isso se resolve no desenho, não na conversa: ancorar a resposta na fonte, de modo que ela venha acompanhada do documento ou registro que a sustenta, e não responder o que não tem base. Onde o processo exige reprodutibilidade, vale usar configuração determinística — mesma entrada, mesma saída, sempre. É o que fazemos no SpecQA para geração de testes, e o princípio vale para qualquer aplicação que precise ser auditada.
O que separa um piloto que vira produto
O caso da J3F é um exemplo de projeto que nasceu do lado certo. A pergunta não era "o que fazemos com IA", era "como aplicamos em escala o conhecimento fiscal que nossos especialistas já têm". Recuperar crédito tributário era trabalho manual, nota fiscal por nota fiscal — inviável com confiabilidade quando o volume chega aos milhares.
A plataforma que construímos processa grandes volumes e aplica automaticamente os parâmetros definidos pelos especialistas deles. Não é software genérico de gestão fiscal: é a expertise da J3F virada processo auditável. O critério de sucesso era óbvio desde o começo, e por isso houve um dia em que ficou claro que o sistema podia entrar em operação.
Depois do deploy o trabalho continua
Modelo em produção degrada, porque o mundo que ele aprendeu muda. Sem medição contínua depois do lançamento, a queda de qualidade só aparece quando alguém reclama — e a essa altura a confiança no sistema já foi embora.
É por isso que tratamos isso como uma etapa própria, e não como suporte: o que está em produção precisa ser monitorado, medido e reajustado. Modelo que não é medido depois do deploy não é produto, é aposta.