A inteligência artificial está gerando uma movimentação sem precedentes nas empresas. Cada vez mais, companhias anunciam investimentos milionários, projetos-piloto e novas ferramentas de automação. Por trás do entusiasmo, existe uma realidade incômoda: entre 50% e 95% dos projetos de IA não saem da fase experimental ou não entregam o retorno financeiro esperado, segundo George Westerman, professor sênior do MIT Sloan, em apresentação no palco do Universo TOTVS, em São Paulo. Menos de 10% dos executivos e CEOs relatam enxergar valor concreto nas iniciativas.
O Problema Nao E Tecnologico
A frase de Westerman é precisa: o problema central não é tecnológico, mas organizacional e cultural. Muitas empresas criam pilotos tecnológicos e falham em integrar os processos, o marketing, o design e as áreas operacionais na rotina de inovação. O modelo funciona no ambiente controlado do piloto e para quando encontra a operação real, com seus prazos, suas exceções e seus incentivos conflitantes.
Isso explica por que tantos projetos morrem na transição. O piloto é medido por uma métrica escolhida para provar viabilidade; a operação é medida por custo, prazo e volume. Quando o projeto migra, muda o critério de sucesso sem que ninguém tenha preparado o time para o novo critério, e o resultado é abandono silencioso.
A Ilusao da Adocao
Especialistas chamam esse cenário de ilusão da adoção de IA: a falsa sensação de que adquirir tecnologia de ponta já é suficiente para transformar o negócio. A ilusão é confortável porque é verificável. É possível mostrar a licença, o dashboard, o número de usuários ativos. Nenhuma dessas evidências responde se alguma decisão mudou.
Comecar Pelo Problema, Nao Pela Ferramenta
A recomendação de Westerman é inverter a lógica: o segredo não é começar pela tecnologia, mas pelo problema. Encontrar um problema real para o qual alguém já precisa de solução garante que a IA agregue valor imediato e ganhe tração organizacional. Quando o projeto nasce da dor de alguém específico, esse alguém se torna o defensor interno que sustenta a iniciativa quando o entusiasmo inicial passa.
No varejo, as dores reais são conhecidas: ruptura de estoque, precificação ineficiente, perda de produtividade, custo de atendimento. São problemas mensuráveis, com responsável definido e impacto financeiro calculável. Projetos que atacam essas dores têm uma vantagem sobre projetos que atacam problemas genéricos: o critério de sucesso já existe antes do projeto começar.
O Caso da Producao Como Referencia
A automação industrial oferece um modelo útil. Quando a Danone usa automação para reduzir perdas na fábrica de laticínios, o objetivo é uma perda mensurável em litros e em reais, não a adoção de tecnologia. A clareza do alvo é o que permite medir, corrigir e escalar. O mesmo rigor aplicado a um projeto de IA no varejo mudaria a taxa de sucesso.
O Papel da Governanca de Dados
Um projeto de IA depende de dados com definição estável. Quando a definição de um indicador muda entre áreas, o modelo aprende com sinais contraditórios e produz recomendações que ninguém confia. A governança não é um departamento, é a prática de manter uma definição única para cada métrica relevante, com responsável e histórico de mudanças.
Há também a dimensão regulatória. O avanço de investigações sobre uso de dados e falhas de moderação, como o caso envolvendo a Meta e a ANPD, mostra que a tolerância a erros de governança está diminuindo. Um projeto de IA que não consegue explicar de onde vêm seus dados tem risco jurídico além do risco de negócio.
Como Medir Valor de Forma Defensavel
Três métricas resistem à auditoria. A primeira é o incremento atribuível: qual seria o resultado sem o projeto, medido com base fixada antes do início. A segunda é o custo por decisão: quanto tempo e quanto erro humano cada decisão consumia antes e depois. A terceira é o efeito defasado na recompra e na reclamação, que revela se o cliente percebeu melhora.
As três exigem medição planejada, e é aí que a maioria falha. Medir depois é fácil e inútil; medir antes é trabalhoso e decisivo. Empresas que definem a linha de base e o método de medição no documento de aprovação do projeto conseguem, ao final, dizer se houve valor. As outras só conseguem dizer que houve atividade.
O Que Fazer Na Proxima Segunda-Feira
Escolher um problema com dono, escrever a linha de base, definir o critério de parada e nomear quem assina o resultado. Quatro ações que não exigem orçamento novo e que separam projetos de IA de iniciativas de compra de software. A diferença entre as duas coisas é a diferença entre valor e ilusão.
Vale lembrar que a pressa tem custo. Em um ambiente onde metade dos projetos não entrega, a vantagem competitiva não está em começar mais projetos, e sim em terminar os que importam. Quem mede antes de escalar aprende mais rápido do que quem escala antes de medir.
O Papel do Time Que Nao Programa
Projetos de IA fracassam com frequência porque o time que entende o problema não participa da construção da solução. Quando a área de negócio apenas entrega requisitos e volta depois para ver o resultado, o modelo é construído sobre uma interpretação do problema, não sobre o problema. A distância entre as duas coisas é onde o valor se perde.
A correção não exige que o time de negócio aprenda a programar. Exige que ele participe das decisões de definição: o que conta como acerto, o que conta como erro aceitável, e qual decisão será tomada com a saída do modelo. Três perguntas que qualquer gestor consegue responder.
A Reuniao de Trinta Minutos
Uma reunião semanal de trinta minutos, com o time de negócio e o time técnico olhando juntos os casos em que o modelo errou, muda mais do que qualquer relatório. O erro compartilhado cria entendimento comum sobre o limite do sistema, e esse entendimento é o que permite escalar sem perder confiança.
