Como construir um roteador de política de retenção de dados para APIs LLM de vários provedores

Um roteador LLM multiprovedor não deve escolher um modelo primeiro e fazer perguntas sobre retenção depois. Se um fluxo de trabalho de suporte for marcado como sem retenção, o gateway precisará saber se o provedor, o terminal, a região, a configuração da conta e a combinação de recursos selecionados podem honrar essa promessa antes que a solicitação saia do seu limite.

O modo de falha é fácil de ignorar. Uma equipe começa com a conclusão do chat sem estado. A rota é aceitável. Mais tarde, alguém adiciona upload de arquivo, histórico de conversas armazenadas, web grounding, processamento em lote ou armazenamento de vetores. O nome do modelo pode permanecer o mesmo, mas o comportamento dos dados muda. Um roteador simples de latência ou custo pode enviar silenciosamente avisos regulamentados ou vinculados ao contrato do cliente para um caminho que armazena conteúdo por mais tempo do que a carga de trabalho permite.

A solução prática é colocar os controles de retenção de dados LLM na frente do roteamento do modelo. O roteador deve classificar a solicitação, compará-la com uma política de retenção canônica, filtrar recursos do provedor, bloquear recursos não permitidos e emitir evidências auditáveis para a decisão.

Fatos a serem tratados como restrições de projeto

O tratamento de dados do provedor não é uniforme e raramente é capturado apenas pelo nome do provedor. Os seguintes fatos são importantes ao projetar um roteador com reconhecimento de retenção:

• OpenAI afirma que API dados não são usados para treinar ou melhorar modelos, a menos que o cliente aceite. Os clientes qualificados podem configurar o monitoramento de abuso modificado ou a retenção zero de dados no nível da organização ou do projeto após a aprovação.
A retenção de dados zero de
• OpenAI altera o comportamento do endpoint, incluindo o tratamento do parâmetro store para respostas e conclusões de bate-papo como falso, mas alguns endpoints e recursos ainda podem armazenar o estado do aplicativo e não são elegíveis para retenção de dados zero.
• Anthropic documenta retenção zero de dados para Claude API como não armazenando solicitações ou respostas do cliente em repouso após a resposta API ser retornada, mas a cobertura depende do endpoint e da elegibilidade do recurso.
• Anthropic afirma que alguns Claude recursos ou modelos cobertos podem exigir retenção e podem estar indisponíveis sob Retenção Zero de Dados, a menos que sejam especificamente autorizados.
• Google A nuvem documenta que Gemini os dados da Enterprise Agent Platform não são usados para treinar ou ajustar modelos de IA/ML sem permissão ou instrução prévia, mas a retenção zero de dados requer ações específicas e pode não ser possível para alguns recursos avançados.
• Google Documentos na nuvem que o Grounding with Google Search armazena consultas derivadas e registros de contexto por até três dias e não pode desativar esse armazenamento para esse recurso. Ela recomenda o Web Grounding for Enterprise quando a retenção zero de dados é necessária.
• A Microsoft documenta que os modelos hospedados no Azure vendidos pelo Azure não disponibilizam prompts e conclusões para OpenAI ou outros provedores de modelos e não os usam para treinar modelos básicos sem permissão ou instrução.
• A Microsoft documenta que o tipo de implantação do Azure afeta o local de processamento. As implantações globais podem processar prompts e respostas em qualquer região onde o modelo é implantado, enquanto as implantações do DataZone restringem o processamento à zona selecionada. Os dados armazenados permanecem na região geográfica designada pelo cliente.
• A Microsoft documenta que alguns recursos com estado do Azure armazenam dados, incluindo arquivos, armazenamentos de vetores, histórico de mensagens de respostas, threads de assistentes, entradas de processamento em lote e conclusões armazenadas.
• Documentos da Microsoft que mostram que os clientes aprovados podem modificar o monitoramento de abuso e que o portal do Azure ou CLI podem mostrar ContentLogging=false quando o armazenamento de dados de monitoramento de abuso está desativado.

Esses não são detalhes de borda. Eles significam que o roteador deve avaliar o endpoint, o recurso, a aprovação da conta e a região juntos. Um rótulo para todo o provedor, como "ZDR ativado", é muito grosseiro para a política de produção.

Arquitetura de referência

Um gateway de IA multimodelo API com reconhecimento de retenção precisa de cinco componentes no caminho da solicitação:

1. Classificador de solicitação: extrai sensibilidade de dados, contrato de locatário, requisitos de região, uso de recursos, entradas de arquivos, uso de ferramentas e permissões de registro.
2. Resolvedor de políticas: mapeia a solicitação para uma política de retenção canônica, geralmente de inquilino, projeto, ambiente, API chave e metadados de carga de trabalho.
3. Registro de capacidade do provedor: registra o provedor, o endpoint, o modelo, o recurso, a região e os recursos de retenção no nível da conta com evidências datadas.
4. Avaliador de política: filtra rotas candidatas e retorna uma rota aprovada ou uma negação de política com um código de motivo.
5. Emissor de auditoria: registra a rota escolhida, política correspondente, suposições de capacidade, região, sinalizadores de armazenamento e modo de registro de conteúdo.

Essa arquitetura mantém as decisões de retenção e residência separadas de custo, latência e reserva. O roteamento de custos ainda pode acontecer, mas apenas dentro do conjunto de rotas que satisfazem a política de retenção.

Definir uma política de retenção canônica

Comece com um objeto de política neutro em relação ao provedor. Não copie a terminologia de um fornecedor em seu contrato interno. Sua política interna deve descrever o que a carga de trabalho pode fazer, e não como um provedor específico comercializa um controle.

{
  "policy_id": "support_no_retention_eu_v1",
  "max_content_retention": "none_after_response",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["EU"],
  "stateful_storage_allowed": false,
  "file_storage_allowed": false,
  "grounding_allowed": false,
  "batch_processing_allowed": false,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "route_decision_with_provider_evidence"
}

Para cargas de trabalho menos restritas, use relaxamento explícito em vez de campos ausentes:

{
  "policy_id": "internal_analytics_standard_v1",
  "max_content_retention": "30_days",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["US", "EU"],
  "stateful_storage_allowed": true,
  "file_storage_allowed": true,
  "grounding_allowed": true,
  "batch_processing_allowed": true,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "metadata_and_decision"
}

Os campos importantes não são apenas a duração da retenção. Recursos com estado, arquivos, aterramento, processamento em lote e modo de registro afetam se uma rota é aceitável.

Criar o registro de recursos do provedor

O registro de capacidade é a fonte da verdade do roteador. Ela deve ser mantida como configuração controlada, e não espalhada pelos adaptadores do provedor.

Um registro útil inclui:

• provider: provedor ou plataforma de nuvem.
• account_scope: organização, projeto, implantação, assinatura ou locatário onde uma configuração é aprovada.
• endpoint: bate-papo, respostas, mensagens, lote, arquivos, assistentes, incorporações, aterramento, armazenamento de vetores ou outra superfície API.
• model_family e opcional model_id: porque a elegibilidade do modelo pode ser diferente.
• region_mode: global, regional, zona de dados, geografia designada pelo cliente ou equivalente específico do provedor.
• content_retention: sem armazenamento após resposta, retenção de monitoramento de abuso, retenção de estado do aplicativo, registros derivados de duração fixa ou desconhecido.
• training_use: desativado por padrão, opcional ou desconhecido.
• human_review: ativado, modificado, desativado ou desconhecido.
• stateful_storage: se o endpoint ou recurso armazena estado de conversação, arquivos, dados vetoriais, conclusões ou entradas em lote.
• feature_flags: aterramento, arquivos, ferramentas, cache, saídas armazenadas, lote, assistentes ou recursos equivalentes.
• evidence: nome do documento de origem, URL, data de recuperação e data de revisão do proprietário.

Exemplo:

{
  "capability_id": "azure-openai-gpt4o-datazone-chat-zdrlike-v3",
  "provider": "azure_openai",
  "account_scope": "prod-subscription-123",
  "endpoint": "chat_completions",
  "model_family": "gpt-4o",
  "region_mode": "datazone_eu",
  "content_retention": "abuse_monitoring_disabled_when_contentlogging_false",
  "training_use": "disabled_without_permission",
  "human_review": "modified_abuse_monitoring_approved",
  "stateful_storage": false,
  "features": {
    "files": false,
    "vector_store": false,
    "stored_completions": false,
    "grounding": false,
    "batch": false
  },
  "evidence": {
    "source": "provider_data_privacy_and_abuse_monitoring_docs",
    "retrieved_at": "2026-10-08",
    "review_owner": "security-architecture"
  }
}

A recomendação é tratar desconhecido como negado para cargas de trabalho confidenciais. Se um registro de capacidade não tiver um campo de retenção, modo de região ou elegibilidade de recurso, ele não deverá satisfazer políticas rígidas.

Classifique a solicitação antes do roteamento

