Arquitetura de sistemas com IA: o que muda quando o modelo vira peça crítica

Todo sistema com IA em produção aprende a mesma lição, cedo ou tarde: o modelo é a parte menos previsível da arquitetura. Ele varia em latência, pode falhar de forma silenciosa, custa por token e não tem SLA no sentido tradicional. Projetar em volta disso é o que separa um protótipo de um sistema que aguenta carga real.

Arquitetura AI-first não é sobre o modelo

É sobre o que acontece quando ele demora, erra ou fica indisponível. Um sistema AI-first trata a chamada ao LLM como uma dependência externa não confiável — igual a qualquer API de terceiro — e desenha timeouts, fallback e degradação graciosa antes de desenhar o prompt.

Monólito ou microsserviços? A pergunta errada

A pergunta certa é onde fica o limite entre a lógica determinística do negócio e a lógica probabilística do modelo. Times que colocam chamadas de LLM espalhadas pelo monólito acabam com um sistema difícil de testar e de escalar de forma independente. Isolar a camada de inferência — como serviço, worker ou gateway — permite escalar, cachear e trocar de modelo sem tocar no resto do domínio.

Event-driven e arquitetura orientada a agentes

Fluxos com IA raramente são request-response puro. Um agente pode levar segundos ou minutos para completar uma tarefa, chamar ferramentas, esperar aprovação humana. Isso empurra a arquitetura para eventos: filas, workers assíncronos e state machines que sobrevivem a reinícios. Tentar forçar isso num ciclo síncrono de HTTP é a origem da maioria dos timeouts em produção.

Sistemas distribuídos: HA e escala horizontal com IA no caminho

Alta disponibilidade em sistemas com IA significa mais do que múltiplas réplicas do serviço. Significa múltiplos provedores de modelo, roteamento por saúde e custo, e processamento assíncrono como padrão — não como otimização tardia. Escalar horizontalmente uma camada de inferência exige pensar em pool de conexões, rate limits por provedor e filas que absorvem picos sem derrubar o restante do sistema.

Circuit breaker para LLMs: a peça que falta

A maioria dos sistemas tem circuit breaker para banco de dados e para APIs externas, mas não para o provedor de LLM. Isso é um erro caro. Quando um modelo começa a degradar — latência subindo, taxa de erro subindo — o sistema precisa parar de insistir, abrir o circuito, cair para um modelo menor ou para uma resposta em cache, e só voltar a tentar depois de um período de recuperação. Sem isso, uma degradação no provedor vira uma cascata de timeouts no seu sistema inteiro.

Cache multicamadas: onde o custo desaparece

Cache é a alavanca mais subestimada em arquitetura de IA. Cache semântico para respostas parecidas, cache de embeddings para não reprocessar o mesmo conteúdo, cache de resultado para consultas determinísticas dentro de um fluxo de agente. Cada camada bem colocada reduz custo de token e latência ao mesmo tempo — o tipo raro de otimização que não exige trade-off.

O ponto de partida

Antes de escolher framework de agente, banco vetorial ou estratégia de fine-tuning, vale fechar esses fundamentos: onde a inferência fica isolada, como o sistema se comporta quando ela falha, e onde o cache entra. É a base que sustenta tudo que vem depois — backend, agentes, RAG, deploy de modelo — e é o primeiro tema desta série sobre engenharia para Senior e Staff AI Engineer.