AI 合規法規與治理計畫

AI 安全合規治理是一門統籌協調的學科，負責確保 AWS 上的 AI 工作負載保持安全、可稽核，並符合外部法規的要求。它不是單一 AWS 服務，也不是單一法規框架。AI 安全合規治理是 AIF-C01 考試用來描述以下組合的總稱詞：五層邊界模型（身分識別、網路、資料、模型輸出、稽核軌跡）如何與法規環境（EU AI Act、NIST AI RMF、ISO/IEC 42001、GDPR、HIPAA）以及組織內部計畫（AI 治理委員會、模型風險管理、事故回應）相互搭配，使 AWS 上每一個 AI 決策都能被解釋、被答辯，並且可以回滾復原。本 Hub 主題串聯整個領域 5（Domain 5）——D5 下每個子主題都對應到下方所介紹的其中一道邊界或其中一個內部計畫。先掌握 AI 安全合規治理的框架全貌，面對 D5 情境題時就很難失分。

什麼是 AWS 上的 AI 安全性、合規與治理？

AI 安全合規治理是由三個核心概念構成的整體框架。AI 安全性（AI Security）是一組防止未授權存取、篡改或濫用 AI 系統的控制措施，涵蓋 prompt injection（提示注入）、模型竊取、透過模型輸出外洩資料等威脅。AI 合規（AI Compliance）是將這些控制措施對應到外部稽核標準（ISO/IEC 42001、SOC 2、HIPAA、FedRAMP）及具約束力的法規（EU AI Act、GDPR）的過程。AI 治理（AI Governance）則是組織內部的制度層——政策、委員會、審批關卡、風險登記冊——決定部署哪些模型、以何種方式部署、搭配哪些安全護欄。

在 AIF-C01 基礎級別，不要求你撰寫服務控制政策（SCP）或起草 EU AI Act 合規評估報告。考試要求你能辨識哪個 AWS 服務、哪個法規概念、哪個治理文件能解決哪種問題，並說明它們如何組合運作。考試題型通常是這樣的：「一家公司正在建置處理歐盟客戶資料的生成式 AI 聊天機器人，應套用哪個框架、哪個 AWS 服務、哪個治理文件？」答案幾乎都是「一個邊界控制 ＋ 一個法規 ＋ 一個稽核服務」的組合。

AI 安全合規治理對 AIF-C01 的重要性

領域 5 佔 AIF-C01 總分 14%。與 CLF-C02 相比，本領域的題目更深入，因為生成式 AI 帶來了傳統雲端安全課程從未涵蓋的全新失效模式——prompt injection、幻覺（hallucination）洩漏 PII、模型逆向攻擊（model inversion）。AI 安全合規治理是將所有這些失效模式納入同一思維模型的唯一框架。只背服務名稱（Bedrock Guardrails、Macie、SageMaker Clarify）卻沒有 Hub 框架的考生，遇到情境題只能靠猜；先建立 Hub 框架的考生則能用排除法找到正確答案。

本 Hub 主題與相鄰 D5 子主題的範疇區分

本 Hub 串聯五個 D5 子主題：AI 威脅模型與攻擊類型 涵蓋攻擊面；IAM 與 Bedrock 安全性 涵蓋身分識別與網路邊界；Bedrock Guardrails 與控制措施 涵蓋模型輸出邊界；資料治理與 PII 涵蓋資料邊界；而本 Hub 涵蓋法規與計畫層（治理委員會、風險管理、事故回應、稽核組合）。建議先讀本 Hub，再點進符合考試情境的子主題。

白話文解釋 AI 安全合規治理

學術描述的 AI 治理很容易流於抽象。以下用三個來自不同領域的類比，把概念牢牢釘住。

類比一 — 健保醫院的開刀房

生產環境中的 AI 模型就像健保體系裡一位醫院開刀房的外科醫師。AI 安全性是無菌手術衣、刷手消毒規範，以及手術室上鎖的大門——只有持有正確資格的人才能靠近病患；這對應到 IAM、Bedrock 的 VPC 端點，以及 KMS 加密。AI 合規是掛在牆上的醫師執照與大廳展示的醫院評鑑證書——外科醫師的訓練由外部機構稽核（EU AI Act 合規評估、ISO/IEC 42001），醫院的作業程序也由另一個機構稽核（SOC 2、透過 AWS Artifact 簽署的 HIPAA BAA）。AI 治理是醫院每週召開的「發病率與死亡率討論會」——檢視每個併發症案例、決定是否暫停某項手術，並更新病患同意書——這對應到你的內部 AI 審查委員會、模型風險管理委員會，以及事故回應劇本。三層任一失效，病患就會受到傷害。沒有任何類比比這個更能說明：AI 安全合規治理必須被當作一個系統來對待，而不是三份獨立的清單。

類比二 — 有衛生稽查員的商業廚房

