Demo vs. produção: porque morrem os pilotos de IA

Hoje todas as empresas contam a mesma história, pela mesma ordem. Terça-feira: uma demo que faz cair o silêncio na sala — o modelo lê o contrato, redige a resposta, toda a gente vê o futuro. Terceiro trimestre: o piloto está "em pausa". Ninguém foi despedido, nada explodiu; simplesmente deixou de ser real, sem ruído. Quando alguém diz "a IA ainda não está pronta para o nosso negócio", é normalmente para este cadáver que está a apontar.

A posição que aqui defendemos é esta: o modelo quase nunca foi o problema. O piloto morreu no abismo entre uma demo e um sistema em produção — um fosso feito de evals, fallbacks, guardrails, observabilidade e responsabilidade atribuída. Palavras pouco impressionantes. São o produto inteiro.

Porque é que as demos mentem

Uma demo não é uma versão reduzida de um sistema em produção. É um objeto diferente que por acaso se parece com ele, como um cenário de cinema se parece com uma rua.

A demo corre com inputs escolhidos a dedo. O fundador escolhe o contrato, o PDF limpo, a pergunta bem formulada. A produção recebe o fax digitalizado de 2011, o email escrito metade em português e metade em fúria, o CSV com uma coluna que um estagiário renomeou em março.

A demo tem uma barreira humana invisível. Quem a conduz desvia-se dos buracos conhecidos sem sequer dar por isso — reformula o prompt, salta o caso-limite esquisito. Em produção essa pessoa já não está lá, e os buracos são a estrada.

A demo é julgada pela melhor execução; a produção é julgada pela pior. Um sistema que é brilhante 95% do tempo e confiantemente errado nos restantes 5% não é, num fluxo de entrada de encomendas, "95% bom". É uma máquina de fabricar incidentes — a não ser que esses 5% tenham um sítio seguro onde aterrar.

Nada disto torna as demos inúteis. Uma demo responde honestamente a uma pergunta: isto é tecnicamente plausível? O erro está em confundir essa resposta com o projeto. É o primeiro 5% — a parte que não produz absolutamente nenhuma da fiabilidade que a sua equipa de operações vai exigir antes de deixar o sistema tocar em seja o que for de real.

O abismo, item a item

O que está mesmo entre a demo de terça-feira e um sistema em que o seu COO deixa de pensar? Uma checklist que nunca tornou entusiasmante nenhum slide de fornecedor:

Evals. Um golden set de inputs reais com outputs de correção conhecida, executado a cada alteração de prompt, a cada upgrade de modelo, a cada ajuste na retrieval. Sem isso, cada "melhoria" é uma moeda ao ar que não consegue ver. As equipas que saltam os evals só sabem que o sistema regrediu quando um cliente lhes diz.
Fallbacks e degradação. O que acontece quando o modelo esgota o tempo, a API impõe rate limit, a ferramenta falha a meio do plano? Um agente em produção precisa de melhor resposta do que "rebenta". Repetir com backoff, degradar para um caminho mais simples ou falhar ruidosamente para uma fila humana — decidido de propósito, passo a passo.
Guardrails. Outputs restringidos por schema, ações em allow-list, fronteiras rígidas de permissões, limites de custo e de volume. O objetivo não é tornar o modelo mais sensato; é tornar pequeno e sobrevivível o raio de destruição do seu pior output. Determinismo onde o determinismo é barato — já argumentámos noutro sítio que o determinismo é uma funcionalidade, não uma limitação.
Observabilidade. Cada execução com trace: o que entrou, o que foi recuperado, o que o modelo decidiu, em que tocou, quanto custou. Quando algo corre mal — e vai correr — "vamos ver o trace" é uma conversa de cinco minutos. "Vamos tentar reproduzir" é uma semana perdida.
Contratos de dados. O piloto leu três ficheiros de exemplo. A produção lê um fluxo vivo de sistemas que mudam sem lhe pedir licença. Os schemas derivam, campos ficam a null, equipas a montante mudam nomes. Um sistema de IA em produção trata os seus inputs como um contrato a validar, não como uma paisagem sobre a qual se fazem figas.
Responsabilidade. A pergunta que melhor prevê a sobrevivência de um piloto: quem é que recebe o alerta? Se a resposta for "bem, a equipa de inovação mais ou menos…", o sistema já morreu. Alguém tem de ser dono da fila de erros, dos resultados dos evals, da linha de custo mensal — como função, não como passatempo.

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

A engenharia aborrecida é o fosso defensivo

