Agent-native article available: Por que 95% dos projetos de IA empresarial não sobrevivem ao pilotoAgent-native article JSON available: Por que 95% dos projetos de IA empresarial não sobrevivem ao piloto
Por que 95% dos projetos de IA empresarial não sobrevivem ao piloto

Por que 95% dos projetos de IA empresarial não sobrevivem ao piloto

Há uma diferença entre uma demonstração que impressiona numa sala de reuniões e um sistema que funciona de segunda a sexta sem que ninguém precise resgatá-lo. A indústria da inteligência artificial passa dois anos construindo o primeiro com uma habilidade que não conseguiu transferir para o segundo. E o motivo não está nos modelos, que são cada vez mais poderosos.

Tomás RiveraTomás Rivera12 de junho de 20269 min
Compartilhar

Por que 95% dos projetos de IA empresarial não sobrevivem ao piloto

Há uma diferença entre uma demonstração que impressiona em uma sala de reuniões e um sistema que funciona de segunda a sexta sem que ninguém precise resgatá-lo. A indústria de inteligência artificial passou dois anos construindo o primeiro com uma destreza que não conseguiu transferir para o segundo. E o motivo não está nos modelos, que são cada vez mais potentes. Está em como se decidiu falar sobre eles e, por extensão, em como se decidiu construí-los.

O número que circula entre as equipes técnicas mais honestas do setor é difícil de ignorar: até 95% dos projetos de IA generativa em empresas não conseguem retorno de investimento mensurável, segundo a MIT NANDA Initiative, citada pela Iris.ai. Uma faixa de 70 a 95 por cento de fracasso não é um sinal de que o mercado "ainda não amadureceu". É um sinal de que algo estrutural está quebrado na forma como a tecnologia está sendo construída.

Enrique Dans, em um artigo publicado em 10 de junho de 2026 na Fast Company, aponta onde está a fratura. Não na capacidade técnica dos modelos de linguagem. Não na resistência dos funcionários. Mas em algo mais difícil de admitir para uma indústria que vive de convencer investidores: a IA empresarial foi construída sobre metáforas em vez de modelos formais. E as metáforas, por mais úteis que sejam para vender, não se industrializam.

Da linguagem poética à arquitetura que não escala

O inventário de metáforas que povoou o discurso sobre IA nos últimos dois anos é extenso e revelador. Os sistemas "lembram", "refletem", "planejam" e, no caso da técnica de "sono" que a Anthropic descreveu para seus agentes, literalmente "dormem". A documentação da API de Assistentes do Azure OpenAI descreve "threads" que armazenam o histórico de mensagens e os truncam quando a janela de contexto se esgota, apresentando isso como "memória". A equipe de engenharia da Anthropic fala de agentes de "longa duração" que devem "preservar a continuidade entre sessões".

Nenhuma dessas descrições é tecnicamente incorreta. O problema é que são descritivas quando precisam ser formais. Uma metáfora descreve. Um modelo formaliza. Essa diferença tem consequências econômicas diretas.

Quando a "memória" não é um modelo de dados, mas uma analogia operacional, não há identidade definida, não há estado persistente, não há relações com permissionamento explícito, não há restrições que o sistema garanta independentemente de quem o usa ou quantas vezes. Não há, em termos técnicos, invariantes: as regras que uma arquitetura mantém independentemente das condições externas. Sem invariantes, cada implementação é uma negociação nova. Cada implantação exige que alguém traduza a realidade operacional da empresa para a linguagem que o sistema consegue processar. E essa tradução não pode ser delegada a um template.

O resultado observável é que os principais provedores de IA de fronteira, incluindo OpenAI e Anthropic conforme descreve a reportagem de Dans, estão enviando engenheiros e equipes de campo para seus clientes empresariais para mapear fluxos de trabalho, definir restrições e conectar sistemas. O que parece um serviço premium é, na verdade, um sinal estrutural: a plataforma não consegue sozinha. Quando a tradução personalizada se torna o modo dominante de entrega, o produto deixa de ser uma plataforma e se converte em consultoria com interface tecnológica.

O custo desse modelo para os compradores é duplo. Primeiro, o gasto direto em integração sob medida que precisa ser repetida toda vez que um sistema, uma norma ou um processo interno muda. Segundo, o custo de oportunidade de não conseguir escalar: se cada nova aplicação exige a mesma intervenção manual, o retorno marginal de cada implementação adicional não melhora com o tempo. A curva de custos não cai. A promessa da plataforma não se materializa.

O padrão histórico que a indústria de IA ainda não atravessou

Dans conecta o momento atual da IA empresarial com três transições tecnológicas que de fato conseguiram se industrializar, e a comparação é incômoda para quem prefere pensar que os agentes de IA são um fenômeno sem precedente.

Edgar F. Codd desenvolveu o modelo relacional de dados nos anos setenta. Antes desse trabalho, os bancos de dados eram implementações proprietárias, cada uma com sua própria linguagem, sua própria lógica de armazenamento e sua própria forma de acesso. Depois de Codd, surgiu uma abstração formal: relações, atributos, chaves, dependências funcionais. Sobre essa formalização nasceu o SQL, e sobre o SQL surgiu um mercado de bilhões de dólares em software, integrações e serviços. O que tornou esse mercado possível não foi que os bancos de dados se tornaram mais potentes. Foi que se tornaram descritíveis com precisão suficiente para que dois sistemas independentes se entendessem sem negociação prévia.

A web seguiu o mesmo padrão. O W3C definiu recursos identificados por URIs, um protocolo sem estado formalizado na RFC 9110 e uma gramática compartilhada de métodos HTTP, códigos de status e HTML. Nenhuma empresa inventou o navegador e depois pediu aos seus clientes que contratassem consultores para interpretar o que significavam suas páginas. A gramática era pública, formal e suficientemente precisa para que qualquer desenvolvedor construísse sobre ela sem precisar ligar para ninguém.

