Day 2 把 Guardrails 可以介入的位置展開了：從使用者輸入、檢索資料，到工具執行前後，都可能需要控制。但架構圖、流程圖畫完，工程師還有一個問題沒得到答案：每個檢查點，究竟要依什麼條件放行？

「不要洩漏個資」聽起來很明確。直到客服需要替客戶修改地址，團隊才發現，地址本身就是個資。全部擋掉，服務做不下去；全部放行，又違反原本的要求。

問題卡在政策還沒寫成工程可用實現規格；今天沿用客服案例試著把一句要求，拆成可以實作、也能驗收的控制項。

把要求寫清楚，別讓工程師、也別讓 LLM 自己猜

假設公司的規定是：「客服使用 AI 時，不能把客戶個資送到未核准的外部服務」。

這句話方向沒錯，但對工程師來說還不夠；因為系統真正需要知道的是：

1. 現在在做什麼事情
2. 資料裡有哪些內容
3. 準備送去哪裡以及那個地方能不能收這些資料

例如：客戶想修改收件地址。

一種比較安全的做法是讓地址直接填在受控表單裡，再交給內部訂單系統處理。外部 LLM 只需要知道「客戶想修改地址」，幫忙理解需求或產生回覆，不一定需要看到完整地址。

參考：像是在 Chatbot 裡新增 Human In The Loop ＋ Pop Up Windows

而比較明確的描述會是：

送出模型請求以前，先檢查這次準備送出去的內容，
有沒有超出目的端被允許接收的資料範圍。

而且不能只看使用者最新輸入的那一句話。

因為個資可能不止藏當前的使用者輸入中、有可能在前幾輪對話、RAG 找回來的文件，甚至工具剛剛回傳的結果裡。只要最後會一起送進模型，就都應該納入檢查。（題外話：早期的 Prompt Injection 就有用過這類的手法來繞過 Guardrails / LLM 內部的 Limitation；甚型到近期也還有案例）

延伸閱讀：Why do multi-turn prompt injections create more risk for agentic AI systems?

但同一份文字，換個用途答案就可能不同

實務上 Detector 會有不同技術方法，像是：

• 文字式偵測（Keyword Matching）：以關鍵字比對或字串搜尋檢查內容，例如敏感詞、黑名單詞彙或特定用語；它的優點是速度快、結果容易解釋，但無法理解同義詞、隱喻或前後文。

Tips: 大量詞彙時，也可以使用 Trie 或 Aho–Corasick 演算法提升搜尋效率

• 規則式偵測（Rule-based／Regular Expression）：透過業務規則與正規表示式（Regular Expression，Regex）辨識固定格式，例如電子郵件、電話號碼、身分證字號、信用卡號或 API Token。規則清楚、結果容易重現，但需要持續維護，也可能漏掉格式變形的內容。

Tips：事實上臺灣政府的資料標準平台已經整理了許多關於台灣在地的 PII 或相關內容，在設計Guardrails 解決方案或應用時可以先參考。

• NER 模型偵測（Named Entity Recognition）：使用命名實體辨識模型，從句子中找出人名、組織、地點等資訊，常見作法是採用 BERT（Bidirectional Encoder Representations from Transformers）或其他 Transformer 架構的 NER 模型。它能利用上下文辨識非固定格式的實體，但準確度仍會受到語言、領域資料與模型訓練品質影響。

Tips：Twinkle Al 社群開源了針對臺灣 PII 偵測的模型「privacy-filter-tw」可以去申請看看。

• LLM 模型偵測（Large Language Model-based Detection）：使用 GPT、Llama 等大型語言模型，根據 Prompt、分類標準與結構化輸出判斷內容是否符合特定風險或政策條件。它適合處理複雜語意，但必須同步管理模型與 Prompt 版本、輸出格式、信心門檻，以及推論成本與延遲。

