Day 27 談的是如何選擇 Guardrails 元件。選好之後，企業還要面對另一個問題：當業務規則改變，這些元件能不能跟著調整，並且知道調整後的防護是否仍然有效？
一份回覆可能沒有有害內容，卻仍夾著個資；個資遮住了，又可能省略必要的核准條件。不同檢查各有工作，接起來後還要決定順序、分流與失敗處置。這篇想談的，就是讓業務需求能持續反映到執行流程的編排（Orchestration）。
相同資料，放在不同任務裡，處置可能不同。姓名與地址出現在核准的內部表單，和準備送到外部模型，是兩種情境。只問「有沒有個資」，還不足以決定在哪裡攔、要遮罩還是拒絕。
這些條件需要業務提供任務、用途與例外，工程再確認控制能在哪個環節執行；安全與法遵也要參與必要邊界的決定。IT 或資料科學團隊可以實作偵測，但不宜單獨替業務猜出全部規則。
業務希望快速調整，維運又需要穩定。編排應讓適用情境、門檻與處置可以依版本變更，再經案例驗證與審查後生效。禁止個資外送等必要要求，則不能因為新任務急著上線就被略過。
「不得揭露個資」或「不得越權承諾」都是合理要求，但還需要說清楚哪些資料、送給誰，以及違反時要做什麼。
假設報支助手要摘要公司規定，業務可以提供一組案例：原文要求核准後才能報支，回覆卻寫成可以直接報支，預期應退回修改；若只是換句話說、核准條件仍在，就不應誤擋。這是設計示例，沒有執行測試。
工具若只提供程式介面與設定檔，這類調整仍需要工程人員接手。企業要讓業務參與，就需要讓他們能提供案例、確認預期處置，並看懂修改前後哪些案例通過、哪些被擋、為什麼。
業務參與測試與規則維護，也需要對應的編輯、審查與發布權限。能快速試驗，和能直接改動線上政策，是不同的權責。
單一元件回傳結果之後，多層防護還要安排它與其他檢查的關係：
這些能力已有工具支援。例如 NeMo Guardrails 提供平行執行，也提醒修改輸入時可能發生競態，需要改用序列模式。官方設定文件
企業仍要補齊的是每條路徑的放行規則。內容安全通過，不能抵銷來源比對發現的必要條件缺漏；若回覆經過改寫，受影響的檢查也要對新版本重跑。最後應能查到走了哪條路徑、略過哪些檢查，以及交付版本依據哪些結果放行。
不同任務需要的防護不同。查詢固定規定、整理自由文字，以及執行業務動作，所需的上下文、授權與檢查成本都可能不同。每筆請求都走最重的流程，可能增加等待；只為降低延遲而省掉必要檢查，又會留下缺口。
編排可以保留共同的必要檢查，再依任務增加來源比對、業務語意或授權條件。若使用分類器分流，也要驗證高風險內容會不會被送到較少檢查的路徑；分類不確定，不能默認為低風險。
服務水準要求（SLA）也要落到具體行為：最多等多久、允許重試幾次、逾時後暫停、轉人工，還是提供固定回覆。尚未取得必要判斷時，不能把「沒有結果」當成通過。旁路觀察可以有不同失敗策略，但需要清楚標示其用途。
這也連到自帶模型與自帶護欄（BYOM／BYOG）。LiteLLM 已提供以 API 接入自有護欄的方式；能接入之後，仍要確認不同元件的輸入、結果與處置能否沿用企業的政策。Generic Guardrail API 文件
雲端護欄也不能一概寫成只支援自家模型。例如 Bedrock 的 ApplyGuardrail 可不呼叫基礎模型，獨立評估文字。更換模型或護欄時，企業要保留的是原本的必要條件、測試案例與判斷紀錄，再確認新組合是否符合要求。ApplyGuardrail 官方文件
iThome鐵人賽
看影片追技術