A classificação deve acontecer antes da seleção do modelo. Um bom classificador combina metadados estáticos e inspeção de solicitação:

• API escopo principal: locatário, equipe, ambiente, aplicativo e tipo de carga de trabalho.
• Tags de contrato: sem retenção, somente para a UE, controles semelhantes aos da HIPAA, dados financeiros, confidenciais do cliente ou apenas internos.
• Tipo de carga útil: texto livre, documento, imagem, referência de arquivo, entrada incorporada, resultado da ferramenta ou contexto recuperado.
• Uso de recursos: web grounding, upload de arquivos, armazenamento de vetores, trabalho em lote, histórico de conversas armazenado, chamadas de ferramentas ou armazenamento de respostas.
• Modo de registro: conteúdo completo permitido, conteúdo redigido permitido, apenas metadados ou nenhum conteúdo de registro do aplicativo.
• Dicas regionais: localização do usuário, residência dos dados do locatário, região do projeto ou região de implantação.

Não confie apenas na detecção automática de dados confidenciais. Use a política de carga de trabalho declarada da chave ou projeto API como fonte primária e, em seguida, use classificadores para restringir a política quando a carga contém sinais de risco.

function resolvePolicy(request) {
  const base = policyForApiKey(request.apiKeyId);
  const tenant = tenantContractPolicy(request.tenantId);
  const features = detectRequestedFeatures(request);
  const sensitivity = classifyPayload(request);

  return strictestApplicablePolicy([base, tenant, features, sensitivity]);
}

Na prática, isso significa que uma chave de suporte ao cliente pode ser padronizada como sem retenção, enquanto uma chave de experimentação interna pode permitir um roteamento mais amplo. Se a mesma chave de suporte tentar fazer upload de arquivo, a política efetiva deverá incluir file_storage_allowed=false, a menos que exista uma rota aprovada compatível com arquivos.

Avalie a política antes do roteamento de custo ou latência

O avaliador deve funcionar como um filtro. Ele recebe uma política, recursos de solicitação e rotas de provedores candidatos. Ele retorna apenas rotas que atendem à política.

function eligibleRoutes(request, policy, capabilities) {
  return capabilities.filter((route) => {
    if (!regionAllowed(route, policy.allowed_regions)) return false;
    if (!retentionAllowed(route, policy.max_content_retention)) return false;
    if (!trainingAllowed(route, policy.training_allowed)) return false;
    if (!humanReviewAllowed(route, policy.human_review_allowed)) return false;
    if (request.usesFiles && !policy.file_storage_allowed) return false;
    if (request.usesFiles && route.features.files !== true) return false;
    if (request.usesGrounding && !policy.grounding_allowed) return false;
    if (request.requiresState && !policy.stateful_storage_allowed) return false;
    if (route.content_retention === "unknown") return false;
    return true;
  });
}

function routeRequest(request) {
  const policy = resolvePolicy(request);
  const candidates = capabilityRegistry.findByModelIntent(request.modelIntent);
  const eligible = eligibleRoutes(request, policy, candidates);

  if (eligible.length === 0) {
    return deny("RETENTION_POLICY_NO_ELIGIBLE_ROUTE", policy.policy_id);
  }

  return chooseByCostLatencyAndHealth(eligible);
}

Essa ordem é importante. O roteamento substituto não deve ir para um provedor inelegível durante uma interrupção. O roteamento em lote não deve mover uma solicitação sem retenção para um armazenamento de trabalho assíncrono. O aterramento não deve ativar um recurso que introduza registros derivados quando a política o proíbe.

Se sua plataforma expõe um multimodelo OpenAI compatível API, mantenha a camada de compatibilidade honesta: o mesmo corpo da solicitação pode ser compilado para diferentes recursos nativos do provedor. O avaliador da política deve inspecionar a solicitação compilada, não apenas a forma SDK original.

Bloqueie explicitamente combinações de recursos arriscados

A implementação mais segura é criar regras de negação explícitas para combinações conhecidas de alto risco. Exemplos:

• NO_RETENTION + FILE_UPLOAD: negar, a menos que o endpoint do arquivo específico e a configuração da conta sejam aprovados para a política.
• NO_RETENTION + VECTOR_STORE: negar, a menos que o armazenamento vetorial esteja dentro de seu próprio armazenamento controlado e o provedor nunca receba estado de arquivo persistente.
• NO_RETENTION + STORED_RESPONSE: força a desativação ou negação dos sinalizadores de armazenamento de resposta se o terminal não puder desativar o armazenamento.
• EU_ONLY + GLOBAL_DEPLOYMENT: negar se o processamento puder ocorrer fora da região ou zona de dados permitida.
• NO_RETENTION + WEB_GROUNDING: negar se o recurso de base armazenar consultas derivadas ou logs de contexto além da política.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: suprime o conteúdo de prompt e conclusão dos registros e rastreamentos do aplicativo.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: negar, a menos que o recurso seja especificamente qualificado de acordo com os controles aprovados da conta.

Retorna erros específicos. Uma negação útil informa ao desenvolvedor o que falhou e quais alternativas aprovadas existem.

{
  "error": {
    "code": "RETENTION_POLICY_DENIED",
    "reason": "NO_RETENTION_POLICY_DISALLOWS_FILE_STORAGE",
    "policy_id": "support_no_retention_eu_v1",
    "requested_feature": "file_upload",
    "approved_alternatives": [
      "send extracted text without provider file storage",
      "use internal document retrieval with metadata-only provider call",
      "request policy approval for controlled file processing"
    ]
  }
}

Registro de inferência separado da telemetria operacional

A política de retenção não deve forçar o gateway a ficar cego. Geralmente, você pode manter a telemetria operacional sem armazenar conteúdo de prompt ou conclusão.

Para cargas de trabalho restritas, preserve:

• ID de solicitação e ID de rastreamento;
• locatário, projeto, API chave e identificadores de carga de trabalho;
• ID da política e versão da política;
• provedor, endpoint, modelo, implantação e região usados;
• sinalizações de recursos solicitadas e permitidas;
• códigos de motivo de decisão;
• contagens de tokens, latência, código de status e metadados de custo;
• hashes ou impressões digitais estáveis para desduplicação, se aprovado pela política.

Suprimir ou redigir:

• solicitações brutas;
• conclusões brutas;
• conteúdo do arquivo enviado;
• saídas de ferramentas que contêm dados do cliente;
• contexto recuperado de sistemas confidenciais;
• o provedor depura cargas úteis que duplicam conteúdo.

É aqui que o roteamento de retenção se conecta à observabilidade LLM neutra em termos de provedor. A observabilidade deve provar o que aconteceu sem expandir o conjunto de sistemas que retêm conteúdo confidencial.

Emitir evidências de auditoria para cada decisão

Um registro de auditoria deve explicar por que uma rota foi permitida ou negada. Não precisa de conteúdo completo para ser útil.

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_42",
  "policy_id": "support_no_retention_eu_v1",
  "policy_version": 7,
  "decision": "allow",
  "provider": "anthropic",
  "endpoint": "messages",
  "model_family": "claude",
  "region_mode": "approved_region",
  "features": {
    "files": false,
    "grounding": false,
    "stateful_storage": false,
    "batch": false
  },
  "logging_mode": "metadata_only",
  "capability_record_id": "anthropic-claude-messages-zdr-v5",
  "capability_evidence_date": "2026-10-08",
  "reason_codes": [
    "POLICY_MATCHED_NO_RETENTION",
    "REGION_ALLOWED",
    "STATELESS_ENDPOINT",
    "CONTENT_LOGGING_SUPPRESSED"
  ]
}

Para solicitações negadas, mantenha a mesma estrutura com decision=deny e códigos de motivo como REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY ou STATEFUL_STORAGE_NOT_ALLOWED.

Use testes de contrato para regras de retenção

O roteamento de retenção deve ter testes automatizados. Os testes importantes não são apenas testes unitários para provedores individuais; eles são testes de contrato para comportamento de políticas em combinações de provedores.

Casos de teste de alto valor incluem:

• A política de não retenção e o upload de arquivos devem ser negados, a menos que exista uma rota específica aprovada com capacidade para arquivos.
• A política exclusiva da UE e a implantação global devem ser negadas mesmo quando o modelo estiver disponível.
• A política de retenção zero e o histórico de conversas armazenadas devem negar ou forçar a desativação do armazenamento quando compatível.
• O recurso de aterramento com retenção de log derivado deve ser negado sob a política de não retenção.
• A política de registro somente de metadados deve suprimir o conteúdo de prompt e conclusão de rastreamentos, registros e relatórios de erros.
• O registro de capacidade do provedor com retenção desconhecida deve ser negado para cargas de trabalho regulamentadas.
• O substituto após a interrupção do provedor deve permanecer dentro do conjunto de rotas elegíveis.
• O processamento em lote deve ser negado quando o endpoint do lote armazena arquivos de entrada por mais tempo do que o permitido pela política.

