A cena se repete em empresa de todo tamanho. A demonstração funciona, a diretoria aprova, o projeto entra no planejamento. Seis meses depois, ele ainda é uma demonstração. Ninguém cancelou; ele só nunca virou operação. Quando alguém pergunta o que aconteceu, a resposta costuma ser vaga, porque não houve um único erro. Houve uma ordem errada de perguntas.
Uma prova de conceito responde se o modelo consegue. Produção depende de outra pergunta: se a operação consegue. Sustentar o agente quando o dado vem sujo, quando o sistema está fora do ar, quando o cliente pergunta o que ninguém previu, quando a pessoa que construiu saiu. A POC não foi desenhada para responder isso, e não deveria ser cobrada por isso. O problema é decidir investir com base só nela.
As cinco causas que se repetem
1. A POC foi otimizada para impressionar, e produção é otimizada para não errar
São objetivos opostos. Para impressionar, escolhe-se o caso mais visual, o exemplo mais bonito, o modelo mais caro. Para não errar, escolhe-se o caso com menor variação, define-se o que o agente não faz, e mede-se a taxa de acerto no pior cenário. Um projeto que nasce no primeiro modo precisa ser refeito para o segundo, e refazer parece regressão para quem aprovou a demonstração.
2. O dado da demonstração era limpo
Toda POC roda com um conjunto de exemplos preparado por quem a construiu. Produção roda com o cliente que escreve tudo em maiúscula, com o pedido que tem dois itens em vez de um, com o campo do CRM que está vazio desde 2023. A taxa de acerto da demonstração não se transfere, e a diferença só aparece quando já existe usuário real reclamando.
3. Depois da demonstração, ninguém é dono
A POC tem dono: a pessoa que a construiu. Produção precisa de dono do processo, dono do dado, dono da integração e dono da operação depois do go-live. Quando o projeto sai da demonstração, essas quatro responsabilidades costumam ficar sem nome, e o que não tem nome não avança.
4. A integração ficou para depois
Na POC o agente responde com dado copiado numa planilha. Em produção ele precisa ler o ERP de verdade, escrever no CRM de verdade e falar pelo canal oficial. É aqui que a maioria dos cronogramas estoura, e não é pelo agente: é pelo acesso ao sistema legado sem API, pela credencial que ninguém pode conceder, pela homologação do canal que leva semanas. Nada disso apareceu na demonstração porque a demonstração não precisava.
5. Governança chegou tarde
Segurança, privacidade e auditoria entram na conversa quando o piloto está pronto e a data está marcada. As perguntas que elas fazem (o que sai para o modelo, quem aprovou essa ação, como reconstruir a decisão) exigem mudança de arquitetura, não de configuração. Refazer arquitetura sob pressão de prazo é onde projetos morrem sem ninguém decretar.
Nenhuma das cinco é falha técnica do modelo. Todas são consequência de tratar a demonstração como o projeto, quando ela é só a primeira pergunta.
A inversão que resolve a maioria delas
Os projetos que chegam à produção costumam ter feito uma coisa diferente desde o começo: começaram pelo processo, não pela demonstração. Na prática isso muda cinco decisões.
- Escolher o caso pelo processo, não pelo efeito. O melhor primeiro caso é o que tem volume, dono claro, dado acessível e uma métrica que já existe. Raramente é o mais impressionante.
- Definir a métrica antes de construir. Taxa de resolução sem transbordo, tempo até a primeira resposta, conversão de uma etapa. Se a métrica não existe hoje, o primeiro trabalho é medi-la, porque sem linha de base nenhum resultado é demonstrável.
- Integrar primeiro, refinar depois. Um agente simples ligado ao sistema real vale mais que um agente sofisticado ligado a uma planilha. A integração é onde o risco mora; enfrentá-la cedo é o que torna o resto previsível.
- Governança no desenho, não na revisão. Decidir desde o primeiro dia o que sai para o modelo, onde entra aprovação humana e o que fica registrado. Feito no começo, custa horas. Feito no fim, custa o projeto.
- Dar nome aos donos antes do go-live. Quem responde pelo processo, pelo dado, pela integração e pela operação. Se uma das quatro não tem nome, o projeto não está pronto para subir, por melhor que seja o agente.
Sinais de que o seu projeto está no caminho errado
- A demonstração já aconteceu e ninguém consegue dizer qual número do negócio ela vai mover.
- O acesso ao sistema principal ainda não foi pedido, e o projeto está "quase pronto".
- A pessoa que construiu é a única que sabe como funciona.
- A conversa com segurança e privacidade está marcada para "depois do piloto".
- O plano prevê data de lançamento, mas não prevê quem acompanha o agente na semana seguinte.
Três desses cinco sinais juntos costumam ser suficientes para prever o desfecho, com meses de antecedência.
O que produção exige, e a POC não mostra
| Dimensão | Na POC | Em produção |
|---|---|---|
| Dado | Preparado, limpo, conhecido. | Real, incompleto, em formato que ninguém previu. |
| Integração | Planilha ou simulação. | ERP, CRM e canal oficial, com credencial e homologação. |
| Erro | Refaz e mostra de novo. | Cliente afetado, trilha para explicar, correção sem parar a operação. |
| Quem sustenta | Quem construiu. | Time de operação, que precisa entender sem ter construído. |
| Custo | Irrelevante. | Por caso resolvido, comparado com o processo anterior. |
| Governança | Não foi perguntada. | Condição de entrada. |
Por que a Runflow trabalha assim
O modelo da Runflow existe por causa desta lista. A plataforma resolve a parte de criar, operar e mensurar; os engenheiros Forward Deployed resolvem a parte que a plataforma sozinha não resolve, que é a ordem das perguntas. Eles entram na descoberta, escolhem o caso pelo processo, integram com o que já existe, sobem para produção junto do seu time e ficam depois do go-live. Quem vai operar o agente é treinado durante o go-live, e não num handoff no fim.
O diagnóstico gratuito é o primeiro passo desse caminho: olhamos o processo que você tem hoje, com o dado real, e dizemos com franqueza se o caso pede um agente e por onde começar. Quando a resposta é que a ferramenta que você já usa resolve, nós dizemos.
Perguntas frequentes
Por que tantos projetos de IA generativa não saem da POC?
Porque a prova de conceito responde se o modelo consegue, e produção depende de outra pergunta: se a operação consegue. As cinco causas mais frequentes são a POC otimizada para impressionar e não para evitar erro, o dado da demonstração ser limpo e o de produção não, a ausência de donos depois da demonstração, a integração com os sistemas reais ter ficado para depois, e a governança de segurança e privacidade chegar quando o piloto já está pronto.
Como escolher o primeiro caso de uso de IA para ir para produção?
Pelo processo, não pelo efeito. O melhor primeiro caso tem volume, dono claro, dado acessível e uma métrica que já existe. Raramente é o mais impressionante em demonstração. Se a métrica não existe hoje, o primeiro trabalho é medi-la, porque sem linha de base nenhum resultado será demonstrável depois.
Quais sinais indicam que um projeto de IA vai morrer na POC?
Ninguém sabe qual número do negócio a demonstração vai mover; o acesso ao sistema principal ainda não foi pedido; só a pessoa que construiu sabe como funciona; a conversa com segurança e privacidade está marcada para depois do piloto; e o plano tem data de lançamento mas não tem quem acompanha o agente na semana seguinte. Três desses cinco juntos costumam prever o desfecho.
O que produção de IA exige que a POC não mostra?
Dado real e incompleto em vez de dado preparado; integração com ERP, CRM e canal oficial em vez de planilha; tratamento de erro com cliente afetado e trilha para explicar; um time de operação que sustenta sem ter construído; custo medido por caso resolvido; e governança como condição de entrada, não como revisão posterior.
O que é um engenheiro Forward Deployed em projeto de IA?
É o engenheiro que trabalha dentro da operação do cliente, do levantamento do processo ao go-live e depois dele, construindo o agente junto do time que vai operá-lo. O modelo existe para resolver a ordem das perguntas: escolher o caso pelo processo, integrar com o que já existe antes de refinar, colocar governança no desenho e treinar quem opera durante a implantação, e não num handoff no fim.