A diferença entre um piloto bonito e um sistema que fica

A sala aplaude. O deck é elegante. O agente processa o pedido de teste em segundos, sem erros, sem hesitação. Três semanas depois a equipe de TI vai homologar. Seis meses depois o projeto está em pausa. Esse ciclo se repete em empresas de setores diferentes, com tecnologias diferentes, com equipes que conhecem o que estão fazendo. A maioria dos pilotos de IA que chegam à demo nunca chegam à produção, e os que chegam frequentemente morrem nos primeiros trimestres. O que separa esses dois destinos raramente é a qualidade do modelo. É tudo o que vem depois do modelo.

Por que a maioria dos pilotos de IA não sobrevive à demo

Segundo relatórios publicados pela McKinsey e pela Deloitte nos últimos anos, a proporção de projetos de inteligência artificial que não chegam à produção em escala é expressiva. Os números variam por setor e metodologia, mas a direção é consistente: a maioria das provas de conceito corporativas não se converte em sistemas operacionais reais. A causa raramente é técnica no sentido estrito. O modelo funcionou. O prompt funcionou. Os dados de teste estavam limpos. O problema começa quando o contexto muda: dados reais são ruidosos, usuários reais fazem perguntas fora do script, sistemas legados não cooperam da forma que o sandbox simulou.

A demo é uma condição controlada. Produção é o oposto disso. Em produção, os dados chegam mal formatados, os endpoints do ERP retornam erros intermitentes, e o usuário que deveria aprovar o fluxo está de férias. Um piloto bonito foi construído para apresentação. Um sistema que fica foi construído para esse caos.

Um piloto bonito foi construído para apresentação. Um sistema que fica foi construído para o caos do mundo real.

O que tecnicamente diferencia um protótipo de um sistema de produção

A diferença começa na forma como o sistema trata o erro. Um protótipo pode não tratar o erro de forma alguma: se a chamada à API falha, o agente para. Se o dado chega fora do formato esperado, o fluxo quebra. Isso é aceitável numa demo com dados controlados. Em produção, é inaceitável. Um sistema real precisa de retry com backoff, fallbacks explícitos, alertas quando a confiança do modelo cai abaixo de um limiar definido, e um mecanismo claro para escalar para revisão humana quando o agente não tem certeza suficiente para decidir sozinho.

Observabilidade é outro divisor fundamental. Num protótipo, o desenvolvedor monitora o terminal. Num sistema de produção, nenhum desenvolvedor olha o terminal às três da manhã de domingo. O sistema precisa logar o que fez, por quê, com qual grau de confiança, e o que aconteceu com a saída. Sem isso, quando algo der errado, a equipe não saberá onde procurar. E algo sempre dá errado.

Os pontos de ruptura mais comuns na transição para operação real

Existem três lugares onde os projetos de IA morrem com mais frequência na passagem do piloto para a operação. O primeiro é qualidade de dados. O dataset usado no piloto foi curado por alguém da equipe que conhecia as exceções e limpou os casos estranhos antes de rodar o modelo. Em produção, esses casos estranhos chegam todos os dias, sem aviso, sem curadoria. O sistema que não foi construído para lidar com eles trava ou, pior, produz respostas erradas em silêncio.

O segundo ponto de ruptura é a integração com sistemas legados. Aqui a teoria encontra a realidade de forma bastante direta. APIs de ERP que na documentação retornam JSON bem estruturado, na prática retornam XML com encoding inesperado, timeouts intermitentes e campos que deveriam ser obrigatórios mas às vezes chegam vazios. Um piloto conectado a um mock dessa API funciona perfeitamente. O sistema de produção conectado ao ERP real enfrenta um universo diferente.

O terceiro ponto é adoção humana. Um agente de IA em produção quase sempre muda o trabalho de alguém. Se esse alguém não entende o que o agente faz, não confia na saída e não tem como auditar a decisão, vai contornar o sistema. Um sistema que as pessoas contornam não está operando. Está em purgação, consumindo recursos sem gerar valor, esperando ser descontinuado.

Um sistema que as pessoas contornam não está em produção. Está em purgação, esperando ser descontinuado.

