Enterprise Controls and Trust2026年7月4日Big Y

AI API 数据保留清单:日志、提示、输出和计费记录

使用此 AI API 数据保留清单,以决定在模型调用后应保留哪些提示、输出、请求日志、审计事件、计费记录、提供商设置和导出副本。

AI API 数据保留清单:日志、提示、输出和计费记录

AI API 数据保留清单应在生产流量开始前回答一个简单的问题:模型调用后会存在哪些记录,谁可以读取它们,它们会保留多久,以及买家以后可以审查哪些证据?

这个问题很快就会变得复杂。单个 AI 请求可以创建提示记录、输出记录、网关请求日志、提供商滥用监控日志、审计事件、跟踪、缓存条目、计费行、支持工单、导出、屏幕截图和事件说明。一些记录帮助工程部门调试故障。一些帮助财务部门核对支出。一些帮助采购部门证明供应商设置已经过审查。对于敏感工作负载,有些记录根本不应该存在。

在通过网关路由真实客户数据之前,请使用此 AI API 数据保留清单来区分这些记录。目标不是盲目地减少记录。目标是为运营、安全、财务和采购保留正确的证据,而不是将每个提示和输出都变成一个长期存在的数据存储。

对于 Flatkey 买家,此审查属于网关批准文件。Flatkey’s 当前的公共网站将产品定位为 AI API 网关和模型运营平台,用于模型访问、路由、计费、使用分析和运营控制。这使其成为集中管理有关路由、模型、所有者、使用情况和成本证据的天然场所。但这并不能免除在批准前验证特定于账户的保留策略、提供商合同和有效负载存储行为的需要。

AI API 数据保留清单

从记录类别开始,而不是供应商的口号。“零数据保留”对于某个提供商功能而言,并不能自动描述您的网关日志、可观察性跟踪、计费分类账、导出或支持工作流程。

保留范围 需要决定的内容 要保留的证据 默认姿态
提示 是否存储原始的用户/系统/开发者消息、检索到的上下文、文件和工具输入 数据流图、有效负载设置、编辑测试、删除测试 默认不存储原始提示
输出 是否存储模型响应、工具调用参数、生成的文件和流式块 输出日志记录策略、保留设置、访问测试 默认不存储原始输出
请求日志 为调试和运营保留哪些元数据字段 示例日志事件、字段字典、保留期 存储元数据,不含有效负载主体
审计日志 哪些管理和策略事件足够不可变以供审查 角色变更日志、关键事件日志、路由策略变更日志 存储时间长于调试有效负载
计费记录 哪些使用、成本、发票、充值、税收和退款记录会保留下来 发票样本、使用导出、对账字段 根据财务和合同需求进行存储
提供商记录 上游模型提供商为滥用监控、应用程序状态、缓存和功能存储保留了哪些内容 提供商文档、合同条款、账户截图 按提供商、端点和账户进行验证
可观察性导出 哪些跟踪、警报、仪表板、工单和仓库会收到副本 目标列表、掩码配置、导出样本 导出前最小化并进行编辑
支持记录 事件说明是否包含提示/输出片段 支持工作流程、工单保留、编辑规则 存储经过清理的证据,而非原始有效负载

这是核心的 AI API 数据保留清单:定义每个记录类别,指定保留负责人,通过带日期的回读来证明设置,并为数据可能被复制的每个地方设置续订触发器。

将保留与训练分开

提供商的训练策略只是审查中的一项。采购团队经常会问 API 数据是否用于训练模型。这很重要,但它没有回答提示或输出是否会为了滥用监控、应用程序状态、产品功能、支持、分析或计费而被存储。

OpenAI’s 的平台数据控制区分了模型训练、滥用监控保留和应用程序状态保留。同一份文档指出,滥用监控日志可能包含提示和响应,默认保留长达 30 天,而符合条件的客户可以申请诸如 Modified Abuse Monitoring 或 Zero Data Retention 等控制措施。它还列出了特定于端点的例外情况,包括某些 API 的存储应用程序状态以及文件、对话、视频、缓存、网络搜索、托管容器和其他功能的特定于功能的行为。

Anthropic’s 的API 数据保留文档将 Zero Data Retention 定义为在 API 响应返回后,客户数据不会被静态存储,但法律要求、防止滥用和特定于功能的存储除外。它还指出,功能资格可能因 API 功能而异。

Google’s 的Gemini Developer API ZDR 文档指出,付费服务的提示和响应不会用于改进 Google 的产品,同时也描述了为滥用监控和某些功能的特定功能存储而进行的有限提示和响应日志记录。该页面将 ZDR 视为一项配置和功能选择审查,而不是一个普遍的假设。

