Abismo demo-produção: por que pilotos de IA morrem

Hoje toda empresa tem a mesma história, contada na mesma ordem. Terça-feira: uma demo que faz a sala inteira silenciar — o modelo lê o contrato, redige a resposta, todo mundo enxerga o futuro. Terceiro trimestre: o piloto está "pausado". Ninguém foi demitido, nada explodiu; ele só parou discretamente de ser real. Quando alguém diz que "IA ainda não está pronta para o nosso negócio", em geral é para esse cadáver que a pessoa está apontando.

A posição que vamos defender é esta: o modelo quase nunca foi o problema. O piloto morreu no abismo entre uma demo e um sistema em produção — um vão feito de evals, fallbacks, guardrails, observabilidade e ownership. Palavras nada impressionantes. Elas são o produto inteiro.

Por que demos mentem

Uma demo não é uma versão pequena de um sistema em produção. É outro objeto, que por acaso se parece com ele — do mesmo jeito que um cenário de cinema se parece com uma rua.

A demo roda com entradas selecionadas a dedo. O fundador escolhe o contrato, o PDF limpo, a pergunta bem formulada. A produção recebe o fax escaneado de 2011, o e-mail escrito metade em português e metade em fúria, o CSV com uma coluna renomeada por um estagiário em março.

A demo tem um guardrail humano invisível. Quem está conduzindo desvia dos buracos conhecidos sem nem perceber — reformula o prompt, pula o edge case estranho. Em produção essa pessoa não existe, e os buracos são a estrada.

A demo é julgada pela melhor execução; a produção, pela pior. Um sistema brilhante em 95% dos casos e confiantemente errado nos outros 5% não é, para um workflow de entrada de pedidos, "95% bom". É uma máquina de fabricar incidentes — a menos que esses 5% restantes tenham um lugar seguro para cair.

Nada disso torna as demos inúteis. Uma demo responde honestamente a uma pergunta: isso é tecnicamente plausível? O erro é tratar essa resposta como se fosse o projeto. Ela é os primeiros 5% — a parte que não produz absolutamente nada da confiabilidade que seu time de operações vai exigir antes de deixar aquilo encostar em qualquer coisa real.

O abismo, item por item

O que realmente fica entre a demo de terça-feira e um sistema que seu COO para de pensar a respeito? Um checklist que nenhum slide de fornecedor jamais tornou empolgante:

Evals. Um golden set de entradas reais com saídas sabidamente corretas, executado a cada mudança de prompt, cada upgrade de modelo, cada ajuste de retrieval. Sem isso, toda "melhoria" é uma moeda jogada para o alto que você não consegue ver. Times que pulam os evals só descobrem que o sistema regrediu quando um cliente avisa.
Fallbacks e degradação. O que acontece quando o modelo dá timeout, a API aplica rate limit, a ferramenta quebra no meio do plano? Um agente em produção precisa de uma resposta melhor do que "ele estoura". Retry com backoff, degradar para um caminho mais simples ou falhar ruidosamente para uma fila humana — escolhido de propósito, passo a passo.
Guardrails. Saídas restritas por schema, ações em allow list, limites rígidos de permissão, tetos de gasto e de volume. O objetivo não é deixar o modelo mais sábio; é fazer com que o raio de explosão da pior saída dele seja pequeno e sobrevivível. Determinismo onde determinismo é barato — já argumentamos em outro lugar que determinismo é uma feature, não uma limitação.
Observabilidade. Toda execução rastreada: o que entrou, o que foi recuperado, o que o modelo decidiu, no que ele mexeu, quanto custou. Quando algo der errado — e vai — "vamos olhar o trace" é uma conversa de cinco minutos. "Vamos tentar reproduzir" é uma semana perdida.
Contratos de dados. O piloto leu três arquivos de exemplo. A produção lê um fluxo vivo, vindo de sistemas que mudam sem te consultar. Schemas mudam, campos viram null, times upstream renomeiam coisas. Um sistema de IA em produção trata suas entradas como um contrato a validar, não como uma paisagem em que se deposita esperança.
Ownership. A pergunta que mais prevê a sobrevivência de um piloto: quem entra de plantão? Se a resposta é "bom, o time de inovação meio que…", o sistema já morreu. Alguém precisa ser dono da fila de erros, dos scores de eval, da linha de custo mensal — como trabalho, não como hobby.

A demo prova que o modelo consegue fazer o trabalho uma vez. Produção é provar que o sistema faz o trabalho todas as vezes em que ninguém está olhando.

Engenharia chata é o diferencial

