Amazon Bedrock Guardrails 與內容控制

Amazon Bedrock Guardrails 是一個可設定的安全層，位於你的應用程式與 Amazon Bedrock 上的基礎模型之間，對使用者輸入及模型輸出同時套用五種獨立的政策類型加以過濾。在 AIF-C01 考試中，Task 5.1 幾乎每次都會測試你能否辨識出哪一種 Bedrock Guardrails 政策（Content filters、Denied topics、Word filters、Sensitive information filters，或 Contextual grounding check）能解決題目所描述的安全問題——以及你是否清楚 Bedrock Guardrails 是一個獨立、具有版本管理的政策物件，由 InvokeModel 和 Converse 呼叫透過參數引用，而非模型本身的屬性。

本頁將帶你走遍 AIF-C01 考綱中 Bedrock Guardrails 的每一個功能，深入拆解五大政策分類，比較 Bedrock Guardrails 與 IAM 及提示詞工程的差異，並涵蓋 ApplyGuardrail 獨立 API、跨區域可用性、版本管理、定價，以及與 Amazon Bedrock Knowledge Bases 的整合。學完本頁，你將能閱讀任何 AIF-C01 安全情境題，辨識被保護的對象，並在十秒內選出正確的 Bedrock Guardrails 政策。

什麼是 Amazon Bedrock Guardrails？

Amazon Bedrock Guardrails 是一個受管理的、與模型無關的安全層，對 Amazon Bedrock 上的基礎模型互動套用五種可設定的政策類型。單一 Bedrock Guardrail 是一個獨立的 AWS 資源——它有自己的 ARN、版本，以及一組政策設定——透過在呼叫 InvokeModel、InvokeModelWithResponseStream 或 Converse 時傳入 guardrailIdentifier 和 guardrailVersion 參數來附加到呼叫上。你也可以完全不呼叫任何基礎模型，直接透過 ApplyGuardrail API 單獨調用 Bedrock Guardrails。

由於 Bedrock Guardrails 是獨立的資源，一份 guardrail 定義可以保護許多不同的應用程式，以及許多不同的基礎模型（Claude、Titan、Llama、Mistral、Cohere、Stability AI），並套用完全相同的政策。這種解耦設計是 Bedrock Guardrails 最重要的架構特性，也是考試中多道陷阱題的根源。

為何需要 Bedrock Guardrails

Amazon Bedrock 上的基礎模型出廠時附有提供商端的安全訓練，但提供商端的安全設定對所有客戶一視同仁，無法表達你的組織特定的風險立場。Bedrock Guardrails 讓你在模型內建對齊機制之上，疊加屬於自己的政策。一家銀行需要封鎖投資建議；一家醫療公司需要封鎖診斷聲明；一款兒童產品需要比成人新聞產品更嚴格的暴力過濾。Bedrock Guardrails 就是編碼這些產品特定規則的機制。

Bedrock Guardrails 在 AI 威脅模型中的位置

Bedrock Guardrails 是防禦層之一，而非唯一防禦。AIF-C01 考綱期望你將 Bedrock Guardrails 與 IAM（誰可以調用模型）、VPC 端點（網路路徑）、CloudTrail（稽核）、提示詞工程（提示內指令），以及負責任 AI 實踐（資料治理、人工審查）分層疊加。Bedrock Guardrails 專注於內容安全層——模型被允許說什麼，以及使用者被允許問什麼。

為何 AIF-C01 考試喜歡考 Bedrock Guardrails

領域 5（AI 的安全性、合規與治理）佔 AIF-C01 的 14%，根據社群回報，Bedrock Guardrails 約佔 Task 5.1 情境題的三分之一。由於 Bedrock Guardrails 的架構整齊地對應到五大政策類型，幾乎每一題都可以歸結為「哪個政策能執行此情境中的規則」。這使得 Bedrock Guardrails 成為考試中投報率最高的備考目標之一——主題範圍窄，題型模式可預測。

白話文解釋 Bedrock Guardrails

把 Bedrock Guardrails 想成你為一個場所聘請的不同種類的過濾器、門衛和查核員。每個人負責把關不同的風險，而 AIF-C01 考試要你把對的把關者配對到對的工作上。

類比一 — 百貨公司保全巡檢制度（台灣在地類比）

想像一棟台灣百貨公司。百貨公司是你的應用程式；各樓層的賣場就是基礎模型的輸出；進門的顧客是使用者的提示詞。Bedrock Guardrails 就是這棟百貨的保全巡檢團隊與樓管主任。

