Construindo um Roadmap de IA Para a Organização Sem Virar Fábrica de POC

Neste artigo · 9 seções

1. A reunião trimestral onde a sala fica em silêncio
2. Roadmap não é lista de POCs
3. Financie em estágios, como quem abre uma posição
4. Compre o que é commodity, construa o que te diferencia
5. A trajetória é de capability, não de feature
6. Meça resultado de negócio, não vaidade
7. Uma tensão honesta sobre os primeiros pilotos
8. Conclusão
9. Insights & Takeaways

A reunião trimestral onde a sala fica em silêncio

Review de fim de trimestre. O slide está bonito: doze pilotos de IA lançados no semestre, todos marcados como "concluídos com sucesso". Copilot pro time de suporte, um assistente de busca interna, um classificador de tickets, um resumo automático de reuniões, mais oito. A liderança aplaude. Aí alguém de finanças faz a pergunta que ninguém preparou: desses doze, quanto virou resultado de negócio que a gente consegue medir?

Silêncio.

Não é que os pilotos não funcionaram. Tecnicamente, funcionaram. O classificador classifica, o resumo resume. O problema é que nenhum deles está ligado a uma métrica que apareça no P&L, e nenhum deles construiu nada que o próximo piloto possa reaproveitar. São doze ilhas, cada uma com seu provedor, seu prompt, sua métrica de vaidade ("90% de precisão no teste"). Doze demos que envelhecem na velocidade em que o entusiasmo esfria.

Esse padrão tem nome na indústria, e tem número. O relatório The GenAI Divide, da iniciativa MIT NANDA, de agosto de 2025, estimou que cerca de 95% das organizações não obtêm retorno mensurável no P&L com seus pilotos de IA generativa. Só uns 5% chegam a acelerar receita de verdade. A RAND, num estudo de agosto de 2024, foi na mesma direção: mais de 80% dos projetos de IA falham, o dobro da taxa de projetos de TI que não envolvem IA. E o Gartner previu que pelo menos 30% dos projetos de GenAI seriam abandonados depois da prova de conceito até o fim de 2025.

Esse artigo é sobre como não fazer parte desse número. Não é sobre escolher modelo nem sobre arquitetura de serviço, que já tratei em Do Monólito ao AI Mesh. É sobre a camada de cima: como montar um roadmap de IA que é portfólio de apostas conectadas a resultado, e não uma esteira de POCs que nascem pra impressionar e morrem sem deixar herança.

Roadmap não é lista de POCs

A raiz do problema é confundir roadmap com lista de coisas pra construir. Marty Cagan, do Silicon Valley Product Group, bate nessa tecla há anos, e tem um número que conversa diretamente com o do MIT: na maioria das empresas, só 10% a 20% dos itens de um roadmap de features realmente entregam o resultado esperado. O resto é movimento. A defesa dele é simples, e quase ninguém pratica: times maduros recebem problemas e resultados de negócio pra resolver, não uma lista de features pra entregar. Outcome, não output.

Com IA isso fica pior, porque a tecnologia é sedutora. É fácil dizer "vamos colocar um agente aqui" sem nunca perguntar que problema ele resolve e como você vai saber que resolveu. A "fábrica de POC" é o estado natural pra onde um roadmap de IA desliza quando ninguém impõe a disciplina de ligar cada aposta a uma métrica e a uma trajetória.

A virada de chave é tratar o roadmap de IA como um portfólio de apostas, cada uma com uma tese explícita: este problema, para este usuário, movendo esta métrica, valendo este investimento. Se você não consegue escrever a tese numa frase, não é uma aposta, é um palpite com orçamento.

Financie em estágios, como quem abre uma posição

Aqui vale roubar uma ideia que mercado financeiro conhece bem. Timothy Luehrman publicou na Harvard Business Review, em 1998, um artigo chamado "Strategy as a Portfolio of Real Options". A tese: estratégia se parece menos com um fluxo de caixa único e projetado, e mais com uma série de opções, onde você decide sequência e timing, investindo um pouco pra ganhar o direito de investir mais se a coisa andar.

