Por que seu projeto de IA não saiu do piloto — e como resolver de verdade

Toda semana eu ouço alguma variação da mesma frase. Pode vir de um CTO de banco, de um founder de startup ou de um diretor de tecnologia de uma grande varejista: "A gente fez um piloto incrível, os números eram ótimos, mas o projeto nunca foi pra frente." Às vezes o tom é de frustração. Às vezes, de vergonha. Quase sempre, de confusão genuína sobre o que deu errado.

A realidade é que isso não é exceção — é a regra. Estudos da McKinsey e do Gartner apontam consistentemente que entre 70% e 80% dos projetos de IA não chegam à produção em escala. O piloto funciona. O caso de uso é validado. O entusiasmo existe. E mesmo assim, o projeto morre numa apresentação de PowerPoint ou vive eternamente como "iniciativa estratégica em avaliação".

Depois de mais de vinte anos trabalhando com tecnologia, passando pela IBM e pela AWS e atuando como conselheiro de empresas como BTG, B3, XP e Inter, posso te dizer com clareza: o problema raramente é técnico. O piloto não trava porque o modelo de IA era ruim. Ele trava porque a organização não estava preparada para o que vem depois do piloto.

O piloto foi desenhado para impressionar, não para escalar

O primeiro erro começa antes mesmo de o projeto sair do papel. A maioria dos pilotos de IA é construída com um objetivo implícito: convencer stakeholders. Você escolhe o caso de uso mais favorável, trabalha com dados limpos e preparados manualmente, coloca os melhores engenheiros no projeto e entrega uma demo que funciona perfeitamente em condições controladas.

O problema é que essa abordagem cria uma armadilha. O piloto foi otimizado para a apresentação, não para a operação. Quando chega a hora de levar para produção, você descobre que os dados reais são sujos, que o volume é dez vezes maior, que o sistema legado não tem a API que você assumiu que teria e que a equipe que vai operar isso no dia a dia nunca foi envolvida no projeto.

Vi isso acontecer em instituições financeiras de grande porte. O piloto de IA generativa para atendimento ao cliente tinha 92% de satisfação nos testes. Na produção real, com volume de milhares de interações por hora, latência, integração com sistemas de core banking e treinamento insuficiente da equipe de operações, os números despencaram em semanas.

A pergunta certa não é "esse piloto funcionou?". A pergunta certa é: "esse piloto foi desenhado para revelar o que vai falhar na produção?"

A ausência de dono real é fatal

Projetos de IA têm um problema de governança que projetos de tecnologia tradicional raramente têm na mesma intensidade: eles vivem no meio do caminho entre a área de negócio, a TI e, frequentemente, um time de dados ou inovação que existe numa espécie de limbo organizacional.

Quando o piloto termina e chega a hora de escalar, a pergunta "quem é o dono disso?" não tem uma resposta clara. A área de negócio quer o resultado mas não quer a responsabilidade técnica. O time de TI quer que o projeto siga os padrões de governança mas não participou do desenvolvimento. O time de dados entregou o modelo mas não opera sistemas em produção.

Nesse vácuo, o projeto não avança. Fica circulando em reuniões, acumulando requisitos novos, esperando aprovações que ninguém quer dar porque ninguém quer ser responsabilizado se algo der errado.

A solução é simples de enunciar e difícil de executar: antes de iniciar qualquer piloto, defina quem é o product owner do projeto de IA em produção. Não o sponsor executivo. Não o líder técnico. O dono operacional — a pessoa que vai acordar às 3 da manhã quando o modelo começar a dar respostas erradas e que tem autoridade para tomar decisões.

Infraestrutura e MLOps: o chão que ninguém preparou

Aqui entra a dimensão genuinamente técnica do problema. Treinar um modelo ou usar uma API de IA generativa é relativamente acessível hoje. Operá-lo com confiabilidade, rastreabilidade e capacidade de atualização em produção é uma disciplina completamente diferente.

A maioria das empresas não tem o que se chama de MLOps maduro: pipelines de CI/CD para modelos, monitoramento de drift (quando o comportamento do modelo muda porque os dados do mundo real mudaram), versionamento de modelos, capacidade de rollback rápido, observabilidade de latência e custo por inferência.

Sem essa infraestrutura, o que acontece na prática é que o modelo vai para produção e ninguém sabe quando ele começa a degradar. Ou pior: ele começa a gerar outputs problemáticos — respostas incorretas, enviesadas ou inadequadas — e a empresa só descobre quando um cliente reclama ou quando aparece numa reportagem.

No contexto de AWS, onde trabalhei diretamente com centenas de clientes em jornadas de adoção de IA, os projetos que escalam com sucesso são quase sempre aqueles que investiram em plataforma antes de investir em casos de uso. Eles construíram o alicerce de MLOps, definiram padrões de segurança e compliance para modelos, criaram um catálogo interno de dados e só então aceleraram a produção de soluções.

