数据保留感知 AI API 路由：在网关处实施 ZDR、驻留和日志记录策略

安全团队不仅需要知道哪种模型最便宜、最快或功能最强大。他们需要知道特定请求是否可以合法且可操作地发送到特定提供商、端点、区域、功能和日志记录模式。

这比听起来更难。模型可能适合普通内部聊天，但不适用于客户 PII。提供商可能会为一条 API 路径提供零数据保留，而搜索基础功能会在固定期限内存储提示和输出。区域可能支持存储驻留，但不支持您期望的处理模式。开发者拥有的日志可能是可配置的，而提供商滥用监控日志则遵循不同的政策。

实际的答案是将保留决策从各个应用程序移至AI API网关。网关应对请求进行分类，根据提供商能力矩阵对其进行评估，阻止不兼容的功能，仅路由到批准的模型配置文件，并记录策略决策，而不默认存储原始提示。

读者问题：提供商隐私条款不是运行时控制

大多数团队都会从电子表格或安全审核开始，说明哪些 AI 提供商获得了批准。这很有用，但对于生产路由来说还不够。

应用程序做出运行时选择：

• 哪个模型 ID 应处理此请求？
• 请求是否应该使用搜索基础、文件上传、代码执行、批处理、提示缓存或存储的对话？
• 哪个区域或端点应处理该请求？
• 系统可以记录原始提示以进行调试吗？
• 回退路由可以将相同的请求发送到另一个提供商吗？

其中每个选择都可以更改保留配置文件。当开发人员打开接地或持久对话存储时，在普通聊天模式下符合要求的请求可能会变得不符合要求。为可靠性而设计的回退规则可能会意外地将受监管的数据路由到未经零数据保留、数据驻留或滥用监控控制批准的提供商路径。

建议：将保留行为视为一流的路由约束，而不是附加到提供商帐户的文档。

设计政策之前需要编码的事实

具体条款因提供商、产品、合同、区域、端点和功能而异。不要依赖记忆或一次性复习。构建源拥有的矩阵并在条款更改时更新它。

当前的几份公共提供商文档说明了这样做的必要性：

• OpenAI: API 数据驻留记录为项目配置的，区域请求需要特定于区域的域前缀。 OpenAI 还按区域区分存储支持和处理支持，并指出非美国区域的附加要求。 OpenAI 指出非美国 API 数据驻留需要滥用监控控制和修改保留修正案的批准。
• Anthropic： Anthropic 记录了与 API 相关的商业用例的零数据保留，同时指出某些相关产品或合规 Feed 具有单独的保留模型，包括活动 Feed 和远程会话记录的更长保留时间。
• Google Gemini: Gemini API 术语区分无付费服务和付费服务。对于无偿服务，Google 可以使用提交的内容和生成的响应来改进产品；对于付费服务，Google 表示提示和响应不会用于改进产品。 Gemini 开发者 API ZDR 文档称，付费服务滥用监控日志通常会在有限的时间内保留提示和响应，而获得批准的 ZDR 项目会在记录前清除用户内容和可识别元数据。
• 特定于功能的存储： Gemini 文档指出，Grounding with Google Search 和 Grounding with Google Maps 会将提示、上下文信息和生成的输出存储 30 天，并且在使用这些功能时无法禁用该存储。
• 开发者拥有的日志： Gemini API 日志记录文档显示，对于启用结算功能的项目，开发者拥有的 API 日志默认可保留最多 55 天，并且开发者可以选择更短的时间窗口，例如 7、14 或 28 天。
• 风险管理：NIST 的生成式 AI 配置文件建议监控人工智能生成的内容是否存在隐私风险，并将生成式人工智能政策与现有数据、软件、法律、合规性和风险管理流程联系起来。

这些是在推出之前根据当前供应商文档进行验证的事实。架构教训是稳定的：保留不是一个提供商级别的布尔值。

架构：请求路径中的网关策略引擎

保留感知网关有五个核心组件：

1. 请求敏感度分类器：在路由之前标记工作负载。
2. 提供商能力矩阵：描述提供商、模型、端点、区域、保留、日志记录和功能行为。
3. 策略即代码规则：将安全要求转换为运行时允许、拒绝或审核决策。
4. 功能门控层： 除非明确允许，否则会阻止保留更改功能。
5. 审核和分析层：记录有用的元数据，默认情况下不存储原始提示。

网关无需了解每一个法律细微差别。它需要执行您的法律、安全、合规和平台团队批准的决定。

第 1 步：选择模型之前对请求敏感度进行分类

从一个小的分类法开始。它应该足够简单，可供开发者使用，但表达力足以推动政策的制定。

敏感度标签示例：