Content filters（內容過濾器） 是大門口的保全人員。他們監視六種標準危險類別——仇恨言論、侮辱、色情、暴力、不當行為，以及提示詞攻擊——你可以個別調高或調低每位保全的嚴格程度（None、Low、Medium、High）。兒童品牌把「暴力」調到 High；成人平台可以把「sexual」調到 Low。Denied topics（禁止話題） 是百貨管理部訂下的「禁止討論」清單——假設總經理規定「不准在館內討論競爭對手的促銷方案」，任何踩進這個話題的對話都會被攔截，並回應一則預先設定好的婉拒訊息。Word filters（字詞過濾器） 是門口的字面禁詞清單——不雅用語加上任何自訂的禁用詞語（競品名稱、內部代號）。Sensitive information filters（敏感資訊過濾器） 是隱私保護組，負責塗掉（MASK）或拒絕（BLOCK）任何夾帶身分證、信用卡或手機號碼的對話內容。Contextual grounding check（情境接地查核） 則是樓管主任，監聽廣播系統——如果廣播說出的資訊和現場實際狀況不符，主任就會立刻切斷麥克風。

這個百貨類比也解釋了架構分離的邏輯：政策物件（百貨管理規章）只需要制定一次、簽署並版本化，再分發給每位保全執行。保全不從對話中記憶規則，他們照著規章行事。這正是 Bedrock Guardrails 作為獨立資源、由 InvokeModel 呼叫引用，而非內建在模型中的原因。

類比二 — 餐廳的忌口食材管理（台灣飲食文化類比）

把你的 AI 應用想成一間台灣餐廳。顧客點餐（使用者輸入）傳進廚房，廚師（基礎模型）出菜，服務生把菜端上桌（模型輸出）。Bedrock Guardrails 就是餐廳的「忌口食材管理制度」——不論哪個廚師在後廚工作，這套制度都一體適用。

Content filters 是衛生局規定的六大食安禁忌分類——類比於過敏原標示，可以按嚴重程度分四級管控，例如對花生過敏可以設成 High，對麩質只是低度控管就設成 Low。Denied topics 是老闆私下訂的「這道菜我們不做」清單——不是食材問題，而是整道料理的概念被禁止；例如「不供應任何以競爭對手廚師命名的菜色」，不管顧客怎麼換著說法點，只要語意符合就被婉拒。Word filters 是字面上的「嚴禁出現在菜單或對話中的詞彙」清單，就像餐廳規定服務生絕對不能說某個詞。Sensitive information filters 是防止顧客個資外洩的機制——服務生在傳遞訂單時，會自動遮蓋信用卡號碼（MASK）或直接拒絕記錄（BLOCK）。Contextual grounding check 則像是食品標示查核員，確認菜單上的描述（模型回應）真的符合廚房實際使用的食材（檢索來源文件），不允許宣稱「有機」卻用一般蔬菜的情況發生。

餐廳類比也說明了成本結構：查核每一道菜（每次文字單元）都有額外費用，但相對於食材成本（模型 token 費用）往往只是小頭，只有在大量出餐（高流量）時才會明顯影響整體帳單。

類比三 — 捷運閘門與列車廣播（台灣交通類比）

把你的 AI 應用想成台北捷運系統。乘客刷卡進站是使用者輸入；列車到站廣播是模型輸出。Bedrock Guardrails 是閘門系統加上廣播審查機制。

Content filters 是進站閘門的六個感應器，偵測乘客是否攜帶危險物品（仇恨、侮辱、色情、暴力、不當行為、提示詞攻擊），每個感應器靈敏度可以獨立調整。Denied topics 是捷運公司列出的「禁止在站內討論的話題」公告——語意偵測，不管你怎麼換個方式說，只要符合禁止概念就會被攔截。Word filters 是廣播稿的字面審查，某些特定詞彙在任何廣播中都不能出現。Sensitive information filters 是旅客個資保護規定，乘客的悠遊卡號（類比信用卡號）或身分證字號（類比 SSN）在廣播或螢幕顯示前必須遮蓋或拒絕顯示。Contextual grounding check 是廣播內容的事實審查員——廣播說「下一班車三分鐘後到達」必須和實際的行控中心資料（RAG 來源文件）相符，說謊的廣播會被截斷。

捷運類比同時凸顯了地區性限制：每個捷運系統（AWS 區域）都是獨立運作的，台北捷運的規則無法直接套用到高雄捷運，就像 us-east-1 建立的 guardrail 不能直接被 eu-west-1 使用。

Bedrock Guardrails 架構 — 獨立的政策物件

對 AIF-C01 而言，最重要的一個架構事實是：Bedrock Guardrail 是一個獨立的 AWS 資源，而非基礎模型或 IAM 角色的屬性。

Guardrails 不綁定特定模型