É contraintuitivo para quem está sob pressão de mostrar resultado rápido. Mas é o único caminho que funciona.

O modelo de negócio do piloto não é o modelo de negócio da produção

Existe um ponto que poucos líderes discutem abertamente: o custo de um piloto de IA e o custo de operar essa mesma solução em produção podem ser completamente diferentes — e o segundo frequentemente surpreende.

Um piloto de IA generativa processando mil documentos por semana para demonstração custa alguns dólares. O mesmo sistema em produção processando um milhão de documentos por semana, com SLA de disponibilidade, auditoria, armazenamento de logs e redundância, pode custar dezenas ou centenas de milhares de dólares por mês. Se o caso de uso não foi validado com esse número real em mente, o ROI que justificou o projeto simplesmente não existe.

Mais do que isso: muitas empresas subestimam o custo humano de operar IA em produção. Você precisa de engenheiros de ML para manter os modelos, analistas de dados para monitorar qualidade, especialistas de negócio para validar outputs periodicamente e, dependendo do caso de uso e do setor regulado, um processo formal de revisão humana para decisões críticas.

A recomendação prática: o business case do piloto precisa incluir o custo total de propriedade em produção, com cenários de volume realistas. Se o ROI só fecha no cenário do piloto, o projeto não deveria sair do piloto.

Mudança organizacional: o elefante na sala

Nenhum projeto de IA escala sem mudar a forma como as pessoas trabalham. E mudar a forma como as pessoas trabalham é infinitamente mais difícil do que treinar um modelo.

Quando uma empresa implementa IA generativa para apoiar analistas de crédito, por exemplo, o processo de decisão muda. O que o analista faz muda. O que ele precisa saber muda. As métricas de performance dele mudam. Se a área de RH, os gestores diretos e o próprio analista não foram envolvidos desde o início, a resistência é natural e legítima.

Nos projetos que acompanhei em instituições financeiras, a diferença entre os que escalaram e os que travaram estava quase sempre aqui. As empresas que foram bem não trataram a IA como um projeto de tecnologia com impacto em pessoas. Trataram como uma transformação de processo com suporte tecnológico. A distinção parece sutil, mas muda radicalmente a abordagem de gestão de mudança, comunicação interna, treinamento e redesenho de funções.

Isso exige que o CTO ou o líder de tecnologia saia do seu domínio de conforto e trabalhe lado a lado com RH, jurídico e as áreas de negócio muito antes de o sistema entrar em produção. É desconfortável. É lento. É absolutamente necessário.

Como sair do ciclo: um roteiro direto

Se você reconhece o seu projeto em algum dos padrões descritos acima, aqui está um caminho objetivo para sair do ciclo:

• Faça um diagnóstico honesto do piloto atual. Mapeie explicitamente o que foi simplificado ou assumido no piloto e que precisará ser resolvido em produção. Dados, integrações, volume, compliance, operação.
• Defina o dono operacional antes de qualquer decisão de escala. Não adianta aprovar budget sem ter a pessoa responsável por operar o sistema claramente identificada e comprometida.
• Invista em MLOps antes de multiplicar casos de uso. Uma plataforma sólida com monitoramento, versionamento e pipelines de atualização vale mais do que cinco pilotos simultâneos.
• Construa o business case com custo total de propriedade. Inclua infraestrutura em escala, equipe de operação, revisão humana quando necessário e ciclos de retraining do modelo.
• Trate gestão de mudança como entregável do projeto, não como atividade paralela. As pessoas que vão usar e operar o sistema precisam ser codesignadoras da solução, não apenas usuárias finais.

Não existe atalho aqui. Mas existe clareza. E clareza, nesse caso, vale muito mais do que entusiasmo.

O momento de agir é agora — com seriedade

A janela de vantagem competitiva da IA está aberta, mas não ficará aberta para sempre. As empresas que estão construindo com seriedade — infraestrutura real, governança real, mudança organizacional real — estão criando um fosso difícil de cruzar.

As que estão acumulando pilotos abandonados estão desperdiçando capital, desgastando equipes e, pior, criando uma cultura de ceticismo interno sobre IA que vai dificultar cada projeto futuro.

A pergunta que eu faço para cada executivo que me procura não é "você quer adotar IA?". Todo mundo quer. A pergunta é: "você está disposto a fazer o que é necessário para que a IA funcione de verdade no seu negócio?" Isso significa investir em plataforma, definir responsabilidades claras, trabalhar a mudança organizacional e ter paciência para construir o alicerce antes de construir os andares.

Se a resposta for sim, o caminho existe. E os resultados — em eficiência operacional, redução de custos e vantagem competitiva — justificam cada passo difícil do percurso.