跳转到主要内容
如果你的智能体处理客户数据，PII 泄漏的两个地方是你发往上游的提示和 你保留的日志。本配方端到端接好PII 安全日志：一条 PII 掩码规则在 模型之前擦洗请求、原始匹配内容默认不进入你的匹配信息流，而请求日志 保留期被钳制，使其不留存。下面的一切都是控制台中的工作区配置——你的 应用照旧调用 /v1/chat/completions，不作改动。
每个配置步骤都受角色门控。编写一条防护栏需要 Developer+；更改保留期 或合规驻留地需要工作区 Admin。读取 Matches 信息流对任何 Member 开放。

​
1. 三步走的 PII 安全日志流水线

一条 PII 安全的流水线是三项独立控制，每一项都是你为整个工作区翻动一次 的开关：

在边缘掩码

一条 pii 防护栏规则在上游模型看到请求之前，把邮箱、SSN、卡号及 更多脱敏成带类型的标签。

不记录原始内容

防护栏的 Log raw content 开关默认关闭，因此匹配信息流记录一条 规则触发了，而绝不记录匹配的子串。

钳制保留期

请求日志保留期默认为 30 天，并被服务端钳制到 180 天的硬性 上限——按设计是短命的。
本页其余部分用一个具体示例把这三项接到一起。

​
2. 在模型看到之前掩码 PII

创建一条防护栏，带一条 input 阶段、mask 动作的单一 pii 规则。 在一次 mask 动作上，每个匹配被替换成一个带类型的标签——一个邮箱变成 [EMAIL]，一个 SSN 变成 [SSN]——因此上游模型收到一个脱敏后的请求， 而不是原始的。 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn", "credit_card", "ip"]
}
在控制台中：Guardrails → New guardrail，加入上面的规则（或从 PII 类别下的 PII Shield 预设开始），然后保存。通过密钥的 Guardrail 下拉框把它附加到一个 API 密钥，或把它设为工作区默认值，这样每个密钥 都继承它。
想要某些实体被掩码而另一些被直接拒绝？一条规则可以携带按实体的覆盖 ——掩码 email/phone 但在 ssn/credit_card 上 block——通过 entity_actions。参见 防护栏 了解完整的 PII 实体集、自定义正则实体，以及按实体的覆盖语法。
用那个密钥发送一个请求，邮箱就在传输中被脱敏： 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Draft a reply to jane@acme.com about her SSN 123-45-6789"}
    ]
  }'
模型看到 Draft a reply to [EMAIL] about her SSN [SSN]。原始值永远不会 离开网关。
输入阶段掩码正是一条 PII 安全流水线所依赖的——它在上游调用之前擦洗 请求。输出阶段掩码在非流式和流式响应上都有效（流式就地重写每个 chunk），因此你也可以脱敏模型发出的 PII。

​
3. 让原始内容远离你的日志

每条触发的规则都记录一次匹配（match）——它的类型、动作、stage 和一个 细节字符串。该匹配是否也存储匹配的子串（实际的邮箱地址、实际的 SSN） 由防护栏的 Log raw content 开关门控，该开关默认关闭——隐私保守 姿态。
在 Log raw content 关闭时，Matches 信息流 显示一条 pii 规则在 input 阶段掩码了一个 email，但绝不显示那个 地址本身。那正是你为一条 PII 安全流水线想要的：对触发了什么的完整 可审计性、零保留的 PII。在生产中保持它关闭；仅为短命的分诊按防护栏开启 它。该开关不可追溯。
在 Guardrails → Matches（GET /api/guardrail/match，Member）读取信息 流。按防护栏、规则类型和动作分组并过滤，以查看你的掩码率，而绝不暴露 一个真实值。把一次匹配标记为误报是一个 Admin 动作 （POST /api/guardrail/match/:id/mark-fp）。

​
4. 钳制请求日志存活多久

请求日志捕获是一个可选启用的排障功能，当它开启时，保留期是有界的：
设置值行为
默认保留期30 天未设置每工作区值时应用。
硬性上限180 天任何更长的值都被服务端向下钳制。
你不能超过 180 天的上限——它在写入时执行，不是一个建议。结合 §2 的掩码， 即便被捕获的日志也只持有脱敏后的文本，并且它们按一个固定的时钟到期。
把被捕获的请求日志当作一个调试杠杆，而不是一个数据存储。在一次事件 期间启用捕获、保持保留窗口紧凑，并依赖 Matches 信息流（当 Log raw content 关闭时它从不持有原始 PII）来做稳态可观测性。

​
5. 被遗忘权与驻留地

另外两项控制让一条合规的流水线完整：
一次用户自删除进入一个 30 天宽限窗口，之后 PII 被擦洗，一次级联 清除把那个用户的请求日志、防护栏匹配和防火墙事件一起 移除——因此没有任何工件比擦除请求活得更久。
通过 PUT /api/compliance/residency（Admin）设置你的合规 报告工件被钉到的区域（us、eu、uk、ap、cn、global）。 对一份报告的跨区域读取被拒绝。这钉住的是报告工件区域——它不是 推理数据的地理钉定。

​
6. 上线前先验证

在任何流量依赖它之前，证明掩码做你预期的事：
1

沙箱测试规则

打开防护栏编辑器中的 Test 标签页，粘贴带一个看起来真实的邮箱和 SSN 的样本文本，挑选 input 阶段，然后运行。沙箱返回判定和渲染后的 文本（[EMAIL]、[SSN]），不作上游调用、不消耗任何配额。
2

对一个语料库做 eval

Eval 标签页在捆绑或自定义的 JSONL 语料库上运行策略，因此你能在 上线前衡量捕捉率和误报。
3

确认信息流保持干净

发送一个真实请求，然后打开 Matches 并确认条目显示规则触发了、 带没有匹配的子串——证明 Log raw content 是关闭的。

​
相关

防护栏参考

完整的 PII 实体集、自定义实体、按实体的覆盖，以及 Matches 信息流。

保护一条 RAG 流水线

用于检索增强智能体的 grounding 和 PII 控制。

SOC 2 证据

把防护栏和防火墙活动变成签名的审计报告。

数据外泄

让 PII 不上线、不进日志背后的威胁模型。