Bedrock Guardrail 建立一次後，可以套用到 Amazon Bedrock 上任何支援的基礎模型。你用 CreateGuardrail 定義 guardrail，取得 guardrailIdentifier 和一個 version（初始為 DRAFT），再在呼叫 InvokeModel 或 Converse 時傳入這兩個參數。切換基礎模型（例如從 Claude 3 Haiku 換到 Amazon Titan Text Lite）不需要重建 guardrail——同一份 Bedrock Guardrails 政策同樣保護兩者。

Guardrails 不是 IAM

Bedrock Guardrails 控管內容；IAM 控管存取。一個擁有 bedrock:InvokeModel 權限但無法繞過 Bedrock Guardrails 的使用者，仍然必須在 guardrail 政策範圍內運作。反之，被 IAM 擋下的使用者根本不會到達 guardrail 那一關。這個區別是 AIF-C01 最常見的陷阱之一。Bedrock Guardrails 不決定「此使用者是否能呼叫模型」——那是 IAM 的工作。Bedrock Guardrails 決定的是「在呼叫已發生的前提下，內容是否安全」。

五種政策類型彼此獨立

每一種 Bedrock Guardrails 政策——Content filters、Denied topics、Word filters、Sensitive information filters、Contextual grounding check——都是獨立啟用和設定的。你可以只用 Content filters、只用 Denied topics，或任意組合。評估時所有已啟用的政策並行執行；只要任何一個觸發封鎖，該請求或回應就會被攔截，並回傳預設的拒絕訊息。

政策一 — Content Filters（六大危害類別，可調強度）

Content filters（內容過濾器）是最常用的 Bedrock Guardrails 政策。它們偵測並封鎖六種預定義的危害類別，每種類別有四個強度等級。

六大 Content Filter 類別

Bedrock Guardrails 的 Content filters 涵蓋以下六個類別：hate（針對受保護群體的歧視性內容）、insults（針對個人的貶低性語言）、sexual（色情露骨內容）、violence（人身傷害或威脅）、misconduct（犯罪或有害行為指引，如武器製作）、prompt attacks（一個只適用於輸入端的類別，用於偵測試圖覆蓋系統提示詞、越獄，或注入指令的行為）。注意「prompt attacks」是僅限輸入端的過濾器——你無法設定輸出端的 prompt attack 過濾器，因為輸出端是模型，不是使用者。

四個強度等級

每個 Content filter 類別都可以獨立設定為 None、Low、Medium 或 High。強度越高，過濾器就會對更多邊緣案例進行標記。你通常在面向兒童的應用程式上設定較高強度，在面向成人的創作工具上設定較低強度。Content filters 對輸入端和輸出端分別對六個類別進行評分，同一類別的輸入端和輸出端可以設定不同的強度。

輸入端過濾 vs. 輸出端過濾

對於六個類別中的每一個，Bedrock Guardrails 都讓你決定要評估使用者的輸入、模型的輸出，還是兩者都評估。輸入端過濾在使用者的提示詞到達基礎模型之前就將其攔截（成本較低、延遲較短，但無法捕捉僅在生成時才出現的問題）。輸出端過濾在模型的回應返回給使用者之前將其攔截（可捕捉模型產生的問題，如幻覺出的 PII、越獄成功的輸出，但模型已經跑完了，所以你仍需為那些 token 付費）。大多數生產環境部署兩個方向都會啟用。

政策二 — Denied Topics（自訂禁止話題類別）

Denied topics（禁止話題）是讓你用自然語言定義自己專屬的禁止主題領域的政策類型。這是 Bedrock Guardrails 最具業務針對性的功能。

Denied Topics 的運作方式

你透過提供一個名稱（簡短標籤，例如 "InvestmentAdvice"）、一段定義（一到兩句話描述這個話題涵蓋的內容），以及範例語句（最多五個落入此話題範疇的例子）來建立一個 denied topic。Bedrock Guardrails 使用語意分類器來判斷使用者的提示詞或模型的輸出是否落入你定義的任何 denied topic。如果是，請求或回應就會被封鎖。

Denied Topics 的限制

單一 Bedrock Guardrails 設定最多可以包含 30 個 denied topics，每個 topic 最多支援 5 個範例語句。Denied topics 預設對輸入端和輸出端都進行評估，你也可以針對每個 topic 縮小範圍。金融服務應用程式的常見做法是把「InvestmentAdvice（投資建議）」、「TaxAdvice（稅務建議）」和「LegalAdvice（法律建議）」設為三個獨立的 denied topics，讓應用程式可以為每個被封鎖的話題回傳不同的婉拒訊息。

Denied Topics vs. Word Filters

