Por que 80% das POCs de IA não chegam à produção — e o que muda quando elas chegam

Há um número que circula em conversas internas de praticamente todo CIO no Brasil: 80% das provas de conceito de IA não viram produto. O número exato é menos importante que o padrão. Há uma assimetria gritante entre o entusiasmo das demos e a quantidade de sistemas de IA que de fato estão hoje rodando — com SLA, observabilidade e KPI atrelado a P&L — em empresas brasileiras.

A explicação mais comum é técnica: alucinação, custo, latência, dados ruins. Não é. Em quase todos os casos que vimos de perto, o motivo da POC ter parado é organizacional.

O ciclo de vida de uma POC de IA, na prática

O caminho recorrente é mais ou menos este:

1. Um diretor volta de um evento empolgado com generative AI.
2. Um time interno escolhe um caso "seguro" — geralmente um chatbot interno ou um resumidor de documentos.
3. Em três a seis semanas, há uma demo razoável. Todos elogiam.
4. Surge a pergunta "como integramos isso?". Aparecem segurança, jurídico, dados, infraestrutura.
5. Cada um traz um requisito legítimo que não estava no escopo original.
6. O ROI da POC, calculado sobre o caso "seguro", não cobre o custo de fazer tudo isso direito.
7. O projeto entra num limbo. A demo continua viva no laptop de alguém.

O problema não é nenhum dos passos. É a sequência. POCs de IA são desenhadas para validar a tecnologia, mas o que precisa ser validado é a operação.

"A pergunta certa não é 'isso funciona?'. É 'isso funciona com nossas regras, nosso volume, nossa governança e nossos custos?'"

Os quatro gates que mudamos

Quando assumimos um projeto, definimos quatro gates antes de escrever uma única linha de código de modelo. Eles parecem óbvios escritos. Não são, na pressa de uma demo.

Gate 1 — Contrato de saída com o negócio

Antes da modelagem, definimos com a área dona do processo qual é o KPI primário, o limite aceitável de erro de cada tipo, e qual é o fallback quando o sistema não responde. Sem essa conversa, qualquer número que o modelo produza fica sem contexto.

Gate 2 — Mapa de dados e governança

Quem é dono dos dados de entrada. Onde eles vivem. Que classificação têm. O que pode sair do perímetro. Em projetos brasileiros isso costuma envolver LGPD, mas também políticas internas que ninguém documentou. Essa conversa precisa acontecer com jurídico e segurança antes da POC, não depois.

Gate 3 — Custo unitário no pior cenário

Qual o custo por inferência se o modelo for chamado pelo volume real de pico, não pelo volume da demo. Esse cálculo, sozinho, mata 30% das POCs antes de começarem — o que é ótimo. Os 30% que não passam aqui não vão passar em produção.

Gate 4 — Plano de operação

Quem fica de plantão. Como observamos drift. Quando retreinamos. Como avaliamos qualidade ao longo do tempo. Isso é o que separa um sistema de uma demo, e quase sempre é deixado para "depois".

O que muda quando os gates estão no lugar

POCs que passam pelos quatro gates antes de começar têm uma característica em comum: são mais lentas para começar e muito mais rápidas para chegar a produção. Tipicamente em 6 a 10 semanas, contra os 6 a 9 meses do caminho clássico.

O motivo é prosaico: os bloqueadores que aparecem depois da demo deixam de aparecer. Não há mais "agora precisamos rever com jurídico". Já reviu. Não há mais "como vamos pagar essa conta de inferência". Já calculou.

Há um efeito secundário menos óbvio. Times que passam por esse processo conseguem propor o segundo e o terceiro caso de uso com muito mais confiança. Não estão mais defendendo a tecnologia, estão defendendo o sistema. É um lugar diferente para se argumentar.

Onde isso deixa a POC, então

Não estamos dizendo para abandonar provas de conceito. Estamos dizendo que a POC moderna deveria ser um contrato de produção em escala reduzida, não uma demo. Pequena em volume, completa em todos os outros aspectos: governança, custo, operação, métricas.

É menos divertido de mostrar em slide. É muito mais barato de errar e muito mais fácil de aprovar quando dá certo. E, no fim, é o que separa as 20% das 80%.