IA em produção: o gargalo é a arquitetura, não o modelo

Existe uma cena que se repete em empresas de todos os tamanhos: o piloto de IA funciona, a diretoria aplaude, o projeto vai para produção — e três meses depois o sistema está lento, caro e ninguém sabe explicar por que uma resposta saiu errada.

A tese é direta: o modelo é a parte menos problemática de uma aplicação de IA em produção. O que separa um demo de um produto é a arquitetura ao redor — filas, observabilidade, fallback, versionamento de prompts e controle de custo por token. Quem trata isso como detalhe de infraestrutura está construindo dívida técnica com juros compostos.

Os números confirmam o gargalo. Segundo a McKinsey Global Survey on AI, cerca de 40% das empresas que adotam IA a utilizam em pelo menos um processo de negócio — mas menos de 25% conseguiram integrá-la em várias funções. A passagem do piloto para a produção ampla é onde os projetos morrem. E não morrem por falta de modelo bom: morrem por falta de engenharia.

O modelo é uma etapa, não o sistema

A documentação de arquitetura de aplicações de IA da Microsoft para startups é explícita nesse ponto: cada chamada de modelo deve ser tratada como parte de um fluxo orquestrado, com etapas mensuráveis — fila, recuperação de dados, execução do modelo, ferramentas, verificações de segurança, resposta ao usuário.

Isso muda o desenho do backend. Em vez de o serviço chamar o LLM de forma síncrona e rezar, arquiteturas maduras colocam filas assíncronas entre a API e o serviço de inferência. A fila absorve picos, desacopla componentes e impede que a latência do modelo derrube o resto do sistema. Arquiteturas de referência para produtos com IA — como as descritas pela brasileira Orbesoft — separam explicitamente backend, serviço de ML e camada de orquestração de dados, com mensageria entre eles.

Parece básico. Não é. Boa parte dos pilotos que chegam à produção é, na prática, um endpoint chamando uma API de LLM diretamente. Funciona no piloto. Em escala, vira incidente.

Medir a média é mentir para si mesmo

A segunda diferença entre demo e produto é o que se mede. A recomendação da Microsoft é decompor a latência ponta a ponta em métricas específicas: TTFT (Time To First Token), latência total, percentis p95 e p99, utilização de tokens por requisição e atraso em fila.

O detalhe dos percentis importa. Uma latência média confortável pode conviver com um p99 inaceitável — e esse 1% de requisições lentas costuma vir justamente dos usuários que fazem as perguntas mais complexas e valiosas. A média esconde exatamente o que precisa ser corrigido.

E observabilidade de IA tem três camadas, não uma. O material da Orbesoft organiza bem: métricas de infraestrutura (latência, throughput, erro), métricas de modelo (acurácia, drift, taxa de inferência bem-sucedida) e métricas de negócio (conversão, churn, receita por usuário) — com SLOs específicos e alertas que correlacionam as três. Um modelo pode estar tecnicamente saudável e degradando o negócio em silêncio. Sem a terceira camada, você só descobre no fechamento do trimestre.

Fallback não é plano B — é requisito de qualidade

O terceiro padrão é tornar as falhas previsíveis. A orientação da Microsoft é definir timeouts explícitos para cada dependência — modelo, recuperação, ferramentas, APIs —, limitar novas tentativas e desenhar um caminho primário (modelo rápido e barato) com rotas alternativas: um modelo mais caro, ou simplesmente regras de negócio determinísticas quando a IA não responde.

A pergunta que todo gestor deveria fazer ao time é: o que acontece quando o modelo não responde dentro do timeout? Se a resposta for silêncio, o sistema não está pronto para produção. Fallback deixou de ser "nice-to-have" e virou critério de aceite — e a Gartner projetava que, até 2024, 60% dos modelos de IA seriam incorporados a aplicações via práticas contínuas de MLOps, contra 20% em 2022. O mercado profissionalizou. Quem não acompanhou está operando artesanato em escala industrial.

Prompt é código. Token é custo de infraestrutura

Dois pontos ainda são tratados com amadorismo generalizado.

Primeiro, versionamento de prompts. Guias de MLOps consolidaram o registro de modelos com metadados — versão, data de treino, métricas, rollback automatizado. Mas o mesmo rigor raramente é aplicado aos prompts, que na prática são lógica de negócio. Uma mudança de três palavras num prompt de produção pode alterar o comportamento do sistema tanto quanto um deploy de código — e frequentemente é feita direto num painel, sem versionamento, sem teste, sem trilha. Prompts precisam ser artefatos versionáveis, com A/B testing e tráfego de avaliação isolado do tráfego real, como a própria documentação da Microsoft recomenda.

Segundo, custo. O IDC projeta que os gastos mundiais em sistemas de IA cheguem a cerca de US$ 500 bilhões em 2027, crescendo a 27% ao ano. No nível da aplicação, isso se traduz em tokens: o custo é proporcional à quantidade de tokens processados. As práticas recomendadas são conhecidas — orçamento de contexto por requisição, recuperação restrita ao necessário, cache de resultados repetidos, estado compacto entre etapas —, mas exigem que alguém trate token como linha de custo de infraestrutura, com dono e meta. Na maioria das empresas, ninguém tem esse chapéu.

O risco que não aparece no slide: rotas opacas

Há um efeito colateral pouco discutido dessa sofisticação toda. Quando você combina fallback, orquestração dinâmica, caching e paralelização de etapas, o sistema passa a tomar decisões de caminho — qual modelo, qual prompt, qual ferramenta — que são difíceis de reconstruir depois.

É a dívida de observabilidade lógica: você tem métricas de latência e erro, mas não consegue responder por que a rota B foi escolhida em vez da A, ou se o fallback foi acionado naquela requisição específica. Sem logs estruturados de decisão, a arquitetura vira caixa preta. E a Deloitte, no "State of AI in the Enterprise", aponta que cerca de 50% dos líderes de IA colocam governança e controle de riscos entre as três principais barreiras para escalar. Em setores regulados, essa opacidade não é desconforto técnico — é passivo jurídico.

O que isso significa para empresas brasileiras

No Brasil, esse tema tem um agravante regulatório. A LGPD já impõe obrigações sobre dados que atravessam toda a arquitetura — data lakes, logs, datasets de treino e inferência. A Estratégia Brasileira de IA (EBIA) pressiona por transparência e explicabilidade. E os projetos de lei sobre IA em discussão no Congresso tendem a exigir rastreabilidade para sistemas de alto risco — exatamente o que arquiteturas opacas não entregam.

Para jurídico, saúde e financeiro, a conclusão é uma só: a capacidade de reconstruir a rota de uma decisão — qual modelo, qual versão de prompt, quais dados, fallback acionado ou não — deixará de ser boa prática e virará exigência de auditoria.

A boa notícia é que nada disso exige invenção. Os padrões existem e estão documentados: filas para desacoplar, TTFT e p99 como KPIs, timeouts e rotas de contingência, prompts versionados como código, orçamento de tokens com dono, logs de decisão estruturados. O que exige é decisão de gestão: tratar IA em produção como engenharia de sistemas distribuídos, com o mesmo rigor que se cobra do resto do stack.

O modelo você aluga de qualquer fornecedor. A arquitetura ao redor dele é o que, daqui a dois anos, vai separar quem tem um produto de quem tem um piloto eterno.

IA em produção não quebra no modelo. Quebra na fila, no timeout e no token