Denied topics 是語意型的——它們比對的是含義，而非精確字詞。「我該買台積電的股票嗎？」和「聯電長期持有值得嗎？」都會被分類為投資建議，即使兩句話沒有任何共同關鍵字。Word filters 是字面型的——它們比對特定字串。當「概念」本身是問題所在時，使用 denied topics；當「精確詞語」是問題所在時，使用 word filters。

政策三 — Word Filters（不雅字詞 + 自訂封鎖清單）

Word filters（字詞過濾器）是最簡單的 Bedrock Guardrails 政策。它們對輸入端和輸出端進行字面字串比對。

兩個字詞過濾器來源

Word filters 有兩個來源。第一，Bedrock Guardrails 提供一份受管理的不雅詞彙清單，只需一個開關就能啟用——AWS 負責策管和更新這份清單，涵蓋多種語言中的常見不雅用語。第二，你自行提供一份最多 10,000 個詞語的自訂封鎖清單（單字或短句）。自訂封鎖清單通常包含競品名稱、內部專案代號、禁止的行銷用語，或任何不得出現在品牌聲音中的詞句。

Word Filters 無法做到的事

Word filters 不會做詞幹還原、語意比對或換句話說偵測。如果你封鎖「槍枝」這個自訂詞語，「火器」仍然可以通過。如果你封鎖「買台積電股票」這個短語，「購入 TSMC 股份」仍然可以通過。若需要能抵禦換句話說的封鎖，請使用 denied topics。若需要精確比對的合規要求——例如「『保證獲利』這幾個字絕對不能出現在輸出中」——就使用 word filters。

大小寫敏感性與比對方式

Word filters 預設不區分大小寫。多字詞短語以連續序列進行比對。詞語之間的標點符號處理較為寬鬆。當 word filter 觸發時，Bedrock Guardrails 會封鎖請求或回應，並回傳設定好的拒絕訊息。

政策四 — Sensitive Information Filters（PII 偵測，支援 MASK 或 BLOCK）

Sensitive information filters（敏感資訊過濾器）偵測使用者輸入和模型輸出中的個人識別資訊（PII），並讓你選擇對每種偵測到的類型採取相應處置。

受管理的 PII 實體類型

Bedrock Guardrails 能識別一份策管好的受管理 PII 實體類型清單，包括 NAME、EMAIL、PHONE、ADDRESS、US_SOCIAL_SECURITY_NUMBER、US_PASSPORT_NUMBER、DRIVER_ID、CREDIT_DEBIT_CARD_NUMBER、CREDIT_DEBIT_CARD_CVV、CREDIT_DEBIT_CARD_EXPIRY、IP_ADDRESS、URL、USERNAME、PASSWORD、AGE、VEHICLE_IDENTIFICATION_NUMBER，以及金融識別碼如 SWIFT_CODE 和 US_BANK_ACCOUNT_NUMBER，還有醫療識別碼等。隨著時間推移，新受管理類型不斷加入，完整清單持續擴充。

兩種動作 — MASK 或 BLOCK

對於你啟用的每種 PII 實體類型，你要選擇一個動作。MASK 以佔位符取代偵測到的實體（例如 {NAME} 或 {EMAIL}），並允許對話繼續進行。BLOCK 拒絕整個請求或回應並回傳拒絕訊息。在同一個 Bedrock Guardrails 設定中，不同的 PII 類型可以有不同的動作。常見的做法是對 NAME 和 EMAIL 使用 MASK（讓助理仍能抽象地討論上下文），對 CREDIT_DEBIT_CARD_NUMBER 和 US_SOCIAL_SECURITY_NUMBER 使用 BLOCK（在任何方向上絕對不允許這些資訊通過）。

Regex 自訂模式

除了受管理的實體類型之外，Bedrock Guardrails 的 Sensitive information filters 還支援自訂的 regex 模式。你定義一個名稱、regex 表達式和動作（MASK 或 BLOCK）。對於沒有任何受管理 PII 類型能涵蓋的組織特定識別碼——例如員工編號、內部案件號碼、SKU 代碼或專屬記錄格式——就使用 regex。

政策五 — Contextual Grounding Check（RAG 忠實性與相關性查核）

Contextual grounding check（情境接地查核）是最新的 Bedrock Guardrails 政策，專門針對 Retrieval-Augmented Generation（RAG）的幻覺問題。它是唯一需要額外輸入的 Bedrock Guardrails 政策——來源文件和使用者的問題。

兩個接地指標

