跳轉到主要內容
一個通過了自身安全訓練的模型，仍可能發出你無法交付的文字：客服回覆裡的 髒話、你品牌助理中出現的競爭對手名稱、你的合規團隊絕不會簽核的一句斬釘截鐵 的法律主張。提示詞看起來沒問題；問題在於回應。 OrcaRouter 在閘道處、在輸出介面上、在回應抵達你的客戶端之前， 審查模型的回應。這個檢查是一條 防護欄規則，在上游模型回應之後執行，並 收斂為一個裁決——封鎖回應、遮罩冒犯的片段，或標記它以供審查——獨立於 是哪個模型服務了該請求。

​
1. 為何要在輸出介面審查 unsafe ai output

輸入審查捕捉到的是一個壞的提示詞。它捕捉不到一個壞的答案：一個被 誘導偏離政策的模型、一個內建防護欄較弱的微調版本，或一個產生了不合理 完成的完全合理的提示詞。輸出介面正是你斷言「無論原因為何，這段文字都 不會離開閘道」之處。 一條閘道規則會確定性地觸發，並在你金鑰背後的每個模型上一視同仁地套用。 而每一條觸發的規則都會落入工作區 Matches 動態——規則型別、 動作、介面——所以你會有一份關於捕捉到什麼、放行了什麼的稽核軌跡。
防禦存在於閘道中，而不是你的應用程式裡。 編輯防護欄，變更就會在 下次呼叫時對每個附加到它的金鑰生效——無需重新部署、無需 SDK 變更。 你的應用程式繼續完全照之前的方式呼叫 /v1/chat/completions。

​
2. 捕捉它的兩種方式

把一個確定性的拒絕清單與一個語意判官配對，以實現縱深防禦。
一條 keyword 規則是不分大小寫的子字串匹配；一條 regex 規則是 一個 RE2 模式（線性時間，無回溯參照）。兩者都在熱路徑上執行，無網路 呼叫——非常適合一份已知的禁用詞清單、一份競爭對手拒絕清單，或一個 結構性模式（一個外洩的聊天範本權杖、一句斬釘截鐵的「你有權獲得賠償」 措辭）。
一條 llm_judge 規則用你工作區裡的一個模型，依你撰寫的評分準則來 評估回應——毒性、偏離品牌的語氣、沒有任何字面清單能捕捉的偏離政策 建議。它攜帶一個 judge_timeout_ms，預設失敗開放（一個判官錯誤 會被記錄而回應繼續），且它的權杖會以一個判官子行計費。參見 LLM 判官參考。

​
3. 一個具體範例——封鎖有毒、遮罩偏離品牌

一個輸出介面防護欄，語意性地封鎖有毒回應，並在剩下的內容中遮罩 禁用的品牌詞： 
{
  "name": "safe-output",
  "rules": [
    {
      "type": "llm_judge",
      "stage": "output",
      "action": "block",
      "judge_model": "openai/gpt-4o-mini",
      "judge_format": "yes_no",
      "judge_rubric": "Does this response contain toxic, harassing, hateful, or otherwise unsafe content? Answer yes or no.",
      "judge_fail_open": true
    },
    {
      "type": "keyword",
      "stage": "output",
      "action": "mask",
      "keywords": ["competitor-name", "internal-codename"]
    }
  ]
}
在主控台中撰寫它——開啟 /console/guardrails → New guardrail，加入 這兩條規則，並從 Token 編輯器把它附加到一個金鑰（綁定以 guardrail_id 存在於金鑰上）。設定在你的主控台工作階段上執行，而不是 你的中繼金鑰；只有下面的 /v1/* 呼叫使用一個 sk-orca-... 金鑰。 
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 this angry customer"}]
  }'
如果模型回傳一個有毒草稿，回應會被以 HTTP 400 guardrail_blocked 扣住。 如果它乾淨但提到了一個禁用詞，那個片段會呈現為一個帶型別的遮蓋，而其餘 部分照流通過。
在你附加之前先反覆迭代。編輯器內的 Test 分頁會在 output 介面上對一個 樣本回應執行目前的政策——無上游呼叫、不消耗配額——而 Eval 分頁會對 一個語料庫執行它，讓你能在上生產之前證明捕捉率與誤報率。參見 評估工具。

​
4. 從一個預設集開始

New guardrail 範本庫在 Safety、Brand 與 Compliance 類別中 提供現成的起點。一個預設集是一顆種子——套用它，然後自由編輯。
類別可作為起點的輸出介面預設集
SafetySystem-Prompt Leak Detector（output）、Strong System Prompt Leak——標記／封鎖那些複述系統提示詞或聊天範本權杖的回應。
BrandProfanity Filter（mask）——在兩個介面上執行，遮罩回應中被列入拒絕清單的詞。（封鎖式的 Profanity / Brand Safety 與 Competitor Mentions 預設集是輸入介面種子；若你想要它們審查答案，把一份副本重新指向 output。）
ComplianceLegal Disclaimer Enforce——標記給出斬釘截鐵的法律／財務建議的回應，以供團隊審查。
Compliance 類別也封裝了與框架對齊的政策；對於由框架驅動的受稽核 上線，安裝一個合規包，並把稽核軌跡與 稽核軌跡配對。

​
5. 串流：那個重要的注意事項

一條輸出規則是否即時強制執行，取決於動作以及你是否串流。
動作非串流串流
block回應被扣住；HTTP 400 guardrail_blocked掃描器在傳輸中途切斷串流並發出一則替代訊息——被封鎖的內容永遠不會抵達客戶端
mask在回傳的文字中遮蓋匹配今天僅限非串流；傳輸途中的串流改寫在路線圖上
flag記錄一個匹配，不改變任何東西記錄一個匹配，不改變任何東西
輸出 mask 在串流回應上尚未即時上線。 如果你串流並仰賴遮罩來遮蓋 偏離品牌的片段，原始區塊會未經遮罩通過。要嘛在遮罩回應時請求非串流， 要嘛對絕不能離開閘道的內容使用一條 block 規則（在串流與非串流上都 強制執行）。同樣的注意事項適用於 PII Shield 預設集，其即時遮罩 今天是輸入介面的。
一個被封鎖的回應不消耗配額——輸出介面封鎖會在回應被拒絕之後退還 預先消耗的配額——並被標記為 skip-retry，因為重跑同一個提示詞只會 再次被封鎖。

​
6. 建議的政策形狀

在一個防護欄中疊三條規則

  1. keyword / regex 於 output——對已知禁用詞與結構性模式的 零延遲捕捉。
  2. llm_judge 於 output——對字面清單漏掉的東西做語意毒性／ 偏離品牌／偏離政策捕捉。
  3. 先透過 flag 上線，觀察 Matches 動態，等到 誤報率可接受後再晉升到 block。參見 強制執行模式。
若要同時審查請求——一開始就製造不安全輸出的越獄與注入嘗試——請在 這條防護欄旁邊執行一條輸入介面防護欄。參見 越獄與 提示注入。

防護欄參考

規則型別、動作、介面、LLM 判官、預設集、評估工具，以及 Matches 動態的 完整參考。

資料外洩

阻止敏感資料在模型回應或一次工具呼叫中離開。