Existe uma crença confortável de que a próxima geração de modelos vai fechar esse vão — que o GPT-próximo ou o Claude-próximo será tão bom que fallbacks e evals virarão coisa de museu. A qualidade dos modelos realmente segue convertendo alguns projetos "impossíveis" em possíveis. Mas repare no que ela não muda: suas entradas continuam caóticas, seus sistemas upstream continuam mudando, seu compliance continua precisando de trilha de auditoria, sua operação continua precisando de um dono. Pesos melhores não resolvem nada disso.

É por isso que o abismo é também, silenciosamente, o diferencial competitivo. Qualquer um reproduz sua demo em um fim de semana — os modelos são commodity, disponíveis para seus concorrentes na mesma URL. O que ninguém reproduz em um fim de semana são dezoito meses de casos de eval acumulados, tratamento de modos de falha e confiança operacional. Se você está decidindo para onde vai o orçamento de IA, isso muda o enquadramento da compra: você não está comprando inteligência, está comprando confiabilidade em torno da inteligência. (E é por isso que vivemos dizendo aos clientes: não compre IA, compre resultados.)

Como isso aparece na prática

Algumas coisas ficam mais fáceis de ver nas nossas próprias construções, então — descritas honestamente:

Nosso motor de brandbook para site renderiza sites multi-tenant completos a partir de dados estruturados de marca. A escolha de design interessante é onde a IA não está: modelos ajudam a produzir e refinar o conteúdo estruturado no início da cadeia, e o caminho de renderização no fim é determinístico — mesmos dados na entrada, mesmo site na saída, sempre. Quando uma página sai errada, olhamos para os dados, não para o humor do modelo. Essa divisão — criativo onde mora o julgamento, chato onde mora a entrega — é o padrão de travessia do abismo em miniatura, e é assim que abordamos cada sistema de IA que entregamos.

Nossas automações internas rodam sobre uma espinha dorsal de n8n self-hosted — retries, filas, caminhos explícitos de falha — com passos de IA embutidos em workflows que logam cada execução. Quando um passo falha às 3 da manhã, ele cai numa fila de erro com contexto, não no silêncio. Nada disso é esperto. Tudo isso é o motivo de as automações ainda estarem rodando meses depois, que é o único benchmark que importa em trabalho de automação.

E um arquétipo ilustrativo: imagine uma seguradora de porte médio pilotando triagem de e-mails de sinistro com IA. A demo deslumbra com dez e-mails escolhidos a dedo. A construção em produção gasta as semanas dela em outro lugar: um golden set de 300 e-mails reais, incluindo os horríveis; um validador de schema que rejeita extrações malformadas; um limiar de confiança abaixo do qual um humano vê primeiro; um dashboard mostrando a acurácia de extração por campo por semana. A demo levou quatro dias. O abismo levou dez semanas. O sistema sobreviveu ao contato com a temporada de renovações de janeiro — que é justamente o ponto.

Como atravessar

Se você tem um piloto em andamento — ou um cadáver que gostaria de ressuscitar — a travessia é mais ou menos assim:

Reduza o escopo até a confiabilidade caber no orçamento. Um workflow totalmente em produção vale mais que cinco workflows demonstrados. Estreito e profundo sobrevive; amplo e raso morre.
Escreva o conjunto de evals antes da próxima feature. Cinquenta casos reais com as respostas corretas. Vai parecer lento. É a coisa mais rápida que você vai fazer no trimestre inteiro, porque converte discussões em medições.
Desenhe o caminho de falha primeiro. Decida onde as saídas ruins vão cair — fila humana, rejeição, rollback — antes de tentar melhorar as saídas. Um lugar seguro para falhar é o que permite entregar com 90% em vez de esperar para sempre pelos 100%.
Dê nome ao dono. Uma pessoa, fila de erros, score de eval, linha de custo. Se ninguém quer o plantão, a organização acabou de te contar algo importante sobre o projeto.
Aí sim, e só aí, expanda. O segundo workflow reaproveita a espinha dorsal — o tracing, os gates, o arcabouço de eval — e é por isso que custa metade. Esse efeito composto é o que um ecossistema de sistemas significa na prática; padrões de orquestração que sobrevivem à produção são um tema à parte, e escrevemos sobre isso em Um orquestrador, muitas mãos.

O resumo desconfortável

A maioria dos pilotos de IA morre porque todo mundo envolvido estava otimizando para o momento em que a sala silencia — o fornecedor vendendo a demo, o padrinho interno apresentando, o executivo aprovando. Produção não tem esse momento. Produção é a ausência de momentos: notas lançadas, sinistros triados, ninguém falando sobre a IA. Esse silêncio é o que você está realmente tentando comprar.

Se você tem um piloto que impressionou todo mundo e não entregou nada, a correção raramente é um modelo melhor — é a lista chata acima, aplicada a um workflow, com um nome associado. Se quiser ajuda para atravessar um workflow real pelo abismo — ou uma leitura honesta sobre se vale a pena atravessar — fale com a gente. A gente conta as partes chatas logo de cara.