總結專案:實作 AI 合規框架

建置全面的 AI 合規框架,將安全測試對應至 EU AI Act、NIST AI RMF 與 ISO 42001 等監管要求。

概述

隨著全球 AI 監管加速推進,部署 AI 系統的組織需要一套結構化方式,將其安全測試活動連結到合規要求。EU AI Act 要求對高風險 AI 系統進行基於風險的測試;NIST AI 風險管理框架呼籲持續進行紅隊演練與對抗性測試;ISO 42001 則要求有文件紀錄的風險評估。然而,大多數組織在孤立的情況下執行這些活動——安全測試由一個團隊執行、合規文件由另一個團隊撰寫,兩者鮮少相互連結。

此總結專案要求你建置一套 AI 合規框架,彌合技術紅隊演練與監管合規之間的落差。此框架接收來自 AI 安全工具(Garak、PyRIT、Promptfoo)的輸出,將發現對應至具體監管要求,產出稽核人員可審閱的合規證據。它也能反向運作:給定一項監管要求,決定必須執行哪些安全測試,以及現有測試結果是否提供足夠證據。

這不是一份合規清查表工具——它是一個工程專案,自動化翻譯技術安全發現與監管語言之間的對照,讓合規成為良好安全測試的自然副產品,而不是獨立的文件負擔。

專案需求

功能需求

1. 監管要求資料庫 — 結構化呈現 EU AI Act、NIST AI RMF 與 ISO 42001 的要求,並提供框架間交叉參照。

2. 合規映射引擎 — 將 AI 安全測試結果對應至監管要求。每一映射包含該要求、提供證據的測試、證據強度,以及任何缺口。

3. 風險分類模組 — 依 EU AI Act 的風險分級(不可接受、高風險、有限、最低)對 AI 系統進行分類,並依分類決定所需測試。

4. 證據管理 — 儲存並組織合規證據(測試結果、報告、聲明),具備版本控制與稽核軌跡。

5. 缺口分析 — 找出缺乏充分測試證據的監管要求,並建議填補缺口的具體測試。

6. 報告產出 — 為不同對象(監管機構、稽核員、高階主管、工程團隊)產出合規狀態報告。

實作指引

階段 1:監管要求模型

此階段以 Python 的 dataclass 與 enum 定義結構化資料模型。Framework 列舉三大框架(EU_AI_ACT、NIST_AI_RMF、ISO_42001);RequirementCategory 列舉九類要求(風險管理、測試驗證、透明度、資料治理、人類監督、穩健性安全、問責、文件、監控);EvidenceStrength 列舉證據強度(strong、moderate、weak、none)。

RegulatoryRequirement 資料類別記錄單一要求,包含 req_id(例如 EU-AI-ACT-ART-9.2.a)、所屬框架、條文章節、標題、描述、類別、適用的風險等級、所需證據類型,以及跨框架交叉參照 ID 與測試指引。

RequirementDatabase 聚合所有要求,支援依框架、類別、風險等級查詢,並支援匯出 JSON。build_default_database 函式預先填入 EU AI Act 第 9 條第 2 項(已知風險識別)、第 9 條第 7 項(效能測試)、第 15 條(準確性、穩健性與網路安全);NIST AI RMF 的 MAP 1.1、MEASURE 2.6、MANAGE 2.2;以及 ISO 42001 第 6.1.2 條(AI 風險評估),並設定它們之間的交叉參照。

階段 2:合規映射引擎

此階段建立 TestEvidence 資料類別,記錄測試證據的 ID、來源工具(garak、pyrit、promptfoo、manual)、測試名稱、日期、結果摘要、發現數量、嚴重度分布、通過率等。ComplianceMapping 則將一筆證據對應至一項要求,記錄強度、缺口描述與建議。

ComplianceMappingEngine 類別設有 TOOL_CATEGORY_MAP,宣告每項工具能滿足哪些要求類別(例如 Garak 可涵蓋測試驗證、穩健性、風險管理);另有 STRENGTH_THRESHOLDS 依通過率決定證據強度(≥90% 為 strong、≥70% 為 moderate、≥50% 為 weak)。

核心方法 map_evidence 將單筆證據對應至所有適用要求;_assess_evidence_strength 檢查證據類型是否相符,再依通過率指派強度;gap_analysis 接收全部證據,為每項要求建立最佳強度,最後找出強度為 none 或 weak 的缺口並回傳建議測試。

階段 3:風險分類模組

此階段依 EU AI Act 的四層風險等級(UNACCEPTABLE、HIGH、LIMITED、MINIMAL)對 AI 系統分類。AISystemProfile 記錄系統名稱、描述、應用領域、能力清單、部署脈絡、處理的資料類型、自主等級、受影響人數規模與可逆性。ClassificationResult 回傳風險等級、理由、適用要求、強制測試項目與文件要求。

EUAIActClassifier 定義 HIGH_RISK_DOMAINS(如生物辨識、關鍵基礎設施、教育職訓、就業、基本服務、執法、移民庇護、司法民主)與 UNACCEPTABLE_CAPABILITIES(社會評分、即時大規模生物辨識監控、潛意識操控、弱勢群體剝削)。

classify 方法依序檢查:

• 若能力包含不可接受項目 → 回傳 UNACCEPTABLE;
• 若領域屬於高風險、進行非諮詢性的自主決策、處理健康或生物辨識資料、動作不可逆 → 回傳 HIGH,並附上適用要求 ID 與強制測試(對抗性穩健性、安全分類、偏誤公平、資料隱私、安全滲透測試)與文件要求(風險管理系統、技術文件、符合性評估、EU 合格聲明、品質管理系統);
• 若為面向客戶的系統 → 回傳 LIMITED,附上透明度義務;
• 其他 → 回傳 MINIMAL。

階段 4:合規報告產生器

此階段建立 ComplianceReportGenerator,為不同對象產出報告。建構子接收要求資料庫、映射引擎與分類結果。

executive_report 方法針對高階主管產出報告:彙整所有映射與缺口,計算強勢與中度覆蓋率,產出包含:

• 系統名稱與報告日期、風險分類;
• 執行摘要(合規覆蓋百分比、各強度證據數量、缺口總數);
• 分類理由列表;
• 缺口表格(要求、框架、缺口、建議行動);
• 強制測試檢查清單,以 [x] 與 [ ] 標示完成狀態。

auditor_report 方法則為稽核員產出詳盡版:列出證據清單表格(ID、工具、測試、日期、通過率、發現數),並以逐項要求(req-by-req)展開,顯示框架、類別、最佳證據強度、要求描述,以及支援證據列表。

評估標準

延伸目標

• 新增產業專屬法規支援(醫療 AI 的 FDA 指引、金融服務 AI 法規)。
• 建置合規儀表板,以熱區圖視覺化跨框架覆蓋情況。
• 實作從 CI/CD 流程自動收集證據(自動拉取 Garak/Promptfoo 結果)。
• 新增監管變更追蹤器,監控框架更新並標示受影響的要求。

參考資料

• European Parliament. (2024). "Regulation (EU) 2024/1689 — Artificial Intelligence Act." https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• NIST. (2023). "AI Risk Management Framework (AI RMF 1.0)." https://doi.org/10.6028/NIST.AI.100-1
• ISO/IEC. (2023). "ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system." https://www.iso.org/standard/81230.html