safety_identifier 字段指南：OpenAI Safety Usage Dashboard 与路由治理

OpenAI Safety Usage Dashboard 改变了 API 团队的一个实际运营问题：安全执行不再只是某次坏请求里出现的 provider-side error。它现在变成了可以按 end-user identifier 查看、并纳入 routing policy、support workflow 和 abuse-response playbook 的使用信号。

对运行 multi-tenant AI products 的组织来说，这很关键，因为一个高风险用户可能影响整个 provider relationship。如果安全事件直到 model call 失败时才可见，operators 只能在客户体验已经受损之后补救。新的 dashboard 让 blocked requests 更容易被检查，但也提高了 gateway-side identity、logging 和 escalation design 的要求。

发生了什么

OpenAI 在 2026 年 6 月 23 日为 API platform 加入了 Safety Usage Dashboard。API changelog 说明，这个 dashboard 会基于请求中用于识别 end users 的 safety_identifier，展示被拦截的 Responses requests。相关 safety-checks guide 解释了这些 identifiers 的作用：OpenAI 可以把风险活动关联到 individual end user，而不是只关联到整个 organization。

同一份 guide 还说明，safety_identifier 可用于 Responses API 和 Chat Completions API；Realtime API 则通过 OpenAI-Safety-Identifier header 表达同一概念。OpenAI 建议发送稳定的 hashed user ID、由 email 生成的 hash，或用于 anonymous previews 的 session ID。help-center article 还说明，新的 safety identifier 已取代此前用于同一目的的 user parameter。

这不只是 analytics。OpenAI 的 safety guide 描述了风险请求越过 thresholds 后可能出现的升级后果：在检查运行时延迟 streaming、阻断某个 individual safety identifier 的访问、向 organization 发送 warning，以及在违规持续时可能丢失 model access。这个 dashboard 给 operators 一个位置查看系统中的 blocked side，而不是把 safety errors 当成孤立的 application logs。

为什么对 AI 工程团队重要

第一个工程问题是 consistency。如果一个 app path 发送 safety_identifier，另一个 path 仍发送旧的 user value，而 Realtime session 两者都不发送，那么 dashboard 就无法和你的 internal tenant model 对齐。通过 AI gateway 代理流量的团队，应在 edge 标准化 safety identity，再让请求进入 provider SDKs。

第二个问题是 privacy。稳定 identifier 有价值的前提，是它足够稳定但不暴露 personal information。OpenAI 明确建议 hash internal IDs 或 emails。Gateway teams 应让 hash 在不同产品间保持 deterministic，但不要把 raw account IDs、names、email addresses 或 customer metadata 发给 provider。

第三个问题是 incident response。一次 blocked request 不一定意味着要 ban account，一次 delayed stream 也不一定是 provider outage。Support、trust-and-safety 与 platform teams 需要共享事件语言：user-level safety block、org-level warning、provider refusal、application moderation block，以及普通 rate-limit 或 quota failure，不应该都被归成同一种 “model failed”。

这也是 OpenAI Safety Usage Dashboard 与此前 platform changes 的连接点。OpenAI 已经为 API responses 加入 inline moderation scores，团队可用它做 application-side policy decisions。新的 dashboard 不同：它报告的是与 safety identifiers 绑定的 provider-side blocked requests。两者结合后，团队可以区分主动 app controls 与 risky request 发出后的 provider enforcement。

路由与运维视角

对 router 和 gateway operators 来说，OpenAI Safety Usage Dashboard 应成为 routing input，而不是 incident 之后才有人截图查看的 console。Routing layer 可以附加 safety identifiers，记录 provider safety outcomes，并决定何时 degrade、pause、escalate，或继续保持同一路由。

一个简单策略是先按 tenant 和 workload class routing，再叠加 safety state。例如，普通 customer-support summarization、内部 code review 和 public user-generated prompts 不应共享完全相同的 escalation rules。如果 public prompts 开始重复产生 safety blocks，gateway 可以要求额外 application moderation、缩短 risky inputs 的 retention，或在 retry high-capability models 前引入 human review。

Fallback 也需要谨慎。如果 OpenAI 因 safety threshold 拦截某个 request，盲目 fallback 到另一个 provider 会把 safety signal 变成 provider shopping。更安全的 router 应把 provider safety blocks 视为 policy events：保留 audit trail，停止对同一 risky payload 的 automatic cross-provider retries，并要求明确 product rule 后才能使用 alternative route。

Cost 与 reliability dashboards 也应该区分 safety latency 和 normal latency。OpenAI 的 guide 说明，streaming 可能因 additional checks 而延迟。如果 gateway 只报告 total time-to-first-token，safety delay 可能被误判为 provider degradation。单独标记这些事件，可以避免错误 failover decisions，也能让 support teams 给出更真实的解释。

TheRouter 用户应关注或尝试什么

采用 TheRouter-style gateway patterns 的团队，应把 OpenAI Safety Usage Dashboard 看成收紧 routing layer 身份传递的提示，而不是孤立的 console feature。

可以用这份 checklist：

• 在 gateway 标准化 safety identity。 请求进入 provider-specific SDK code 之前，为每个 end user 或 anonymous session 生成一个 deterministic、privacy-preserving 的 safety_identifier。
• 把 safety blocks 和 provider errors 分开。 在你的 AI routing layer 中，把 safety blocks、refusals、rate limits、quota failures 和 transport errors 记录为不同 event classes。
• 不要自动 fallback 被拦截 payloads。 Provider safety block 应触发 policy decision，而不是自动换另一个 model 重试。
• 把 dashboard review 接到 moderation policy。 将 OpenAI Safety Usage Dashboard events 与 application moderation signals，以及此前的 inline moderation API response changes 对比。
• 准备 support language。 Delayed stream、individual user block 和 organization warning 需要不同的 customer-facing explanations，也需要不同 escalation owners。

OpenAI Safety Usage Dashboard 表面上只是一个较窄的 API-console feature。放到运营层面，它再次说明 AI gateways 需要 user-aware governance：不只是决定调用哪个 model，还要判断哪个 user、tenant、workload 和 safety state 该被允许触达这个 model。