AI Gateways e roteamento de modelos: escolha de modelos e aplicação de políticas

Mesmo um pedido claro de programação deixa decisões de infraestrutura em aberto: quais modelos podem receber o código, como as requisições são encaminhadas e o que acontece quando um provedor fica indisponível. Um AI gateway é um ponto de acesso compartilhado que pode aplicar regras de uso; um roteador escolhe entre os modelos permitidos.

Este é o segundo de seis artigos sobre agentes de programação, depois de Prompt Engineering. O exemplo do desconto na finalização da compra continua aqui. Explicar as regras de preço e corrigir um erro que afeta vários serviços podem exigir modelos diferentes; a equipe precisa avaliar se essa escolha ajuda.

O que a seleção automática de modelo controla

A seleção automática de modelo é um recurso de produto, não um algoritmo universal de roteamento. Por exemplo, a documentação do GitHub descreve tanto roteamento orientado à tarefa quanto roteamento voltado à disponibilidade e confiabilidade, dependendo da interface do Copilot. As políticas do plano e do administrador também afetam os modelos elegíveis. Consulte a documentação de seleção automática de modelos do GitHub.

Não presuma que mencionar “15 arquivos” obrigue o uso de um modelo com uma janela de contexto grande, nem que escrever “raciocínio complexo” selecione um modelo específico. Descreva os requisitos reais da tarefa e confira o comportamento documentado da ferramenta.

Um AI gateway corporativo pode centralizar o acesso aos provedores, a escolha de modelos, o acompanhamento de uso e a aplicação de regras. Esses controles precisam ser configurados e verificados; o gateway sozinho não impede a exposição de dados sensíveis. Quando houver configurações explícitas de modelo ou orçamento, use-as em vez de tentar controlar a infraestrutura por meio do texto do prompt. Para saber mais sobre roteadores e gateways de IA, consulte o capítulo 10, “AI Engineering Architecture and User Feedback”, de Chip Huyen; sobre gateways de entrada, consulte o capítulo 3, “API Gateways: Ingress Traffic Management”, de James Gough, Daniel Bryant e Matthew Auburn.

Ferramentas que analisam prompts antes da execução do modelo

O prompt pode passar por outros componentes antes de chegar ao modelo. Um roteador pode classificar a tarefa para escolher um modelo. Um filtro de proteção pode permitir, bloquear ou sinalizar pedidos conforme regras configuradas. Um gateway pode conectar esses recursos à autenticação, aos limites de uso e aos registros de execução. A visão geral de AI gateways da Kong explica esse papel.

Essas ferramentas respondem a perguntas diferentes:

Ferramenta ou recurso	O que analisa	O que pode fazer
DigitalOcean Inference Router	Prompts recebidos comparados a descrições de tarefas e instruções de roteamento configuradas	Selecionar modelos de pools segundo políticas como preferência por custo ou latência, com fallback
Kong AI Proxy Advanced	Com roteamento semântico configurado, a similaridade entre o prompt e o modelo	Roteia para modelos configurados; outras estratégias usam sinais operacionais como latência ou uso
Kong AI Semantic Prompt Guard	Similaridade semântica com prompts permitidos ou negados configurados	Permite ou bloqueia requisições conforme as regras e os limites configurados
Amazon Bedrock Guardrails	Entradas e respostas segundo políticas habilitadas de conteúdo, tópicos, palavras e informações sensíveis	Filtra conteúdo segundo essas políticas; um filtro de ataques via prompt configurado separadamente trata padrões de ataque compatíveis

Os recursos dos produtos dependem da versão, da configuração e da implantação. Na revisão deste artigo, de setembro de 2026, a documentação da DigitalOcean lista o Inference Router como prévia pública. Ao configurar essas ferramentas, consulte a documentação da implementação vinculada em vez de presumir que todo gateway inclui todos os recursos por padrão.

Instruções de roteamento são diferentes do prompt do usuário

Por exemplo, uma equipe pode configurar um roteador para enviar explicações curtas de código a um grupo de modelos e tarefas de depuração a outro. Um pedido como “diagnostique este teste de integração com falha usando o registro de execução anexado” ajuda a classificar a tarefa. Ele não escolhe, por si só, um modelo específico.

A DigitalOcean permite que equipes descrevam tarefas de roteamento em linguagem natural. Essas descrições definidas pelo administrador são configuração; o prompt recebido é a solicitação que será classificada. Mantenha provedores permitidos, regras de acesso e controles de gastos em configuração confiável, em vez de aceitar as afirmações do próprio prompt sobre suas permissões.

Verificações de segurança do prompt avaliam riscos específicos

“Este prompt é seguro?” é amplo demais para ser uma garantia única. Defina o que será verificado: conteúdo proibido, informação sensível, um tópico fora do escopo ou uma tentativa de sobrepor as instruções da aplicação. Regras de similaridade semântica e classificadores de ataque têm finalidades diferentes e podem gerar falsos positivos e falsos negativos.

