A decisão estratégica da IA corporativa não é o modelo

Há poucos meses, uma empresa decidiu iniciar sua jornada de inteligência artificial. Depois de semanas de análise comparativa, o comitê executivo chegou a uma conclusão que pareceu profundamente estratégica: padronizar toda a companhia no Modelo X. Ele liderava os benchmarks, era o mais comentado do mercado e prometia resolver praticamente qualquer problema. Seis meses depois, um novo modelo apareceu, mais barato, mais rápido e melhor em várias das tarefas que importavam. E a discussão recomeçou do zero. Migrar ou não migrar?

Essa cena se repete em milhares de empresas e revela um problema maior do que parece. As organizações acreditam estar tomando uma decisão sobre modelos de IA. Na prática, estão tomando uma decisão sobre arquitetura, sem saber que a estão tomando.

As melhores notícias de tecnologia B2B

Acompanhe todas as novidades diretamente na sua caixa de entrada

Não é uma percepção isolada. Em junho de 2025, o Gartner projetou que mais de 40% dos projetos de IA agêntica seriam cancelados até o fim de 2027, atribuindo os cancelamentos a três causas: custos que escalam, valor de negócio indefinido e controles de risco inadequados. Nenhuma das três é qualidade de modelo. Todas remetem a decisões de arquitetura, governança e economia que o piloto, sozinho, não resolve.

A analista responsável pela previsão foi ainda mais específica: o entusiasmo com provas de conceito cega as organizações para o custo e a complexidade reais de operar agentes em escala, e é isso que trava a passagem para produção.

O gargalo também não está na adoção. A McKinsey encontrou o mesmo contraste por outro ângulo: 88% das organizações já usam IA em pelo menos uma função, mas apenas 39% relatam algum impacto no EBIT em nível corporativo, e, entre essas, a maior parte fica abaixo de 5%. A distância entre experimentar e capturar valor não é um problema de acesso ao modelo. É um problema de transformar capacidade tecnológica em operação governável, mensurável e repetível.

A diferença não é semântica. Uma decisão de modelo tende a ser reversível: troca-se o provedor, adapta-se, mede-se de novo. Uma decisão de arquitetura define onde a execução acontece, quem a controla e quanto ela custa por unidade de negócio. Essa não se desfaz com uma troca de chave de API. É ela que determina se o piloto vira operação.

Já vimos esse filme. Quando a nuvem chegou, o mercado passou anos debatendo AWS contra Azure contra Google Cloud, como se ali estivesse a decisão estratégica. Não estava. Saíram na frente as empresas que construíram arquiteturas capazes de evoluir independentemente do provedor.

A lição mais duradoura da nuvem não foi acertar o vencedor da disputa entre provedores. Foi preservar portabilidade suficiente para que infraestrutura e aplicações pudessem evoluir em ritmos diferentes. Isso nunca eliminou o custo de migrar, mas mudou sua natureza: quando a abstração está no lugar certo, trocar de ambiente é uma decisão econômica; quando não está, é uma reescrita.

Os modelos evoluem em meses. As arquiteturas permanecem por anos.

Vale definir o termo, porque na maioria das conversas que tenho com comitês executivos ele é confundido com infraestrutura. Quando falo em arquitetura, não me refiro a servidores nem a provedores de nuvem, mas à camada que governa como modelos, agentes, ferramentas, políticas, dados e sistemas corporativos operam em conjunto ao longo de uma transação de negócio e, sobretudo, a quem pertence essa camada.

O piloto esconde as perguntas difíceis

Ao longo dos anos, aprendi a desconfiar menos do piloto que falha do que do piloto que funciona.

Quase toda empresa consegue construir um bom piloto. Um copiloto de atendimento ou uma automação de processo interno funciona, impressiona o comitê e produz um ganho mensurável. O travamento vem depois, quando o experimento precisa atender centenas de milhares de usuários sob requisitos reais de custo, segurança e auditoria.

A explicação costuma ser cultural: falta maturidade de dados, patrocínio ou gente. Às vezes é verdade. Mas, na maioria dos casos que acompanhei, a causa é mais específica. O piloto funciona justamente porque adia as perguntas difíceis.

O tamanho do problema está medido. Em 2026, uma pesquisa global da Deloitte com mais de três mil executivos apontou que apenas 25% das organizações haviam levado à produção 40% ou mais de seus experimentos de IA. A explicação que a própria Deloitte oferece é a que encontro em campo: o piloto roda com uma equipe pequena, dados tratados e um ambiente isolado, enquanto a produção exige integração, revisão de segurança, conformidade e monitoramento contínuo.

Em um piloto há um agente, um usuário por vez, um caminho feliz e nenhuma concorrência. A arquitetura é invisível, não porque seja simples, mas porque nada a estressa. O modelo é a única variável que se move, então parece ser a única que importa. É um erro de observação, não de raciocínio.

