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

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

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

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

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

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

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

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

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

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

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

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

当前的几份公共提供商文件说明了为什么这是必要的：

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

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

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

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

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

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

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

从一个小的分类法开始。它应该足够简单，可供开发人员使用，但具有足够的表现力来推动政策的制定。

敏感度标签示例：

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

分类可以来自多个来源：

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

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

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

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

示例字段：

<前><代码>{ "profile_id": "provider_x.chat.eu.zdr", “提供商”：“provider_x”， "model": "模型-大", "api_family": "chat_completions", “端点”：“https://eu.example-provider.com/v1”， “地区”：“欧盟”， “处理居住权”：[“欧盟”]， “storage_residency”：[“欧盟”]， “zdr_eligible”：正确， “zdr_contract_required”：正确， "training_use": "not_used_for_training_on_paid_api", "abuse_monitoring": "approved_modified_retention_required", “developer_log_retention_days”：0， “raw_prompt_logging_allowed”：假， “支持的功能”：{ “plain_chat”：正确， “流”：真实， “tool_calls”：正确， “search_grounding”：假， “maps_grounding”：假， “文件上传”：假， “批次”：假， “stored_conversations”：假 }, “last_reviewed”：“2026-08-01”， “source_refs”：[“security-review-123”，“供应商文档版本-abc”] }

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

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

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

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

伪代码中的示例规则：

如果 data_class == "credentials" 则拒绝
  原因“credentials_must_not_be_sent_to_model”
仅当 data_class 在 ["regulated", "customer_pii"] 中时才允许
  并且 profile.zdr_eligible == true
  和 profile.zdr_contract_required_satisfied == true
  Reason_on_failure“model_profile_not_zdr_eligible”
如果 Residence_required == "eu" 则拒绝
  并且“eu”不在 profile.processing_residency 中
  原因“region_processing_not_supported”
如果 data_class 位于 ["confidential", "customer_pii", "监管"] 中，则拒绝和 request.raw_prompt_logging == true
  原因“raw_prompt_logging_not_allowed”
如果 request.features.search_grounding == true 则拒绝
  并且policy.requires_zdr == true
  并且 profile.feature_storage.search_grounding_days > 0
  原因“grounding_requires_retained_content”
如果fallback_profile.retention_level 

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

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

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

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

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

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

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

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

安全默认遥测字段：

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

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

• 客户或租户批准
• 时间窗口狭窄
• 抽样限制
• 编辑通行证
• 单独的访问控制
• 过期时间短
• 审核日志，了解谁启用了它以及为什么启用它

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

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

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

响应示例：

<前><代码>{ “错误”：{ “类型”：“policy_denied”， “代码”：“grounding_requires_30_day_storage”， "message": "标记为 require_zdr 的工作负载不允许搜索接地，因为此提供程序功能存储提示、上下文和输出内容。", “request_id”：“req_123”， “policy_version”：“保留政策-2026-08-01”， “允许的操作”：[ “禁用搜索接地”， “选择个人资料：zdr_plain_chat”， “请求异常” ] } }

有用的拒绝代码包括：

• 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_precession_missing
• credentials_Detected

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

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

每个异常应包括：

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

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

操作清单

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

权衡以明确

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

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

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

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

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

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

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

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

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

可行的结论

数据保留感知路由不是单独的合规性仪表板。它属于请求路径。

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

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

相关阅读

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