É exatamente assim que um roadmap de IA deveria ser financiado. Não se aprova o orçamento inteiro de uma iniciativa lá no começo, quando você sabe menos. Você libera capital em estágios, e cada estágio precisa ganhar o próximo. Quem vem de mercado pensa assim por instinto: cada aposta é uma posição que você dimensiona, acompanha e encerra sem drama quando a tese não se confirma. Matar um piloto que não moveu a métrica não é fracasso; é gestão de risco. O fracasso é manter doze posições abertas só porque dá vergonha fechar.

O gate que mais falta nas empresas é o segundo. Todo mundo tem critério pra começar um piloto; quase ninguém tem critério pra matá-lo. Sem um gate de "moveu a métrica ou morre", o piloto vira um zumbi: consome manutenção, ocupa time, e fica em produção porque desligar dá trabalho. O portfólio saudável tem mais coisas mortas do que vivas, e isso é saúde, não desperdício.

Compre o que é commodity, construa o que te diferencia

A próxima decisão que separa roadmap maduro de fábrica de POC é build versus buy, e aqui o melhor mapa que conheço é o de Simon Wardley. Já escrevi sobre pensar estratégia com o tabuleiro à vista em Você Está Construindo a Estratégia de Arquitetura Sem Ver o Tabuleiro?, e a lógica se aplica inteira à IA.

Wardley mapeia tudo num eixo de evolução, da gênese (novo, incerto, experimental) até a commodity (padronizado, utility). A inferência de um LLM de fronteira, embeddings, infraestrutura de vetores, tudo isso já é commodity. Você aluga. Não faz o menor sentido alocar seus melhores engenheiros pra manter o que a AWS, a OpenAI e a Anthropic vendem por centavos. O que você constrói é o que está mais perto da gênese e te diferencia de verdade: o jeito específico como você combina dados proprietários, regras de domínio e fluxo de trabalho que ninguém mais tem.

E não é só elegância conceitual. O próprio relatório do MIT trouxe um número que aperta esse ponto: comprar de fornecedores especializados teve sucesso cerca de duas vezes mais que construir internamente. Construir tudo porque "queremos dominar a tecnologia" é uma das formas mais caras de entrar no grupo dos 95%.

A trajetória é de capability, não de feature

A pergunta que transforma um roadmap é esta: depois que essa aposta acabar, o que fica? Se a resposta é "uma feature", você construiu uma ilha. Se a resposta é "uma capacidade que a próxima feature reaproveita", você construiu trajetória.

É a diferença entre planejar por projetos e planejar por capabilities. Cada iniciativa de IA deveria deixar pra trás um pedaço de plataforma: um serviço de classificação, um pipeline de avaliação, um padrão de observabilidade, um conjunto de dados curado. A décima feature fica barata porque a primeira pagou a conta de construir a base. Esse é o oposto da fábrica de POC, onde a décima é tão cara quanto a primeira porque ninguém deixou nada reutilizável pra trás.

Team Topologies, do Matthew Skelton e do Manuel Pais, dá um conceito útil aqui: o thinnest viable platform, a menor plataforma que já acelera os outros times de forma mensurável. Você não começa construindo a plataforma de IA dos sonhos. Começa com a casca mínima que faz o segundo time ir mais rápido que o primeiro, e deixa ela engordar conforme a demanda real aparece.

E tem um dado da BCG, de outubro de 2024, que todo líder técnico precisa colar na parede. No esforço de escalar IA, eles estimam a regra 10-20-70: 10% é algoritmo, 20% é tecnologia e dados, e 70% é gente e processo. Um roadmap que só lista modelos e integrações está planejando 30% do problema e ignorando o pedaço que de fato decide o sucesso. A trajetória de capability inclui a capacidade do time e dos processos de absorver aquilo, não só o código.

Meça resultado de negócio, não vaidade

Tudo isso desaba se a métrica estiver errada. Contar pilotos lançados, demos feitas, "precisão no conjunto de teste", é métrica de vaidade: sobe sem mover o negócio. A disciplina é a velha distinção entre indicador de resultado e indicador de vaidade, e ela é dura porque a métrica de vaidade é mais fácil e mais bonita de reportar.

