IA Industrial · 7 min de leitura
A maioria dos projetos de IA na indústria não fracassa na demonstração. Fracassa depois, quando o piloto que funcionou precisa virar rotina de turno. O white paper “The Four Gaps: Where AI Investment Stalls” dá nome a esse ponto, e o que vemos em campo acrescenta uma camada que costuma ficar fora da análise.
Adoção de IA é problema de diagnóstico, não de caso de uso
O white paper foi escrito por Ian McCulloh, da Johns Hopkins, e Maria Chaloux, da Octant Advisory. A tese central é que a adoção de IA emperra por falta de diagnóstico, não por falta de caso de uso. As empresas sabem onde a IA poderia ajudar; o que não sabem é em qual ponto do caminho entre o piloto e a operação o investimento está parando.
Essa inversão importa para quem está no chão de fábrica. A conversa comum começa pela tecnologia: qual modelo, qual plataforma, qual fornecedor. A conversa que o paper propõe começa pela organização: onde está a lacuna que impede o resultado de chegar à operação, e como medi-la.
O paper descreve quatro lacunas. A que mais interessa à operação industrial é a de execução, que separa a decisão de investir do resultado na linha, porque é nela que a maior parte dos projetos para e é nela que a experiência de campo tem mais a dizer.
Os números do Execution Gap
O paper reúne números de fontes diferentes que apontam na mesma direção. Nenhum deles é sobre a qualidade dos modelos; todos são sobre o que acontece depois da prova de conceito. Lidos juntos, descrevem um funil em que quase tudo entra e muito pouco sai.
O gargalo não é técnico no sentido estrito: o modelo funcionou o suficiente para passar no piloto. O que falhou foi a passagem do experimento para a rotina, e os três números medem exatamente essa passagem:
- 95% dos pilotos de IA generativa sem impacto mensurável no P&L (MIT NANDA, 2025)
- Só 26% das empresas levam IA além da prova de conceito (BCG, 2024)
- 30% dos projetos abandonados após o piloto (Gartner, 2024)
Em campo, o Execution Gap tem outro nome: rejeição
McCulloh chama esse ponto de Execution Gap. Em campo, o sintoma tem um nome mais simples: rejeição. E ela não é exclusiva de IA. O mesmo padrão aparece em MES novo, em expansão de SCADA, em dashboard de OEE e em manutenção preditiva.
O roteiro é conhecido. O piloto demonstra, o comitê aprova, o fornecedor apresenta os números da prova de conceito. Meses depois, a ferramenta está instalada, tecnicamente funcionando, e o turno continua trabalhando do jeito antigo. A escala não aconteceu, e ninguém consegue apontar exatamente por quê.
Parte do problema é que os indicadores usados para declarar sucesso vêm do fornecedor: licenças ativas, acessos por semana, alertas gerados. Nenhum deles mede se a operação passou a decidir de outro jeito. Para isso, é preciso olhar para o turno.
Três indicadores de adoção real que o relatório do fornecedor não mostra
Há três sinais que indicam adoção real, e nenhum deles aparece em painel de uso. Eles precisam ser observados por quem convive com a operação.
O primeiro é a menção espontânea da ferramenta no turno. Quando alguém diz “vou conferir no painel antes de soltar” sem que ninguém tenha pedido, a ferramenta entrou no processo de decisão. Se ela só é citada em reunião de acompanhamento do projeto, ainda não entrou.
O segundo é quem usou primeiro fora do escopo original. A pessoa que aplica a ferramenta em um problema que não estava no piloto demonstrou ownership. Normalmente é um líder informal, e é por ele que a adoção se espalha, muito mais do que por treinamento formal.
O terceiro é o que acontece se a ferramenta cair por 48 horas. Se o time continua raciocinando da forma que a ferramenta ensinou, houve adoção: o método foi internalizado. Se o time para, ou volta ao chute, houve dependência. Adoção é internalizar o método; dependência é tratar a ferramenta como oráculo.
A camada que precede tudo
Existe uma causa de rejeição que raramente aparece nos diagnósticos de adoção, porque ela não está na organização nem no software. Está na infraestrutura que leva o dado até a ferramenta.
Uma ferramenta que cai duas vezes por mês por jitter ou por um loop de terra escondido ensina o time a desconfiar dela. E o time aprende rápido. Depois de algumas quedas, ele passa a desconfiar também quando a ferramenta está certa, e aí nenhum treinamento recupera a credibilidade.
Nesse caso, a culpa não é da ferramenta, e não adianta trocar de fornecedor. É da fundação. Antes de concluir que a equipe rejeitou a IA, vale verificar se a rede que alimenta a IA estava entregando dado confiável todos os dias do piloto, e não só no dia da demonstração.
O que muda na forma de avaliar um piloto
Para a gestão, a consequência é prática. Um piloto de IA deveria ser avaliado em três frentes, e não só em uma. A frente técnica mede se o modelo acerta. A frente de adoção observa os três indicadores do turno. A frente de infraestrutura verifica se as interrupções da ferramenta tiveram origem na rede, e quantas foram.
Sem a terceira frente, a planta corre o risco de encerrar um projeto bom por um problema que não era do projeto, ou de escalar um projeto sobre uma fundação que vai repetir as mesmas quedas em dez linhas em vez de uma. Nos dois casos, o custo aparece depois, quando já não há verba nem paciência para refazer o diagnóstico.
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.