Pular para conteúdo

Capítulo 2.5 — AI gateways, model gateways e governança de chamadas

🎯 Objetivo

Tratar AI gateway como ponto de governança operacional entre aplicações de IA e providers de modelo. O capítulo cobre o que um gateway resolve, o que não resolve, como avaliar e os riscos de adotá-lo cegamente.

🧠 O que é um AI Gateway / Model Gateway

Camada intermediária entre aplicações que consomem LLMs e os providers (OpenAI, Anthropic, Vertex, Bedrock, Azure OpenAI, modelos locais via vLLM, TGI, Ollama). Costuma ser um serviço HTTP/gRPC stateless ou stateful com backing store para budgets e logs.

🔁 API gateway tradicional vs AI gateway

Função API Gateway tradicional AI Gateway
AuthN / AuthZ ✅ ✅
Rate limiting ✅ (req/s) ✅ (req/s + tokens/s + cost/s)
Caching Por chave/URL Prompt cache + semantic cache
Routing Por path/host Por modelo, tarefa, custo, jurisdição
Fallback Endpoint reserva Modelo reserva + retry com modelo diferente
Observabilidade Latência, status Tokens, custo, qualidade, citações
DLP / Redaction Geralmente externo Inline em prompt/output
Audit log Requests/responses Requests + tokens + decisão de policy
Budget Não Sim, por tenant/produto/agente
Versionamento API version Model + prompt + schema

Resumo: um API gateway tradicional não entende tokens, prompt caching, modelos ou risco semântico - por isso, em portfólio de LLMs, é frequente ter as duas camadas (API gateway no perímetro de rede e AI gateway específico de IA).

🧠 Capacidades comuns

Capacidade O que faz Limites
Model routing Escolhe modelo por tarefa, custo, latência, jurisdição Roteamento errado degrada qualidade silenciosamente
Fallback Tenta provedor B se A falhar/exceder SLA Pode mascarar incidentes; cuidado com cobranças em duplicidade
Retry com backoff Trata 429/5xx Pode amplificar custo se mal calibrado
Budget enforcement Bloqueia ao exceder cap por usuário/tenant Precisa de classificação fina; "tenant" mal definido vaza orçamento
Rate limiting Limita RPM/TPM/CPM (cost-per-min) Usar em camadas: cliente, tenant, agente
Tenant-level quotas Aloca capacidade por cliente Requer isolamento real, não só rótulo
Prompt caching Aproveita prefixos estáveis Precisa de prefixo determinístico + chaveamento por versão
Semantic caching Reaproveita resposta para queries semanticamente similares Risco de resposta stale ou incorreta; usar com TTL e revalidação
Observabilidade Trace por chamada, métricas custos/tokens/latência Vale OpenTelemetry GenAI conventions
DLP / Redaction Mascara PII/secrets em prompts e logs Não é defesa contra prompt injection
Audit log Registro imutável Depende de retenção e criptografia
Guardrails Classificadores e regras em runtime Mitigações, não controles (cap. 0.6)
Policy enforcement Integração com OPA/Cedar Política depende do dado contextual exposto
MCP / tools integration Roteia chamadas para MCP servers Mantém risco de tool misuse - autorização real ainda é responsabilidade do executor

🏗️ Padrões de arquitetura

aplicação ──► AI gateway ──► provider A
                     │  ├──► provider B
                     │  └──► self-hosted (vLLM/TGI)
                     ├──► cache (prompt + semantic)
                     ├──► policy engine (OPA/Cedar)
                     ├──► observability (OTel -> backend)
                     └──► budget store (Redis/SQL)

Em ambientes maduros, agentes não falam diretamente com providers; falam com o gateway. O gateway falha rápido quando há violação de budget ou policy.

🧪 Comparação neutra entre projetos amplamente usados

Postura editorial. O livro não recomenda um produto. A comparação é apenas para orientar avaliação. Verifique documentação oficial e a licença atual antes de adotar.