想像一家商業廚房現在用了一位機器人主廚（AI 模型）。上鎖的食材儲藏室、員工識別徽章，以及每個工作站上方的監視器，就是 AI 安全性——防止外人下毒或竊取食譜，並記錄機器人的每一個動作（這就是 CloudTrail 記錄 Bedrock 呼叫、Config 追蹤 SageMaker 設定）。牆上裱框的衛生局合格證書是 AI 合規——外部稽查員按照公開標準完成了現場稽查（食品界是 FDA，AI 界是 EU AI Act）。主廚手邊那本夾著菜單、每道食材供應商、最近一次食譜修改紀錄，以及所有客訴日期的管理活頁夾，就是 AI 治理——模型清冊、資料血緣、審批關卡，以及 AIF-C01 考試希望你聯想到「模型登錄（model registry）」、「資料目錄（data catalog）」、「稽核軌跡（audit trail）」這些詞彙的事件日誌。有監視器卻沒有活頁夾的廚房，稽查一定不通過；有活頁夾卻沒上鎖的廚房，遲早被人闖入。三樣都要有。

類比三 — 台灣金融監理的對照框架

台灣金管會對金融機構 AI 應用的治理指引，與本 Hub 討論的國際框架高度相似，可以做為本土對照參考。AI 安全性對應金管會要求的資訊安全控制措施與存取管理，同時也符合我國《個人資料保護法》（個資法）對資料存取的保護義務。AI 合規對應金管會發布的「金融機構作業委外管理辦法」與「人工智慧相關規範指引」——金融業者須說明模型如何符合現行法規、備妥符合性文件供主管機關檢閱。AI 治理對應國發會數位發展部推動的 AI 基本法草案所強調的「問責機制」與「人機協作」原則：明確指定負責人、建立內部審查委員會、確保高影響力決策保有人工複核。這個台灣在地視角說明一件事：不論是歐盟、美國或台灣，AI 安全合規治理的三層架構在全球都具有普遍性——只是名稱與主管機關不同，核心邏輯一致。

AWS 上 AI 的五層邊界模型

AWS 上的 AI 安全合規治理最清晰的教學方式是五道同心邊界。考試很少直接問「說出五道邊界的名稱」，但每一道情境題都能歸入其中一道。

邊界一 — 身分識別（Identity）

身分識別邊界回答「誰可以呼叫 AI 服務？」在 AWS 上，這由 AWS Identity and Access Management（IAM）結合 AWS Organizations 共同負責。IAM 政策把 bedrock:InvokeModel、sagemaker:CreateEndpoint、comprehend:DetectPiiEntities 等動作限縮到特定主體（principal）。來自 AWS Organizations 的服務控制政策（SCP）則約束成員帳號中每個 IAM 主體的最大權限——例如，防止沙盒 OU 中的任何帳號呼叫 Bedrock。Bedrock 資源型政策可進一步限制哪些跨帳號呼叫者可以調用特定模型。詳細內容請參閱 IAM 與 Bedrock 安全性 子主題。

邊界二 — 網路（Network）

網路邊界回答「流量如何到達 AI 服務？」在預設情況下，Bedrock 與 SageMaker 端點可以透過公開網際網路連線。針對受監管的 AI 工作負載，你需要新增 VPC 端點（AWS PrivateLink），使流量完全不離開 AWS 骨幹網路；為訓練任務啟用 SageMaker 網路隔離（network isolation），讓訓練容器無法對外存取網際網路；並在任何公開的聊天介面前加上 AWS WAF。沒有網路邊界，竊取到憑證的攻擊者可以從任何地方呼叫模型；有了網路邊界，攻擊必須源自你的 VPC 內部。

邊界三 — 資料（Data）

資料邊界回答「什麼資料可以進出 AI 系統，以及如何保護這些資料？」AWS Key Management Service（KMS）對靜態訓練資料（S3、EBS）、模型成品、Bedrock 知識庫索引，以及 SageMaker Feature Store 條目進行加密。Amazon Macie 在訓練資料進入訓練任務之前，掃描 S3 上的資料集中是否含有個人識別資訊（PII）。AWS Glue Data Catalog 維護資料血緣（data lineage），讓你可以追溯每個模型的訓練來源。資料留存地（data residency）則透過 Region 選擇加上 SCP 來強制執行。資料治理與 PII 子主題有更深入的說明。

邊界四 — 模型輸出（Model Output）

這道邊界正是 AI 安全合規治理與傳統雲端安全的最大差異。即使身分識別、網路和資料都已鎖定，模型本身仍可能輸出有害內容（仇恨言論、從訓練資料洩漏的 PII、幻覺式的醫療建議），或被 prompt injection 操縱。Amazon Bedrock Guardrails 在輸入與輸出兩端同時套用內容過濾、拒絕主題封鎖、PII 遮蔽，以及接地性（grounding）檢查。Amazon SageMaker Clarify 呈現偏差（bias）與特徵歸因（feature attribution）。Amazon A2I（Augmented AI）將低信心預測路由給人工審查員。服務層細節請參閱 Bedrock Guardrails 與控制措施 子主題。

邊界五 — 稽核軌跡（Audit Trail）

