筆者在過去文章中提到的眾多 Guardrails案例、看起來只是多加一項檢查，實際在開發和部署時時卻得先問：
而上述眾多的只要其中一個檢查器還在用舊規則，要攔截或要被擋掉的內容可能就會衝破缺口造成影響。所以 Guardrails 放在哪裡，會影響規則怎麼更新，也會影響出問題時誰能（謎之音：誰該負責）處理。 因此，接近尾聲的這篇文章會比較把檢查放在 App（應用端）、Sidecar（輔助容器 / 邊車容器）、中央服務（共用服務）、LLM Gateway＋BYOG，以及使用供應商內建防護的差別。
[Day 28]：Guardrails 不會只有一個：多層防護到底應該怎麼組？ 討論怎麼安排多項檢查：哪些先做、哪些能同時做，以及失敗後怎麼處理。這篇接著看，把這些檢查放在應用程式裡、旁邊的容器，或共用服務後，資料會送到哪裡，又由誰維護。
下面用這個假設案例說明各種做法的取捨，架構圖也是示意，沒有實際部署測試或比較效能。圖中先畫出「必要檢查通過後才繼續」的路徑。什麼情況要阻擋、等不到結果要怎麼辦、能重試幾次，以及串流回覆何時能送給使用者，仍要依規則另外決定。
以移除姓名的規則來說，企業可以由同一組人決定適用範圍、核准版本，再發給各個應用程式使用。每份摘要不必都送到中央服務：應用程式也可以在本地載入核准的規則，先完成檢查，再把摘要回傳給使用者。
這裡有兩份工作。管理平面（Control Plane）處理規則怎麼訂、由誰審核、使用哪個版本，以及怎麼發布。執行平面（Data Plane）則處理每次送進來的資料：執行檢查，再把結果交給負責阻擋或修改內容的元件。這兩份工作可以由同一套服務負責，也可以分開。
Open Policy Agent（OPA）的部署文件就比較了兩種做法：在應用程式附近判斷是否符合政策，或交給中央服務判斷。政策套件（Bundle）機制則讓各處的 OPA 從遠端載入政策與資料，不必每次更新都重新部署程式。這是「規則集中管理、各處自行執行」的參考。
把檢查做成共用 API，則是讓大家呼叫同一個地方。至於誰能修改要移除的姓名、誰能核准例外，以及新版誤擋時怎麼退回舊版，仍要另外安排。
所以，這些工作不必全放在一起。大型偵測模型可以集中執行，讓多個應用共用；各應用則先整理資料、選擇適用的規則，再依檢查結果決定是否繼續。下面就來看這些檢查可以放在哪裡。
App、Sidecar、中央服務與 Gateway，描述的是檢查放在哪裡、應用程式怎麼呼叫它。供應商原生防護（Provider-native）指的則是供應商內建的檢查功能。應用程式可以直接呼叫，也可以透過中央服務或 Gateway 使用，後面會另外說明。
把檢查模組放進摘要應用程式，就能讓兩者在同一個行程（process）內執行。應用程式準備回傳摘要時，可以取得目前的任務、使用者身分與業務資料，再依檢查結果修改摘要，或停止回傳。下圖也保留送往模型前的輸入檢查，方便看完整的來回流程。
這種做法方便應用程式在需要的步驟插入檢查，也能直接提供檢查所需的資料。以移除姓名為例，程式拿到模型回覆後先檢查，確認最後要送出的摘要符合規則，再回傳給使用者。
應用團隊也得一起維護檢查模組：它需要哪些套件、使用哪個版本、占用多少資源，以及出錯時怎麼處理。如果其他應用也用到同一條規則，就要逐一確認套件是否已更新、是否能載入新規則，不能只改好其中一個服務。
應用程式可以取得系統中可信的任務與核准紀錄，這對判斷操作權限很重要。例如 Agent 要修改訂單，執行工具前就得確認這筆操作是否已核准。使用者在文字裡說「主管已同意」，不能代替核准紀錄；回覆通過內容檢查，也不等於取得修改訂單的權限。
還要看 SDK 實際呼叫了哪個服務。模組裝在 App 裡，資料仍可能被送到外面。 如果 SDK 呼叫遠端偵測模型，待檢查的資料就會離開應用程式。OPA 的整合文件也分別說明了在同一行程內用 SDK／嵌入式方式判斷政策，以及透過 HTTP 請另一個服務判斷的做法。
如果希望平台團隊統一維護檢查器，又想把它放在應用附近，可以讓檢查器在同一個 Pod 裡的另一個容器執行，這就是這裡說的 Sidecar。應用程式和檢查器能各自使用需要的執行環境；應用透過本地介面送出資料，拿到檢查結果後，決定下一步。
下圖由應用程式主動呼叫 Sidecar。如果改用代理方式攔截請求，就得另外設定流量要怎麼經過它；放在同一個 Pod 裡，不會自動讓所有請求都被檢查。
摘要服務可以把姓名檢查交給旁邊的容器，不必把檢查器需要的套件全裝進應用程式。平台團隊更新容器或規則後，要確認各 Pod 已載入哪個版本。應用程式則要處理檢查器還沒準備好、正在重啟，或沒有回應的情況。
Kubernetes 的 Sidecar 文件說明，Sidecar 與主容器位於同一個 Pod，但可以各自管理啟動、停止與重啟，並用探針檢查狀態。檢查器能單獨重啟，資源卻仍要在每個 Pod 裡配置。如果每個副本都帶一份大型模型，就得為每一份模型準備資源。這和多個應用共用一個推論服務、單獨調整該服務的規模，仍是兩種做法。
如果 Sidecar 只是把文字轉送到遠端模型，資料仍會離開本地；遠端模型沒回應，這裡也拿不到檢查結果。放在應用旁邊的是 Sidecar，實際檢查仍要靠遠端模型。
如果多個應用都要移除電話與指定姓名，或希望共用偵測模型的運算資源，可以讓它們呼叫同一組護欄 API。下圖由中央服務負責檢查；應用程式自己呼叫模型，再根據檢查結果決定要阻擋、修改內容，還是繼續。
應用程式送出的可能不只有文字，還包括正在做什麼任務、資料要送到哪裡、屬於哪個租戶，以及要用哪個政策版本。中央服務先確認呼叫者的身分，取得判斷需要的資料，再回傳檢查結果或處理後的文字。應用收到後，才決定要不要繼續呼叫模型，或把回覆送給使用者。
這樣可以共用檢查模型與運算資源，但原文也多了一個被處理、可能被記錄的地方。平台團隊要準備足夠的資源、管理誰能呼叫，並確保不同租戶的資料彼此隔離；服務會留下哪些紀錄，也要先決定。應用得等檢查結果回來，才能繼續處理，還要安排等不到結果時的做法。如果判斷需要核准紀錄，就要確認紀錄從哪裡取得、如何傳送與驗證，不能直接相信使用者寫的內容。
中央服務也可以放在企業內網。規定原文不能離開內網，仍可能允許使用內網的共用檢查服務。 只是要接著確認：它呼叫的模型在哪裡？紀錄又送到哪裡？OPA 的部署文件也比較了中央服務與靠近應用的做法。選擇時，要連同後面會呼叫的服務一起看。
這裡的中央服務只幫忙檢查。如果應用連模型請求都交給它轉送，就開始接近下一節的 Gateway。
如果應用程式已經透過同一個模型閘道（LLM Gateway）呼叫模型，就可以在這裡加入共用的檢查。自帶護欄（Bring Your Own Guardrails，BYOG）是讓企業把自己選的檢查器接到 LLM Gateway。檢查器可以直接在 Gateway 的行程內執行、也可以是另外呼叫的服務。
以摘要服務為例，LLM Gateway 可以在模型回覆後檢查姓名，把符合規則的內容交還應用。前提是需要檢查的請求都會經過 LLM Gateway，而且應用不能自行關掉必要檢查。如果應用還能直接呼叫模型，那條路徑也得安排檢查。
如果供應商已經有需要的檢查功能，可以評估直接使用，省下自行維護底層服務的工作。前面的幾種架構都可以搭配這類服務，但能檢查哪些風險、怎麼判定，以及能用哪些介面，仍取決於供應商支援什麼。
以摘要服務來說，先確認供應商的設定能不能表達「移除指定員工姓名」這條規則，再決定由哪個元件呼叫它。產品標示有個資檢查，不等於能完成這項要求，還是要拿企業自己的案例測試。
至少有兩種用法。第一種是呼叫模型時，一起啟用護欄。下圖以會等待檢查完成、通過後才繼續的整合方式為例。
應用程式呼叫模型時，同時指定護欄設定與版本。供應商執行支援的檢查，再回傳模型回覆、阻擋結果或相關資訊。例如 Bedrock 的 Converse API 可以用 guardrailConfig 指定護欄 ID 與版本。實際會檢查哪些輸入與輸出，要依Converse 護欄文件確認。
第二種是獨立呼叫護欄 API：
應用送出待檢查文字 → 供應商回傳檢查結果或處理後的文字 → 應用依結果決定是否呼叫模型，或把回覆送給使用者。
Bedrock 的 ApplyGuardrail可以單獨檢查輸入或輸出文字，不必同時呼叫 Bedrock 的基礎模型。中央服務或 Gateway 因此也能呼叫它來完成檢查。呼叫時需要指定 guardrailIdentifier 與 guardrailVersion；企業仍要管理設定與版本，並決定如何處理回傳結果，以及檢查失敗時怎麼辦。
兩種用法都會把文字送到供應商，所以要先確認對方如何使用這些資料，以及企業是否允許這樣使用。如果規定原文不能送給這家供應商，就必須在送出前完成必要檢查與處理。即使護欄能搭配其他模型使用，也不能拿來補救已經送出去的原文。
把前面的做法放在一起看，就能比較檢查由誰執行、更新與維護又由誰負責。表格前四列說明怎麼部署，最後一列則是可以搭配使用的供應商功能。
| 部署方式／供應商功能 | 怎麼使用與調整 | 誰負責更新與維護 | 要注意什麼 |
|---|---|---|---|
| 應用內（App） | 用程式或 SDK 在業務流程中加入檢查，可取得目前的任務狀態，也能在工具執行前檢查。 | 應用團隊負責串接、所需套件，以及依結果阻擋或修改內容；共用規則可由平台發布。 | 各應用可能用不同版本；檢查會占用應用程式的資源。SDK 也可能把資料送到外部服務。 |
| 伴隨容器（Sidecar） | 檢查器與應用放在同一個 Pod 的不同容器。由應用主動呼叫，或設定代理，讓流量經過檢查器。 | 平台團隊維護容器與更新方式；應用團隊確認怎麼呼叫、何時可用，以及失敗時怎麼辦。 | 每個應用副本都要準備檢查器的資源。放在同一個 Pod 不會自動檢查流量，也可能一起受 Pod 故障影響。 |
| 中央服務（Central Service） | 應用把文字與必要的任務資料送到共用 API，由中央維護偵測模型，也可提供客製化介面。 | 平台團隊準備運算資源、管理權限並維持服務運作；應用等待結果，再決定如何處理。 | 多一次服務呼叫；原文可能在共用服務被處理或記錄，要管理租戶隔離與紀錄存取。服務故障可能影響多個應用。 |
| 模型閘道＋自帶護欄（Gateway＋BYOG） | 在經過 Gateway 的模型請求與回覆中，加入企業自選的檢查器。 | 平台團隊維護 Gateway、轉接器與共用規則；應用提供可信的任務資料。 | 能做哪些客製化，要看擴充介面支援什麼。未經 Gateway 的檢索、模型直連或工具操作，仍要另外檢查。 |
| 供應商原生防護（Provider-native） | 使用供應商支援的規則設定，隨模型呼叫啟用護欄，或單獨呼叫檢查 API。 | 供應商維護底層服務；企業管理設定、選擇版本，並決定應用如何處理結果。 | 功能、風險判定與介面由供應商提供。更換時，要重新確認設定怎麼換、每種結果代表什麼。 |
回到摘要服務，如果之後把姓名檢查從 App 搬到共用服務，就要確認：該移除的內容還是會被移除，原本允許保留的內容也沒有被誤擋。換了位置或工具，都要照新的呼叫流程重新測試，確認符合原有要求。
這也接回 Day 4 提過的可攜性護欄（Portable Guardrails）的慨念：企業自己保留規則的意思、適用範圍、核准版本與驗收案例，再透過轉接器換成各工具需要的風險類別、門檻和處理設定。BYOG 讓企業可以接上自選的護欄，但換過去後是否有相同結果，仍要測試。應用可能依賴自家中央服務的 API，各家 Gateway 要求的串接格式也可能不同。就算都回傳 Safe 或「阻擋」，也要確認它們各自檢查了什麼、這個結果代表什麼或至少包括：
以上林林總總也要對得起來；這樣搬移後有差異，才查得出是偵測結果不同、規則解讀不同，還是應用改了處理方式。
iThome鐵人賽
看影片追技術