AI Guardrails 怎麼設計？企業控制層、驗證證據與失效模式指南
企業談 AI guardrails，常先想到 system prompt 的禁止句、關鍵字過濾或模型拒答。但真正的系統還有身分、資料、RAG、輸出解析、工具、外部狀態與人工決定。只要下游程式仍會執行不可信輸出，或 Agent 還握有超出用途的權限，模型說「我不會這樣做」就不是可靠控制。
NIST AI RMF Core 用 Govern、Map、Measure、Manage 四個功能描述風險成果，並明示不是逐項勾選表。NIST 正在更新 AI RMF 1.0；Playbook 也是自願性建議，不是合規認證或保證。企業應把框架轉成符合自身用途、資料、權限與錯誤後果的控制堆疊，而不是宣稱套用某框架就已安全。
第一層：用途、Owner 與政策邊界
先定義 AI 用在哪個工作、誰受影響、哪些資料可用、結果如何進正式流程，以及誰有權停止。高影響、敏感資料、跨租戶與外部動作要走更深審查；例外必須有理由、補償控制、Owner 與到期日。可先到企業 AI 控制措施資料庫挑選治理與資料控制，再用AI 系統清冊保存實際資產與責任。
第二層：資料、身分與工具權限
在資料進模型、索引、trace 與供應商前做最小化，RAG 應在檢索前依呼叫者套用 ACL。每個工作負載使用獨立服務身分與最小 scope；工具採允許清單、嚴格 schema、固定目的地與伺服器端授權。秘密只由受管機制注入，不放進 prompt、程式庫或評測資料。這些控制由確定性程式與權限層執行，不能交給模型自己判斷。
第三層：輸入、輸出與外部動作
外部文件、網頁與郵件都屬不可信資料，不得自行改變系統任務、收件人或工具。模型輸出也要視為不可信：進 HTML、SQL、命令、金額、分類或工具前，重新做型別、範圍、允許值與業務規則驗證。OWASP LLM05 特別提醒不當輸出處理可能把模型內容變成下游漏洞。涉及寄送、寫入、刪除、付款或權限變更時，還要有逐次批准、冪等鍵、狀態機與人工補償。
第四層：評測、發布與停止條件
在測試前定義代表案例、分群、人工基準與重大阻斷，不讓敏感資料洩漏、跨權限或未授權動作被平均分數抵銷。用AI 評測指標資料庫選擇品質、依據、安全、營運與人工指標，再從AI 測試案例庫加入正常、邊界、無答案、權限、重試和人工接管案例。真正的發布閘門要能在 no-go 時阻止放量，而不是只生成一份報告。
第五層：監控、事件與回復
部署後監控不能只看 HTTP 200。要依版本、角色、語言、租戶與高影響情境觀察任務成功、重大錯誤、引用、權限、成本、申訴與人工負荷。每項告警要測到能送達適任角色，並連到停止、證據保全、回復、外部補償及受影響者更正。發現問題可先到AI 事故類型資料庫確認止血與證據，再用AI 系統變更資料庫規劃修復重測。
驗證控制，不只檢查它存在
每項控制至少回答四件事：在哪個技術或流程層實施、用什麼失敗案例測試、留下什麼證據、誰在失效時接手。政策文件、UI 按鈕、prompt 句子和供應商聲明都只能算設計線索；只有拒絕結果、權限差異、逐題測試、告警送達、回切與人工接管演練，才能證明控制在實際條件下有作用。用AI 控制缺口規劃器產生起始清單後，仍應由各 Owner 依系統現況裁剪與驗證。