稽核軌跡邊界回答「事後能否證明發生了什麼事？」AWS CloudTrail 記錄每一次 Bedrock 模型呼叫、SageMaker API 呼叫，以及每一個 IAM 決策。AWS Config 追蹤每個 SageMaker 端點、Bedrock 護欄版本，以及知識庫資料來源的設定歷程。AWS Audit Manager 持續從 CloudTrail、Config、Security Hub 及手動上傳中收集證據，並將這些證據對應到控制框架（SOC 2、HIPAA、ISO、NIST）。沒有可靠的稽核軌跡，你的合規立場就會崩潰——無法證明控制措施正在運作、無法進行事故鑑識，也無法滿足主管機關的「解釋權」（right-to-explanation）要求。

法規環境 — 認知層級要求

AIF-C01 不要求你解讀法律條文。它要求你能依名稱辨識每項法規、理解其風險分類思維模型，並將其對應到協助合規的 AWS 基礎元件。

EU AI Act — 基於風險的四級分類

EU Artificial Intelligence Act（歐盟人工智慧法）是第一部主要的橫向 AI 法律。它將每個 AI 系統分為四個風險等級。不可接受風險（Unacceptable-risk）系統——如社會評分、公共場所即時生物辨識——全面禁止。高風險（High-risk）系統——如用於招募、信用評分、醫療器材、關鍵基礎設施的 AI——必須完成合規評估、備妥技術文件、建立人工監督機制、保留記錄，並進行上市後監控；這正是 AWS 安全合規治理工具（CloudTrail、Config、SageMaker Model Cards、A2I）直接對應法律義務的地方。有限風險（Limited-risk）系統——如聊天機器人、深度偽造——必須告知用戶他們正在與 AI 互動，即透明度要求。最小風險（Minimal-risk）系統則沒有特定義務。備考重點：記住四個等級，並認識到高風險系統驅動了大部分的記錄與人工審查要求。

NIST AI Risk Management Framework（NIST AI RMF）

NIST AI Risk Management Framework（NIST AI RMF 1.0）是美國自願性框架，圍繞四個功能組織：Govern（治理）建立組織的 AI 風險政策；Map（映射）識別背景脈絡與 AI 系統風險；Measure（衡量）分析並追蹤風險；Manage（管理）分配資源並回應事故。NIST AI RMF 不是認證——你無法「通過 NIST AI RMF 認證」——它是一個參考模型，許多組織自願採用，美國聯邦採購招標書（RFP）也越來越多要求採用。備考重點：認識四個功能的詞彙，並區分 AI RMF 與舊版 NIST Cybersecurity Framework（後者使用 Identify、Protect、Detect、Respond、Recover）。

ISO/IEC 42001 — AI 管理系統標準

ISO/IEC 42001:2023 是第一個用於 AI 的國際管理系統標準。與 NIST AI RMF 不同，它是可認證的——外部稽核員可以授予你的組織 ISO/IEC 42001 證書，就像 ISO 27001 之於資訊安全。ISO/IEC 42001 要求建立有文件記錄的 AI 管理系統（AIMS），包含政策、目標、風險評估、內部稽核，以及持續改善。向歐盟銷售 AI 服務的組織，通常會取得 ISO/IEC 42001 認證，作為能夠滿足 EU AI Act 高風險系統義務的佐證。

GDPR 在 AI 處理個人資料時的適用

EU General Data Protection Regulation（GDPR，通用資料保護規則）先於 AI 專用法而存在，但只要 AI 系統處理歐盟居民的個人資料，GDPR 就依然適用。AI 安全合規治理最相關的三條 GDPR 條款如下。第 22 條賦予資料主體不受純自動化決策（具重大影響）約束的權利——實務意涵：要嘛加入人工審查（Amazon A2I），要嘛不要完全自動化決策。第 15 條創設存取權，並隱含解釋權——實務意涵：你必須能用白話說明模型為何做出特定決策（SageMaker Clarify 的特徵歸因有助於此）。資料最小化與目的限制原則意味著你不能使用超出必要的 PII 進行訓練，也不能轉用資料——實務意涵：用 Amazon Macie 掃描訓練資料、用 Comprehend 或 Bedrock Guardrails 遮蔽 PII，並在 SageMaker Model Card 中記錄用途。

此外，台灣的**《個人資料保護法》**（個資法）在概念上與 GDPR 高度對應，同樣要求限制個資的蒐集目的、禁止逾越目的使用，並賦予當事人查詢與更正的權利。在台灣部署處理個資的 AI 系統時，需同步考量個資法的合規義務。

產業專屬法規

橫向框架之上，還有各產業的專屬法規。HIPAA 適用於 AI 處理美國受保護健康資訊（PHI）的情況——透過 AWS Artifact 簽署 HIPAA Business Associate Addendum（BAA），並僅使用符合 HIPAA 資格的服務（Bedrock、SageMaker、Comprehend Medical 均符合資格）。FINRA 與 SEC 管轄在美國用於金融建議與交易的 AI。PCI DSS 在 AI 聊天機器人接觸支付卡資料時仍然適用。FDA 管轄在美國作為醫療器材的 AI。這些法規在考試中以情境限定詞的形式出現（「一家醫療公司」、「一家自營商」）——你的任務是辨識正確框架，而不是引用條款內容。