Confira exatamente qual conteúdo chega a cada filtro. Por exemplo, a AWS informa que o filtro de ataques via prompt do Bedrock não avalia resultados de ferramentas. Portanto, analisar a mensagem inicial do usuário não demonstra que documentos recuperados depois ou a saída de ferramentas também foram verificados.

Um fluxo ilustrativo da aplicação poderia ser:

flowchart LR
    accTitle: Política e roteamento do gateway
    accDescr: As verificações de entrada bloqueiam requisições não permitidas ou encaminham as permitidas a um modelo aprovado. As verificações de saída decidem se a resposta será entregue.
    P["Prompt e metadados da requisição"] --> G{"Verificações de política na entrada"}
    G -- Bloquear --> B["Retornar resposta de política"]
    G -- Permitir --> R["Roteamento dentro do pool de modelos aprovado"]
    R --> M["Execução do modelo"]
    M --> O["Verificações de política na saída"]
    O --> D["Entregar ou bloquear resposta"]

Este é um exemplo de projeto, não a sequência padrão de todo produto. Os classificadores e serviços de roteamento também processam dados; por isso, sua localização importa ao definir para onde informações sensíveis podem ser enviadas. As permissões de ferramentas e a autorização da aplicação continuam sendo controles separados.

Para quem escreve prompts, a lição prática é descrever claramente a tarefa real, distinguir instruções de conteúdo citado e fornecer somente o contexto necessário. Para as equipes de plataforma, é testar decisões de roteamento, bloqueios indevidos, violações não detectadas, latência adicional e custo total com requisições representativas. Nem uma rota bem-sucedida nem um prompt permitido demonstram que o código gerado está correto.

Teste os limites além do gateway

Em Agentic AI and Security, Korny Sietsma explica a combinação perigosa de dados sensíveis, conteúdo não confiável e comunicação externa. Uma requisição de inferência permitida não demonstra que as ações seguintes do agente com ferramentas estão autorizadas.

Para um assistente de checkout, teste com um documento sintético no repositório que o instrua a enviar um segredo falso para um destino não aprovado. Verifique o fluxo completo: recuperação, resposta do modelo, chamada de ferramenta proposta e decisão de autorização do executor. Um resultado útil registra se a instrução foi seguida e se a tentativa de transferência foi bloqueada. Use um destino controlado de teste e valores sintéticos.

Defina destinos permitidos e credenciais com acesso limitado no ambiente de execução das ferramentas. Mantenha esses controles também quando outro modelo for usado por indisponibilidade do primeiro. Um classificador que não detecte a instrução injetada não deve conceder uma nova capacidade de rede. Este teste complementa a avaliação de roteamento abaixo; ele não demonstra resistência a todas as técnicas de injeção de instruções em prompts.

Avalie a política de roteamento contra uma referência

Comece com um modelo aprovado como referência. Compare-o ao roteador proposto no mesmo conjunto de tarefas, revisões do repositório, ferramentas, verificações de aceitação e limites de execução. Inclua explicações de contratos, alterações na finalização da compra e tarefas de depuração; reserve alguns casos para avaliação depois de fixar a configuração.

Cenário	Evidências a coletar	Decisão informada
Explicar o contrato de desconto	Correção em relação ao contrato versionado, rota, latência e uso cobrado	Se o pool selecionado lida adequadamente com tarefas de explicação
Corrigir uma regressão de desconto entre serviços	Resultados de aceitação independentes, esforço de revisão, todas as tentativas e custo	Se o roteamento melhora a tarefa completa de programação
Provedor preferido indisponível	Modelo alternativo escolhido, tempo decorrido e erro final se não houver opção permitida	Se a alternativa obedece às mesmas regras de provedor e dados
Requisição legítima semelhante a um tópico bloqueado	Bloqueios indevidos entre requisições permitidas rotuladas	Se a política evita trabalho legítimo
Violação de política rotulada	Violações não detectadas entre requisições proibidas rotuladas	Se a verificação configurada detecta o risco pretendido

Estes são experimentos propostos, não resultados medidos de produtos. Registre a versão das regras e o modelo realmente escolhido em cada chamada, inclusive quando houver troca por indisponibilidade. Inclua os custos de roteamento, classificação, cache e correções, quando cobrados. Uma resposta inicial mais barata pode exigir mais trabalho corretivo antes de o código passar pelos critérios de aceitação.

Mantenha as restrições de autorização como regras rígidas de elegibilidade. Se não houver um modelo permitido disponível, retorne uma falha clara; a troca de modelo não deve ampliar silenciosamente o conjunto de provedores aprovados. Se o cliente repetir um pedido após um limite de tempo sem resposta conclusiva, diferencie outra chamada ao modelo da repetição de ações de ferramentas que talvez já tenham alterado dados.

O rótulo da rota é uma evidência diagnóstica, não a métrica de resultado. Adote uma política somente depois de medir o sucesso das tarefas e os custos operacionais nas condições de uso da sua equipe. O protocolo de avaliação de Loop Engineering oferece um formato de registro reutilizável.

O próximo artigo explica como fornecer os fatos necessários ao modelo que atenderá a tarefa: Context Engineering.