O piloto do agente de triagem de chamados rodou liso por três semanas. Fila de teste, banco de dados limpo, um sistema só para consultar. Quando a operação pediu para ligar o agente ao ERP de verdade, ao CRM da equipe comercial e ao sistema de estoque que ninguém atualiza direito há dois anos, o projeto travou. Não foi o modelo que parou de funcionar. Foi a cola entre os sistemas, que nunca tinha existido.
Essa história se repete tanto que virou dado. Um estudo da Forrester Consulting encomendado pela FPT Corporation, publicado em 8 de julho de 2026 com 397 líderes de tecnologia e negócio da América do Norte, Europa, Ásia-Pacífico e Japão, perguntou onde a IA trava ao sair do piloto. A resposta não foi modelo, não foi talento, não foi orçamento. Complexidade de integração ficou em primeiro lugar, citada por 41% dos respondentes. Silos de dados vem logo atrás, com 38%. No fim da conta, só 26% das empresas se consideram avançadas em operacionalizar IA de verdade.
Faz sentido quando se olha o tamanho do piloto e o tamanho da produção lado a lado. O piloto toca um sistema, às vezes dois, e roda com um recorte de dado que alguém exportou e limpou à mão numa tarde. A produção toca o ERP, o CRM, a planilha que virou banco de dados sem ninguém perceber, o sistema legado que só uma pessoa do financeiro sabe operar. Cada um desses sistemas tem seu próprio formato de data, seu próprio jeito de marcar um campo como vazio, sua própria versão da verdade sobre o mesmo cliente. O modelo lida bem com ambiguidade de linguagem. Lida mal com um CPF que chega com máscara em um sistema e sem máscara em outro.
A gente vê isso direto quando entra num projeto depois que o piloto já rodou em algum canto da empresa. O time mostra o piloto funcionando e pergunta por que não sobe pra produção, já que está pronto. A resposta quase nunca tem a ver com o agente. Tem a ver com o fato de que ninguém mapeou, antes de começar, quais sistemas ele ia precisar tocar quando saísse do ambiente controlado.
O que checar antes de tirar o piloto do ambiente controlado
Isso vira uma lista curta, e dá para rodar antes de qualquer linha de código de produção:
- Mapear cada sistema que o agente vai ler ou escrever em produção, não só os que ele tocou no piloto.
- Para cada sistema, definir quem é o dono do dado e quem responde se o campo mudar de formato sem aviso.
- Testar o agente com o dado sujo de verdade, não com a amostra limpa preparada para a demonstração.
- Decidir o que o agente faz quando um dos sistemas está fora do ar: espera, segue sem aquele dado, ou para e chama um humano.
- Escrever, numa frase, quem aprova a mudança quando o contrato de uma API muda do lado de fora.
Nenhum item exige framework novo ou reunião de arquitetura de três dias. Exige sentar com quem cuida dos dados antes do piloto, não depois que ele já funcionou.
| Piloto | Produção | |
|---|---|---|
| Sistemas tocados | 1 a 2 | Todos os que o processo real usa |
| Origem do dado | Amostra exportada e limpa | Dado vivo, com inconsistência |
| Falha de um sistema | Para o teste, sem custo | Trava a operação, tem custo |
| Dono do dado | Quem rodou o piloto | Precisa estar definido antes |
O ponto que mais chama atenção no estudo não é a integração em si, é a distância entre quem diz que IA é prioridade e quem organizou o time em volta disso. Segundo o mesmo levantamento, só 39% das empresas relatam progresso real em alinhar estratégia, governança e modelo operacional em torno da IA. A tecnologia andou mais rápido que a operação que precisa sustentar ela.
Isso muda a pergunta de um diagnóstico. Em vez de "esse processo é bom candidato para IA", a pergunta vira "quantos sistemas esse processo toca, e quem é dono de cada um deles". Um processo que parece simples no fluxograma pode tocar seis sistemas diferentes na hora de rodar. Um processo que parece complexo pode tocar só um. O critério de prioridade muda de figura quando o dono de cada integração já está mapeado, porque aí o piloto que funciona tem para onde ir.
Na Overflow, essa é uma das razões para tratar diagnóstico e piloto como fases separadas: o diagnóstico mapeia o processo e os sistemas que ele toca antes de qualquer linha de código, para que o piloto já nasça sabendo o caminho até a produção, em vez de descobrir na marra que esse caminho não existe. Tem mais sobre como isso funciona em /ia-first.
Para segunda de manhã: pega o próximo piloto de IA que está rodando ou prestes a rodar na sua empresa e lista, numa folha só, todos os sistemas que ele vai precisar tocar quando sair do ambiente de teste. Ao lado de cada um, escreve o nome de quem é dono daquele dado. Se a lista tiver um espaço em branco, é ali que o piloto vai travar, não no modelo.