組織內部 AI 治理計畫

光靠法規與 AWS 服務無法治理 AI——需要人與流程的配合。每個在 AWS 上認真部署 AI 的組織都需要一套內部治理計畫，而 AIF-C01 考試測試的正是對其組成元素的認識。

AI 治理委員會（審查委員會）

跨功能的 AI 治理委員會通常涵蓋法務、資訊安全、資料保護長（DPO）、產品、工程和高階主管代表。委員會負責審批或拒絕每個新 AI 應用案例、審查高風險模型部署、在商業急迫性與負責任 AI 考量之間仲裁，並對事故回應結果進行核准。在受監管的產業中，委員會的章程本身就是合規文件——稽核員在進行 ISO/IEC 42001 或 EU AI Act 評估時會要求提交。

負責任 AI 政策

負責任 AI 政策是書面文件，說明你的組織如何應用 AWS 負責任 AI 七大支柱（公平性、可解釋性、隱私、安全、可控性、正確性、治理）。文件中列出禁止的應用案例、每個風險等級所需的控制措施，以及升級處理路徑。在 AWS 上，政策透過 SCP（預防性控制）、AWS Config 規則（偵測性控制）和 SageMaker Model Cards（文件記錄）來落地執行。政策是稽核員最先閱讀的文件。

AI 應用案例申請流程

每個新 AI 專案都應通過申請表單，記錄用途、資料來源、受影響的利害關係人、風險等級（依 EU AI Act 或內部分類法）、選定的基礎模型，以及所需的護欄措施。申請表觸發審批關卡。沒有申請流程，「影子 AI」就會蔓延——各團隊自行建置模型，治理委員會在事故發生前從未見過。

訓練與意識推廣

沒有訓練有素的開發人員和業務負責人，AI 治理就會失效。AWS 為每個受管 AI 服務發布 AI Service Cards，說明其預期用途與局限；內部團隊應在此基礎上補充組織特有的指引。訓練計畫必須涵蓋 prompt injection 意識、PII 處理義務，以及事故升級流程——尤其是使用 Amazon Q Business 或 SageMaker Canvas 等低程式碼工具的非工程師。

AI 模型風險管理

模型風險管理（MRM）是識別、評分、審批及監控每個生產環境模型的結構化實踐。它起源於銀行業（美國聯準會 SR 11-7、英國 PRA SS1/23），現已成為各領域 AI 治理的骨幹。台灣金管會近年也要求金融機構針對 AI 模型建立等同 MRM 精神的管控機制。

模型清冊（Model Inventory）

模型清冊是組織使用的所有 AI 模型的主列表——無論是自行建置、從基礎模型微調，還是作為第三方 API 使用。每筆紀錄記錄用途、負責人、風險等級、資料來源、訓練日期、部署環境，以及目前狀態。在 AWS 上，SageMaker Model Registry 搭配透過 AWS Config 維護的標籤標準，是常見的技術基礎。對於透過 Amazon Bedrock 使用的第三方基礎模型，清冊條目應記錄模型系列、版本，以及適用的 Bedrock Guardrail。

風險評分（Risk Rating）

每筆清冊條目都要進行風險評分。組織通常採用三級制（低、中、高）或直接對齊 EU AI Act 的等級。風險驅動因素包括：決策自主性（每個輸出是否有人工審批？）、利害關係人影響（是否影響招募、信用或健康？）、資料敏感度（是否接觸 PII 或 PHI？），以及模型可解釋性（能否描述模型決策的原因？）。評分決定部署前的審查深度和部署後的監控頻率。

審批關卡（Approval Gates）

高風險模型未經審批關卡不得部署：包括治理委員會審查、獨立驗證，以及高階主管簽核。AWS 提供配套機制——SageMaker Model Registry 支援明確的審批狀態（Approved、Rejected、PendingManualApproval），可以串接到 SageMaker Pipelines，使未審批的模型無法到達生產端點。對於基於 Bedrock 的應用，審批關卡通常在應用部署流水線（CodePipeline ＋ AWS Config 規則）層面強制執行。

部署後監控（Post-Deployment Monitoring）

模型部署後會發生飄移（drift）。資料分佈改變、用戶行為演變、外部環境變化。SageMaker Model Monitor 持續將生產環境的輸入和輸出與基準值（baseline）比較，並對資料品質飄移、模型品質飄移、偏差飄移，以及特徵歸因飄移發出警報。對於 Bedrock 模型，CloudWatch 指標加上自訂評估任務（Bedrock Model Evaluation）扮演相同的角色。當偵測到飄移時，模型重新進入風險評分和審批流程。

第三方模型風險（Third-Party Model Risk）