对买家而言,这是一个很实际的教训:保留提供商策略的证据,但不要让它取代您自己的 AI API 数据保留策略。提供商可能会保留一些数据,网关可能会保留另一些,而您的可观测性堆栈可能会同时复制这两者。

提示和输出需要有自己的规则

在 AI API 数据保留清单中,提示和输出是风险最高的记录,因为它们通常包含最有用的调试证据和最敏感的业务数据。

将提示和输出的保留视为一个例外工作流:

  1. 对于生产路由,默认不存储原始有效负载,除非特定工作负载需要。
  2. 仅在固定数据证明掩码处理对提示、输出、工具结果、检索块、错误和流式事件都有效后,才允许存储经过编辑的有效负载
  3. 仅在指定的事件、预演测试、客户批准的工作流或供应商升级的情况下,才允许存储完整的有效负载
  4. 在收集之前设置过期时间,这样调试窗口就不会变成永久存储。
  5. 记录对有效负载日志的访问,因为日志查看器本身就是一个敏感系统。
  6. 在有效负载过期后,保留清理过的事件摘要,而不是原始的提示或输出。

OWASP 日志记录备忘单在这里很有用,因为它将日志中的敏感值视为一个设计问题,而不是格式问题。机密信息、访问令牌、敏感个人数据、支付数据、连接字符串、加密密钥和高机密性数据通常应在记录日志前被移除、掩码处理、清理、哈希或加密。AI 提示可能包含所有这些类别。

对于编辑模式,工具文档也指向了相同的方向。Langfuse masking 可以在跟踪数据离开应用程序之前编辑数据。Helicone Omit Logs 旨在保留运营指标,同时省略请求和响应体。Portkey request logging controls 将请求/响应内容与面向指标的日志记录分开。即使您使用不同的技术栈,模式也是相同的:在存储和导出前进行编辑或省略。

请求日志应以元数据为先

请求日志通常是 AI API 运营的主力。它们不需要包含原始提示也能发挥作用。

对于大多数生产路由,一个元数据优先的事件就足够了:

{
  "request_id": "req_01jz4...",
  "timestamp": "2026-07-04T04:00:00Z",
  "environment": "production",
  "owner_key_id": "support_summarizer_prod",
  "route": "support-summary",
  "endpoint_family": "chat_completions",
  "requested_model": "approved-summary-route",
  "served_provider": "selected_by_gateway",
  "prompt_tokens": 1840,
  "output_tokens": 312,
  "status": "success",
  "latency_ms": 1420,
  "cost_usd": "0.0042",
  "payload_storage": "none",
  "retention_class": "ops_metadata_90d"
}

该事件支持账单审查、事件关联、路由审查、SLO 审查、滥用调查和所有者退款,而无需保留提示体或响应体。

Cloudflare AI Gateway 日志记录说明了为什么请求日志的决策需要明确。网关日志可以包括提供商、模型、状态、令牌使用量、成本、持续时间、提示、响应和策略操作,而每个请求的控制可以影响是否存储请求和响应体。保留清单应同时捕获默认网关设置和任何每个请求的覆盖路径。

使用此请求日志清单:

字段组 默认保留? 备注
请求 ID、跟踪 ID、时间戳 支持和事件审查所需
密钥、项目、路由、环境 使用稳定的内部 ID;避免原始机密信息
提供商、模型、端点族 路由和供应商证据所需
状态、错误类别、重试/回退原因 可靠性审查所需
令牌数、延迟、成本 财务和异常检测所需
安全/DLP/策略结果 通常 存储决策元数据,除非有要求,否则不存储敏感的匹配文本
提示体 默认不保留 通过调试工作流升级
输出体 默认不保留 通过调试工作流升级
工具输入和输出 默认不保留 通常包含私有系统数据
检索块和文件 默认不保留 通常包含文档、合同或客户数据

这就是 AI API 数据保留从理论走向实践的地方:工程师仍然可以获得他们需要的记录,而隐私和安全负责人可以看到哪些内容被有意省略了。

审计日志不是有效负载日志

审计日志回答了谁更改了什么、何时更改以及控制路径是否有效。它们通常应比调试有效负载保留更长时间,但不应成为一个后门的有效负载存储。

AI API 数据保留清单应包括以下审计事件:

  • API 密钥的创建、轮换、禁用和删除。
  • 工作区、项目、路由、提供商和模型策略的变更。
  • 配额、预算和计费控制的变更。
  • 有效负载日志记录的启用、禁用和异常批准。
  • 敏感日志和导出的访问事件。
  • 管理员角色变更和权限授予。
  • 数据导出、删除和支持升级事件。

审计日志应记录执行者、目标、操作、时间戳、源系统、批准参考以及变更前后的状态。它们应避免存储原始提示、原始输出、原始 API 密钥、持有者令牌、支付卡数据和未经编辑的客户数据。

