Os ganhos de IA industrial medidos em nível de operação são reais e consistentes:
+10% a 20%
de output de produção
+7% a 20%
de produtividade de funcionários
+10% a 15%
de capacidade destravada
61% → 97%
de entrega no prazo na Schneider Electric
Na Global Lighthouse Network, a Schneider Electric elevou a entrega no prazo de 61% para 97% e eliminou US$ 43 milhões em backorders; a Rockwell aumentou 43% as unidades por hora-homem e reduziu defeitos em 35%.
No consolidado, nada disso aparece. A parcela de organizações que atribui algum impacto de IA no EBIT ficou em 37%, a mesma de 2025, e apenas 6% reportam impacto de 5% ou mais (McKinsey, 1.719 respondentes em 97 países).
O ganho é limpo na planta e evapora na holding. Este artigo é sobre por que ele não sai do primeiro site, e o que é preciso para que saia.
A aritmética que explica o desaparecimento
Antes de qualquer causa técnica, há uma conta que resolve metade do mistério.
Um ganho de 15% em duas plantas de uma rede de 30 vale 1% no consolidado, dentro do ruído de variação de mix, câmbio e parada não programada. O resultado é verdadeiro, auditável na planta, e invisível na demonstração financeira.
Isso tem duas implicações desconfortáveis:
- O piloto bem-sucedido não prova nada sobre a rede. Ele prova que funciona naquele site, com aquele equipamento e aquela equipe.
- O board não vai ver o ganho até a replicação acontecer, e a replicação é o pedaço que quase nunca é orçado.
Os casos mais citados vêm da Global Lighthouse Network, cujos sites são, por seleção, os melhores do mundo. Eles mostram o teto do que é possível, não a média do que é provável.
Por que o modelo não atravessa a cerca
O equipamento não é o mesmo. Duas linhas que produzem o mesmo item raramente têm a mesma marca, o mesmo ano e a mesma configuração. Um modelo de detecção de anomalia aprendeu a assinatura de vibração daquele motor, com aquela base e aquele histórico de manutenção.
O sensor não está no mesmo lugar. Posição, fixação e faixa de medição mudam a leitura. Um acelerômetro montado no mancal e outro na carcaça produzem sinais diferentes para a mesma falha.
O mix é outro. A planta B roda outra família de produtos, com outra receita e outro ritmo. O modelo aprendeu a distribuição da planta A.
A definição operacional diverge. O que a planta A chama de "parada não programada" a planta B registra como "setup estendido". Sem definição comum, o mesmo indicador mede coisas diferentes, e o ganho reportado não é comparável.
O comportamento de quem opera muda o dado. Apontamento feito na hora produz série diferente de apontamento feito no fim do turno. O modelo aprende o hábito junto com o processo.
Resultado prático: transferir o modelo raramente funciona; transferir o método quase sempre funciona.
O que é replicável, e o que precisa ser refeito
| Camada | Viaja? | Por quê |
|---|---|---|
| Definição do problema e da variável alvo | sim | é a parte cara e não depende do equipamento |
| Pipeline de coleta e contextualização | sim, com ajuste | o padrão de nomes e o modelo semântico se repetem |
| Engenharia de variáveis | em grande parte | as mesmas features costumam servir |
| Pesos do modelo treinado | quase nunca | aprendeu o equipamento e o mix daquele site |
| Limiar de alarme | não | precisa ser recalibrado com dado local |
| Integração com MES e HMI | sim | se os sistemas forem os mesmos |
| Procedimento de resposta | sim | é processo, não modelo |
O que dá trabalho é replicável; o que parece o produto (os pesos) não é. O segundo site custa bem menos que o primeiro, desde que o primeiro tenha sido construído pensando no segundo.
O que precisa existir para replicar
Quatro peças, todas de engenharia, nenhuma de modelagem:
Padrão de nomes e modelo semântico. Se cada planta nomeia suas variáveis à sua maneira, cada replicação recomeça do dicionário. Um endereçamento hierárquico comum (planta, área, linha, máquina, variável) é o que transforma replicar em configurar.
Registro de modelos com versão. Qual versão roda em qual planta, treinada com que dado, desde quando, com que desempenho medido. Sem isso, seis meses depois ninguém sabe qual modelo está onde.
Monitoramento de deriva. O processo muda com matéria-prima, desgaste e estação do ano. Um modelo que era bom degrada silenciosamente, e a degradação aparece primeiro na distribuição das entradas, antes de aparecer no resultado. Sem esse monitoramento, o ganho do ano 1 evapora no ano 2 sem que ninguém saiba por quê.
Rotina de retreino. Quem decide, com que gatilho, com que validação antes de subir. É a diferença entre um projeto e um sistema.
Deriva: como o ganho do ano 1 evapora no ano 2
Há uma forma de perder o ganho que não tem nada a ver com replicação, e que atinge até quem ficou numa planta só. Vale nomear porque ela é silenciosa.
Deriva de dado é quando a entrada muda de distribuição: trocou o fornecedor da matéria-prima, o mancal foi substituído, a estação do ano mudou a temperatura ambiente. O modelo continua recebendo números plausíveis e já não está vendo o mesmo processo.
Deriva de conceito é quando a relação entre entrada e saída muda: a manutenção passou a trocar a peça antes, então o padrão que antecedia a falha deixou de aparecer. O modelo fica cada vez mais confiante num padrão que a operação eliminou.
No segundo caso, quanto melhor o projeto funciona, mais rápido ele destrói a própria base de treino. Se o modelo previne falhas, as falhas somem do histórico, e o retreino seguinte tem menos exemplos do que o primeiro.
Como detectar antes de perder
A regra prática: a deriva aparece na entrada antes de aparecer no resultado. Monitorar só o desempenho do modelo é descobrir tarde, porque o resultado só piora quando a decisão já foi tomada errada muitas vezes.
Três monitoramentos, em ordem de custo:
- Distribuição das variáveis de entrada, comparada com a do período de treino. É barato, roda sobre dado que já está passando, e pega troca de matéria-prima e falha de sensor.
- Distribuição das saídas do modelo. Se o modelo começa a alarmar duas vezes mais que na semana passada sem que nada tenha mudado na operação, algo mudou na entrada.
- Desempenho contra o real, quando há rótulo. É o mais confiável e o mais lento, porque depende de a falha acontecer para saber se a previsão estava certa.
Uma decisão de processo vale mais que os três: definir o gatilho de retreino antes de subir, por tempo, por volume de deriva ou por queda de desempenho, com quem aprova e como se valida. Sem isso, o retreino acontece quando alguém reclama, que costuma ser meses depois de o ganho ter sumido.
O custo que ninguém coloca no business case
Há um número que muda a conta da replicação: cerca de 20% das organizações já relatam que o custo operacional de IA restringe o uso (McKinsey, 2026).
Replicar não é só implantar N vezes. É manter N vezes: N modelos monitorados, N conjuntos de limiares recalibrados, N integrações que quebram quando alguém atualiza o MES de um site.
A pergunta que o business case do piloto quase nunca responde: qual é o custo de operar esse modelo daqui a um ano, multiplicado pelo número de plantas?
O que fazer diferente no primeiro site
A conclusão prática é sobre como o primeiro projeto é montado.
Escolha o primeiro site pensando no segundo. O site mais fácil dá o piloto mais rápido e a replicação mais difícil, porque nada do que foi feito lá serve para o resto da rede. O site mais representativo dá um piloto mais lento e uma replicação viável.
Defina a variável alvo e o indicador uma vez, para a rede. É a parte que viaja, e a que mais se perde quando cada planta define a sua.
Construa o pipeline como produto, não como projeto. Coleta, contextualização e integração pensadas para serem configuradas em outro site, não recriadas.
Meça na rede desde o começo. Se o indicador só existe na planta piloto, não haverá como demonstrar o efeito consolidado, que é o que o board cobra.
O Fórum Econômico Mundial resume assim: "os verdadeiros vencedores não são os que pilotam mais tecnologias, mas os que escalam com sucesso suas inovações de maior valor". A transformação acontece quando o valor é quantificado, rastreado continuamente e escalado entre sites e funções.
Três perguntas antes do próximo piloto
- O ganho foi medido em uma planta ou na rede? Linha de base construída depois do projeto não é linha de base: é justificativa.
- O que exatamente vai ser replicado? Se a resposta for "o modelo", a replicação vai custar quase o mesmo que o primeiro site.
- Qual é o custo de operar isso daqui a um ano, vezes o número de plantas? É o número que decide se a rede inteira é viável ou se o caso de uso morre no terceiro site.
