Por que o piloto de IA não vira produção: os quatro bloqueios que não são do modelo
Oitenta e oito por cento das grandes empresas brasileiras já têm alguma iniciativa de inteligência artificial. Quarenta e oito por cento continuam em piloto.
Os dois números são da pesquisa Antes de TI, a Estratégia 2026, feita pelo IT Forum com 243 grandes empresas, e juntos eles descrevem uma situação específica: metade do mercado provou que a coisa funciona e não conseguiu colocar em produção. Não é ceticismo. É travamento.
A explicação que circula nos eventos é que falta maturidade, ou dado, ou gente. Nossa experiência aponta outra coisa, menos confortável: o que trava o piloto quase nunca tem a ver com o modelo. Tem a ver com quatro assuntos entediantes que ninguém quer discutir numa reunião sobre IA.
O que muda entre o piloto e a produção
Vale nomear a diferença antes de listar os bloqueios, porque ela explica todos eles.
No piloto, uma pessoa está olhando. Ela escolhe os casos, confere o resultado, corrige o que saiu torto e conta a história na apresentação. O sistema não precisa saber o que fazer quando não sabe — a pessoa sabe.
Em produção ninguém está olhando. O acerto vira lançamento, o erro vira lançamento também, e a descoberta acontece semanas depois, na conciliação. Tudo o que a pessoa fazia sem perceber precisa virar desenho.
É a mesma razão pela qual a autonomia herda o ambiente: dar autonomia remove o último sensor humano de um ambiente que talvez não tenha nenhum outro. Os quatro bloqueios abaixo são, cada um, um sensor que precisa ser construído no lugar dele.
Bloqueio 1 — com que identidade ele age?
É a pergunta que encerra mais projeto de IA do que qualquer limitação técnica, e ela costuma aparecer tarde: quando o processo roda sozinho, qual usuário assina o lançamento?
No piloto, roda com o usuário de quem está demonstrando — que normalmente tem acesso amplo, porque é quem construiu. Em produção isso não se sustenta: um processo automático com permissão de gente é um achado de auditoria esperando acontecer.
E aí a conversa deixa de ser sobre IA e vira desenho de perfil. Que atividade esse processo precisa? Só exibir, ou também alterar? Sobre quais dados, de quais empresas? Quem responde pelo que ele fizer?
É um trabalho conhecido, mas é outro trabalho — e é onde a maioria dos pilotos descobre que ninguém reservou tempo para ele. Vale entender antes como catálogo, espaço e atividade se dividem num perfil, porque as três camadas aparecem todas aqui.
Bloqueio 2 — o que acontece quando a mesma coisa chega duas vezes?
Piloto processa uma lista. Produção recebe eventos, e evento se repete: o tempo limite estourou do outro lado, a fila reenviou, alguém reprocessou uma mensagem que já tinha passado.
Um processo determinístico repetido gera duplicata, o que já é ruim. Um processo com IA repetido pode gerar duplicata diferente — porque não há garantia de que a segunda passagem decida igual à primeira. Isso transforma um problema conhecido num problema que ninguém sabe investigar.
A solução é a mesma de qualquer integração séria — uma chave que identifica a operação e uma resposta de “já processei” —, e ela precisa ser decidida antes, não depois. O mecanismo está detalhado em pedido faturado duas vezes: por que a mesma mensagem chega duas vezes.
Bloqueio 3 — para onde vai o que ele não resolve?
Todo piloto tem uma taxa de acerto e ela é sempre boa, porque os casos foram escolhidos. Em produção chega o resto: o documento ilegível, o fornecedor novo, o caso que não estava na amostra.
A pergunta que decide se vai para produção não é “qual a taxa de acerto”, é “o que acontece com os que ele não acerta”. Precisa existir uma fila de exceção com dono, prazo e um caminho de volta — e alguém precisa aceitar que essa fila existe.
Projetos que prometeram automação total costumam travar exatamente aqui, porque assumir a fila de exceção parece assumir fracasso. Não é: é a diferença entre um sistema honesto e um que esconde o problema até a conciliação.
Bloqueio 4 — quem explica a decisão daqui a seis meses?
Auditoria não pergunta se o modelo é bom. Pergunta por que aquele documento foi classificado daquele jeito, em março.
Se a resposta depende de rodar de novo e torcer para dar igual, não há resposta. Produção exige registrar a decisão junto com o que a sustentou: qual entrada, qual versão, qual regra, qual foi a alternativa descartada. Isso é log, não é IA — mas é obrigação de quem coloca um processo automático em cima de dado fiscal ou contábil.
O que dá errado, com nome
Escolher o caso pela facilidade técnica. O primeiro piloto costuma ser o que era mais fácil de demonstrar, não o que doía mais. Ele funciona, encanta, e não gera pressão para resolver os quatro bloqueios — porque ninguém sente falta dele em produção.
Medir o piloto pela taxa de acerto. É a métrica do laboratório. A métrica de produção é custo por transação, tempo até detectar erro e tamanho da fila de exceção.
Deixar segurança para o fim. Quando a identidade do processo entra em discussão depois do piloto pronto, o resultado costuma ser refazer o desenho — ou colocar em produção com permissão demais, que é pior.
Prometer que não haverá exceção. Compra-se aprovação e perde-se credibilidade no primeiro mês.
Tratar dado ruim como problema da IA. Cadastro inconsistente derruba processo automático com ou sem modelo. Se o piloto brilhou, boa chance de ter rodado sobre uma amostra limpa que não representa a base.
O limite honesto
Nada disso é argumento contra IA — é a lista do que separa um bom experimento de um sistema. As quatro perguntas são as mesmas que se faz a qualquer automação; a diferença é que com IA elas são ignoradas com mais frequência, porque a demonstração impressiona e a conversa vai para o modelo.
Também é honesto dizer que resolver os quatro não garante retorno. Um processo automático bem construído sobre um processo de negócio ruim entrega o mesmo resultado ruim, mais rápido. A pergunta anterior a todas — esse processo deveria existir desse jeito? — continua sendo de gente.
E há uma consequência de prazo que muda o planejamento: o trabalho dos quatro bloqueios costuma ser maior que o do piloto. Quem planeja a entrada em produção como “mais duas semanas depois da prova de conceito” está planejando errado.
Se o ponto de partida é entender o ambiente antes de automatizar qualquer coisa nele, comece pelo diagnóstico de TI. Se o interesse é ver a IA aplicada num processo real, com o limite dito na cara, veja ler o XML e classificar dentro do SAP. E para o panorama de arquitetura, IA corporativa: o desafio não é o modelo, é a arquitetura.