Projeto Modelo de licença Foco declarado Forma comum de deploy
LiteLLM Open-source (MIT) + edição empresarial Proxy unificado para 100+ providers, budgets, logs, MCP integration Container/binário; SDK Python
Kong AI Gateway Plugins sobre Kong (open-source + edição empresarial) AI proxy plugins (rate limit, prompt template, semantic cache) integrados ao Kong Kong Gateway com plugins ativados
Portkey SaaS + opção self-hosted AI gateway + observability + guardrails SaaS gerenciado ou self-hosted (planos pagos)

Outros projetos existem (cloudflare AI Gateway, Envoy AI extensions etc.). Critério de avaliação:

  1. Suporte aos providers que você usa, com paridade de feature (streaming, tool calling, structured outputs).
  2. Modelo de licença e custo total.
  3. Compatibilidade com o seu stack (observability, secrets, OPA, MCP).
  4. Como rate limiting/budget funcionam quando o provider está fora.
  5. Comportamento de cache e consistency model.
  6. Suporte a multi-tenant real (não apenas tags).
  7. Possibilidade de self-host com dados sob controle.
  8. Frequência e qualidade dos releases.

⚠️ O que AI gateways NÃO garantem

  • Não substituem autorização. Quem decide o que um usuário/agente pode fazer é IAM + policy engine, não o gateway.
  • Não impedem prompt injection. DLP e filtros heurísticos são mitigações.
  • Não eliminam alucinação. Caching pode até amplificá-la se servir resposta antiga.
  • Não suprem evals. Métrica de qualidade é responsabilidade do produto.
  • Não garantem isolamento multi-tenant. Isolamento real é storage, índices, credenciais; o gateway só observa.

🚨 Modos de falha

  • Lock-in operacional: aplicação só funciona com aquele gateway.
  • Ponto único de falha quando todo tráfego de IA passa por ele.
  • Budgets calculados a partir de tokens estimados sem reconciliação com a fatura do provedor.
  • Cache semântico devolvendo resposta de outro tenant por similarity search mal isolada.
  • Fallback automático mascarando incidente do provider primário.
  • Logs com prompts não redigidos vazando PII.
  • Falsa sensação de governança porque "passa pelo gateway".

🛡️ Controles e mitigações

  • Stateless e horizontalmente escalável; failover transparente.
  • Redaction antes de log.
  • Budget com chaves por tenant/agente e reconciliação periódica com a fatura.
  • Cache semântico sempre com filtro de tenant na chave.
  • Métricas de fallback como sinal operacional, não como tapete sob a sujeira.
  • Política de retenção dos prompts e respostas.
  • Plano de portabilidade: como migrar para outro gateway sem reescrever produto.

🧠 Token budget

Budgets sem AI gateway viram planilha. Com gateway, viram política executável. Defina por:

  • request;
  • etapa;
  • tarefa;
  • usuário;
  • tenant;
  • produto.

Sem budget, agentes podem entrar em loop e consumir orçamento mensal em horas. Veja também Capítulo 6.4 (FinOps).

📈 Métricas

  • Custo por tarefa, por tenant, por produto.
  • Hit rate de prompt cache e de semantic cache.
  • Fallback rate por provider.
  • Rejeições por budget e por policy.
  • Distribuição de latência por modelo.

📌 Checklist

  • [ ] Há gateway centralizando chamadas?
  • [ ] Há roteamento explícito por tipo de tarefa?
  • [ ] Há budget por tenant, reconciliado com a fatura?
  • [ ] Cache semântico é isolado por tenant?
  • [ ] Logs são redigidos antes de persistir?
  • [ ] Existe plano de portabilidade para outro gateway?
  • [ ] Métricas de fallback acionam alerta operacional?

🧰 Exemplos práticos relacionados (planejados)

  • EX-LLM-04 - gateway simplificado com routing, budget e redaction.
  • EX-COST-02 - gateway com semantic cache controlado por tenant.

📚 Referências