基礎模型通常是採購使用而非自行建置。第三方模型風險要問的是：誰訓練了它、用什麼資料、進行了什麼安全測試，我們能稽核其中任何一項嗎？AWS AI Service Cards 和 Bedrock 發布的模型文件提供了供應商端的透明度，但客戶仍然需要負責。你的治理政策應明確說明哪些第三方模型已獲批准、其上方強制套用哪些護欄，以及當供應商在未通知的情況下更新模型版本時應如何處理。

AI 事故回應模式

AI 事故不同於傳統資安事故。傳統事故是入侵；AI 事故可能是有偏差的輸出、誤導客戶的幻覺、成功的 prompt injection，或是洩漏訓練記錄——這一切都可能在沒有任何憑證被竊取的情況下發生。

偵測（Detection）

偵測來源包括：Bedrock Guardrails 違規日誌（用戶觸發了拒絕主題）、CloudWatch 異常指標（呼叫率暴增 50 倍）、SageMaker Model Monitor 警報（偏差飄移超過閾值）、透過回饋管道彙整的客戶投訴，以及主管機關通知。成熟的計畫會將所有這些訊號匯入單一事故佇列。注意：Amazon GuardDuty 不偵測 AI 特有事故——遇到描述模型偏差或幻覺的情境時，不要把它選為第一答案。

圍堵（Containment）

AI 事故的圍堵有兩個超越傳統圍堵的獨特模式。第一，模型回滾（model rollback）——將生產端點回復到之前已審批的模型版本（SageMaker 端點原地更新或 Bedrock Provisioned Throughput 切換）。第二，收緊護欄（guardrail tightening）——在調查根本原因期間，暫時提高 Bedrock Guardrails 的嚴格程度或套用更窄的主題拒絕政策。完成圍堵後才進行根本原因分析。

根本原因分析（Root Cause Analysis）

AI 事故的根本原因通常分為四類：資料根本原因（訓練資料有偏差或被投毒）、模型根本原因（微調後行為劣化）、Prompt 根本原因（系統 prompt 允許被利用）、操作根本原因（護欄設定錯誤）。CloudTrail 與 Config 提供時間線；SageMaker Clarify 與特徵歸因報告提供行為解釋；模型登錄與資料目錄提供血緣追溯。

補救與溝通（Remediation and Communication）

補救措施可能需要重新訓練（若為資料根本原因）、重新微調（若為模型根本原因）、更新系統 prompt 或 prompt 範本（若為 prompt 根本原因），或重新設定護欄。溝通是獨立的工作流——依據 GDPR 第 33 條，個人資料外洩必須在 72 小時內通知主管機關；EU AI Act 也對高風險 AI 系統引入了事故通報義務。你的事故回應劇本必須包含法務與 DPO 的介入時間點。台灣方面，個資法第 22 條及主管機關（如金管會）的相關規定，也要求在個資事故發生後向當事人及主管機關通報。

事後檢討（Post-Incident Review）

事後檢討回饋到模型風險管理中：風險評分可能提高、審批關卡可能收緊、負責任 AI 政策可能新增禁止的應用案例。稽核員期望看到治理委員會在約定的 SLA 時限內審查每一件重大事故的佐證。

跨 AI 技術堆疊組合 CloudTrail、Config 與 Audit Manager

AWS 稽核三件組——CloudTrail、Config、Audit Manager——支撐著你向稽核員或主管機關所做的每一項聲明。理解它們如何在 AI 技術堆疊中組合運作，是考試的常見考點。

AWS CloudTrail 用於 AI 工作負載

CloudTrail 記錄每一個變更或使用 AI 資源的 API 呼叫。管理事件（Management Events）涵蓋 Bedrock 的 IAM 授權、SageMaker 端點建立，以及 Bedrock Guardrails 更新。資料事件（Data Events，需手動啟用，資料量較大）涵蓋個別模型呼叫——Bedrock 的 InvokeModel、SageMaker 的 InvokeEndpoint、傳送至 Amazon Comprehend 或 Amazon Rekognition 的內容。啟用資料事件才能進行逐次呼叫的鑑識分析；停用資料事件會讓你只能看到誰設定了模型，卻看不到誰使用了模型。

AWS Config 用於 AI 工作負載

Config 追蹤設定狀態（configuration state）與設定歷程（configuration history）。對 AI 工作負載而言，關注的資源類型包括 AWS::SageMaker::Endpoint、AWS::SageMaker::Model、AWS::SageMaker::NotebookInstance，以及 Bedrock 資源（於 Config 涵蓋範圍內）。Config 規則可強制執行政策——例如，要求每個 SageMaker 端點必須附加 VPC 設定，或每個 Bedrock 知識庫必須使用客戶自管的 KMS 金鑰。合規套件（Conformance Packs）將數十條此類規則與 NIST 800-53 或 HIPAA 等框架對齊，打包成套應用。

AWS Audit Manager 用於 AI 工作負載

