Revisão: João Paulo Chagas, gestor de Marketing e Operações da Audatia · atualizado em 18 de agosto de 2026
Projetos de IA falham nas empresas por três causas que o Gartner repete em duas previsões diferentes: custo crescente, valor de negócio pouco claro e controle de risco insuficiente. Nenhuma das três é um problema do modelo de IA. As três são problemas do que existe antes dele — escopo mal definido, ausência de número de referência e dado desorganizado. A projeção de 2024 estimava que pelo menos 30% dos projetos de IA generativa seriam abandonados após a prova de conceito até o fim de 2025; a de 2025 estima que mais de 40% dos projetos de IA com agentes serão cancelados até o fim de 2027. E a pesquisa da McKinsey publicada em novembro de 2025 mostra o outro lado do mesmo fenômeno: quase dois terços das organizações ainda não começaram a escalar IA pela empresa.
O padrão é sempre o mesmo. O piloto funciona, a demonstração impressiona, e a coisa não atravessa. Não porque o modelo seja ruim — porque a operação embaixo dele não sustenta.
Quais são as causas que aparecem em toda apuração?
Cinco, em ordem de frequência no que vemos em campo. As três primeiras são as citadas pelo Gartner; as duas últimas são as que aparecem antes delas.
| Causa | Como se manifesta | O que estava faltando |
|---|---|---|
| Valor pouco claro | Ninguém consegue dizer quanto melhorou | Um número medido antes de começar |
| Custo crescente | A conta do mês surpreende | Teto definido e entendimento de como a cobrança funciona |
| Controle de risco insuficiente | Uma saída errada chegou ao cliente | Regra escrita de revisão humana |
| Dado desorganizado | A IA responde com confiança sobre algo que não é verdade | Fonte única sobre o estado do trabalho |
| Escopo grande demais | Deu morno e ninguém sabe por quê | Um processo só |
As duas últimas são causa das três primeiras. Escopo grande é o que impede medir valor. Dado desorganizado é o que produz a saída errada que estoura o controle de risco. E as duas juntas são o que faz o custo escalar sem contrapartida visível.
Por que a base de dados vem antes do modelo?
Porque o modelo não sabe o que ele não recebeu. Ele responde com a mesma fluência sobre informação completa e sobre informação parcial — e essa é exatamente a parte perigosa.
| Pergunta de operação | IA sem contexto devolve | IA sobre operação dispersa devolve | IA com base organizada devolve |
|---|---|---|---|
| “Em que pé está o projeto?” | Um modelo de relatório para você preencher | O que apareceu nas conversas, sem saber o que ficou de fora | Entregas, responsáveis e o que está aberto desde quando |
| “Quem está sobrecarregado?” | Critérios genéricos de avaliação de carga | Impressão a partir de quem falou mais | Volume de trabalho aberto por pessoa, com prazos |
| “O que atrasou e por quê?” | Causas comuns de atraso | Um atraso citado, sem histórico | A data que mudou, quando mudou e o motivo registrado |
A coluna do meio é a que mata projeto. Ela não parece erro: parece resposta. A empresa passa a decidir com base em resumo confiante de informação incompleta, e quando alguém percebe, a confiança na ferramenta já foi embora junto com o orçamento.
É a razão de a regra de ouro do nosso método ser “IA não roda sobre caos”, e de a camada de IA ser o quinto passo do Método Núcleo→Escala, nunca o primeiro.
O que a governança formal diz sobre isso?
O NIST, agência do governo americano de padrões e tecnologia, publicou em 2023 o AI Risk Management Framework, que é público e gratuito. Ele não fala de ferramenta; fala de estrutura. Uma das subcategorias do framework é direta sobre o ponto que mais falta nas empresas:
“Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.”
— NIST AI Risk Management Framework 1.0, subcategoria MANAGE 2.4
Traduzindo o que isso significa numa empresa de trinta pessoas: existe alguém com autoridade e com o botão para desligar, e todo mundo sabe quem é? Na maioria dos projetos que travam, a resposta é não. E quando algo sai errado, o desligamento leva dias porque ninguém sabe de quem é a decisão.
Falha de projeto de IA é falha de tecnologia ou de processo?
Quase sempre de processo — e há um teste simples para separar as duas coisas.
Pegue o caso concreto que deu errado e pergunte: se uma pessoa competente e bem-intencionada tivesse feito esse trabalho manualmente, com as mesmas informações disponíveis, ela teria acertado?
- Se sim, a informação existia e o problema é de configuração, de prompt ou de escopo do que a IA acessa. É corrigível em dias.
- Se não — a pessoa também não teria como saber —, a informação não existia. Nenhum ajuste de modelo resolve, porque o que falta não está na ferramenta. É corrigível em meses, e é trabalho de processo.
A segunda resposta é a mais comum e a menos aceita. Ela é impopular porque transfere o problema de um lugar onde se compra para um lugar onde se trabalha.
Por que o piloto funciona e a produção não?
Porque piloto e produção rodam sobre condições diferentes, e três delas mudam de uma vez.
- Quem participa muda. O piloto é feito por gente interessada. A produção inclui quem não pediu para participar.
- O dado muda de qualidade. No piloto, alguém arruma os dados de entrada — às vezes sem perceber. Em produção, entra o que a operação produz de verdade.
- O custo muda de escala. O consumo de dez pessoas por seis semanas não projeta linearmente para duzentas pessoas por doze meses, especialmente onde a cobrança é por consumo.
Nenhuma dessas três é culpa do modelo. E as três são previsíveis — o que significa que dá para desenhar o piloto já sabendo delas. É o assunto de como implantar IA em um processo.
O que fazer quando o projeto já falhou?
Não recomeçar do mesmo ponto com outra ferramenta. É o reflexo mais comum e o mais caro: trocar de fornecedor sem trocar de diagnóstico devolve o mesmo resultado com outro logotipo.
O roteiro de retomada tem quatro perguntas, nesta ordem:
- Qual era o número de antes? Se não havia, o projeto nunca teve como ser avaliado — e isso já explica boa parte do que aconteceu.
- A informação necessária existia em algum sistema? Se não, a causa está aqui e não adianta olhar mais nada.
- A saída errada tinha caminho para ser barrada? Se não, faltava regra de revisão, e ela custa uma tabela, não um contrato.
- Alguém era dono disso? Se o projeto era de todo mundo, era de ninguém.
Na prática, a maioria das retomadas descobre que precisa parar de falar de IA por um tempo e resolver registro. É um diagnóstico ingrato de entregar e é o que economiza mais dinheiro.
Resumo
| Pergunta | Resposta curta |
|---|---|
| Quais as causas mais citadas? | Custo crescente, valor pouco claro e controle de risco insuficiente |
| Qual a causa por trás dessas? | Escopo grande demais e dado desorganizado |
| Por que a base vem antes? | O modelo responde com a mesma confiança sobre informação completa e parcial |
| É falha de tecnologia ou de processo? | Aplique o teste: uma pessoa competente teria acertado com as mesmas informações? |
| Por que o piloto funciona e a produção não? | Muda quem usa, muda a qualidade do dado e muda a escala de custo |
| O que fazer depois de falhar? | Refazer o diagnóstico antes de trocar de ferramenta |
| Quantos projetos falham? | O Gartner projeta mais de 40% de cancelamento em projetos com agentes até 2027 |
Próximo passo
Se as quatro perguntas de retomada te levaram para “a informação não existia em lugar nenhum”, o próximo trabalho não é de IA: é definir o que a empresa registra e onde. É o que fazemos em consultoria e desenho de processo, e é o passo que o método coloca antes da automação por um motivo prático, não estético.
Se a sua dúvida específica é sobre risco de a IA agir sozinha na operação, tenho medo de plugar IA na operação trata da objeção em detalhe, com o que as plataformas oferecem hoje de barreira real.
