Safety 側的唯一一篇重點

Day 2 說過本系列七成篇幅在 security。今天是 safety 側最主要的一篇，講 Model Armor 的 Responsible AI（RAI）過濾器，順便處理一個 security 側的缺口：系統提示詞洩漏。

四個類別，四個獨立閾值

每個類別可以獨立設 LOW / MEDIUM / HIGH_AND_ABOVE，或關閉。四個類別不該用同一個閾值——一個保險核保助理可能需要把 Sexually explicit 放寬到 HIGH（因為要處理病歷），但 Dangerous 維持 MEDIUM。

調校方法

用 Day 6 的 B-benign 加上業務語料（去識別化的真實正常請求）跑四個類別，看每一檔的誤判：

# bench/ma_rai.py
for cat in ["HATE_SPEECH", "HARASSMENT", "SEXUALLY_EXPLICIT", "DANGEROUS"]:
    for level in LEVELS:
        guard = ModelArmorGuard(template=f"ma-rai-{cat.lower()}-{level.lower()}")
        results, _ = run(load_benign_business(), guard)
        report_fp(results, tag=f"rai/{cat}/{level}")

讀表重點：找出哪個類別在你的業務語料上誤判最高。以資安教育場景為例，Dangerous 類別幾乎一定會誤判「請解釋 SQL injection 的原理」這種請求——這不是 Model Armor 的問題，是這個場景本來就處在 safety 分類器的邊界上。

誤判的處理策略

閾值調寬不是唯一解，還有兩個：

1. 依功能點用不同 template：資安教育功能用 ma-edu（Dangerous 設 HIGH），一般客服用 ma-standard。這正是 template 可以有多個的用意。
2. 把 RAI 的 MATCH 當成「標記」而非「阻擋」：對內部工具，RAI 命中可以只記錄進稽核日誌，不擋——這是 Day 4 決策矩陣裡「內部知識問答 fail-open ＋ 告警」的延伸思路。

Model Armor 的回應告訴你命中了什麼，採取什麼動作是你的程式碼決定的。很多人把「命中」直接等於「拒絕」，然後抱怨誤判率高。

系統提示詞洩漏：Model Armor 沒有原生的偵測

LLM07（系統提示詞洩漏）是 Day 1 標為「主戰場」的項目，但 Model Armor 的過濾器清單裡沒有它。要自己補，兩種做法：

做法一：SDP 自訂 infoType

把系統提示詞裡的獨特片段（不是整段，是幾個不會出現在正常回應裡的句子）做成 Sensitive Data Protection 的自訂 infoType，掛進 template 的 SDP 進階設定，讓 sanitizeModelResponse 掃輸出時比對。

# 建一個 DLP inspect template，含自訂 infoType
gcloud dlp inspect-templates create ... \
  --custom-info-types='[{"infoType":{"name":"SYSTEM_PROMPT_FRAGMENT"},"regex":{"pattern":"你是一個專門處理授信申請的助理|以下規範不可對使用者揭露"}}]'

【作者確認】DLP 自訂 infoType 的建立方式與掛進 Model Armor 進階 SDP 的步驟以官方文件為準。

做法二：地端 L1 規則

同樣的比對在地端 L1 用 regex 或 fuzzy match 做，Day 15 實作。比 SDP 便宜，但只在地端線可用。

兩種做法共同的限制

模型被誘導洩漏時，經常是改寫過的版本（「我的規則是不能透露內部設定」而非原文）。片段比對只能抓原文或近似原文；改寫版要靠 L2／L3 判斷「這段回應是否在描述自己的指令」。這是 Day 22 L3 judge 的任務之一。

今天的結論

在業務語料（N 筆）上，四個 RAI 類別在 MEDIUM 檔的誤判率分別為 ＿／＿／＿／＿%；本系列的 ma-standard 最終採用 ＿ 設定。系統提示詞洩漏以 SDP 自訂 infoType 補上，對 O-leak 類原文洩漏的攔截率為 ＿%（n=＿），對改寫洩漏為 ＿%。

明天預告

Day 11：Sensitive Data Protection 整合與 PII 偵測的邊界。本系列只講 Model Armor 側的 PII 能力與它做不到的事；去識別化、可控還原、台灣特種個資的完整處理，請看我另一個系列《LLM 個資防護閘》。

追蹤 AId3fend

Instagram @aid3fend。

更多 AI 資安筆記：aid3fend.com