AWS Audit Manager 持續從 CloudTrail、Config、Security Hub 及手動上傳中收集證據，然後將這些證據對應到框架中的控制措施。AWS 發布了預建框架（SOC 2、PCI DSS、HIPAA、GDPR、ISO 27001、NIST CSF），你也可以建置對齊 NIST AI RMF 或 ISO/IEC 42001 的自訂框架。輸出是適合外部稽核員使用的評估報告——實質上是將持續遙測轉化為帶有簽名的 PDF 文件。

AWS Artifact 用於 AI 工作負載

AWS Artifact 發布 AWS 自身經外部稽核的合規報告（SOC 1/2/3、ISO 27001、ISO 27017、ISO 27018、PCI DSS、FedRAMP）以及法律協議（HIPAA BAA、GDPR DPA）。Artifact 本身不會讓你的 AI 工作負載合規，但它讓你能夠繼承 AWS 基礎設施層的控制措施，並簽署用於觸發法律切換的協議——例如，在 Bedrock 或 SageMaker 上儲存 PHI 之前必須簽署的 HIPAA BAA。

組合方式 — 稽核鏈（Audit Chain）

審查高風險 AI 系統的稽核員通常會問一連串問題。「模型是否已獲審批？」——SageMaker Model Registry 審批狀態，加上治理委員會會議記錄。「它是以什麼資料訓練的？」——SageMaker Lineage 加上 AWS Glue Data Catalog 加上 Macie 發現結果。「誰一直在呼叫它？」——CloudTrail 資料事件。「它的設定是否仍與審批時一致？」——AWS Config 歷程。「請給我對應到 ISO 27001 控制措施 A.8.1.1 的證據。」——AWS Audit Manager 評估報告。「AWS 本身是否已獲認證？」——AWS Artifact SOC 2 報告。每個問題都有答案，因為每一層從一開始就已接線配置。

AI 安全合規治理與相鄰主題的區分

本 Hub 與幾個相鄰主題有交集，需要保持邊界清晰。

Hub 對比 AI 威脅模型（5.1）

本 Hub 架構邊界與外部法規。AI 威脅模型與攻擊類型 子主題則列舉具體攻擊——prompt injection、越獄（jailbreaking）、模型逆向攻擊（model inversion）、資料投毒（data poisoning）、對抗性範例（adversarial examples）。描述攻擊技術的考題屬於威脅模型主題；涉及法規或計畫回應的考題屬於本 Hub。

Hub 對比 IAM 與 Bedrock 安全性（5.1）

IAM 與 Bedrock 安全性 負責身分識別與網路邊界的配管：IAM 政策、Bedrock 資源政策、VPC 端點、KMS 金鑰。本 Hub 負責這些基礎元件如何服務更大的治理計畫。

Hub 對比 Bedrock Guardrails（5.1）

Bedrock Guardrails 與控制措施 負責模型輸出邊界——內容過濾、拒絕主題、PII 遮蔽、接地性檢查。本 Hub 負責護欄如何融入受監管計畫（EU AI Act 高風險系統的強制要求、對應到 ISO/IEC 42001 操作控制措施）。

Hub 對比資料治理（5.2）

資料治理與 PII 負責資料邊界的配管：Macie、Glue Data Catalog、血緣追溯、PII 偵測、訓練資料品質。本 Hub 負責消費這些訊號的法規與計畫層（GDPR 義務、模型風險管理、事故回應）。

Hub 對比負責任 AI 原則（4.1）

負責任 AI 原則 在設計層面負責 AWS 七大支柱（公平性、可解釋性、隱私、安全、可控性、正確性、治理）。本 Hub 在操作層面將治理支柱具體化——委員會、政策、風險管理、事故回應。

Hub 對比透明度與可解釋性（4.2）

透明度與可解釋性 涵蓋技術區分與工具（SageMaker Clarify、A2I、Model Cards）。本 Hub 將這些工具作為支持 GDPR 第 22 條、EU AI Act 人工監督義務，以及 ISO/IEC 42001 文件記錄控制措施的佐證。

關鍵數字與必記事實

AIF-C01 在 D5 不要求精確的數字記憶，但有幾個錨點在情境題中反覆出現。

• EU AI Act 定義四個風險等級：不可接受、高風險、有限風險、最小風險。
• NIST AI RMF 有四個核心功能：Govern、Map、Measure、Manage。
• ISO/IEC 42001:2023 是第一個可認證的 AI 管理系統標準。
• GDPR 向主管機關的個資外洩通報時限為 72 小時（第 33 條）。
• CloudTrail 在 Event History 免費保存 90 天的管理事件；資料事件需要明確建立追蹤記錄（trail）。
• Bedrock Guardrails 同時在輸入與輸出端套用——雙層過濾。
• SageMaker Model Registry 審批狀態：Approved、Rejected、PendingManualApproval。
• AWS 支援 140 個以上的合規計畫；完整清單請參閱 AWS Compliance Programs 頁面。

常見考試陷阱

除了前述 CloudTrail/Config/Audit Manager 陷阱，還有幾個 D5 的混淆點讓考生頻繁失分。

AWS 合規 vs 客戶合規