A SAP fez o mesmo com os processos empresariais. Seu domínio em ERP não veio de ter interfaces melhores do que os consultores da época. Veio de ter formalizado a empresa como objeto técnico: dados mestres, transações, lógica contábil, estoque, compras, relações operacionais. Essa formalização tornou as implementações suficientemente repetíveis para que existissem templates, parceiros certificados, extensões e um mercado secundário robusto. A variância entre um cliente e outro se reduziu o suficiente para que o conhecimento acumulado em uma implementação transferisse valor para a seguinte.

O que esses três casos têm em comum é que o salto da capacidade para a plataforma não ocorreu porque a tecnologia melhorou. Ocorreu porque alguém definiu com precisão o que a tecnologia representava e sob quais regras operava. Nos três casos, houve um momento de formalização que precedeu o momento de escala.

A IA empresarial ainda não atravessou esse momento. Tem a capacidade. Falta a gramática.

O que a McKinsey confirma e a maioria das equipes ignora

Os números do MIT sobre fracasso não são a única evidência disponível. A pesquisa da McKinsey sobre o estado da IA, referenciada no artigo de Dans, chega a uma conclusão que deveria incomodar as equipes que medem seu progresso pelo número de pilotos lançados: as empresas que obtêm benefícios materiais da IA não são as que usam mais IA. São as que redesenharam seus fluxos de trabalho.

Essa distinção não é semântica. Usar IA sobre um processo existente produz ganhos marginais no melhor dos casos. Redesenhar o processo em torno de uma representação formal do trabalho produz algo diferente: um sistema no qual a inteligência artificial não é um acessório, mas uma condição de funcionamento do próprio processo.

Michael Hammer escreveu na Harvard Business Review que as empresas cometem um erro previsível ao adotar nova tecnologia: aceleram os processos existentes em vez de substituí-los. Dans retoma esse argumento para o momento atual. A versão contemporânea do erro de Hammer é pegar um fluxo de aprovações projetado para humanos que leem documentos em papel, adicionar um modelo de linguagem que resume os documentos e chamar isso de transformação. O processo tem a mesma estrutura causal. Apenas tem um componente mais rápido em uma etapa intermediária.

O redesenho que a McKinsey detecta nas empresas com retorno mensurável tem uma característica estrutural: há uma camada que define o que é uma entidade no negócio, quais estados ela pode ter, quais transições são válidas, quais permissões são necessárias para cada ação e quais regras não podem ser violadas independentemente da instrução que o sistema receba. Isso não é um prompt elaborado. É o que Dans chama de camada formal que a indústria ainda não construiu de maneira padronizada.

A diferença entre ter essa camada e não tê-la é auditável. Sem ela, o sistema pode dar uma resposta diferente à mesma consulta dependendo do histórico da sessão, do usuário que pergunta ou de como foi formulada a instrução anterior. Com ela, existem invariantes: o contrato com o cliente não pode ser modificado sem autorização do gerente regional, independentemente do que o agente tenha "entendido" do e-mail que leu. Essa garantia não vem do modelo de linguagem. Vem da arquitetura que o contém.

Para os setores regulados, essa distinção não é uma preferência técnica. Em serviços financeiros, saúde ou setor público, a ausência de invariantes verificáveis não é um inconveniente operacional. É um bloqueador para a implantação em escala, porque nenhuma equipe jurídica vai assinar a responsabilidade sobre um sistema que não consegue garantir consistência em suas decisões.

A próxima batalha não é entre modelos, é entre abstrações

A análise de Dans termina com uma projeção que vale a pena levar a sério como sinal estratégico: a vantagem competitiva na próxima fase da IA empresarial não será conquistada pelos provedores com os modelos mais potentes. Será conquistada por aqueles que definirem a abstração formal sobre a qual os demais constroem.

Isso abre uma pergunta com consequências concretas de mercado, ainda que a resposta ainda não esteja clara. Os candidatos naturais para definir essa abstração são vários e têm incentivos distintos. Os grandes provedores de nuvem — Microsoft, Google e Amazon — têm a distribuição e os relacionamentos empresariais, mas também têm o incentivo de manter o modelo de consultoria intensiva que gera receita por serviços profissionais. Os laboratórios de modelos como OpenAI e Anthropic têm profundidade técnica, mas construíram seus negócios em torno da capacidade dos modelos, não em torno da formalização dos processos que os cercam. As empresas de software empresarial estabelecidas — SAP, Salesforce, Oracle — já operam sobre camadas formais de dados e processos, mas sua velocidade de adaptação a novas arquiteturas tem sido historicamente lenta.

O espaço mais interessante pode pertencer a um tipo de ator que ainda não tem nome claro no mercado: um especialista em infraestrutura de conhecimento e fluxo de trabalho cuja proposta de valor não seja o modelo de linguagem, mas a camada que o torna operável dentro de uma empresa sem exigir tradução manual em cada implementação. Algo análogo ao que foi o middleware nos anos noventa, mas com a capacidade de raciocinar sobre as regras que contém.

O sinal de que esse ator está vencendo não será um anúncio de produto. Será o momento em que duas empresas de setores distintos consigam compartilhar uma implementação sem que nenhuma das duas precise ligar para um consultor para explicar o que significa "aprovado" em sua organização. Quando a gramática for suficientemente precisa para que isso aconteça, a fase artesanal da IA empresarial terá terminado. Até lá, os 95 por cento de fracasso não são um acidente estatístico. São o preço de construir sobre analogias em vez de definições.

Compartilhar

Você também pode gostar