# Arquitetura de software com IA: 7 camadas novas

> Published 2026-09-16T00:02:50.583Z on https://www.crazystack.com.br/pt/p/arquitetura-de-software-com-ia-7-camadas-novas/
> Source video: https://www.youtube.com/watch?v=amvOfi86IC8

Arquitetura de software com IA muda o centro da decisão: em vez de escolher um modelo específico no código, você define intenção, gateway, avaliação e cache por fingerprint. O SDK de um fornecedor é só a ponta do problema; o que decide custo, segurança e confiabilidade é o que fica em volta da chamada ao LLM.

## Arquitetura de software com IA: o que muda de verdade

Arquitetura de software com IA desloca a decisão do nome do modelo para a intenção de negócio dentro do sistema. Em vez de fixar `gpt-4.1-mini` ou outro identificador no código, a aplicação pede "resumidor de texto" e deixa o roteamento, o timeout, o retry e o fallback para uma camada compartilhada chamada gateway de IA.

Integrar um SDK é a parte fácil. O trabalho real está em autenticação, autorização, filtros, logs, orçamento, governança, rate limiting e cache em volta da chamada. Sem essas camadas, cada equipe escolhe um modelo por conta própria e a empresa paga por contratos que ninguém negociou.

A analogia útil é com implantação de infraestrutura. Quem desenvolve uma aplicação web não escolhe se ela roda em Kubernetes ou numa VPS: pede uma máquina com determinada capacidade e um banco que aguente a carga. Com modelos de linguagem, o mesmo vale para latência, qualidade e custo.

Modelos de linguagem caminham para virar commodity, e o valor migra para a camada que decide qual deles atende cada pedido. Essa inversão explica por que a arquitetura, e não o SDK, passa a ser a habilidade escassa.

## Agentes de IA: por que markdown com prompt não basta

Agente de IA não é um arquivo markdown com um prompt dentro, embora muita implementação comece assim. O termo ficou amplo porque virou rótulo de marketing em vendas, direito, desenvolvimento e atendimento, e essa amplitude esconde o que separa um agente de um encadeamento de chamadas.

Um agente real precisa decidir quando usar ferramenta, manter estado entre turnos e devolver resultado verificável. Isso exige contrato de entrada e saída, tratamento de erro por ferramenta e observabilidade do passo a passo. Um prompt em markdown não entrega nada disso sozinho.

A proliferação de rótulos também cria confusão de escopo. Quando áreas diferentes da empresa usam "agente" para coisas distintas, o time de engenharia herda requisitos contraditórios e precisa traduzir cada caso em fluxo determinístico com pontos de controle explícitos.

## Protocolos e design patterns para sistemas agênticos