AWS Artifact 發布的是 AWS 基礎設施的稽核報告。它不會讓你的 AI 應用程式合規。你仍然負責 IAM、加密選擇、護欄、訓練資料治理和模型文件。考試反覆測試這個繼承邊界（inheritance boundary）。

NIST AI RMF vs NIST Cybersecurity Framework

兩者都由 NIST 發布，都使用「framework」一詞，但它們是使用不同功能名稱的不同文件。AI RMF 使用 Govern/Map/Measure/Manage；CSF 使用 Identify/Protect/Detect/Respond/Recover。涉及 AI 風險的考題對應 AI RMF；通用資安考題對應 CSF。

EU AI Act vs GDPR

GDPR 針對個人資料的處理，無論是否涉及 AI。EU AI Act 針對 AI 系統，無論是否涉及個人資料。當 AI 系統處理個人資料時，兩者同時適用——這是一個常見的陷阱答案，其中一個被混用來取代另一個。

治理委員會 vs 技術控制措施

「如何確保高風險模型在部署前獲得審批？」有治理答案（委員會 ＋ 審批關卡）和技術支援手段（SageMaker Model Registry 審批狀態）。考試通常期望組合答案——委員會決策，技術執行。

ISO/IEC 42001 vs ISO 27001

ISO 27001 是資訊安全管理標準；ISO/IEC 42001 是 AI 管理標準。兩者疊加而非替代——認真的 AI 供應商通常同時持有兩項認證。

AI 事故 vs 傳統資安事故

有偏差的輸出、prompt injection，或幻覺答案，即使沒有資料被匯出、沒有憑證被竊取，也是 AI 事故。事故回應劇本必須涵蓋這些情境；單靠 GuardDuty 是不夠的。

練習題連結 — 任務 5.2 對應練習

AIF-C01 考試在 AI 安全合規治理主題上，預期會出現以下類型的考題。

1. 「一家公司正在為歐盟市場建置招募推薦 AI，請問適用哪個框架？」答：EU AI Act（招募屬於高風險）加上 GDPR（處理個人資料）。
2. 「哪個 AWS 服務能持續收集對應到合規框架的 AI 工作負載證據？」答：AWS Audit Manager。
3. 「稽核員想知道上週二是誰呼叫了特定的 Bedrock 模型。」答：CloudTrail 資料事件。
4. 「一家公司需要證明其 AI 管理系統已通過國際標準的外部認證。」答：ISO/IEC 42001。
5. 「在 SageMaker 訓練任務中儲存 PHI 之前，需要簽署哪份 AWS 文件？」答：透過 AWS Artifact 簽署 HIPAA Business Associate Addendum。
6. 「公司如何確保微調後的模型在未獲高層主管簽核的情況下無法到達生產端點？」答：在 Pipelines 關卡中使用帶有 PendingManualApproval 狀態的 SageMaker Model Registry，加上治理委員會。
7. 「哪個框架圍繞 Govern、Map、Measure、Manage 來組織 AI 風險？」答：NIST AI Risk Management Framework。
8. 「在生產環境 LLM 中發現有偏差的輸出。事故回應鑑識鏈中的第一個 AWS 服務是什麼？」答：CloudTrail（誰呼叫了、何時呼叫）加上 SageMaker Model Monitor 警報（偏差飄移）。

常見問題 — AI 安全合規治理熱門問答

Q1. EU AI Act 和 GDPR 是同一件事嗎？

不是。GDPR（2016/679）管轄歐盟居民個人資料的處理，無論是否涉及 AI。EU AI Act（2024）管轄在歐盟市場上市的 AI 系統，無論是否涉及個人資料。兩者疊加：處理歐盟個人資料的 AI 系統必須同時遵守兩者。GDPR 驅動 PII 處理、同意書，以及解釋權等議題；EU AI Act 驅動基於風險的分級、合規評估、記錄保存，以及人工監督義務。在 AWS 上，GDPR 義務通常透過 Macie、Comprehend PII 偵測、Bedrock Guardrails PII 遮蔽，以及 AWS Artifact 中的 AWS GDPR Data Processing Addendum 來解決；EU AI Act 義務則額外要求 SageMaker Model Cards、A2I 人工監督，以及 Audit Manager 持續蒐集證據。

Q2. 在 AWS 上部署 AI 需要取得 ISO/IEC 42001 認證嗎？

不需要。ISO/IEC 42001 是自願性認證，用來展示你的組織具有成熟的 AI 管理系統。AWS 本身正在推進多項 AI 相關認證，並在 AWS Artifact 中發布狀態。你自己的認證決定取決於市場需求——歐盟客戶越來越多地要求，且它能強化 EU AI Act 高風險系統合規評估的佐證。對 AIF-C01 考試而言，將 ISO/IEC 42001 認識為可認證的 AI 管理系統標準，並將其與自願性的 NIST AI RMF 區分開來。

Q3. AI 治理委員會每週實際上在做什麼？