Governança e monitoramento: o que sustenta um sistema ao longo do tempo

Sistemas de IA em produção degradam. Isso não é defeito de design: é uma propriedade do ambiente. Os dados mudam, os padrões mudam, os processos que o agente aprendeu a navegar evoluem. Um sistema construído sem monitoramento ativo vai degradar em silêncio, produzindo respostas progressivamente piores sem que ninguém perceba até que o dano já seja grande.

Governança real significa definir, antes do deploy, quais métricas indicam que o sistema está saudável, quais limiares disparam revisão humana, quem é responsável por essa revisão e com qual frequência o sistema inteiro será auditado. Significa também ter um processo documentado para quando o modelo precisar ser atualizado. Esses são elementos de engenharia, não de política corporativa. E precisam estar prontos no dia um, não adicionados depois que o primeiro problema aparecer.

Integração com ERP: onde os projetos de IA costumam morrer

A integração com sistemas de gestão empresarial, como o Protheus da TOTVS, é onde uma proporção desproporcional de projetos de IA corporativa falha. O motivo é estrutural: esses sistemas foram construídos ao longo de décadas, com lógicas de negócio complexas, regras de validação implícitas e comportamentos que só um especialista com anos de experiência conhece. Um agente que não foi treinado com esse conhecimento vai cometer erros que um analista experiente nunca cometeria, e vai cometê-los de formas que não aparecem num teste com dados sintéticos.

Num projeto de automação de compras em mineração que operamos sob NDA, o resultado de construir essa integração com profundidade foi a redução do tempo de processamento por pedido de 30 para 5 minutos, com zero erros de entrada no ERP ao longo de toda a operação. Esse resultado não veio do modelo de linguagem em si. Veio de meses mapeando as regras do Protheus, os casos de borda, os campos que o sistema aceita mas valida de forma não documentada. A IA era o executor. O conhecimento operacional era a fundação.

Como saber se uma prova de conceito está pronta para produção

Existem perguntas que, respondidas honestamente, indicam se um piloto está pronto para virar sistema. A primeira: o sistema foi testado com dados reais, não curados, incluindo os casos malformados e as exceções que o processo gera na prática? A segunda: existe um mecanismo de fallback para quando o agente não tem confiança suficiente para decidir sozinho? A terceira: alguém fora da equipe de desenvolvimento consegue entender o que o sistema fez e por quê, só lendo os logs?

A quarta pergunta é a mais reveladora: quem é responsável pelo sistema quando der errado às três da manhã de domingo? Se a resposta for 'ninguém ainda', o sistema não está pronto para produção. Responsabilidade operacional não é burocracia: é o que transforma um experimento em infraestrutura.

O que separa quem entrega de quem fica na apresentação

A diferença entre organizações que têm IA em produção funcionando e organizações que têm pilotos bonitos é, fundamentalmente, uma diferença de escopo do que se considera entrega. Para quem fica no piloto, entrega é a demo que funciona. Para quem chega à produção, entrega é o sistema rodando sem supervisão constante, integrado, monitorado, com usuários reais que confiam na saída.

Na nossa fábrica de agentes, o trabalho de build começa com as perguntas de produção, não com a demo. Antes de escrever a primeira linha de código de agente, mapeamos onde o sistema vai falhar, quais integrações vão ser difíceis, quem vai usar o sistema e o que vai fazer com que essa pessoa confie na saída. Isso torna os pilotos menos impressionantes na primeira semana. E mantém os sistemas rodando no sexto mês.

Seis vezes mais capacidade da mesma equipe, como vimos em operações que acompanhamos, não vem de um modelo mais sofisticado. Vem de um sistema que opera continuamente, sem interrupção, sem a supervisão constante que transforma o ganho de produtividade em outro trabalho para alguém. Essa é a diferença entre automação como experimento e automação como infraestrutura operacional.

IA em produção não é o modelo funcionando. É o sistema inteiro, com dados reais, usuários reais e falhas reais, funcionando seis meses depois de você ter parado de olhar para ele.

Quer ler a sua operação a fundo?