寫到第三十天，這個系列也要告一段落了；雖然因為某些緣故導致比賽中斷了，但還是想要把整個系列寫清楚，也讓自己這些年累積的經驗沉澱下來。
前面從企業為什麼需要 AI Guardrails 開始，一路談到合成測試資料、評估方法、不同情境的防護，以及最後的元件選型與部署。回頭看，這些題目都在回答同一個問題：當企業把 AI 放進實際流程，要怎麼把風險要求，變成能執行、能驗證，也能持續調整的防護？
最後這一篇，就帶大家沿著這條路再走一次。把各篇接起來看，會比較清楚為什麼要花時間準備資料、檢查評估器，以及這些工作如何影響最後的架構選擇。
系列一開始，把 Guardrails 放回治理、風險與合規（GRC）的脈絡。企業想避免個資外洩、錯誤承諾或越權操作，但這些要求還需要翻譯成工程可以實作、業務可以確認的行為。
以客服地址為例，同一份資料送往未核准的外部模型，要阻擋；只需要整理通話重點，可以先遮罩；送往已授權的內部訂單服務，則可能允許。判斷需要任務、資料、目的端與權限，單靠「有沒有個資」還不夠。
因此，前五天反覆拆開偵測器（Detector）、政策（Policy）與處置（Action）的責任：先找出什麼，再依條件決定怎麼辦，最後讓流程真的照做。控制放在輸入、檢索、輸出或工具執行前，也要確認它來得及阻止資料送出或動作發生。
到了 Day 5，這些要求被寫成可以重跑的驗收案例。預期阻擋，就看下游是否真的沒有被呼叫；預期遮罩，就看接收端拿到的內容。連正常用途被誤擋，也要算進結果。
走到這裡，我們有了比較方案的依據：換模型、換護欄之後，可以拿同一組業務要求重新驗證。
驗收條件寫出來後，接著要準備足夠多樣的資料。真實客戶資料的使用受到限制，少量手寫案例又容易漏掉長文本、特殊格式與政策邊界，於是進入合成資料（Synthetic Data）。
這六天拆解的種子資料（Seed）、階段任務（Stage）、相依關係（Dependency）與品質控制（Quality Control），各自處理一個實際問題。
Seed 先固定任務、預期處置與不能捏造的條件，再安排哪些語句、長度與個資位置可以變動。Stage 把原文、遮罩版本與標註分開產生，Dependency 則要求它們指向同一版原文，避免每份資料都合理，放在一起卻對不起來。
品質控制接著決定哪些能收錄、哪些退回、哪些留待審查，並留下原因。這些紀錄讓我們知道該修哪一步，以及修改後哪些下游結果需要重做。
這一段想帶出的，是對資料品質的責任。合成管線產生的每筆資料，都應該能回答「它在測哪個要求」。數量增加之後，仍要保留正常、風險與容易誤判的案例，也要知道生成方式沒有涵蓋哪些情況。
資料進入待審區之後，誰來決定它能不能用？
規則（Rule）適合核對明確條件，例如必要欄位、已知電話是否殘留。同一份原文有多個候選版本時，獎勵模型（Reward Model）可以協助排序。至於遮罩後有沒有保留配送查詢任務，就需要模型評審（LLM-as-a-Judge）對照原文與評分準則，判斷語意。
人工審查再接手需要人決定的部分，例如準則不清楚、有效判定互相矛盾，或政策要求人工核准的高風險案件。只有一份候選資料時，可以略過排序；規則已指出必要條件失敗，也不用繼續花錢評分。流程依任務安排。
這裡容易忽略的是，評估器本身也會出問題。排名靠前只能支持相對偏好；Judge 若拿錯準則，理由寫得再完整，仍可能回答了另一個問題。遇到異常結果，得回頭核對原文、候選內容、準則與判斷理由。
Day 17 把這些分工接回同一筆客服資料，也留下後續處理方式。資料有錯就修資料，服務逾時就查服務，政策不清楚則交給政策負責人。這樣才能知道每個結果代表什麼，以及誰應該接手。
有了前面的資料需求與評估分工，接下來要把案例放進待測流程：系統到底有沒有照預期處理？
Day 18 的客服模擬留下了一個很具體的例子。兩個版本都判定要遮罩，也都呼叫接收端一次，但舊版仍把原文送出去。改成傳送遮罩後的文字，這筆案例才通過。只看判斷標籤與呼叫次數，找不到這個接線錯誤。
後面幾天把問題擴展到不同情境。長文本要注意切分與個資位置，不能只憑某一段檢查通過就放行全文；有害內容與離題防護，則需要配合客服的任務與語境，思考哪些內容要處理、哪些正常需求應保留。
到了檢索增強生成（RAG），還要分清文件是否適用、回答是否有來源支持，以及缺少資料時能回答到哪裡。文件裡夾帶的指令，也不能因為被檢索回來，就取得修改服務規則的權限。
Agent 更往前走了一步：它會改變業務狀態。顧客請它查詢能否退貨，還沒有授權建立退貨申請。這時要核對的是身分、批准範圍、工具參數與目前狀態，並在執行前由可信的系統確認。
這幾篇讓控制對象逐漸展開：輸入文字、檢索資料、交付答案，以及真正執行的動作。驗收也跟著改變，需要觀察實際收件內容、使用者看到的回答，或業務系統最後發生的變更。
走到最後一段，才比較有條件討論哪種技術適合自己的問題。
正規表示式、命名實體辨識（NER）、分類器、防護模型（Guardian LLM）與 Judge，需要的輸入、能提供的判斷，以及成本都不同。要定位個資來遮罩，就需要位置資訊；只回報整段有風險，還不足以完成這項工作。
串流防護則把焦點放在內容何時交付。先送出再檢查、累積一段檢查後再送出，會留下不同的風險與等待時間。看多大的文字範圍，以及什麼時候允許使用者看到，是需要分別決定的事。
選好元件之後，Day 28 接著處理序列、平行與條件分流。相互依賴的檢查要依序做，獨立檢查可以同時執行；每條路徑都要有放行條件，也要決定必要檢查沒有結果時怎麼辦。
Day 29 再把它們放到應用內、輔助容器、中央服務或模型閘道來看。部署會影響資料流向、等待時間、更新方式與維護責任；供應商內建防護則可以搭配這些位置使用。規則集中管理，也不代表每筆資料都必須送往中央處理。
選型與部署放在這裡，是因為前面已經說清楚要保護什麼、如何判斷與驗收。現在才能進一步決定哪些能力值得共用，以及業務、工程與平台團隊各自負責哪一段。
這三十天完成的，是把風險要求、測試資料、評估、防護處置與架構選擇接成一條可以往下實作的路。下次拿到企業 AI 需求時，希望你已經知道該先釐清哪些條件，也能在結果不如預期時，找到需要調整的地方。
接下來，建議讀者可以從自己的場景挑一個具體需求、一筆資料或一次工具操作。先寫清楚預期行為，再觀察系統實際做了什麼；把差異留下來，修正後用同一個案例重跑。前面談過的方法，就能從這裡開始用起來。
三十篇寫到這裡，這次鐵人賽系列正式完賽。謝謝一路讀到這裡的你。
iThome鐵人賽
看影片追技術