Tips：LLM 確實可以處理部分需要語意判斷的 PII 情境，但它的成本或延遲性可能也是最高的；讀者再評估一下是不是 LLM is All You Need；還是因地制宜選對工具、做合理且合適的事情。

以判斷使用者內容是否有地址的案例而言、Detector 雖然可以回報疑似地址文字及其在內容中位置，但在系統層面上它未必知道誰有權使用、要交給哪個服務，以及目前任務是否真的需要。

因此，測試案例不能只有一段文字和 has_pii: true。至少要把影響政策判斷的情境帶進來（其實就是要考量任務的語境啦）。

這樣的情境列得越詳細、越具體，我們就能設計出更好的 Detector 以及測試案例，用於後續驗證及測試；但只有案例是不夠的，還是要考量到底在偵測到問題之後，還有什麼比較彈性的方法，讓內容可以被管理以及被標註分類來執行後續的動作。

接下來我們會參考不同產品的處理方法有哪些、比較對象涵蓋開源、閉源產品以及工具。

偵測到問題只是第一步、重點是後續處置要怎麼實現

筆者有一個很深刻的印象，是早期在做臨床醫療情境中併發症發生的分類預測;那時候的訓練、驗證和測試結果的準確度或召回率都很高。
但筆者當以為萬無一失的時候，在臨床訪談裡，我們卻受到一個像是潑了冷水的反饋。
當模型告訴我這個人會不會發生已經很準，現場的第一線醫療工作者更在意的是：「發生了，那要我去做什麼？」或者是「可以做什麼來介入，避免它發生」。
而在 GRC Engineering / AI Guardrails 的任務情境也是一樣，偵測到了、能判斷到，只是第一步；後續永遠都是要讓當前再生效的時候，告訴後續流程我應該怎麼做，才是實際上要考量的。

以下我們用三步驟的心法來進行思考以及評估：

1. Detector 是否真的發現目標？
2. Policy 是否依照情境做出正確決定？
3. 後續是否真的遵守這個決定作出對應動作？

當然，這些問題早就被不同的開源、閉源供應商思考過了；筆者見賢思齊，為大家整理了以下不同工具產品的處理方式。

不同 Guardrails 產品 / 工具的偵測後處理方式

這邊為讀者們整理比較常用或通用的動作清單，實務上應該會涵蓋大部分的使用情境：

• ALLOW：允許繼續處理，接續處理後續流程
• BLOCK：拒絕請求或回應罐頭訊息或生成拒絕內容
• MASK：使用遮罩處理敏感內容：像 [陳大文] 會變成 【###】
• REPLACE：以標記、假名或替代值取代原；像 【陳大文】會變成 【陳先生】
• WARN + LOG：允許通過，但留下警告與稽核紀錄
• RETRY：要求模型重新產生符合政策的結果
• HUMAN_REVIEW：轉交人工判斷
• DENY_TOOL_CALL：拒絕執行工具呼叫，或阻止敏感參數送往外部系統

實務上需要特別保留的邊界

如果政策禁止客戶資訊離開內網，偵測服務本身就必須納入同一份資料流與信任邊界；不能先把原文送到外部偵測服務，再請它判斷這段資料能不能外傳（迷之音：雲端服務還是有其能力邊界的）

註一：筆者私心認為地端或雲端都應該要有 Guardrails 的服務，這樣才可以在善用「Cloud / Local」算力時更安心，也是有效的手段

註二：只有對要處理的內容情境、例外及限制有清楚了解，才可以打造以及組合出對應的 AI Guardrails 工具，才能更好地服務使用者與客戶

延伸閱讀

• Microsoft Presidio
• Guardrails.AI: 幾年前開源我覺得是最好的產品之一，但現在他們公司轉型往資料合成的方向去了。筆者也曾為他們撰寫過文章。
• NVIDIA Nemo Guardrails
• Microsoft Azure AI Content Safety
• Amazon Bedrock Guardrails