Convém delimitar a tese. Nem tudo precisa de um modelo: o que pode ser resolvido de forma determinística deve continuar determinístico, e o probabilístico entra onde realmente agrega valor. Se o caminho da execução é definido em tempo de projeto, em um fluxo determinístico que chama um modelo em pontos fixos, os controles convencionais bastam. O argumento muda quando o próprio caminho passa a ser decidido em tempo de execução, sob custo, auditoria e consequência real. É aí que os pilotos morrem.

E há um vetor de dependência que este artigo deixa de fora: os dados. Reindexar um corpus, trocar um modelo de embedding ou migrar milhões de vetores costuma custar mais que reescrever agentes. É um problema real, de outra natureza, e merece tratamento próprio.

Produção estressa tudo ao mesmo tempo. E revela que as decisões arquiteturais já haviam sido tomadas meses antes, por omissão, quando alguém escolheu construir o piloto dentro de uma plataforma específica porque era o caminho mais curto até a demonstração. O custo dessa velocidade aparece depois, por três mecanismos concretos, nenhum deles relacionado à qualidade do modelo.

O primeiro mecanismo: a unidade econômica muda de lugar

No piloto, o custo de IA é medido em tokens. É a métrica que o provedor entrega e, nesse estágio, costuma bastar: o volume é pequeno e o orçamento é de inovação, não de operação.

Em produção, a unidade que importa é o custo por transação de negócio concluída: uma proposta de crédito analisada, uma fatura conciliada. Mas uma transação em um sistema agêntico não é uma chamada. É uma trajetória, com múltiplas invocações de modelo, acessos a ferramentas e sistemas de registro, tentativas que falham e se repetem, ramificações alternativas e, às vezes, vários agentes colaborando.

O Gartner quantificou o efeito: rotear uma tarefa para um modelo agêntico de raciocínio eleva o custo de inferência em pelo menos cinco vezes em relação a um chatbot simples, e muito mais conforme a complexidade cresce. Isso acontece porque uma única solicitação pode se desdobrar em múltiplas chamadas ao modelo, uso de ferramentas, verificações e novas tentativas.

O custo real está distribuído por essa trajetória inteira, e a maioria das empresas não consegue medi-lo. A instrumentação foi desenhada para contar chamadas, não para reconstituir transações. O diretor financeiro pergunta quanto custa atender um cliente com IA e a resposta honesta é que não se sabe. Ninguém aprova a escala de algo cujo custo unitário é desconhecido. O projeto não morre por rejeição, morre por impossibilidade de aprovação.

Sem medição não existe controle. Não se impõe um teto de gasto a uma transação quando não se sabe onde ela começa e termina. O que existe são limites por chamada, que não protegem de quase nada: uma trajetória de cem chamadas baratas custa mais que uma de três caras, e nenhum limite por chamada percebe a diferença.

O segundo mecanismo: o piloto não tem trajetória

Em produção, uma decisão do agente deixa de ser uma chamada isolada e passa a fazer parte de uma trajetória com consequências. Idempotência: se um agente repete uma operação porque a primeira tentativa pareceu falhar, o cliente é cobrado duas vezes? Compensação: quando o quinto passo falha, quem desfaz os quatro anteriores, e em que ordem? Autorização sensível ao contexto: uma ação legítima no início do processo pode ser inaceitável depois que outras decisões já foram tomadas, e uma verificação que enxerga apenas a chamada isolada não distingue os dois casos.

Nada disso é novidade conceitual. É o repertório clássico de sistemas distribuídos. A novidade é que o caminho da execução não é definido em tempo de projeto. Ele é decidido pelo próprio modelo e muda a cada requisição, de modo que não é possível enumerar antecipadamente os fluxos que precisam ser protegidos: eles não existem antes de acontecerem.

Quando apresento esse ponto a lideranças técnicas, é aqui que a discussão muda de lugar. Governança deixa de ser algo que se verifica em revisão de arquitetura e passa a ser aplicada durante a execução, com conhecimento do que já ocorreu na trajetória. É uma mudança de natureza, não de grau, e é a razão pela qual painéis de observabilidade não resolvem sozinhos: contam o que aconteceu depois que aconteceu. Em uma transação que movimenta dinheiro ou compromete a empresa perante um cliente, saber depois é tarde.

Leia mais: Especial IT Forum 35 anos: tecnologia com alma será essencial para o futuro dos negócios

O terceiro mecanismo: escolher o modelo é escolher a plataforma de execução

As grandes plataformas de IA não vendem modelos; vendem ambientes completos, nos quais orquestração, memória, ferramentas, observabilidade e segurança vêm no mesmo pacote. É uma oferta legitimamente boa e reduz drasticamente o tempo até o primeiro resultado.