• public：公共文档、营销文案、公共网站内容。
• internal：敏感度较低的非公开公司信息。
• confidential：策略、合同、客户背景、未发布的产品详细信息。
• customer_pii：姓名、电子邮件、地址、帐户标识符、支持记录。
• regulated：医疗保健、财务、法律、教育或特定司法管辖区的受保护数据。
• source_code：专有代码、配置、架构文件。
• credentials：秘密、令牌、密码、私钥。在大多数系统中，这应该被阻止，而不是被路由。

分类可以来自多个来源：

• 应用程序提供的标头，例如X-Data-Class: customer_pii.
• 租户政策，其中来自受监管客户的所有流量均被视为受监管，除非被批准的规则降级。
• 端点策略，其中支持票证摘要默认为customer_pii.
• 针对凭据、明显 PII 或政策违规行为的轻量级内容扫描。

建议：不完全依赖自动检测。要求应用程序声明预期的数据类，然后使用扫描来捕获明显的不匹配或强制使用更安全的类。

第 2 步：构建提供商能力矩阵

能力矩阵是路由器评估的事实来源。应像生产配置一样对其进行版本控制、审核和测试。

示例字段：

{
  "profile_id": "provider_x.chat.eu.zdr",
  "provider": "provider_x",
  "model": "model-large",
  "api_family": "chat_completions",
  "endpoint": "https://eu.example-provider.com/v1",
  "region": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": true,
  "zdr_contract_required": true,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": false,
  "supported_features": {
    "plain_chat": true,
    "streaming": true,
    "tool_calls": true,
    "search_grounding": false,
    "maps_grounding": false,
    "file_upload": false,
    "batch": false,
    "stored_conversations": false
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

使用模型配置文件而不是原始模型 ID。配置文件结合了模型、提供商、端点、区域、功能集和保留状态。开发者请求model_profile: compliant_summarization，而不仅仅是model: fastest-large-model.

建议： 在矩阵中包含合同先决条件。一条路由不会仅仅因为供应商在某处提供 ZDR 而获得 ZDR 批准。仅当您的帐户、项目、区域和端点满足所需条件时才会获得批准。

第 3 步：编写政策即代码规则

政策规则应该是明确的、可测试的，并且安全和平台团队可读。

伪代码中的示例规则：

deny if data_class == "credentials"
  reason "credentials_must_not_be_sent_to_model"

allow only if data_class in ["regulated", "customer_pii"]
  and profile.zdr_eligible == true
  and profile.zdr_contract_required_satisfied == true
  reason_on_failure "model_profile_not_zdr_eligible"

deny if residency_required == "eu"
  and "eu" not in profile.processing_residency
  reason "region_processing_not_supported"

deny if data_class in ["confidential", "customer_pii", "regulated"]
  and request.raw_prompt_logging == true
  reason "raw_prompt_logging_not_allowed"

deny if request.features.search_grounding == true
  and policy.requires_zdr == true
  and profile.feature_storage.search_grounding_days > 0
  reason "grounding_requires_retained_content"

deny if fallback_profile.retention_level < primary_profile.retention_level
  reason "fallback_weakens_retention_policy"

这些规则应在选择提供商之前运行，并在回退之前再次运行。后备路由是意外政策漂移的常见原因：主路由可能合规，而后备路由仅可用。

第 4 步：将工具和功能视为改变留存率的功能

不要将保留率单独建模为基本模型的属性。功能通常会改变存储、日志记录或审核行为。

为每个功能提供自己的政策标志：

• 搜索基础：可以根据提供商条款存储提示、检索到的上下文和生成的输出。
• 地图或位置接地：可能会引入特定于位置的日志或保留规则。
• 文件上传：可以将文件与提示和响应分开存储。
• 代码执行：可能会创建临时文件、执行日志或沙箱工件。
• 批处理作业： 可能具有与同步 API 调用不同的保留、排队和结果存储行为。
• 存储的对话：有意保留内容，切勿隐藏在通用聊天选项后面。
• 评估或审核仪表板：可以创建人工审核工作流程或长期存在的数据集。

建议：在租户和路由级别选择启用保留更改功能。如果开发者启用 grounding_search=true，网关应在将请求发送到上游之前根据功能存储规则重新评估请求。

第 5 步：保留分析结果而不存储原始提示

保留感知路由不应让平台团队蒙蔽双眼。您可以保留有用的AI 使用情况分析，同时最大限度地减少内容存储。

安全默认遥测字段：

• 租户 ID 和项目 ID
• 散列或内部API密钥 ID
• 模型配置文件 ID 和提供商 ID
• 请求时间戳和区域
• 输入、输出、缓存和推理令牌计数（如果可用）
• 延迟、状态代码、重试次数和后备决策
• 预计和结算的费用
• 数据分类标签
• 政策版本和政策决策原因
• 请求的功能标记和允许的功能标记

避免默认存储机密流量的原始提示和模型输出。如果调试需要内容，请使用受控工作流程：

• 客户或租户批准
• 时间窗口较短
• 抽样限制
• 编辑通行证
• 单独的访问控制
• 过期时间短
• 审核日志，记录启用者及其原因

这是一种权衡。阻止原始提示日志会使调试、支持、质量审查和滥用调查变得更加困难。但默认情况下存储所有内容会造成更大的隐私、泄露和合规面。

第 6 步：返回可操作的拒绝原因

通用的 403 forbidden 会让开发者感到沮丧并鼓励采取变通办法。返回稳定的机器可读原因和人类可读的解释。

响应示例：

{
  "error": {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "Search grounding is not allowed for workloads marked requires_zdr because this provider feature stores prompt, context, and output content.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "choose_profile:zdr_plain_chat",
      "request_exception"
    ]
  }
}

有用的拒绝代码包括：

• model_profile_not_zdr_eligible
• region_processing_not_supported
• storage_residency_not_supported
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• fallback_weakens_retention_policy
• contract_prerequisite_missing
• credentials_detected

第 7 步：添加例外工作流程，而不是隐藏旁路

一些例外情况是合法的：事件响应、客户批准的调试、迁移测试或临时提供商限制。网关应支持异常，而不会将其转变为永久影子策略。

每个例外情况应包括：

• 审批者身份
• 请求团队或租户
• 票证或风险评估链接
• 商业理由
• 允许的模型配置文件和功能
• 涵盖的数据类
• 到期日期
• 其他日志记录要求

建议：使例外情况比普通政策更窄。避免全局开关，例如disable_retention_policy=true。首选范围覆盖，例如“允许对租户 A、端点 B 进行调试提示日志记录 24 小时，并进行修订和安全批准。”

操作清单

• 创建版本化的提供商能力矩阵。
• 为提供商条款、合同先决条件和保留审核分配所有者。
• 要求应用声明数据类、居住要求和请求的功能。
• 默认机密和受监管的流量不进行原始提示日志记录。
• 将工具、基础、文件上传、批处理和存储的对话表示为单独的功能标志。
• 在主路由和后备路由之前运行策略检查。
• 记录政策版本、模型配置文件、数据类、功能标志和拒绝原因。
• 将分析元数据与提示和输出内容分开。
• 测试代表在 CI 中允许和拒绝案例。
• 每当提供商更改条款、区域、端点或功能时，请检查政策变化。

为了明确而做出的权衡

严格路由减少了选择。ZDR 和驻留限制可能会阻止使用最新模型、成本最低的路由或功能丰富的端点。

区域路由可能会增加延迟或成本。最近的合规区域可能不支持所需的处理模式，或者可能需要不同的提供程序路径。

功能门让开发者感到惊讶。开发者可能认为他们只是启用搜索，但安全性会看到新的保留行为。文档和拒绝消息可以减少摩擦。

提示最小化会使调试变得复杂。团队需要经过编辑的示例、租户批准的调试窗口和强大的元数据来调查问题，而无需存储所有内容。

该矩阵需要维护。提供商条款发生变化。新车型推出。地区扩大。功能从测试版转向生产版。过时的矩阵比没有矩阵更糟糕，因为它会产生错误的置信度。

什么是推荐，什么是预测？

建议：在网关强制保留，在路由之前对请求进行分类，构建提供商能力矩阵，按策略阻止保留更改功能，默认情况下避免原始提示日志记录，并对每个策略决策进行版本控制。

预测：AI 平台团队将越来越多地将隐私状况视为模型选择的一部分。而不是问“我们应该使用哪种模型？”应用程序将要求提供满足功能、成本、延迟、驻留和保留约束的模型配置文件。

预测：提供商特定的隐私功能将继续存在差异。仅标准化请求和响应格式的网关是不够的；制作团队也需要政策规范化。

可行的结论

数据保留感知路由不是单独的合规性信息中心。它属于请求路径。

从三个可交付成果开始：请求敏感度分类法、版本化提供商能力矩阵以及一小组针对 ZDR、驻留、原始日志记录、回退和保留更改功能的政策即代码规则。然后让网关返回明确的拒绝原因并保留分析，默认情况下不存储原始内容。

该设计集中了决策，否则这些决策将分散在SDK选项、环境变量、提供商控制台和特定于团队的约定中。它还为安全和平台团队提供了实用的审核跟踪：允许哪个请求、应用哪个策略版本、选择哪个模型配置文件以及原因。

相关阅读

• 安全提示日志记录和网关级使用情况分析
• 在 OpenAI 兼容 API 期间构建提供商能力矩阵迁移
• 管理具有范围、审批和审核跟踪的代理工具