Há uma crença reconfortante de que a próxima geração de modelos vai fechar esta distância — que o GPT-seguinte ou o Claude-seguinte serão tão bons que fallbacks e evals passarão a ser folclore. A qualidade dos modelos continua, de facto, a converter alguns projetos "impossíveis" em possíveis. Mas repare no que não muda: os seus inputs continuam caóticos, os seus sistemas a montante continuam a derivar, o seu compliance continua a precisar de um registo de auditoria, as suas operações continuam a precisar de um dono. Pesos melhores não resolvem nada disso.

É por isso que o abismo é também, discretamente, o fosso defensivo. Qualquer um reproduz a sua demo num fim de semana — os modelos são uma commodity disponível aos seus concorrentes no mesmo URL. O que ninguém reproduz num fim de semana são dezoito meses de casos de eval acumulados, de tratamento de modos de falha e de confiança operacional. Se está a decidir para onde vai o orçamento de IA, isto reenquadra a compra: não está a comprar inteligência, está a comprar fiabilidade à volta da inteligência. (É também por isso que continuamos a dizer aos clientes: não compre IA, compre resultados.)

Como é que isto se vê na prática

Parte disto vê-se melhor nos sistemas que construímos para nós próprios, por isso — descritos com honestidade:

O nosso motor de brandbook-para-website gera websites multi-tenant completos a partir de dados de marca estruturados. A escolha de design interessante é onde a IA não está: os modelos ajudam a produzir e a refinar o conteúdo estruturado a montante, e o caminho de renderização a jusante é determinístico — os mesmos dados à entrada, o mesmo site à saída, sempre. Quando uma página está errada, olhamos para os dados, não para um estado de espírito. Essa separação — criativa onde vive o julgamento, aborrecida onde vive a entrega — é o padrão de travessia do abismo em miniatura, e é assim que abordamos todos os sistemas de IA que entregamos.

As nossas automações internas correm sobre uma espinha dorsal n8n self-hosted — retries, filas, caminhos de falha explícitos — com passos de IA embebidos em workflows que registam cada execução. Quando um passo falha às 3 da manhã, aterra numa fila de erros com contexto, não no silêncio. Nada disto é engenhoso. Tudo isto é a razão pela qual as automações continuam a correr meses depois, que é o único benchmark que interessa em trabalho de automação.

E um arquétipo ilustrativo: imagine uma seguradora de média dimensão a testar IA na receção de emails de sinistros. A demo deslumbra com dez emails escolhidos a dedo. A construção para produção gasta as semanas noutro sítio: um golden set de 300 emails 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 com a exatidão da extração por campo e por semana. A demo levou quatro dias. O abismo levou dez semanas. O sistema sobreviveu ao contacto com a época de renovações de janeiro — que é precisamente o objetivo.

Como atravessá-lo

Se tem um piloto em curso — ou um cadáver que gostaria de ressuscitar — a travessia é assim:

Reduza o âmbito até a fiabilidade ser comportável. Um workflow, totalmente posto em produção, vale mais do que cinco workflows em demo. Estreito e profundo sobrevive; largo e superficial morre.
Escreva o conjunto de evals antes da próxima funcionalidade. Cinquenta casos reais com as respostas certas. Vai parecer lento. É a coisa mais rápida que faz no trimestre inteiro, porque converte discussões em medições.
Desenhe primeiro o caminho de falha. Decida onde aterram os maus outputs — fila humana, rejeição, rollback — antes de os tentar melhorar. Um sítio seguro para falhar é o que lhe permite lançar a 90% em vez de esperar eternamente pelos 100%.
Dê um nome ao dono. Uma pessoa, fila de erros, resultado dos evals, linha de custo. Se ninguém quiser o pager, a organização acabou de lhe dizer algo importante sobre o projeto.
Só então expanda. O segundo workflow reaproveita a espinha dorsal — o tracing, os gates, o harness de evals — e é por isso que custa metade. Esta capitalização é o que significa na prática um ecossistema de sistemas; os padrões de orquestração que sobrevivem à produção são um tema à parte, e escrevemos sobre ele em Um orquestrador, muitas mãos.

O resumo incómodo

A maioria dos pilotos de IA morre porque toda a gente envolvida estava a otimizar para o momento em que a sala fica em silêncio — o fornecedor que vende a demo, o campeão interno que a apresenta, o executivo que a aprova. A produção não tem momentos desses. É a ausência de momentos: faturas lançadas, sinistros triados, ninguém a falar de IA. É esse silêncio que está realmente a tentar comprar.

Se tem um piloto que impressionou toda a gente e não entregou nada, a solução raramente é um modelo melhor — é a lista aborrecida aqui em cima, aplicada a um workflow, com um nome associado. Se quiser ajuda para levar um workflow real até ao outro lado do abismo — ou uma leitura honesta sobre se vale sequer a pena atravessá-lo — fale connosco. Dizemos-lhe as partes aborrecidas logo à partida.