Roteamento de API de IA com reconhecimento de retenção de dados: aplique políticas de ZDR, residência e registro no gateway
Uma arquitetura de gateway prática para rotear o tráfego de API de IA por política de retenção de dados: classifique a sensibilidade da solicitação, mapeie o comportamento de retenção do provedor, bloqueie recursos incompatíveis, preserve análises seguras e audite todas as decisões.
As equipes de segurança não precisam apenas saber qual modelo é mais barato, mais rápido ou mais capaz. Eles precisam saber se uma solicitação específica pode ser enviada legal e operacionalmente para um provedor, endpoint, região, recurso e modo de registro específicos.
Isso é mais difícil do que parece. Um modelo pode ser aceitável para bate-papo interno comum, mas não para PII do cliente. Um provedor pode oferecer retenção zero de dados para um caminho de API, enquanto um recurso de base de pesquisa armazena prompts e resultados por um período fixo. Uma região pode dar suporte à residência de armazenamento, mas não ao modo de processamento esperado. Os registros de propriedade do desenvolvedor podem ser configuráveis, enquanto os registros de monitoramento de abuso do provedor seguem uma política diferente.
A resposta prática é transferir as decisões de retenção de aplicativos individuais para o gateway da API de IA. O gateway deve classificar a solicitação, avaliá-la em relação a uma matriz de capacidade do provedor, bloquear recursos incompatíveis, encaminhar apenas para perfis de modelo aprovados e registrar uma decisão política sem armazenar solicitações brutas por padrão.
O problema do leitor: os termos de privacidade do provedor não são controles de tempo de execução
A maioria das equipes começa com uma planilha ou análise de segurança que indica quais provedores de IA são aprovados. Isso é útil, mas não é suficiente para o roteamento da produção.
Os aplicativos fazem escolhas de tempo de execução:
- Qual ID de modelo deve processar esta solicitação?
- A solicitação deve usar base de pesquisa, upload de arquivo, execução de código, processamento em lote, cache de prompt ou conversas armazenadas?
- Qual região ou endpoint deve processar a solicitação?
- O sistema pode registrar o prompt bruto para depuração?
- O roteamento substituto pode enviar a mesma solicitação para outro provedor?
Cada uma dessas opções pode alterar o perfil de retenção. Uma solicitação que estava em conformidade no modo de chat simples pode se tornar incompatível quando o desenvolvedor ativar o aterramento ou o armazenamento persistente de conversas. Uma regra substituta projetada para confiabilidade pode rotear acidentalmente dados regulamentados para um caminho de provedor que não tenha sido aprovado para retenção zero de dados, residência de dados ou controles de monitoramento de abuso.
Recomendação: trate o comportamento de retenção como uma restrição de roteamento de primeira classe, não como documentação anexada a uma conta de provedor.
Fatos a serem codificados antes de elaborar uma política
Os termos exatos variam de acordo com fornecedor, produto, contrato, região, endpoint e recurso. Não confie na memória ou em uma revisão única. Crie uma matriz de propriedade da fonte e atualize-a quando os termos mudarem.
Vários documentos atuais de provedores públicos ilustram por que isso é necessário:
- OpenAI: a residência dos dados da API é documentada conforme configurada pelo projeto, com solicitações regionais que exigem prefixos de domínio específicos da região. A OpenAI também distingue o suporte de armazenamento do suporte de processamento por região e observa requisitos adicionais para regiões fora dos EUA. A OpenAI afirma que a residência de dados de API fora dos EUA requer aprovação para controles de monitoramento de abuso e uma alteração de retenção modificada.
- Anthropic: a Anthropic documenta zero retenção de dados para casos de uso comercial relacionados à API, ao mesmo tempo em que observa que alguns produtos relacionados ou feeds de conformidade têm modelos de retenção separados, incluindo retenção mais longa para feed de atividades e transcrições de sessões remotas.
- Google Gemini: os termos da API Gemini distinguem serviços pagos e não pagos. Para serviços não pagos, o Google poderá usar o conteúdo enviado e as respostas geradas para melhorar os produtos; para serviços pagos, o Google afirma que as solicitações e respostas não são usadas para melhorar os produtos. A documentação do ZDR da Gemini Developer API diz que os registros de monitoramento de abuso de serviços pagos normalmente retêm prompts e respostas por um período limitado, enquanto os projetos ZDR aprovados limpam o conteúdo do usuário e os metadados identificáveis antes do registro.
- Armazenamento específico de recursos: a documentação do Gemini afirma que o Grounding with Google Search e o Grounding with Google Maps armazenam avisos, informações contextuais e resultados gerados por 30 dias, sem nenhuma maneira de desativar esse armazenamento quando esses recursos são usados.
- Registros de propriedade do desenvolvedor: a documentação de registro da API Gemini diz que os registros da API de propriedade do desenvolvedor podem ser retidos por até 55 dias por padrão para projetos habilitados para faturamento e que os desenvolvedores podem escolher janelas mais curtas, como 7, 14 ou 28 dias.
- Gerenciamento de riscos: o perfil de IA generativa do NIST recomenda monitorar o conteúdo gerado por IA para detectar riscos de privacidade e conectar políticas de IA generativa a dados, software, processos jurídicos, de conformidade e de gerenciamento de riscos existentes.
Estes são fatos que devem ser verificados em relação à documentação atual do fornecedor antes da implementação. A lição arquitetônica é estável: a retenção não é um booleano no nível do provedor.
Arquitetura: um mecanismo de política de gateway no caminho da solicitação
Um gateway com reconhecimento de retenção tem cinco componentes principais:
- Classificador de sensibilidade da solicitação: rotula a carga de trabalho antes do roteamento.
- Matriz de capacidade do provedor: descreve o provedor, o modelo, o endpoint, a região, a retenção, a geração de registros e o comportamento do recurso.
- Regras de política como código: convertem requisitos de segurança em decisões de permissão, negação ou revisão em tempo de execução.
- Camada de porta de recursos: bloqueia recursos que alteram a retenção, a menos que seja explicitamente permitido.
- Camada de auditoria e análise: registra metadados úteis sem armazenar prompts brutos por padrão.
O gateway não precisa compreender todas as nuances jurídicas. Ele precisa aplicar as decisões aprovadas pelas equipes jurídica, de segurança, de conformidade e de plataforma.
Etapa 1: classificar a sensibilidade da solicitação antes de selecionar um modelo
Comece com uma pequena taxonomia de classificação. Deve ser simples o suficiente para ser usado pelos desenvolvedores, mas expressivo o suficiente para orientar as políticas.
Exemplos de rótulos de confidencialidade:
público: documentação pública, texto de marketing, conteúdo público do site.interno: informações não públicas da empresa com baixa sensibilidade.confidencial: estratégia, contratos, contexto do cliente, detalhes de produtos não divulgados.customer_pii: nomes, e-mails, endereços, identificadores de conta, transcrições de suporte.regulamentados: dados protegidos de saúde, financeiros, jurídicos, educacionais ou específicos de jurisdição.source_code: código proprietário, configuração, arquivos de arquitetura.credenciais: segredos, tokens, senhas, chaves privadas. Na maioria dos sistemas, isso deve ser bloqueado, não roteado.
A classificação pode vir de diversas fontes:
- Um cabeçalho fornecido pelo aplicativo, como
X-Data-Class: customer_pii. - Política de locatário, em que todo o tráfego de um cliente regulamentado é tratado como regulamentado, a menos que seja rebaixado por uma regra aprovada.
- Política de endpoint, onde o padrão do resumo de tickets de suporte é
customer_pii. - Verificação leve de conteúdo em busca de credenciais, PII óbvias ou violações de políticas.
Recomendação: não dependa inteiramente da detecção automática. Exija que os aplicativos declarem a classe de dados pretendida e, em seguida, use a varredura para detectar incompatibilidades óbvias ou forçar uma classe mais segura.
Etapa 2: construir uma matriz de capacidade do provedor
A matriz de capacidade é a fonte da verdade que o roteador avalia. Deve ser versionado, revisado e testado como configuração de produção.
Campos de exemplo:
Use perfis de modelo em vez de IDs de modelo brutos. Um perfil combina modelo, provedor, endpoint, região, conjunto de recursos e postura de retenção. Os desenvolvedores solicitam model_profile: compatível_summarization, não apenas model: fast-large-model.
Recomendação: incluir pré-requisitos contratuais na matriz. Uma rota não é aprovada pelo ZDR apenas porque um fornecedor oferece ZDR em algum lugar. Ele será aprovado somente quando sua conta, projeto, região e endpoint atenderem às condições exigidas.
Etapa 3: escrever regras de política como código
As regras da política devem ser explícitas, testáveis e legíveis pelas equipes de segurança e plataforma.
Exemplos de regras em pseudocódigo:
negar se data_class == "credenciais"
motivo "credenciais_deve_não_ser_sent_to_model"
permitir apenas se data_class em ["regulated", "customer_pii"]
e profile.zdr_eligible == verdadeiro
e profile.zdr_contract_required_satisfied == verdadeiro
reason_on_failure "model_profile_not_zdr_eligible"
negar se residency_required == "eu"
e "eu" não está em profile.processing_residency
motivo "region_processing_not_supported"
negar se data_class em ["confidencial", "customer_pii", "regulado"]e request.raw_prompt_logging == verdadeiro
motivo "raw_prompt_logging_not_allowed"
negar se request.features.search_grounding == true
e política.requires_zdr == verdadeiro
e profile.feature_storage.search_grounding_days > 0
motivo "grounding_requires_retained_content"
negar se fallback_profile.retention_level < primário_profile.retention_level
motivo "fallback_weakens_retention_policy"Essas regras devem ser executadas antes da seleção do provedor e novamente antes do substituto. O roteamento substituto é uma fonte comum de desvios acidentais da política: a rota principal pode ser compatível, enquanto a rota alternativa está apenas disponível.
Etapa 4: trate ferramentas e recursos como recursos de mudança de retenção
Não modele a retenção como uma propriedade apenas do modelo base. Os recursos geralmente alteram o comportamento de armazenamento, registro ou revisão.
Dê a cada recurso seus próprios sinalizadores de política:
- Fundamentação da pesquisa: pode armazenar prompts, contexto recuperado e resultados gerados dependendo dos termos do provedor.
- Mapas ou localização: podem introduzir registros específicos do local ou regras de retenção.
- Upload de arquivo: pode armazenar arquivos separadamente de solicitações e respostas.
- Execução de código: pode criar arquivos temporários, logs de execução ou artefatos de sandbox.
- Trabalhos em lote: podem ter retenção, enfileiramento e comportamento de armazenamento de resultados diferentes das chamadas de API síncronas.
- Conversas armazenadas: persistem intencionalmente o conteúdo e nunca devem ser ocultadas atrás de uma opção genérica de bate-papo.
- Painéis de avaliação ou revisão: podem criar fluxos de trabalho de revisão humana ou conjuntos de dados de vida mais longa.
Recomendação: faça com que os recursos de alteração de retenção sejam ativados no nível do locatário e da rota. Se um desenvolvedor ativar grounding_search=true, o gateway deverá reavaliar a solicitação em relação às regras de armazenamento de recursos antes de enviá-la ao upstream.
Etapa 5: preserve as análises sem armazenar prompts brutos
O roteamento com reconhecimento de retenção não deve cegar a equipe da plataforma. Você pode manter análises de uso de IA úteis e, ao mesmo tempo, minimizar o armazenamento de conteúdo.
Campos de telemetria padrão seguros:
- ID do locatário e ID do projeto
- ID da chave de API interna ou com hash
- ID do perfil do modelo e ID do provedor
- solicitar carimbo de data/hora e região
- contagens de tokens de entrada, saída, cache e raciocínio, quando disponíveis
- latência, código de status, contagem de novas tentativas e decisão de fallback
- custo estimado e liquidado
- rótulo de classificação de dados
- versão da política e motivo da decisão da política
- sinalizações de recursos solicitadas e sinalizações de recursos permitidas
Evite armazenar prompts brutos e saídas de modelo por padrão para tráfego confidencial. Se a depuração exigir conteúdo, use um fluxo de trabalho controlado:
- aprovação do cliente ou locatário
- janela de tempo estreita
- limite de amostragem
- passe de redação
- controle de acesso separado
- expiração curta
- registro de auditoria de quem ativou e por quê
Esta é uma troca. O bloqueio de logs de prompt brutos dificulta a depuração, o suporte, a revisão de qualidade e a investigação de abusos. Mas armazenar tudo por padrão cria uma superfície maior de privacidade, violação e conformidade.
Etapa 6: retornar motivos de negação acionáveis
Um 403 proibido genérico frustra os desenvolvedores e incentiva soluções alternativas. Retorne um motivo estável e legível por máquina e uma explicação legível por humanos.
Exemplo de resposta:
Os códigos de negação úteis incluem:
model_profile_not_zdr_eligibleregion_processing_not_supportedstorage_residency_not_supportedraw_prompt_logging_not_allowedfeature_requires_content_storagefallback_weakens_retention_policycontract_prerequisite_missingcredenciais_detectadas
Etapa 7: adicione um fluxo de trabalho de exceção, não um desvio oculto
Algumas exceções são legítimas: resposta a incidentes, depuração aprovada pelo cliente, testes de migração ou limitação temporária do provedor. O gateway deve suportar exceções sem transformá-las em uma política sombra permanente.
Cada exceção deve incluir:
- identidade do aprovador
- solicitando equipe ou inquilino
- link para ticket ou análise de risco
- justificativa comercial
- perfis e recursos de modelo permitidos
- classes de dados abrangidas
- data de validade
- requisitos adicionais de registro
Recomendação: torne as exceções mais restritas do que a política comum. Evite opções globais como disable_retention_policy=true. Prefira substituições de escopo, como “permitir registro de prompt de depuração para o locatário A, endpoint B, por 24 horas, com redação e aprovação de segurança”.
Lista de verificação operacional
- Crie uma matriz de capacidade do provedor com versão.
- Atribuir um proprietário para termos do fornecedor, pré-requisitos de contrato e análises de retenção.
- Exigir que os aplicativos declarem a classe dos dados, os requisitos de residência e os recursos solicitados.
- Tráfego confidencial e regulamentado padrão para nenhum registro de prompt bruto.
- Represente ferramentas, fundamentação, upload de arquivos, lote e conversas armazenadas como sinalizadores de capacidade separados.
- Execute verificações de políticas antes do roteamento primário e antes do roteamento substituto.
- Registre a versão da política, o perfil do modelo, a classe de dados, os sinalizadores de recurso e o motivo da negação.
- Mantenha os metadados analíticos separados do conteúdo de prompt e de saída.
- Representante de teste permite e nega casos em CI.
- Revise a variação da política sempre que um provedor alterar termos, regiões, pontos de extremidade ou recursos.
Compensações a serem explicitadas
O roteamento estrito reduz as opções. As restrições de ZDR e de residência podem impedir o uso do modelo mais novo, da rota de menor custo ou de um endpoint rico em recursos.
O roteamento regional pode aumentar a latência ou o custo. A região compatível mais próxima pode não oferecer suporte ao modo de processamento desejado ou pode exigir um caminho de provedor diferente.
As portas de recursos surpreendem os desenvolvedores. Um desenvolvedor pode pensar que está apenas habilitando a pesquisa, mas a segurança vê um novo comportamento de retenção. Mensagens de documentação e negação reduzem o atrito.
A minimização de prompts complica a depuração. As equipes precisam de amostras editadas, janelas de depuração aprovadas pelo locatário e metadados fortes para investigar problemas sem armazenar tudo.
A matriz requer manutenção. Os termos do fornecedor mudam. Lançamento de novos modelos. As regiões se expandem. Os recursos passam da versão beta para a produção. Uma matriz obsoleta é pior do que nenhuma matriz porque cria uma falsa confiança.
O que é uma recomendação e o que é uma previsão?
Recomendações: aplique a retenção no gateway, classifique as solicitações antes do roteamento, crie uma matriz de capacidade do provedor, bloqueie os recursos de alteração da retenção por política, evite o registro de prompt bruto por padrão e crie versões de cada decisão política.
Previsão: as equipes da plataforma de IA tratarão cada vez mais a postura de privacidade como parte da seleção do modelo. Em vez de perguntar “qual modelo devemos usar?” os aplicativos solicitarão um perfil de modelo que satisfaça as restrições de capacidade, custo, latência, residência e retenção.
Previsão: os recursos de privacidade específicos do provedor continuarão a divergir. Gateways que normalizam apenas formatos de solicitação e resposta não serão suficientes; as equipes de produção também precisarão de normalização de políticas.
Conclusão acionável
O roteamento com reconhecimento de retenção de dados não é um painel de conformidade separado. Ele pertence ao caminho da solicitação.
Comece com três resultados: uma taxonomia de sensibilidade de solicitação, uma matriz de capacidade do provedor com versão e um pequeno conjunto de regras de política como código para ZDR, residência, registro bruto, fallback e recursos de alteração de retenção. Em seguida, faça com que o gateway retorne motivos de negação claros e preserve as análises sem armazenar conteúdo bruto por padrão.
Esse design centraliza decisões que, de outra forma, estariam espalhadas entre opções de SDK, variáveis de ambiente, consoles de provedores e convenções específicas de equipe. Ele também fornece às equipes de segurança e de plataforma uma trilha de auditoria prática: qual solicitação foi permitida, qual versão da política aplicada, qual perfil de modelo foi selecionado e por quê.