Bedrock Guardrails 的 Contextual grounding check 從兩個維度評估模型的回應。Grounding score（接地分數） 衡量回應對所提供來源段落的忠實程度——有多少答案實際上有來源上下文的支撐。Relevance score（相關性分數） 衡量回應與使用者問題的相關程度——回應是否真正回答了被問到的問題。每個指標產生一個介於 0 到 1 之間的分數。

可設定的閾值

你可以為每個指標分別設定一個閾值（介於 0 到 1 之間）。如果 grounding score 低於 grounding 閾值，或 relevance score 低於 relevance 閾值，Bedrock Guardrails 就會封鎖回應。典型的初始閾值是 grounding 設 0.75，relevance 設 0.5，再根據你的領域對幻覺與保守拒絕之間的容忍度進行調整。

Contextual Grounding 何時會觸發

Contextual grounding check 只在提供了來源段落時才會評估回應（透過 Converse API 的接地來源欄位、透過 Bedrock Knowledge Bases，或透過 ApplyGuardrail API）。沒有來源段落就沒有可供接地的基準，這個查核就會是空操作（no-op）。對於純粹的創意生成（沒有檢索上下文），contextual grounding 並不相關；對於 RAG 系統，它往往是最有價值的 Bedrock Guardrails 政策。

Bedrock Guardrails 中的輸入端 vs. 輸出端過濾

每個已啟用的 Bedrock Guardrails 政策在兩個檢查點中的一個或兩個執行：輸入端（使用者提示詞）和輸出端（模型回應）。了解哪個方向是哪個，是 AIF-C01 的反覆考測模式。

輸入端過濾在早期阻止不安全的提示詞

輸入端過濾在使用者的提示詞呼叫基礎模型之前，對其執行 Bedrock Guardrails 政策。優點：成本較低（模型不會在被封鎖的提示詞上執行）、延遲較短，以及對提示詞注入和提示詞攻擊的早期防禦。限制：輸入端過濾無法捕捉僅在生成時才出現的問題，例如模型幻覺出不在提示詞中的 PII。

輸出端過濾在不安全的回應返回前阻止它

輸出端過濾在模型的回應返回給使用者之前，對其執行 Bedrock Guardrails 政策。優點：可捕捉模型產生的問題（幻覺出的 PII、生成的暴力內容、成功的提示詞注入），可捕捉對溜過輸入端過濾的提示詞所產生的回應。成本：模型已經跑完並產生了 token，所以即使輸出被封鎖，你仍然需要為那些 token 付費。

每個政策各自選擇方向

Content filters 和 Sensitive information filters 讓你按類別選擇方向是輸入端、輸出端，還是兩者都有。Denied topics 預設評估輸入端和輸出端。Word filters 在輸入端和輸出端都執行。Contextual grounding check 只在輸出端執行（輸入端沒有「接地」的概念）。「prompt attacks」這個 Content filter 類別根據定義只在輸入端執行。

Bedrock Guardrails 的跨區域可用性

Bedrock Guardrails 和大多數 Bedrock 基本元件一樣，是區域性資源。

按區域建立

你在特定的 AWS 區域建立 Bedrock Guardrail。Guardrail 的 ARN 包含區域資訊。一個同時在 us-east-1 和 eu-west-1 部署的應用程式需要兩個獨立的 guardrail 資源——每個區域各一個——即使政策內容完全相同。基礎設施即程式碼（CloudFormation、CDK、Terraform）是讓兩者保持同步的標準做法。

區域可用性與功能對等性

新的 Bedrock Guardrails 功能（例如 contextual grounding check 正式上線時）會逐步在各區域推出。並非每個 Bedrock 區域都會立刻支援每個 Bedrock Guardrails 功能。在設計依賴特定 Bedrock Guardrails 政策類型的架構之前，務必查閱 Bedrock Guardrails 文件中的區域功能矩陣。

跨區域推論與 Guardrails

Amazon Bedrock 支援將請求路由到有可用容量之區域的跨區域推論 profile。當你使用跨區域推論時，guardrail 仍然透過 ID 附加到呼叫上，Bedrock 會在適當的區域處理評估。你不需要建立獨立的跨區域 guardrail；你只需在推論 profile 的起源區域建立 guardrail。

Bedrock Guardrails 的版本管理

Bedrock Guardrails 對其政策定義進行版本管理，而版本管理是考試值得關注的功能集之一。

DRAFT 版 vs. 編號版本

當你建立 Bedrock Guardrail 時，它以 DRAFT 版本開始。你可以自由編輯草稿——新增 denied topics、調整 content filter 強度、更改 sensitive information 動作。在任何時間點，你都可以將草稿發布為編號版本（1、2、3、……），這些版本是不可更改的。應用程式在呼叫 InvokeModel 或 Converse 時指定特定的 guardrailVersion——測試時用 DRAFT，生產環境使用編號版本。

