Claude Access Transparency 合规 API：企业运营商必须在第一个 cmek_preserve 事件到来之前做好准备

每一个在敏感数据上运行 AI 工作负载的企业运营商都面临同一个治理问题：当 Anthropic 审查内容时，你会知道吗？随着 Claude Access Transparency 文档在 7 月 10 日的扩展——新增了 cmek_preserve 原因代码、过滤示例，并澄清了自动化 pipeline 也可触发保存事件——答案现在是明确的"是"，但前提是你在第一个事件到来之前已经完成了 Compliance API 的集成。

这不是一项新能力。Access Transparency 在 Anthropic 平台上已经存在一段时间。7 月的变化在于文档深度：两个新的 cmek_preserve 原因代码（policy_violation_investigation 和 csae_report）、一个事件 payload 示例，以及明确说明保存可由自动化安全 pipeline 触发，而不仅仅是人工审核员。对于尚未将此功能集成到审计体系的运营商来说，这次文档扩展就是立即行动的信号。

发生了什么

Anthropic 在 Access Transparency 参考页面上新增了三项对运营商有实质意义的内容：

两个新的 cmek_preserve 原因代码。 原因代码表中现在新增了 policy_violation_investigation（内容在 Trust and Safety 调查期间被保存）和 csae_report（内容作为儿童安全报告的证据被保存）。原有的代码——safety_review 和 incident_response——仍适用于 anthropic_access 事件，保存代码仅适用于 cmek_preserve 事件。

对自动化 pipeline 触发的明确说明。 文档现在明确指出，cmek_preserve 事件的写入"无论保存是由人工审核员还是自动化安全 pipeline 触发"。这对那些认为"没有人工访问事件 = Anthropic 对数据零操作"的运营商来说是一个重要变化。anthropic_access feed 为空并不等于没有内容审查——自动化分类器在流量上运行，可以独立触发保存事件，无需先生成 anthropic_access 事件。

cmek_preserve 事件的过滤示例和 payload 示例。 运营商现在可以这样查询：

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --data-urlencode "activity_types[]=cmek_preserve" \
  --data-urlencode "limit=50" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"

事件 payload 与 anthropic_access 事件格式相同——字段完全一致，只有 type 值不同——这意味着为访问事件构建的解析器无需修改即可处理保存事件。

为什么这对 AI 工程团队很重要

通过 Claude 路由 API 流量的企业运营商需要将 anthropic_access 和 cmek_preserve 视为两个不同但互补的信号：

• anthropic_access = Anthropic 的人工员工在你的保留窗口内，以命名原因代码查看了你的内容。
• cmek_preserve = 你的内容加密状态发生了变化；内容被重新加密，移出你的 CMEK 密钥，保留期超出你的标准窗口。

第二类事件具有直接的合规影响。对于受监管行业——医疗健康（HIPAA）、金融服务、法律——cmek_preserve 事件意味着原本应该轮转出保留期的内容被保留了。这是一个实质性的数据生命周期事件，你的合规和法务团队需要了解，在 GDPR 等框架下通常要求在 72 小时内完成。

Anthropic 文档中说明的两个工作日交付窗口意味着这个 feed 不是实时告警渠道，而是审计记录。配置 SIEM 的回溯窗口或定时导出时要相应调整：日导出任务使用 48 小时回溯窗口会漏掉事件，使用 7 天回溯则不会。

Router/Operator 视角

对于运营代理 Claude API 流量的 AI gateway 团队，Access Transparency 引入了两个运营层面的注意事项：

记录 msg_id 以实现关联查询。 anthropic_access 和 cmek_preserve 事件携带 resource_details.id，即 Messages API 响应中的 msg_... ID。如果你的 gateway 没有将这个 ID 与内部请求元数据（用户 ID、租户、工作流）一同记录，那么事件只能告诉你访问发生了，却无法追溯到哪个下游应用、用户或对话。这是大多数 gateway 日志配置中的漏洞——在启用 Access Transparency 之前修复它，而不是之后。

多 provider 路由栈中的覆盖盲区。 Access Transparency 覆盖 api.anthropic.com 流量、使用 API key 的 Claude Code session，以及 Claude Platform on AWS。它不覆盖 Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry，以及 Batch/Files API。运营同时分发流量到 api.anthropic.com 和 Bedrock 的多 provider 路由栈的团队，需要为每条路径建立独立的透明度机制。Bedrock 流量走 AWS CloudTrail 记录密钥使用，以及 AWS 服务控制访问——而非 Anthropic Compliance API。

成本与资格要求。 Access Transparency 不是自助式功能。它需要联系 Anthropic 客户代表并满足合同条款中定义的资格标准。没有企业合同的团队无法使用此功能。这也意味着没有企业合同、提供托管 Claude 路由的 AI gateway 供应商，无法向其客户提供这一审计层——这是 build-vs-buy 决策中值得考虑的治理差距。

TheRouter 用户应该关注什么

如果你的组织正在评估或积极通过路由 gateway 使用 Claude API 流量，本次文档更新的行动事项如下：

1. 确认你的组织是否已启用 Access Transparency。 如果你有企业合同但尚未注册，请联系 Anthropic 客户代表。
2. 在 gateway 中添加 msg_id 日志。 记录每个 Messages API 响应体中的 id 字段，并与内部请求元数据一同存储。没有这个，未来的审计事件将难以追溯到具体工作流。
3. 配置 Compliance API 轮询时使用 7 天回溯窗口。 不要依赖实时事件交付——将该 feed 视为延迟审计日志，并相应配置 SIEM 集成。
4. 为 anthropic_access 和 cmek_preserve 设置不同的告警阈值。 访问事件需要人工审查；保存事件可能需要根据数据处理协议进行法律通知。
5. 审计你的多 provider 路由覆盖。 如果你同时路由流量到 api.anthropic.com 和 Bedrock，你需要独立的审计机制。TheRouter 的 provider 路由策略可以帮助你标记和分离这些流量，以便下游合规报告使用。

对于探索 AI 路由治理 的团队，这一功能代表了新兴规范：provider 构建可观测、可审计的数据访问层，为企业运营商提供数据处理方式的可验证记录。