Protocolos novos surgiram para padronizar como aplicações conversam com modelos e ferramentas. O mais citado é o [Model Context Protocol (MCP)](https://modelcontextprotocol.io), que a Anthropic publicou em novembro de 2024 para padronizar a exposição de ferramentas e contexto a assistentes.

A evolução do MCP merece atenção porque muda decisões de infraestrutura. A [especificação do MCP de 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18) tornou o protocolo stateless no transporte HTTP, permitindo que servidores rodem sem sessão persistente entre chamadas. Isso simplifica escalar horizontalmente atrás de um balanceador.

Também existem protocolos de comunicação entre agentes, além do antigo repertório HTTP, gRPC e TCP que você já conhece. O detalhe prático é que você não precisa decorar a lista: precisa saber que a fronteira de integração virou uma decisão de arquitetura e que ela muda com frequência.

Design patterns para IA cumprem o papel que os padrões de orientação a objetos cumpriram nos anos 1990: dar vocabulário compartilhado. Eles reduzem o custo de discutir roteamento, memória, avaliação e fallback sem reinventar a roda em cada projeto.

## AI Gateway: roteamento por intenção entre fornecedores

Um gateway de IA recebe pedidos nomeados por capacidade e resolve qual modelo, de qual fornecedor, atende cada um. A aplicação pede "resumidor de texto"; o gateway aplica política de timeout, retry, fallback e escolha por custo, latência ou qualidade.

Esse desenho separa duas responsabilidades que costumam se misturar. O time de produto define a intenção e o critério de sucesso. A plataforma define qual fornecedor entrega aquela intenção dentro do contrato vigente, sem que cada desenvolvedor precise saber qual modelo está ativo naquele dia.

| Papel | O que faz | Onde falha sem gateway |
| --- | --- | --- |
| Roteamento de modelo | Resolve a intenção para um modelo específico | Identificador fixo no código quebra na troca de versão |
| Timeout e retry | Aplica política uniforme por tipo de pedido | Cada serviço inventa o próprio limite |
| Fallback | Redireciona para modelo alternativo quando o primário falha | Erro chega ao usuário final |
| Custo e uso | Mede consumo por equipe e por intenção | Orçamento sem dono e sem atribuição |
| Cache | Evita chamada repetida ao modelo | Conta cresce sem relação com o tráfego |

O [Model Context Protocol](https://modelcontextprotocol.io) e os gateways compartilham a mesma lógica: mover a complexidade de integração para uma camada reutilizável. Cabe avaliar soluções comerciais e opções de código aberto, mas o critério de escolha é o mesmo: política centralizada, observável e versionada.

## Avaliação automatizada: como testar um agente

Avaliação é o teste automatizado que verifica se o agente continua se comportando como esperado depois de cada mudança. Sem ela, você altera o prompt para corrigir grosseria e descobre em produção que o agendamento de reuniões parou de funcionar.

Existem dois tipos de verificação. A probabilística cria critérios mensuráveis sobre a resposta: foi gentil, agendou, repetiu palavras, escreveu mais de 300 caracteres de uma vez, transferiu para humano quando o cliente ofendeu. A determinística checa ordem ou presença de ações: chamou a ferramenta A, depois a B, depois a C — ou usou as três, em qualquer ordem.

Os dois tipos respondem perguntas diferentes e você precisa dos dois. Avaliação probabilística captura qualidade percebida; a determinística captura contrato de fluxo. Um agente que passa só na primeira pode estar agradável e quebrado ao mesmo tempo.

A consequência prática é que nenhum agente deveria ir para produção sem suíte de avaliação versionada junto com o prompt. A cada mudança de instrução, a suíte roda e mostra o que regrediu, do mesmo modo que testes unitários protegem código.

## Latência, qualidade e custo: os três tradeoffs

Toda escolha de modelo envolve três variáveis que competem entre si: latência, qualidade e custo. Você raramente melhora uma sem piorar outra, e a decisão depende do impacto do erro naquele fluxo específico.

Um exemplo ajuda. Imagine um modelo que custa um valor por milhão de tokens e acerta 80% dos pedidos. Outro acerta 85% e custa 50% mais. Trocar vale a pena? Depende de quanto os 20% de erro custam ao negócio. Em categorização tolerante, com fallback controlado, o ganho não paga a diferença. Em fluxo financeiro, provavelmente paga.

A terceira variável entra quando qualidade e custo empatam. Se a opção melhor demora 3 segundos a mais para responder, a pergunta vira se o seu caso de uso tolera essa espera. Chat conversacional tolera; validação em tempo real de transação não.

Essas contas precisam ser feitas com dados do seu próprio tráfego, não com ranking genérico de modelos. O número que importa é a taxa de acerto na sua distribuição de pedidos e o custo por pedido resolvido, não por token.

## Pipeline, mensageria e cache por fingerprint

Injetar modelos em pipelines assíncronos muda a matemática de latência. Um consumidor que respondia em milissegundos agora espera 10 segundos pela inferência, o que afeta tamanho de lote, visibilidade de mensagem, política de retry e ordenação em filas como Kafka, RabbitMQ, SQS ou SNS.

O cache de IA é o ponto mais mal compreendido. Em cache tradicional, você invalida por tempo ou por mudança de conteúdo. Em IA, a mesma pergunta pode ter resposta diferente porque uma variável invisível mudou: o modelo, a instrução, a política de acesso ou o documento de contexto.

A solução é gerar uma assinatura — um fingerprint — que combina prompt, regra, modelo, contexto e resultado final em um hash. Se o pedido seguinte produz o mesmo fingerprint, você reaproveita a resposta. Se qualquer componente mudou, o cache é invalidado e a chamada acontece de novo.

Classificar o prompt não resolve. Você pode categorizar a pergunta de mil formas, mas se o modelo ou o contexto mudou, a resposta antiga continha outro resultado e devolvê-la propaga erro com confiança. O fingerprint amarra a chave ao conjunto completo que gerou aquela saída.

## Segurança em IA: prompt não é fronteira de controle

O system prompt não é secreto e não serve como fronteira de segurança. Instruções reduzem a superfície de ataque, mas decisões críticas precisam ser tomadas fora do modelo, antes e depois de cada chamada, inclusive antes e depois de cada chamada de ferramenta.

O problema mudou de forma em relação ao SQL Injection. Em vez de aspas e parâmetros manipulados, você tem texto livre em um chat tentando induzir transação indevida ou vazamento de dado. Um funcionário pode tentar ver o faturamento de outro vendedor, e o filtro tem que barrar isso fora do modelo.

Referências úteis existem e são mantidas publicamente. O [OWASP Top 10 para aplicações de LLM](https://genai.owasp.org/llm-top-10/) de 2025 cataloga prompt injection, vazamento de dados sensíveis e consumo excessivo, e a mesma organização publicou uma lista voltada a riscos de agentes.

Auditoria, autorização e mascaramento de dado sensível ficam na aplicação, não no prompt. Logs também exigem cuidado: nunca registre tudo, porque o próprio histórico pode carregar informação pessoal que você não pode armazenar sem controle.

## Observabilidade e nuvem: traces ganham peso

Observabilidade em IA mantém os três pilares clássicos — logs, métricas e traces — com uma mudança de ênfase. O trace passa a ser o artefato mais valioso, porque mostra o passo a passo desde a chamada do modelo até cada ferramenta executada e cada resposta intermediária.

Logs continuam necessários, mas exigem política de retenção e mascaramento. Métricas respondem se o sistema está saudável em volume, latência e erro. Traces respondem por que uma resposta específica saiu errada, e é essa pergunta que domina a operação de sistemas agênticos.

Do lado de nuvem, a mudança é de volume de serviços. Plataformas como [Vertex AI](https://cloud.google.com/vertex-ai), na arquitetura do Google Cloud, somam camadas de modelos, avaliação, busca vetorial e governança que não existiam no repertório de quem só provisionava máquina e banco.

Bancos vetoriais entram na mesma lista. Busca semântica exige decidir índice, dimensão de vetor e estratégia de atualização, e essa escolha afeta custo de armazenamento e qualidade de recuperação tanto quanto a escolha do modelo.

## O que isso significa para a carreira em 2026

Saber codificar com IA virou requisito mínimo, não diferencial. Ferramentas como [Claude Code](https://www.anthropic.com/claude-code), [GitHub Copilot](https://github.com/features/copilot) e [Gemini](https://gemini.google.com) aceleram a escrita de código, e quem não usa entrega menos no mesmo prazo.

O diferencial migrou para as camadas que essas ferramentas não resolvem sozinhas: gateway, avaliação, cache, segurança e observabilidade. É aí que uma entrevista técnica em empresa grande separa quem integrou um SDK de quem projeta o sistema em volta dele.

Velocidade sem verificação não sustenta nada. Entregar mais rápido com comportamento não avaliado gera regressão silenciosa que aparece semanas depois, e o custo de corrigir em produção supera o ganho inicial.

A leitura honesta é que a base de engenharia continua valendo: contrato claro, teste automatizado, decisão documentada e medição. A IA muda onde essas práticas são aplicadas, não a necessidade delas.

## FAQ sobre arquitetura de software com IA

- **O que é um AI gateway e por que ele importa?** É uma camada que recebe pedidos nomeados por capacidade e resolve qual modelo, de qual fornecedor, atende cada um, aplicando timeout, retry, fallback e limite de custo. Ele importa porque centraliza decisões que, dispersas por serviço, geram gasto sem controle e quebra na troca de versão.

- **Preciso escolher um modelo específico no código da minha aplicação?** Não é recomendável. Fixar o identificador do modelo no código faz cada atualização do fornecedor virar refatoração. Pedir por intenção — resumidor de texto, classificador de ticket — e deixar o roteamento na camada de plataforma reduz esse acoplamento.

- **Como funciona o cache com fingerprint em aplicações de IA?** Você gera um hash que combina prompt, regra, modelo, contexto e resultado. Se um pedido posterior produz o mesmo hash, a resposta é reaproveitada. Se qualquer componente mudou, o cache é invalidado, porque a resposta antiga foi produzida sob outras condições.

- **Prompt injection pode ser resolvido com um bom system prompt?** Não. O system prompt não é secreto e não funciona como fronteira de segurança. Controles precisam rodar antes e depois de cada chamada de modelo e de ferramenta, com autorização, auditoria e mascaramento de dado na aplicação.

- **Qual a diferença entre avaliação probabilística e determinística?** A probabilística mede critérios de qualidade, como tom, tamanho da resposta ou sucesso em agendar. A determinística verifica contrato de fluxo, como ordem de chamadas de ferramenta ou presença de todas elas. Sistemas sérios usam as duas.

- **Vale a pena pagar mais por um modelo com poucos pontos percentuais a mais de acerto?** Depende do custo do erro naquele fluxo. A decisão precisa considerar latência, qualidade e preço juntos, e a conta se faz com a taxa de acerto no seu tráfego real, não com ranking genérico de fornecedor.

- **Como a latência de inferência afeta pipelines de mensageria?** Um consumidor que respondia em milissegundos pode passar a esperar segundos pela inferência. Isso obriga a revisar tamanho de lote, timeout de visibilidade, política de retry e ordenação em filas como Kafka, RabbitMQ, SQS ou SNS.

- **Traces são mais importantes que logs em sistemas agênticos?** Os dois têm papéis distintos. Logs registram eventos e exigem mascaramento de informação sensível. Traces mostram o passo a passo da chamada e das ferramentas, sendo o artefato que explica por que uma resposta específica saiu errada.

- **O que estudar primeiro para trabalhar com arquitetura de IA?** Comece pelo que sobrevive à troca de fornecedor: roteamento por intenção, suíte de avaliação, invalidação de cache, controles de segurança fora do prompt e observabilidade por trace. Codificar com assistente é o ponto de partida, não o destino.

- **Documentos de design ainda fazem sentido quando a IA lê o repositório?** Fazem, e com mais exigência de estrutura. RFCs, ADRs e documentos de produto viram contexto para o modelo; documento desatualizado ou ambíguo pode induzir decisão errada em vez de orientar.

## Transforme o vídeo em artigo com o Skala Blog

Arquitetura de software com IA mostra que o valor não está no SDK que você pluga, mas no que você projeta em volta dele: roteamento por intenção, avaliação, cache por fingerprint, segurança fora do prompt. Esse mesmo raciocínio vale para o conhecimento que hoje fica preso em vídeos e nunca chega a quem pesquisa.

Se você tem entrevistas, aulas, opiniões ou lições gravadas em vídeo, o [Skala Blog](https://skalablog.com) transforma esse material em artigo escrito. Você cola a URL do YouTube, o vídeo é transcrito e a partir da transcrição nasce um texto estruturado, pronto para revisão. Para conhecer outras ferramentas do ecossistema, vale visitar o [Crazystack](https://crazystack.com.br), projeto de [Crazystack typescript](https://crazystack.com.br) mantido pelo [Dev doido](https://crazystack.com.br).

[Skala Blog](https://skalablog.com)

[Source video](https://www.youtube.com/watch?v=amvOfi86IC8)