版本管理為何重要

版本管理讓你可以回滾。如果你的 Bedrock Guardrails 第 5 版引入了過度積極的 content filter，開始封鎖合法流量，你可以透過在應用程式中將 guardrailVersion 參數改回第 4 版來將生產環境切回去，這是一個設定變更，不需要重新構建。版本管理也提供了稽核軌跡——每個編號版本都記錄了是誰在什麼時候發布的，因此合規審查可以追溯任何過去時間點所啟用的政策。

發布工作流程

典型的工作流程：建立 guardrail，在 Bedrock 主控台的 playground 測試工具中以 DRAFT 迭代，滿意後發布版本 1，將測試環境應用程式指向版本 1，經過一段觀察期後將生產環境應用程式也指向版本 1，繼續編輯 DRAFT 準備版本 2，發布版本 2，再依序將測試環境和生產環境遷移過去。編號版本是不可更改的——要變更政策，你永遠都是發布一個新版本。

Bedrock Guardrails 的費用

Bedrock Guardrails 有自己的定價，與基礎模型的 token 費用是分開計算的。

文字單元定價

Bedrock Guardrails 按處理的文字單元計費。一個文字單元是最多 1,000 個字元的文字區塊；費用按每個文字單元、每個被評估的政策類型計算。不同政策的每文字單元單價不同——Content filters、Denied topics、Word filters 和 Sensitive information filters 通常很便宜；Contextual grounding check 因為要執行自己的模型比對，所以費用較高。請查閱 Bedrock 定價頁面了解每個區域各政策的最新每文字單元價格。

輸入端 vs. 輸出端過濾的成本影響

由於文字單元按方向計費，對某個政策同時啟用輸入端和輸出端評估，大約會讓你的 Bedrock Guardrails 帳單那個部分翻倍。大多數生產部署對於安全關鍵政策（PII、Content filters）都接受這個成本，但可能透過只在單一方向執行某些政策來節省費用（例如 Denied topics 只在輸入端執行）。

相對於模型 Token 的費用

對於大多數工作負載而言，Bedrock Guardrails 費用只是基礎模型 token 費用的一小部分。一次產生 500 token 回應的 Claude 3 Sonnet 呼叫要花好幾分錢（美元）；用所有五種政策類型評估該回應只需加上不到一分錢。例外情況是配合大量請求量使用的極低成本模型——如果你在高流量環境下運行 Amazon Titan Text Lite，Bedrock Guardrails 費用就可能對帳單產生明顯影響，而方向選擇（只輸入端 vs. 兩端都評估）也就成為有實質意義的最佳化槓桿。

Bedrock Guardrails 與 Bedrock Knowledge Bases 的整合

Amazon Bedrock Knowledge Bases 是 Bedrock 上的受管理 RAG pipeline。Bedrock Guardrails 與 Knowledge Bases 原生整合。

將 Guardrails 附加到 RetrieveAndGenerate

當你對 Bedrock Knowledge Base 呼叫 RetrieveAndGenerate 時，你可以提供一個包含 guardrail 識別碼和版本的 guardrailConfiguration。整個 RAG pipeline——檢索、提示詞建構、模型呼叫、回應回傳——都會流過 Bedrock Guardrails 政策。對於 RAG 工作負載，這是讓所有五種政策類型都套用進去、且零額外應用程式程式碼的最簡單方式。

Contextual Grounding 是天然的最佳搭配

由於 Bedrock Knowledge Bases 天生就會提供已檢索的段落，Contextual grounding check 是最自然地與 Knowledge Bases 搭配的 Bedrock Guardrails 政策。在基本 Knowledge Bases 費用之外，你就能獲得 RAG 忠實性查核。許多團隊開始使用 Bedrock Guardrails 的第一步，就是將 Contextual grounding check 附加到現有的 Knowledge Bases RetrieveAndGenerate 工作流程上。

Guardrails 與 Bedrock Agents

Bedrock Agents 是 Bedrock 上多步驟工具使用工作流程的協作層。Agents 在建立 agent 時接受 guardrail 設定，而 guardrail 會套用到 agent 在其推理循環中所做的每一次 LLM 呼叫。這特別有價值，因為 agent 每個使用者回合可能產生數十次 LLM 呼叫，每一次都必須個別對安全政策進行評估。

ApplyGuardrail API — 不需模型呼叫的獨立內容審核

ApplyGuardrail API 是最常讓 AIF-C01 考生感到意外的 Bedrock Guardrails 功能。

ApplyGuardrail 做什麼