Cada aposta do portfólio precisa estar amarrada a um indicador que alguém de negócio reconhece como seu: tempo de resolução, taxa de conversão, custo por atendimento, churn, receita por cliente. Antes de aprovar o piloto, não depois. Se a métrica só foi inventada na hora de justificar o que já foi construído, ela vai ser escolhida pra parecer boa, e você acabou de fabricar mais um número de vaidade com aparência de resultado.

Aqui a cultura de métricas de fluxo que já maturou em engenharia ajuda. As métricas de DORA, sobre as quais já escrevi em DORA Metrics, são um bom modelo mental: poucas, ligadas a resultado, difíceis de fraudar. O roadmap de IA precisa do equivalente, métricas que conectam a aposta ao que a empresa de fato persegue, e não ao que é confortável mostrar no slide.

Uma tensão honesta sobre os primeiros pilotos

Tem uma objeção legítima a tudo isso, e vale encarar de frente. Andrew Ng, no "AI Transformation Playbook" de 2018, recomenda começar por pilotos escolhidos mais pela chance de sucesso do que pelo valor, justamente pra criar tração e momentum interno. Faz sentido: ninguém constrói apoio político pra IA mostrando fracasso.

O problema é o que acontece depois do momentum. O piloto que nasceu "pra ganhar tração" precisa de um gate que o force a virar valor, ou a morrer. Sem esse gate, ele vira exatamente o piloto eterno que o MIT e a RAND contabilizam como fracasso. Momentum é um meio legítimo; vira armadilha quando você confunde o piloto-vitrine com o objetivo. Comece com vitórias fáceis se precisar, mas escreva no contrato, desde o dia 1, qual é a métrica de negócio que justifica continuar.

Um truque que ajuda a manter a honestidade é o "working backwards" da Amazon: antes de aprovar a aposta, escreva o press release do resultado, como se ele já existisse. Se o texto não convence, o piloto não vale. É uma forma barata de matar, no papel, o POC que ninguém pediu.

Conclusão

A fábrica de POC não é falta de talento técnico nem de tecnologia. É falta de uma disciplina de portfólio. Roadmap de IA que funciona trata cada iniciativa como aposta com tese explícita, financia em estágios com gates de verdade (inclusive o gate de matar), compra o que é commodity e constrói só o que diferencia, deixa capability reutilizável pra trás em vez de ilhas, e mede resultado de negócio em vez de vaidade.

A diferença entre a empresa que está nos 5% e a que está nos 95% raramente é o modelo que ela escolheu. É se ela tratou IA como um portfólio que se gerencia, ou como uma vitrine que se enche. A primeira tem menos pilotos vivos e mais resultado. A segunda tem doze slides bonitos e a sala em silêncio quando alguém pergunta sobre o P&L.

A pergunta honesta que organiza o roadmap inteiro: se eu matar agora todas as iniciativas de IA que não estão ligadas a uma métrica de negócio, o que sobra? O que sobra é o seu roadmap de verdade. O resto é a fábrica.

Insights & Takeaways

1. O número que assombra é real: o MIT estimou em 2025 que cerca de 95% dos pilotos de GenAI não geram retorno mensurável no P&L. A causa raramente é o modelo; é POC desconectado de métrica de negócio e sem herança reutilizável.

2. Roadmap não é lista de POCs. Cagan estima que só 10% a 20% dos itens de um roadmap entregam o resultado esperado. Trate cada item como aposta com tese explícita: este problema, este usuário, esta métrica, este investimento.

3. Financie em estágios, como opções reais (Luehrman, HBR, 1998), com gates que ganham o próximo passo. O gate que mais falta é o de matar: portfólio saudável tem mais apostas mortas do que vivas.

4. Compre commodity, construa diferenciação. No mapa de Wardley, inferência e embeddings são utility que você aluga; o MIT achou que comprar teve sucesso cerca de duas vezes maior que construir. E lembre do 10-20-70 da BCG: 70% do esforço é gente e processo, não algoritmo.

5. Meça resultado, não vaidade, e defina a métrica antes do piloto, não depois. Cada aposta deve deixar capability reutilizável pra trás; é o que faz a décima feature ser barata e separa trajetória de fábrica de POC.