Como apresentar um projeto de IA para a diretoria e sair com o orçamento aprovado

Resposta rápida

Pra sair da sala com o orçamento aprovado, o business case de um projeto de IA precisa de quatro coisas que a maioria das apresentações não tem: um problema de negócio quantificado em reais (não “a IA vai revolucionar nosso processo”), um escopo estreito de piloto com prazo curto (não “vamos implementar IA na empresa toda”), uma métrica de sucesso definida ANTES de começar (não medida depois, quando já dá pra inventar uma boa história), e um orçamento com margem de segurança, porque projeto de IA estoura o custo inicial entre 40% e 65% na maioria dos casos. O motivo de tanto rigor: segundo o relatório do MIT Project NANDA (“The GenAI Divide: State of AI in Business 2025”), 95% dos pilotos de IA generativa dentro de empresas não entregam retorno financeiro mensurável. A diretoria não está sendo conservadora à toa, ela está certa em desconfiar na maioria dos casos. Seu trabalho na apresentação não é vender entusiasmo, é provar que o seu projeto está no grupo dos 5% que funcionam, e isso se prova com estrutura, não com slide bonito.

Neste artigo:

• Por que a diretoria hesita, com números que explicam a desconfiança
• O erro nº1 que mata a aprovação antes de começar
• Como estruturar o business case (o que colocar em cada parte)
• Roteiro prático pra reunião: o que apresentar e em que ordem
• As objeções mais comuns e como responder cada uma

---

Por que a diretoria hesita (e por que ela não está errada)

Antes de montar a apresentação, vale entender o estado de espírito de quem vai ouvir você. Segundo uma pesquisa da Zoho Workplace com mais de 100 líderes de TI brasileiros, feita em março de 2026, 83,7% dos CIOs já tiveram que adiar projetos estratégicos por restrição de orçamento, e boa parte deles nem chega a levar a proposta pra diretoria porque já espera rejeição. O clima de aprovação de investimento em tecnologia está mais apertado, não mais aberto, mesmo com toda a conversa sobre IA no mercado.

E tem um motivo estrutural pra essa cautela: o relatório do MIT Project NANDA, construído a partir de 52 entrevistas com executivos, pesquisa com 153 líderes e análise de 300 implementações públicas de IA, encontrou que 95% dos pilotos de IA generativa dentro de empresas não geram retorno financeiro mensurável, apesar de bilhões de dólares investidos globalmente. A conclusão do próprio relatório é interessante: o problema não está na tecnologia, está na abordagem. Os 5% que funcionam não usam modelo melhor, eles têm escopo mais estreito, integração mais cuidadosa e prioridade mais alinhada com o negócio.

Ou seja: quando você entra numa sala pedindo orçamento pra “um projeto de IA”, você está pedindo pra ser julgado pela taxa de fracasso de 95%. O trabalho da sua apresentação é mostrar, com estrutura visível, por que o seu caso está no outro grupo.

O erro nº1: pedir aprovação de “IA”, não de um resultado

O erro mais comum, e o mais fácil de corrigir, é abrir a apresentação falando da tecnologia em vez do problema. “Quero implementar um agente de IA pra atendimento” é um pedido de tecnologia. “Hoje gastamos X horas de equipe respondendo Y perguntas repetitivas por mês, que custam Z reais em salário, e quero testar se um sistema resolve 60% delas em 90 dias, com orçamento de W” é um pedido de resultado.

A diferença não é estilística, é o que faz a diretoria conseguir avaliar o pedido com os mesmos critérios que usa pra qualquer outro investimento: quanto custa, quanto tempo leva, o que muda se der certo, o que perdemos se der errado. Projeto de IA apresentado como projeto de IA compete por “confiança na tecnologia”. Projeto de IA apresentado como redução de custo ou aumento de receita compete pelos mesmos critérios de qualquer investimento que já foi aprovado antes.

Como estruturar o business case

1. O problema, quantificado

Comece pelo número, não pela ferramenta. Quanto custa hoje o processo que você quer melhorar (em horas, em reais, em erros, em tempo de resposta)? Se você não sabe o número exato, é melhor levantar isso antes da reunião do que estimar na hora, porque é a primeira pergunta que vai aparecer.

2. O escopo do piloto, deliberadamente pequeno

Não peça pra “implementar IA no processo todo”. Peça pra testar num recorte específico, com prazo curto (30 a 90 dias é uma faixa razoável) e critério de sucesso definido antes de começar. Isso não é falta de ambição, é a diferença entre os 5% que funcionam e os 95% que não: escopo estreito reduz a superfície de erro e dá um resultado mensurável rápido, que vira a prova pra pedir o próximo investimento maior.

3. A métrica de sucesso, travada ANTES

Defina o número que vai decidir se o piloto funcionou, e escreva ele no documento que a diretoria aprova. Se depois do piloto você for inventar uma métrica que “mostra que deu certo”, ninguém confia no próximo pedido. Métrica travada antes é o que separa apresentação séria de venda de peixe.