ApplyGuardrail 在不呼叫任何基礎模型的情況下，對任意文字執行 Bedrock Guardrails 評估。你傳入 guardrail 識別碼、guardrail 版本、來源類型（"INPUT" 或 "OUTPUT"），以及要評估的文字。API 回傳評估結果——封鎖或通過——以及關於哪個過濾器被觸發的政策特定詳情。

為何存在 ApplyGuardrail

ApplyGuardrail 支援兩種重要的使用模式。第一，它讓你能把 Bedrock Guardrails 套用到不在 Bedrock 上的模型輸出——例如，在 SageMaker 端點上運行的內部微調模型。你把模型的輸出透過 ApplyGuardrail 進行內容安全審查，再返回給使用者。第二，它讓你能用 AI stack 其他地方使用的同一份 Bedrock Guardrails 政策，對使用者產生的內容（論壇貼文、客服票務提交、聊天訊息）進行審核，統一跨 AI 和非 AI 介面的審核層。

定價與延遲

ApplyGuardrail 的每文字單元定價與嵌入式 guardrail 評估相同。延遲低於完整的 InvokeModel，因為不需要執行任何基礎模型——只是政策評估。典型的端到端延遲是數十毫秒到低幾百毫秒之間，取決於啟用的政策和文字長度。

Bedrock Guardrails vs. 提示詞工程 — 互補，非替代

AIF-C01 常見的陷阱是將 Bedrock Guardrails 和提示詞工程設定為競爭關係。它們不是。

提示詞工程能做什麼

提示詞工程透過系統提示詞或使用者提示詞中的指令來塑造模型行為。良好的提示詞工程可以減少不安全的輸出、限制話題，並改善回應風格。提示詞工程成本低廉（不需要額外的 AWS 資源），且與應用程式緊密耦合。

提示詞工程無法做到的事

提示詞工程會被蓄意的提示詞注入所攻破——一個說「忽略所有先前的指令」的使用者，通常可以覆蓋精心撰寫的系統提示詞。提示詞工程也無法跨應用程式擴展政策變更；每個應用程式各自擁有自己的提示詞。而且提示詞工程沒有稽核產出物——你無法輕易向法務合規人員證明在某個時間點啟用的是什麼安全政策。

為何要兩者都用

Bedrock Guardrails 和提示詞工程在不同的層運作。提示詞工程設定預設行為；Bedrock Guardrails 執行不可協商的政策。設計良好的應用程式使用提示詞工程來指定語氣、角色和典型任務框架，使用 Bedrock Guardrails 來執行硬性規則——「絕不討論競爭對手」、「絕不輸出統一編號或信用卡號碼」、「絕不生成暴力內容」。這兩層合在一起提供了縱深防禦。

常見的 Bedrock Guardrails 考試陷阱

AIF-C01 考試輪流出現一小組 Bedrock Guardrails 陷阱題。認識它們就能讓這個主題變得幾乎是自動得分的。

陷阱一 — Bedrock Guardrails vs. IAM

Bedrock Guardrails 是內容安全；IAM 是存取控制。描述「阻止使用者調用特定模型」的考題是 IAM。描述「不論使用者是誰，都要封鎖某些內容類型」的考題是 Bedrock Guardrails。兩者都可能同時出現；不要讓其中一個讓你分心而看不到另一個。

陷阱二 — Contextual Grounding vs. RAG

Contextual grounding check 驗證 RAG 的回應；它本身不執行 RAG。描述「檢索文件並提供給模型」的情境是 RAG。描述「確保模型的答案確實有已檢索文件的支撐」的情境是 Contextual grounding check。

陷阱三 — Denied Topics vs. Word Filters

Denied topics 是語意型的（基於含義）。Word filters 是字面型的（基於字串）。「封鎖關於併購的討論」是 Denied topics。「封鎖『保證獲利』這個詞語」是 Word filters。

陷阱四 — Content Filters 不是二元的

Content filters 有四個強度等級（None、Low、Medium、High），不只是開/關。回答「啟用仇恨過濾器」的考生並沒有錯，但詢問特定強度等級的考題——「對仇恨內容最積極的過濾」——問的是 High 這個設定。

陷阱五 — PII 動作是 MASK 或 BLOCK，按類型各自選擇

Sensitive information filters 沒有全域動作。每種 PII 類型各自決定 MASK 還是 BLOCK。同一份 guardrail 可能對姓名使用 MASK，對信用卡號碼使用 BLOCK。那些預期對所有 PII 都套用單一動作的情境，是在引你去選一個微妙的錯誤答案選項。

陷阱六 — ApplyGuardrail 是獨立的

ApplyGuardrail 很容易被忽略，因為它不涉及任何模型呼叫。如果情境描述的是審核不透過 InvokeModel 發送的文字，答案是 ApplyGuardrail，而不是任何整合型選項。