当采购部门需要一个持久的网关操作事件模型时,请将本文与 Flatkey 的AI API 使用审计日志指南联系起来。审计日志应证明保留策略已应用;它不需要保留触发该策略的敏感有效负载。

计费记录有不同的保留需求

在 AI API 数据保留清单中,计费记录很容易被忽视,因为它们看起来不像提示数据。但它们仍然很重要。

计费和财务记录可能包括:

  • API 密钥、工作区、团队、项目、客户或环境 ID。
  • 模型、提供商、端点系列和路由。
  • 提示令牌、输出令牌、缓存令牌、图像/视频单位、持续时间或请求计数。
  • 单价、有效价格、加价、积分、税费、发票行、充值记录、退款和余额变动。
  • 时间戳、计费周期、发票 ID、支付提供商 ID 和分类账参考。

这些记录通常需要比调试有效负载保存更长时间,因为财务、税务、客户支持和采购团队需要对账证据。它们仍然需要最小化。计费分类账不应需要原始提示或输出来证明支出。

请使用此计费保留表:

计费产物 典型所有者 保留问题 是否需要有效负载?
使用情况行 财务运营和平台 我们需要多长时间的退款证据?
发票 财务 适用哪些税务、审计和客户合同规则?
充值或预付余额变动 财务 团队能否将余额变动与使用情况进行对账?
定价快照 采购和财务 请求运行时哪个单价是有效的?
客户争议记录 支持和财务 有什么经过清理的证据可以解释这笔费用? 通常不需要
供应商发票 财务和采购 上游支出能否与内部使用情况挂钩?

Flatkey 的当前定价页面描述了透明的模型定价、按需付费使用、配额限制、使用分析、成本控制和计费审查路径。将这些视为有用的公开筛选声明,然后为自己的买家记录验证实时仪表板、账户条款、发票和导出数据。

建立买方拥有的证据文件

信任页面很有帮助,但持久的产物应由买方拥有。六个月后的审查员应该能够看到批准日期检查了什么以及后来发生了什么变化。

创建一个具有以下结构的文件夹或治理记录:

证据项目 要捕获的内容 续订触发器
数据流图 从应用程序到网关、提供商、可观察性、计费、支持和导出的请求路径 新的提供商、工具、路由或导出器
提供商设置 用于保留、训练、ZDR/MAM、区域和应用程序状态行为的屏幕截图或 API 回读 提供商合同或功能变更
网关设置 请求日志记录、有效负载日志记录、编辑、删除、路由策略和导出控制 网关发布或配置变更
示例元数据日志 不含有效负载正文的、经过清理的、类似生产的事件 新的端点系列或路由
编辑测试 提示、输出、工具数据、检索块和流块的固定结果 新的 SDK、模型、工具或导出器
有效负载异常记录 谁批准了完整的有效负载日志记录、原因、范围、到期时间和清除证据 每个事件
审计事件示例 密钥、路由、配额、角色、日志记录、导出和删除事件 角色或管理员工作流变更
计费示例 使用情况行、定价快照、发票/充值证据和所有者映射 定价或计费工作流变更
访问审查 谁可以查看日志、有效负载保险库、导出、发票和支持工单 每季度或角色变更时
删除测试 证明日志、有效负载、导出和工单可以过期或被清除 保留策略或客户删除流程变更

这个证据文件将 AI API 数据保留从供应商的声明转变为一个可重复的审查流程。它还使续订变得更容易,因为审查员可以将当前状态与先前状态进行比较,而不是从营销文案重新开始。

在启动前设置保留类别

不要让每个系统都自行设定其保留期。定义保留类别,并将每条记录映射到一个类别。

retention_classes:
  ops_metadata_90d:
    stores_payload: false
    records:
      - request_id
      - route
      - provider
      - model
      - status
      - latency
      - token_usage
      - cost
    access: engineering_ops_finance_security
  debug_payload_72h:
    stores_payload: true
    approval_required: true
    redaction_required: true
    expiration_required_before_collection: true
    access: named_incident_responders
  audit_control_1y:
    stores_payload: false
    records:
      - actor
      - action
      - target
      - before_after_state
      - approval_reference
    access: security_procurement_admins
  finance_ledger_contract_term:
    stores_payload: false
    records:
      - usage
      - pricing_snapshot
      - invoice
      - recharge
      - balance_movement
    access: finance_procurement

确切的保留期限应根据您的合同、安全策略、税务要求和客户承诺来确定。重要的是,在流量开始之前类别就已存在,并且有效负载存储应作为单独的属性可见。

这如何与 Flatkey 配合

