筆者在 Day 3 的文章中把「不要洩漏個資」這句要求，拆成三件事：
如果今天只有一個客服系統、一個模型和一條規則，工程師把它們接起來變成一個 Guardrails通常不算太難、也不複雜。
企業真正會遇到的挑戰、往往是從第二個、第三個應用上線後才開始，我們舉個例子：
這些應用面對的使用者、資料與風險都不同，而企業的現有工具真的準備好了嗎？是用 LLM As A Judge 模型或某個開源防護工具就夠了嗎？是有在 Prompt 打入「你不準輸出以下任務的內容」就能抵擋駭客和現實中各種的惡意嗎？
最要命的是：每當企業因應外部法遵要求、像是國科會訂定、連同數發部一同起草的《人工智慧基本法》、金管會的《金融業運用人工智慧(AI)指引》、甚至公司生意很廣，連歐洲《歐盟人工智慧法案 (EU AI Act)》、美國的《AI 風險管理框架 (NIST AI RMF)》等指引都是企業要參考和對齊(Alignment)的規範——外部是日新月異的技術及監管法規、而內部則要面對《負責任 AI 準則（Responsible AI）》或相關法遵稽核的需求。
當這些政策規則改變，團隊也不能只問「有沒有檢查到」或是「我有加 Guardrails 在 Prompt」就完成了，還要知道誰決定這條規則、哪些應用受到影響、發生例外時怎麼處理，以及更換工具後原本的要求是否仍然成立，這也正正是本系列文章的出發點：治理、風險與合規（Governance, Risk, and Compliance）工程要實現的一大原因。
筆者在實作與企業討論中反覆遇到的，是以下四個管理問題：
做出一個會攔截內容的功能不難；難的是讓業務、風險、資訊與應用團隊，對同一條規則有相同理解，並且能長期一起維護。
接下來不會深入介紹特定工具，而是從企業落地的角度，談這四個問題為什麼經常讓專案/讓團隊卡住。
同一筆資料放在不同業務情境裡，處理方式可能完全不同。
以地址或其他 PII 資訊為例，客戶直接把完整地址貼進聊天視窗，如果這段內容即將送往未核准接收個資的外部 LLM 服務，系統就應該阻止資料送出，並引導客戶改用受控表單。但如果地址是由受控表單取得，使用者身分與訂單權限也已確認，那麼同一筆資料便可能被允許送進內部訂單系統。
資料沒有變，差別在於誰正在操作、要完成什麼任務、資料準備送去哪裡，以及接收方是否有權取得。
這也是企業導入 Guardrails 時很容易誤判的地方。Guardrails 或相關的檢查工具可以告訴我們「這段文字裡可能有 PII 」，卻不知道這位使用者能不能修改訂單、也不知道目前的服務是否真的需要這筆資料。甚至最後要不要放行，仍然需要業務情境與公司規則一起判斷。
筆者到企業訪談裡如果只聽到一句「不要洩漏個資」的需求時、通常不會先談要用哪一個 LLM 模型來處理，而是先問：
這些問題應該先整理成一份所有參與者都看得懂的業務情境說明，再交給技術團隊實作。否則，業務以為自己講清楚了，工程師也以為系統已經符合要求，直到例外真的發生，雙方才發現理解並不一致。
Guardrail 的檢查結果只是在提醒系統「這裡可能有問題」。它不能代替企業決定誰可以做什麼，也不能代替真正的業務流程執行後續處置。
企業政策規則不會訂定一次就永遠不變，就像古希臘哲學家說過「世上唯一不變的事，就是改變」。（迷之音：赫拉克利特 4 你！？）
新產品應用上線、內外部法規調整、服務流程改版，甚至只是客服活動期間多了一項例外，都可能影響原本的 Guardrails 的防護方式。問題在於，最理解這些變化的人通常在業務、法遵或風險單位；但在企業真正能修改系統設定的人，卻多半在資訊或開發團隊。
如果請業務人員直接修改程式或複雜設定，並不實際。反過來請工程師根據會議紀錄自行猜測規則，也很危險。工程師可以把要求做進系統，但不應替業務決定哪些例外可以接受、發生錯誤時公司願意承擔什麼後果。
有些團隊會想：「那能不能刻一個簡單的操作畫面，讓業務自己改規則？」
這個方向不是不行，但能夠按下修改按鈕，不代表規則已經可以安全上線；站在企業治理的角度，應該要在意的是：
因此企業應建立一條每個相關利害關係人（Stakeholder）都能參與、且責任仍然清楚的變更流程，像是：
這樣做看起來比直接改設定多了幾個步驟，卻能避免最常見的落差：規則已經在會議上改了，系統卻還在執行舊版本；或是系統雖然更新了，相關應用卻沒有人知道自己受到影響。
企業實際使用 Guardrails 工具時，通常會同時檢查個資（PII）、不當內容（Content Security）、使用權限、資料來源，以及 AI 是否準備執行高風險操作。每一項檢查單獨看都合理，放在同一個流程裡卻可能互相衝突。
例如，個資檢查認為把地址遮住就可以繼續；權限檢查卻發現這位客服根本不能查看該筆訂單；另一項內容檢查則認為回覆本身沒有問題。這時候，系統最後應該採用哪一個結果？如果其中一項檢查沒有回應，是繼續處理，還是暫停服務？
這些問題無法靠「再加一個更強的檢查工具」解決。企業需要先訂出共同的判斷方式：
從顧問角度來看，這裡最容易出現的問題的是每個團隊都只負責自己那一小段：
但最後資料真的被送錯地方 / 不合規，卻沒有人能說清楚是哪一段應該負責阻止。
因此，多種 Guardrails 要先建立共同的決策順序與責任分工，執行先後只是其中一部分。至於各項檢查要依序執行、同時執行，還是依風險決定是否啟動，會留到後面的文章再談。
作為 IT 顧問的從業人員，每次和客戶 Engage 時都會被問的三個問題是：
因為企業通常不希望長期被單一模型或單一供應商綁住（Vendor Lock-In），而市場上因應這樣需求設計出 BYOM （Bring Your Own Model）／BYOG （Bring Your Own Guardrails）的功能，意思是企業可以自行選擇模型與防護工具的供應商。
名詞看起來很技術對嗎？但背後其實是一個很直白的經營問題：
「今天換了供應商，原本答應業務與風險單位的事情還算不算數？」
很多方案會先證明「新的工具接得上」。但接得上只能表示資料送得進去、結果拿得回來。不同工具對風險的分類方式、分數高低與安全標準可能不一樣；同樣寫著「安全」，背後的判斷範圍也未必相同。
因此，如果企業真的希望保有選擇權，更換前後至少要回答四個問題：
筆者認為這裡最容易被低估的是第二與第三題；企業如果沒有保留一組固定的驗收案例（Validation Dataset），就只能憑幾次人工操作判斷新工具「看起來差不多」的 Gut Feeling 來拍板。
等到真的發生誤擋或漏判時，也很難分辨是模型改變、規則改變，還是使用情境本來就沒有定義清楚。（迷之音：就和換了主管理一樣、業績變好或變壞到底是誰的功勞呢）
所以，企業級解決方追求的不能只有「換得動」，還要能證明「換完之後仍然符合原本的要求」。供應商是否容易替換，只是選擇權的起點；規則、案例與判斷依據能不能跟著帶走，才決定這份選擇權是否真的存在。
回頭看這四個痛點，它們分別發生在不同位置：
但它們最後都會回到同一件事：企業能不能把一條抽象的風險要求，變成大家理解一致、系統確實執行、改版後可以比較，也能在事後說明的管理方式。
如果要判斷一套 Guardrails 是否準備好從概念驗證走向企業使用，我會先問四個問題：
單一 Guardrail 的展示只能證明某項功能在某次輸入上有反應或有生效；而企業級 Guardrails 還應該要證明：這個執行結果有反應符合業務規則、後續流程真的照做、所有參與者知道自己的責任，而且改版或更換工具之後，仍然能用相同標準重新檢查。
下一篇，筆者會把這四個問題整理成一張驗收矩陣，把業務情境、預期處置、例外條件與實際結果放在一起。
到了那時候我們才有辦法回答：這套 Guardrails 解決方案是真的可以交付，還是只是展示時看起來會動。
iThome鐵人賽
看影片追技術