Mas o pacote carrega uma propriedade que raramente entra na análise. Ao adotá-lo, a empresa não escolheu apenas onde o modelo é inferido. Escolheu onde a execução de negócio é controlada. As regras de custo, as políticas de autorização, a lógica de recuperação de falhas e o registro de auditoria passam a viver dentro do ambiente do fornecedor.

A consequência aparece na primeira tentativa de mudança. Trocar de modelo pode parecer simples quando o acesso é mediado por interfaces padronizadas.

Considere um banco que construiu seu primeiro agente de análise documental dentro da plataforma de um fornecedor. Meses depois surge um modelo sensivelmente mais barato e melhor naquela tarefa. A troca parece uma decisão de uma semana, até o time descobrir que a memória do agente, o catálogo de ferramentas, as políticas de autorização e a trilha de auditoria também pertencem à plataforma original.

O modelo se troca em dias. A camada de controle, não. O projeto permanece onde está, não porque aquela seja a melhor tecnologia disponível, mas porque ninguém orçou a reescrita que a mudança exige.

O custo disso não é perder a próxima capacidade de fronteira: a distância entre os modelos de topo é menor do que o marketing sugere. É perder opcionalidade: não aproveitar uma queda de preço, não usar um modelo pequeno onde ele bastaria ou não sair quando o fornecedor muda os termos. A dependência não cobra pedágio no contrato. Cobra na margem.

Convém ser preciso: o problema não é usar uma plataforma, nem a alternativa é construir tudo internamente. Uma camada de controle caseira, complexa e sem dono claro, aprisiona tanto quanto a de um fornecedor. O problema é permitir que a escolha da plataforma decida, por omissão, onde ficam as regras de negócio.

Daí a inversão que quase ninguém faz. A empresa acredita estar presa ao fornecedor, quando na verdade está presa às próprias decisões de arquitetura. O aprisionamento não foi imposto de fora: foi construído em casa, uma escolha de conveniência por vez.

O que muda quando a decisão é tratada como arquitetural

Tratar a adoção de IA como decisão de arquitetura significa preservar três propriedades, independentemente de quantos fornecedores existam no desenho.

A primeira é a reversibilidade. A empresa precisa conseguir responder, com um número, quanto custa trocar de modelo ou de plataforma de agentes. Se ninguém sabe, o custo é alto. Se o número existe e é aceitável, a dependência passa a ser uma escolha, não uma armadilha.

A segunda é governança aplicada em linha. As políticas que realmente importam, como orçamento, autorização e limites de ação, precisam ser aplicadas no caminho da execução, com conhecimento da trajetória, e não conferidas depois em um relatório. Um controle que apenas observa não é um controle.

A terceira é o custo atribuído à transação de negócio. Enquanto a única métrica disponível for o token, a conversa com a área financeira será sempre uma negociação de fé. Com custo por transação concluída, ela vira uma discussão de margem, conversa que a empresa sabe conduzir há décadas.

Isso também muda o papel humano. Em escala enterprise, o especialista não pode permanecer no loop apenas para validar cada decisão da IA. Precisa estar acima do loop: definir políticas, limites, exceções e níveis de autonomia dentro dos quais o sistema pode operar — preservando validação humana para exceções e decisões de maior risco ou impacto. O humano deixa de controlar cada decisão para definir o espaço em que as decisões podem ser tomadas.

A passagem do piloto para a Enterprise AI não acontece quando o modelo fica melhor. Acontece quando a arquitetura torna sua execução governável, mensurável e reversível em escala.

Nenhuma dessas três propriedades depende de qual modelo está por baixo. É precisamente esse o ponto.

A pergunta que precede o próximo piloto

Existe um teste simples, e não é técnico. Antes de aprovar a próxima prova de conceito, o executivo deveria fazer uma única pergunta ao time: se daqui a doze meses quisermos trocar o modelo e a plataforma que estamos prestes a adotar, o que exatamente teremos de reescrever?

Se a resposta for “apenas a configuração de acesso”, a organização está tomando uma decisão de modelo, e ela é reversível. Se a resposta envolver as regras de custo, as políticas de autorização, a lógica de recuperação de falhas e a auditoria, então a decisão em pauta nunca foi sobre modelo. É uma decisão de arquitetura, provavelmente uma das mais consequentes que a empresa tomará nesta década.

A primeira geração da IA corporativa foi marcada pela corrida aos modelos. A próxima será marcada pela corrida às arquiteturas. E o paradoxo dos pilotos que não escalam não se explica apenas por imaturidade tecnológica. Explica-se, sobretudo, por um erro de enquadramento: milhares de organizações tomam decisões estruturais de longo prazo com o processo decisório reservado a experimentos de curto prazo.

O piloto é barato justamente porque adia todas as perguntas difíceis. A conta chega quando ele tenta virar operação. Nesse momento, o que está sobre a mesa não é mais uma escolha de modelo. Nunca foi.

Siga o IT Forum no LinkedIn e fique por dentro de todas as notícias!