Flatkey 可以支持这种操作模型,因为其公共产品层面围绕着一个 API 网关、模型路由、使用情况可见性、计费、配额控制和运营审查。2026 年 7 月 4 日的实时定价 API 检查返回了 success=true、45 个模型行、48 条供应商记录、定价版本 a42d372ccf0b5dd13ecf71203521f9d2,并支持包括 /v1/chat/completions/v1/messages、Gemini generateContent、图像生成和视频端点在内的端点路径。

使用 Flatkey 作为网关的证据层面,然后验证公共页面无法证明的特定于账户的详细信息:

  • Flatkey 存储哪些请求元数据。
  • 是否存储原始提示和响应体。
  • 有效负载存储是否可以被禁用、限定范围、编辑或限制时间。
  • 哪些审计事件可用于密钥、路由、配额、计费和日志访问。
  • 哪些计费导出可用于财务对账。
  • 每个路由背后适用哪些提供商的保留设置。
  • 哪些支持、导出和可观察性路径可以复制请求数据。

这种区别很重要。网关可以简化操作和证据收集,但买方仍然是最终 AI API 数据保留清单的所有者。

运行预生产保留测试

在批准生产路由之前,针对测试工作负载运行此清单。

  1. 发送一个正常请求,并确认元数据日志中不包含提示或输出体。
  2. 发送一个包含预设敏感固定数据的请求,例如电子邮件、访问令牌格式的字符串、账户 ID、类似支付的值和专有代码标记。
  3. 确认这些固定数据不会出现在日志、跟踪、警报、支持导出或计费记录中,除非路由明确进入了经批准的调试通道。
  4. 在非生产环境中启用一个范围限定的调试有效负载例外,并验证批准、访问日志记录、编辑和过期设置。
  5. 清除或等待调试保留期结束,并确认回读不再返回有效负载。
  6. 拉取日志策略变更和清除操作的审计事件。
  7. 拉取计费或使用情况行,并确认其在没有有效负载内容的情况下可以对账。
  8. 在证据文件中记录屏幕截图、API 回读信息、时间戳、账户 ID 和审查员姓名。

此测试可以捕捉到常见的失败情况:团队在网关中禁用了有效负载存储,但仍然通过跟踪导出器、警报消息、支持工单或调试屏幕截图泄露了提示文本。

这在信任审查中的位置

AI API 数据保留是更广泛的网关审查的一部分。使用企业 AI API 网关清单来涵盖访问、路由、计费、配额和运营所有权。使用AI API 供应商风险评估来比较上游提供商合同和第三方处理器。当采购部门询问网关如何证明谁更改了密钥、路由、配额和日志记录策略时,请使用AI API 使用情况审计日志指南。

这些审查应该相互关联。网关清单展示了控制层面。供应商风险评估展示了上游合同和数据边界。审计日志指南展示了持久的管理证据。这份 AI API 数据保留清单则展示了每次请求后留下了什么。

常见问题解答

什么是 AI API 数据保留?

AI API 数据保留是指决定 AI API 请求发生后,提示、输出、元数据日志、审计事件、跟踪、计费行、支持记录和提供商端记录存储多长时间的策略和系统行为。

零数据保留是否等同于无日志?

不是。零数据保留通常描述的是针对客户内容的提供商或特定于功能级别的控制。它可能不涵盖网关元数据、审计日志、计费记录、可观察性导出、支持工单或每个提供商的功能。务必核实其范围和例外情况。

是否应该为调试目的存储提示和输出?

仅作为例外情况。元数据日志应作为生产流量的默认设置。仅在经批准的工作流、范围限定的事件、预演测试或客户批准的通道中存储经过编辑或完整的有效负载,并在收集前设置过期时间。

AI API 请求日志应保留多长时间?

没有一个通用的期限。元数据日志通常需要足够的时间来进行事件审查、计费对账和滥用调查。原始提示和输出有效负载的保留期通常应远短于元数据、审计日志或计费记录。

哪些计费记录对 AI API 保留很重要?

保留使用情况行、令牌计数、模型/提供商标识符、定价快照、发票、充值记录、退款和所有者映射作为财务证据。这些记录不应要求原始提示或输出正文。

采购部门应向网关供应商询问什么?

要求提供有关请求元数据、有效负载存储行为、编辑、删除、审计日志、访问控制、计费导出、提供商保留设置和第三方导出目的地的带日期证据。然后将该证据与您自己的数据分类和事件响应策略进行比较。

结论

AI API 数据保留清单将模糊的信任声明转变为可审查的操作文件。将提示与输出分开,将请求日志与审计日志分开,将计费记录与调试有效负载分开。默认保留元数据,仅在例外情况下存储原始有效负载,在存储前测试编辑,并为续订保留带日期的证据。当您准备好通过一个网关界面集中管理模型访问、使用、计费和路由时,请查看 Flatkey 当前的定价和模型目录,然后获取密钥