4. O orçamento, com margem

Coloque uma reserva explícita no orçamento, porque projeto de IA estoura a estimativa inicial entre 40% e 65% na maioria dos casos, geralmente por causa de integração com sistema legado, ajuste de dado sujo, ou retrabalho depois do primeiro teste com usuário real. Apresentar isso com transparência (em vez de deixar a diretoria descobrir depois que o projeto já estourou) constrói mais confiança do que esconder o risco.

5. O plano se der errado

Diga explicitamente o que acontece se a métrica não for atingida no prazo: o projeto para, o orçamento não escala, e ninguém fica com a sensação de que dinheiro sumiu sem critério. Esse ponto sozinho já tira boa parte da resistência, porque muda a pergunta de “e se isso não funcionar” pra “já sei o que acontece se não funcionar”.

Roteiro prático pra reunião

Uma ordem que funciona bem, testada em apresentação de negócio de qualquer tipo, não só IA:

1. Abra pelo custo do problema atual, não pela solução. Um número concreto de quanto o processo custa hoje prende atenção mais rápido que qualquer slide de tecnologia.
2. Mostre o que você já tentou (se aplicável) sem IA, e por que não resolveu. Isso mostra que você não está pulando pra IA por modismo.
3. Apresente o escopo do piloto com prazo, métrica e orçamento (incluindo a margem).
4. Mostre o plano de decisão pós-piloto: o que acontece se funcionar (próximo passo, próximo orçamento) e o que acontece se não funcionar (encerra, sem drama).
5. Termine com quem vai tocar o projeto e quanto tempo da equipe isso consome, porque orçamento aprovado sem gente pra executar é orçamento que não sai do papel.

Objeções mais comuns, e como responder

“Já tentamos algo parecido e não funcionou.” Pergunte o que foi medido e por que não funcionou especificamente. Na maioria das vezes, o piloto anterior tinha escopo largo demais ou não tinha métrica definida antes, exatamente os dois erros que o seu business case já corrige.

“Isso não é arriscado demais?” Mostre que o escopo é deliberadamente pequeno e o prazo é curto justamente pra limitar o risco. Um piloto de 60 dias com orçamento definido é um risco controlado, diferente de um projeto de escopo aberto.

“Quanto tempo até dar retorno?” Seja honesto sobre o prazo do piloto (não do projeto completo escalado). Prometer retorno rápido demais é o tipo de promessa que queima confiança pro próximo pedido.

“Por que IA e não uma automação mais simples?” Essa é uma pergunta legítima, e às vezes a resposta certa é “não precisa ser IA”. Se o processo é bem definido, com regras claras, automação tradicional resolve mais barato. IA faz sentido quando o processo lida com linguagem natural, decisão com contexto variável, ou volume de exceções que regra fixa não cobre bem.

Perguntas frequentes

Preciso ter conhecimento técnico de IA pra apresentar esse business case?

Não precisa entender de modelo ou arquitetura. Precisa entender do PROCESSO que quer melhorar, profundamente, porque é isso que a diretoria vai questionar. O conhecimento técnico de como a IA resolve pode vir de um fornecedor ou consultor depois que o orçamento do piloto for aprovado.

Quanto custa um piloto de IA, pra eu colocar no orçamento?

Varia muito conforme o processo e a ferramenta, mas o ponto mais importante não é o número exato, é incluir a margem de 40% a 65% sobre a estimativa inicial, porque é a faixa real de estouro documentada na maioria dos projetos.

O que fazer se a diretoria pedir “prova de que outras empresas tiveram sucesso” antes de aprovar?

Use o próprio dado do MIT: 5% dos pilotos de IA integrados entregam retorno significativo, e o que diferencia esses 5% não é o modelo usado, é exatamente a estrutura que este artigo descreve (escopo estreito, métrica prévia, integração cuidadosa). Isso reposiciona a pergunta: não é “IA funciona ou não”, é “esse projeto específico está estruturado pra funcionar”.

Depois que o piloto der certo, como pedir o orçamento pra escalar?

Use o resultado do piloto como o novo ponto de partida da conversa, com o mesmo formato: problema quantificado (agora com dado real, não estimativa), escopo do próximo passo, métrica e orçamento com margem. A aprovação do piloto vira a prova social interna que faltava na primeira apresentação.

Se você está nessa fase, decidindo por onde começar o projeto de IA da sua empresa antes mesmo de montar a apresentação pra diretoria, vale ler também o nosso guia de como implementar IA na empresa e o quanto custa implementar IA numa empresa, que ajudam a chegar na reunião já com os números que a diretoria vai pedir. Na CPDF (Comunidade Profissionais do Futuro - por Danilo Gato), a gente trabalha justamente essa ponte entre entender IA de verdade e conseguir defender isso dentro da empresa, não só saber usar a ferramenta.