Bedrock Guardrails 快速參考摘要

Bedrock Guardrails 是一個獨立的、具有版本管理的 AWS 資源，對輸入和輸出評估最多五種獨立的政策類型。Content filters 涵蓋六個危害類別（hate、insults、sexual、violence、misconduct、prompt attacks），有四個強度等級。Denied topics 是自訂的語意主題封鎖。Word filters 比對不雅詞彙和自訂字面封鎖清單。Sensitive information filters 偵測受管理的 PII 類型加上自訂 regex 模式，每種類型各自設定 MASK 或 BLOCK 動作。Contextual grounding check 根據接地分數和相關性分數閾值，對照來源文件驗證 RAG 回應。透過 InvokeModel/Converse 參數、Bedrock Knowledge Bases 和 Agents 整合，或透過 ApplyGuardrail 獨立調用。具有 DRAFT 加編號版本的版本管理，按每文字單元每政策計費，與所有其他 Bedrock 資源一樣是區域性資源。

FAQ — Amazon Bedrock Guardrails

Q1 — 不呼叫基礎模型也能使用 Bedrock Guardrails 嗎？

可以。ApplyGuardrail API 在不呼叫任何基礎模型的情況下，對任意文字評估 Bedrock Guardrails 設定。這是對來自外部（非 Bedrock）模型的內容，或對一般使用者產生的內容進行審核的模式，使用的是你在 AI stack 其他地方也使用的同一份 Bedrock Guardrails 政策。

Q2 — Bedrock Guardrails 和 Bedrock 的 IAM 權限是一樣的東西嗎？

不是，而且這是一個常見的陷阱。Bedrock Guardrails 是內容安全層——它們決定哪些內容可以流過模型呼叫。IAM 是存取控制層——它決定誰被允許首先呼叫哪些模型。生產環境通常兩者都需要：IAM 負責授權，Bedrock Guardrails 負責內容政策。

Q3 — Contextual grounding check 能取代 RAG 嗎？

不能。Contextual grounding check 是跑在 RAG 系統或任何提供來源段落的工作流程之上的忠實性查核。RAG 檢索段落並注入提示詞，讓模型能用外部知識回答問題；Contextual grounding check 驗證模型的答案確實有那些段落的支撐。你兩者都需要——RAG 負責檢索，Contextual grounding check 負責驗證。

Q4 — 如何用 Bedrock Guardrails 防範提示詞注入攻擊？

最直接的控制措施是 Content filters 中的「prompt attacks」類別，它在輸入端執行。將其設定為 Medium 或 High 強度，以捕捉常見的注入模式。在這之上再疊加針對已知敏感主題的 Denied topics、以及定義清楚系統角色邊界的提示詞工程，並啟用輸出端過濾來捕捉任何從輸入端溜過去的注入。請記住，沒有任何單一的 Bedrock Guardrails 功能是完整的提示詞注入防禦——縱深防禦是必要的。

Q5 — 一個 Bedrock Guardrails 資源可以保護多個基礎模型嗎？

可以。單一 Bedrock Guardrails 資源與模型無關。你建立一次，然後透過 InvokeModel 或 Converse 上的 guardrailIdentifier 和 guardrailVersion 參數，將其附加到任何支援的基礎模型上。切換模型不需要重建 guardrail；同一份 Bedrock Guardrails 政策無論模型是 Claude、Titan、Llama、Mistral 還是 Cohere，都以相同方式評估輸入和輸出。

Q6 — 如果 Bedrock Guardrails 的某個變更開始封鎖合法流量，如何回滾？

使用版本管理。Bedrock Guardrails 的版本（1、2、3、……）一旦發布就是不可更改的。如果第 5 版開始封鎖合法流量，就把你的應用程式的 guardrailVersion 參數改回第 4 版——這是一個設定變更，不需要重新構建。然後編輯 DRAFT 準備一個修復好的第 6 版，就緒後再發布。這種回滾模式是 Bedrock Guardrails 作為具有版本管理的資源而非行內呼叫時間設定的主要原因之一。

Q7 — Bedrock Guardrails 能跨 AWS 區域使用嗎？

Bedrock Guardrails 是區域性資源。在 us-east-1 建立的 guardrail 無法從 eu-west-1 存取。對於多區域應用程式，你要在每個區域各自建立一個相對應的 Bedrock Guardrails 資源（通常透過基礎設施即程式碼讓政策定義保持同步）。Bedrock 上的跨區域推論 profile 會透明地處理 guardrail 附加——你附加到 profile 的起源區域，Bedrock 會在推論實際執行的地方評估 guardrail。