Teste também o desvio. Quando um registro de capacidade muda, o sistema deve mostrar quais políticas e rotas são afetadas antes que a mudança chegue à produção.

Propriedade operacional

A parte difícil não é escrever o primeiro avaliador. Ele mantém o registro atualizado e evita exceções não documentadas.

Atribuir proprietários para:

• cadência de revisão da documentação do provedor;
• status de aprovação para controles em nível de conta, como monitoramento de abuso modificado ou retenção zero de dados;
• inventário de implantação regional;
• apresenta elegibilidade para arquivos, armazenamentos de vetores, aterramento, lote e respostas armazenadas;
• fluxo de trabalho de exceção de política;
• retenção de registros de auditoria e controle de acesso;
• mensagens de erro e alternativas aprovadas voltadas para o desenvolvedor.

Todo registro de capacidade deve ter uma data de revisão. Se expirar, políticas rígidas deverão deixar de confiar nele ou exigir aprovação manual. Os documentos do provedor e o comportamento dos recursos mudam com muita frequência para que esta seja uma configuração estática.

Compensações

Um roteador de retenção estrito reduz as opções de modelos disponíveis. Alguns modelos de visualização, APIs com estado, ferramentas de base e fluxos de trabalho de arquivos não estarão disponíveis para cargas de trabalho confidenciais. Esse é o ponto do controle, mas as equipes de produto precisam de alternativas claras.

O roteamento regional pode aumentar a latência ou o custo quando a implantação mais rápida é global, mas a carga de trabalho requer uma região geográfica ou zona de dados específica. Torne isso visível na telemetria para que as equipes entendam por que uma solicitação usou uma rota mais cara ou mais lenta.

O bloqueio de recursos com estado pode levar as equipes a criar sua própria camada de memória. Essa pode ser a arquitetura certa, mas ainda precisa de política de armazenamento, fluxos de trabalho de exclusão, criptografia, controle de acesso e registros de auditoria. Mover o estado para fora do provedor não elimina o trabalho de governança.

A redação imediata e completa protege dados confidenciais, mas enfraquece a depuração e a revisão de qualidade. Use metadados de solicitação reproduzíveis, dispositivos de teste determinísticos, amostragem controlada para cargas de trabalho permitidas e acesso de segurança documentado onde a política permitir.

Recomendações

• Aplicar retenção e residência antes do roteamento do modelo, não como uma verificação pós-processamento.
• Modele recursos em nível de provedor, endpoint, recurso, região e aprovação de conta.
• Use o comportamento de negação por padrão para cargas de trabalho regulamentadas ou vinculadas ao contrato do cliente.
• Trate upload de arquivos, armazenamento de vetores, web grounding, processamento em lote e histórico de conversas armazenadas como dimensões de política separadas.
• Mantenha a telemetria operacional mesmo quando o conteúdo do prompt e da conclusão precisar ser suprimido.
• Emitir registros de auditoria que incluam política, rota, evidência de capacidade, região, sinalizadores de armazenamento e códigos de motivo.
• Escreva testes de contrato para combinações de recursos de alto risco e comportamento substituto.

Predição: o roteamento de retenção se tornará uma camada de gateway padrão

A direção provável é que o roteamento de retenção se torne uma camada padrão em plataformas LLM corporativas, semelhante a limites de taxa, controles de orçamento e observabilidade. À medida que os provedores adicionam mais ferramentas com estado, opções de aterramento, caches, arquivos, agentes e recursos de memória gerenciada, a rota segura dependerá menos do nome do modelo e mais do caminho de execução completo.

Isso é uma previsão, não um requisito universal atual. O requisito atual é mais simples: se sua equipe não promete retenção, processamento regional, uso de treinamento ou revisão humana, seu gateway precisa de lógica política e evidências suficientes para provar que cada solicitação seguiu essas restrições.

Conclusão acionável

Crie o roteador de retenção como uma porta de política antes da seleção do provedor. Defina uma política de retenção canônica, classifique cada solicitação antes do roteamento, mantenha um registro de capacidade do provedor datado, negue combinações inseguras por padrão e registre evidências de auditoria sem reter conteúdo confidencial.

O objetivo do design não é encontrar um provedor que seja sempre seguro. O objetivo é provar que uma solicitação específica, usando um endpoint e um conjunto de recursos específicos, em uma conta e região específicas, satisfez a política antes de ser enviada.

Leitura relacionada

• design de observabilidade LLM neutro para o provedor