成熟的 AI 治理委員會每週通常審查新 AI 應用案例申請表、審批或拒絕待部署的模型、審查上週的事故報告、在出現新風險時更新負責任 AI 政策，並對第三方基礎模型的新增進行核准。在 AWS 上，委員會的核准在技術層面表現為 SageMaker Model Registry 狀態變更、AWS Organizations 中的 SCP 更新、AWS Config 規則調整，以及 Bedrock Guardrail 設定變更。稽核員將委員會會議記錄作為主動治理的主要佐證。

Q4. CloudTrail 與 Audit Manager 在 AI 合規中有何不同？

CloudTrail 是原始的 API 呼叫日誌——每個資源上的每個動作，逐事件捕捉。Audit Manager 是更高層次的服務，它消費 CloudTrail（以及 Config、Security Hub 和手動上傳），並將發現結果對應到合規框架中的控制措施（SOC 2、HIPAA、ISO、NIST）。你使用 CloudTrail 進行鑑識（「誰呼叫了這個模型」），使用 Audit Manager 進行合規報告（「這是我們 SOC 2 控制措施 CC6.1 的佐證」）。兩者相輔相成——沒有 CloudTrail 的 Audit Manager 沒有原始資料；沒有 Audit Manager 的 CloudTrail 需要手動進行證據映射。

Q5. 什麼是 AI 事故，何時必須對外通報？

AI 事故是 AI 系統造成或接近造成損害的任何事件——影響受保護族群的有偏差輸出、導致客戶誤入歧途的幻覺建議、洩漏機密背景的 prompt injection，或模型飄移導致準確率低於約定閾值。對外通報義務視管轄區和事故類型而定。依據 GDPR，個人資料外洩必須在 72 小時內通知主管機關（第 33 條），當存在高風險時應不延遲地通知受影響的資料主體。依據 EU AI Act，高風險 AI 系統的提供者必須向主管的國家機關通報嚴重事故。各部門主管機關也有其規定（FDA 針對醫療 AI、FINRA 針對投資 AI）。台灣《個資法》亦要求個資外洩事故須向主管機關及當事人通報。你的內部事故回應劇本必須編入這些觸發條件，並從偵測環節起就讓法務與 DPO 介入。

Q6. 我可以將 AWS Control Tower 護欄用作 EU AI Act 合規佐證嗎？

部分可以。AWS Control Tower 強制性護欄（例如，禁止變更 CloudTrail）建立了 EU AI Act 高風險系統所需的基礎記錄與治理姿態。但單靠 Control Tower 護欄並不能滿足訓練資料品質、模型文件、人工監督或合規評估等 AI 專屬義務。將 Control Tower 視為 AWS 上 AI 安全合規治理的強固基礎，並在其上疊加 AI 專屬控制措施（Bedrock Guardrails、SageMaker Clarify、Model Cards、Audit Manager AI 證據）。

Q7. 如何處理 Amazon Bedrock 上的第三方基礎模型風險？

三個步驟。第一，透過 IAM 限制——將 bedrock:InvokeModel 範疇限縮至治理委員會已核准的特定模型識別碼。第二，在供應商內建安全訓練之上疊加 Bedrock Guardrails，以強制執行你的組織內容政策。第三，在清冊中記錄模型，包含供應商、版本、訓練截止日期、AWS AI Service Card 參考資料，以及核准日期；當供應商更新模型版本時，將其重新路由回審批關卡。Bedrock 模型的溯源也意味著認識到：AWS 本身不訓練第三方模型——Anthropic、Meta、Mistral、Stability 和 Cohere 才是——因此你的供應鏈盡職調查延伸到這些供應商。

延伸閱讀

• AWS Well-Architected Machine Learning Lens: https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/machine-learning-lens.html
• AWS Responsible AI — policies and resources: https://aws.amazon.com/ai/responsible-ai/
• AWS Cloud Adoption Framework for AI/ML/Generative AI: https://docs.aws.amazon.com/whitepapers/latest/aws-caf-for-ai/aws-caf-for-ai.html
• AWS Compliance Programs overview: https://aws.amazon.com/compliance/programs/
• AWS Audit Manager User Guide: https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html
• AWS CloudTrail User Guide: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
• AWS Config Developer Guide: https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html
• AWS Artifact User Guide: https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html
• Amazon Bedrock Security: https://docs.aws.amazon.com/bedrock/latest/userguide/security.html
• Amazon SageMaker Security: https://docs.aws.amazon.com/sagemaker/latest/dg/security.html
• NIST AI Risk Management Framework (AI RMF 1.0): https://www.nist.gov/itl/ai-risk-management-framework
• ISO/IEC 42001:2023 — AI management system: https://www.iso.org/standard/81230.html
• EU Artificial Intelligence Act: https://artificialintelligenceact.eu/
• EU General Data Protection Regulation: https://gdpr-info.eu/
• AWS Certified AI Practitioner Exam Guide (AIF-C01): https://d1.awsstatic.com/training-and-certification/docs-ai-practitioner/AWS-Certified-AI-Practitioner_Exam-Guide.pdf