AI 治理教學手冊（AI Governance Handbook）

版本：v5.0
適用對象：管理團隊 + 開發團隊
最後更新：2026-07-16
分類：企業內部標準文件（技術白皮書等級）
文件編號：GOV-AI-001
機密等級：內部使用

版本歷程

目錄

• 法規與標準對照表
• 1. AI 治理總體架構（Governance Framework）
  • 1.1 AI 治理目標
  • 1.2 三道防線（Three Lines of Defense）
  • 1.3 AI 風險分類
  • 1.4 與 IT Governance / Data Governance 關聯
• 2. AI 在 SSDLC 各階段治理
  • 2.0 SSDLC 全景圖
  • 2.1 Requirement（需求階段）
  • 2.2 Design（設計階段）
  • 2.3 Development（開發階段）— AI Coding
  • 2.4 Testing（測試階段）
  • 2.5 Deployment（部署階段）
  • 2.6 Maintenance（維護階段）
• 3. AI Coding 工具治理
  • 3.1 工具對照與管理
  • 3.2 Prompt 管理（Prompt Governance）
  • 3.3 輸出驗證（Output Validation）
  • 3.4 Code Review 政策
  • 3.5 禁止事項
  • 3.6 AI Hallucination 控制
• 4. 公司 AI 治理章程（Policy）
  • 4.1 AI 使用政策
  • 4.2 AI 開發規範
  • 4.3 資料使用規範
  • 4.4 模型使用規範
  • 4.5 第三方 AI 管理
• 5. 標準作業程序（SOP）
  • 5.1 AI 開發流程 SOP
  • 5.2 Prompt 使用 SOP
  • 5.3 AI Code Review SOP
  • 5.4 AI 產出驗證 SOP
  • 5.5 AI 事件通報 SOP
• 6. 驗證與稽核機制（Validation & Audit）
  • 6.1 AI 產出驗證方法（Test Strategy）
  • 6.2 安全掃描（SAST / DAST）
  • 6.3 AI 風險評估
  • 6.4 稽核流程（Audit Checklist）
  • 6.5 Logging & Traceability
• 7. AI 風險管理（Risk Management）
  • 7.1 風險總覽
  • 7.2 各風險詳細分析與控制
• 8. 技術落地架構（Architecture）
  • 8.1 AI Gateway 架構
  • 8.2 Prompt Registry 設計
  • 8.3 Audit Log 系統
  • 8.4 Secure Proxy 設計
  • 8.5 DevSecOps 整合
• 9. 管理層決策建議（Executive Guide）
  • 9.1 KPI / KRI
  • 9.2 AI 成本控管
  • 9.3 導入策略（Phase 1~3）
  • 9.4 組織設計（AI Governance Team）
• 10. 生成式 AI 治理專章（Generative AI Governance）
  • 10.1 生成式 AI 風險特論
  • 10.2 大型語言模型（LLM）使用規範
  • 10.3 AI Agent 與自動化工作流治理
  • 10.4 生成式 AI 倫理框架
• 11. 附錄（Templates）
  • 11.1 AI 使用申請表
  • 11.2 Prompt Template 範例
  • 11.3 AI Risk Assessment 表
  • 11.4 Code Review Checklist（AI 產出專用）
• 12. AI 素養與教育訓練體系（AI Literacy & Training）
  • 12.1 AI 素養框架
  • 12.2 分層培訓體系
  • 12.3 培訓成效評估
• 13. 跨境資料傳輸與多法域合規（Cross-border & Multi-jurisdiction）
  • 13.1 跨境資料傳輸治理
  • 13.2 多法域合規矩陣
  • 13.3 國際合作與互認機制
• 檢查清單（Checklist）

法規與標準對照表

台灣法規

國際法規與標準

1. AI 治理總體架構（Governance Framework）

1.1 AI 治理目標

本公司 AI 治理制度之目標：

1. 合規性：符合台灣《人工智慧基本法》、金管會 AI 核心原則、《個人資料保護法》、《資通安全管理法》及 ISO/IEC 42001 等國際標準
2. 安全性：確保 AI 輔助開發不引入安全漏洞、不洩漏敏感資料，符合 OWASP Top 10 與企業資安基線
3. 品質性：AI 產出經多層驗證，符合企業程式碼品質標準與架構規範
4. 可追溯性：所有 AI 使用行為可稽核、可追蹤，滿足主管機關檢查要求
5. 效率性：在治理框架下最大化 AI 開發效益，提升團隊生產力
6. 倫理性：遵循以人為本、公平無偏見、透明可解釋之倫理原則，呼應 UNESCO AI 倫理建議書精神
7. 永續性：建立持續改善機制，確保 AI 治理框架隨技術演進與法規更新而迭代

治理原則

台灣《人工智慧基本法》七大基本原則

台灣《人工智慧基本法》於 2025 年 12 月 23 日經立法院三讀通過，2026 年 1 月 14 日總統公布施行，為我國首部 AI 專法。本法確立政府推動 AI 之七大基本原則，並明定治理分工：國科會為中央主管機關、行政院已於 2026 年 5 月 21 日由行政院長卓榮泰親自召集正式成立「國家 AI 戰略特別委員會」統籌跨部會協調（成員涵蓋學者、產業、公民團體代表、部會首長與地方首長），並將由國科會據以研擬《國家人工智慧發展綱領》提委員會審議、數位發展部負責研議「AI 風險分類框架」（已於 2026 年 3 月發布，採應用盤點 → 風險辨識 → 風險評估 → 風險應變之四步驟流程，詳見前述法規對照表）與資料治理機制、各目的事業主管機關就其領域進行法規調適。法案明定 2 年落日條款：各主管機關須於施行後 2 年內完成對應子法訂修，企業應據此規劃中長期合規時程。企業應以七大原則作為內部 AI 治理政策之對齊基準：

法規追蹤重點：本法為「基本法」性質，具體義務由風險分類框架與各部會子法落實，2 年落日條款到期日為 2028 年 1 月 14 日。企業應持續追蹤數位發展部風險分類框架後續修正，以及所屬產業主管機關（如金管會研議中之代理式 AI 指引修訂，見前述法規對照表，現階段尚未定案）之發布進度，並預留政策調整彈性。

金管會「金融業運用AI核心原則」六大核心原則

金管會於 2023 年 10 月發布「金融業運用AI核心原則與相關推動政策」，揭示六大核心原則與八項配套政策；並於 2024 年 6 月 20 日正式發布「金融業運用人工智慧（AI）指引」，將核心原則展開為可操作之遵循文件，適用於銀行、證券、保險等金融機構，構成金融業 AI 治理「核心原則 → 指引 → 公會自律規範」三層規範體系：

「金融業運用 AI 指引」（2024/6）之操作性要求重點：

1. 治理與問責：董事會與高階管理階層對 AI 運用負最終責任，應核定 AI 運用策略與風險管理機制，並指定專責單位統籌
2. 生命週期風險管理：依 AI 系統之規劃、設計、開發、驗證、部署、監控至退場之全生命週期建立風險管控，風險程度愈高、管控強度愈高（風險基礎方法）
3. 第三方與委外管理：使用外部 AI 服務（含生成式 AI）時，應評估供應商之資安、隱私與模型風險，並確保責任不因委外而移轉
4. 透明性與客戶權益：對客戶揭露 AI 參與程度、提供申訴與人工介入管道，重大自動化決策應可解釋
5. 公會自律規範：金管會責成各金融業公會依指引訂定自律規範與最佳實務守則，金融機構應同步遵循所屬公會規範

本手冊第 4 章（Policy）、第 6 章（驗證與稽核）、第 7 章（風險管理）之設計均已對應上述指引要求；非金融業企業亦可將其作為自主治理之參考基準。

ISO/IEC 42001:2023 AIMS 核心要求

ISO/IEC 42001 是全球首個 AI 管理系統（AIMS）國際標準，於 2023 年 12 月正式發布。企業可依此標準建立、實施、維護並持續改善 AI 管理系統，並取得第三方認證。2025 年起本標準家族進一步完備：ISO/IEC 42005:2025 提供 AI 系統影響評估方法論（對應條款 6 之風險與影響評估要求，詳見第 6.3 節）、ISO/IEC 42006:2025 規範驗證機構之能力要求（企業選擇認證機構時應確認其符合本標準），形成「管理系統建置 → 影響評估 → 第三方驗證」的完整標準包：

1.2 三道防線（Three Lines of Defense）

graph LR
    A[第一道防線<br/>開發團隊] --> B[第二道防線<br/>風險管理/合規]
    B --> C[第三道防線<br/>內部稽核]
    
    A1[AI 使用者自律<br/>Code Review<br/>Prompt 規範遵循] --> A
    B1[AI Risk Assessment<br/>Policy 制定<br/>合規監控] --> B
    C1[獨立稽核<br/>AI Audit<br/>改善建議] --> C

第一道防線：開發團隊（業務單位）

• 職責：日常 AI 使用遵循規範
• 控制措施：
  • 遵循 Prompt 使用 SOP
  • 執行 AI 產出 Code Review
  • 不輸入敏感資料至 AI 工具
  • 記錄 AI 使用日誌

第二道防線：風險管理 / 合規部門

• 職責：制定政策、監控風險
• 控制措施：
  • 制定 AI 使用政策與規範
  • 執行 AI 風險評估
  • 監控 AI 使用合規狀態
  • 管理第三方 AI 供應商

第三道防線：內部稽核

• 職責：獨立驗證治理有效性
• 控制措施：
  • 定期稽核 AI 使用紀錄
  • 驗證控制措施有效性
  • 出具稽核報告與改善建議
  • 向董事會/管理層報告

1.3 AI 風險分類

EU AI Act 風險分級對照（Regulation 2024/1689，含 2026 年 Digital Omnibus 修正）

EU AI Act 已於 2024 年 8 月 1 日正式生效，建立全球首個全面性 AI 監管框架；歐盟委員會於 2025 年 2 月發布《禁止 AI 實踐指南》與《AI 系統定義指南》協助理解法規範圍。2026 年上半年歐盟完成「Digital Omnibus on AI」修正案立法程序（5 月 7 日理事會與歐洲議會達成臨時協議、6 月 16 日歐洲議會通過、6 月 29 日理事會最終批准），為 AI Act 通過後首次修正：高風險義務時程大幅展延、部分透明度子義務調整、並新增二項禁止實踐。修正案須待《歐盟官方公報》正式刊登後始生效力（預計於理事會批准後數週內公告），本節時程以立法程序確定之生效日為準。以下為修正後之風險分級制度與企業對照：

企業行動建議：即使營運範圍不在歐盟，EU AI Act 具域外效力（Article 2(1)），若 AI 系統之輸出在歐盟境內使用，仍可能受規範。Digital Omnibus 的時程展延是「給予準備時間」而非「降低要求」——高風險義務之實質內容未變。特別提醒：第 50 條透明度義務之主要規定（AI 互動告知、深偽內容標示）仍自 2026 年 8 月 2 日生效，僅既有系統之機器可讀標記/浮水印技術性子義務展延至 12 月，切勿誤植為透明度義務全面延後而延遲準備。建議企業維持原有差距分析與合規建置節奏，將高風險義務之展延期間用於完善技術文件、FRIA 與品質管理系統；使用 LLM 之場景應對照 GPAI Code of Practice 三章檢視供應商合規狀態。

企業內部 AI 風險分級

結合 EU AI Act 與金管會指引，建立企業三級風險分類：

風險分類決策樹

flowchart TD
    A[AI 使用申請] --> B{是否涉及客戶資料?}
    B -->|是| C{是否影響客戶權益決策?}
    B -->|否| D{是否涉及核心業務邏輯?}
    C -->|是| E[高風險]
    C -->|否| F[中風險]
    D -->|是| F
    D -->|否| G{是否涉及生產環境?}
    G -->|是| F
    G -->|否| H[低風險]
    
    E --> I[AI 委員會審核]
    F --> J[主管審核 + 強化 Review]
    H --> K[自我管理 + 基本規範]

1.4 與 IT Governance / Data Governance 關聯

graph TB
    subgraph 企業治理
        CG[Corporate Governance]
    end
    
    subgraph IT治理
        ITG[IT Governance]
        ISMS[ISMS ISO 27001]
        SDLC[SSDLC]
    end
    
    subgraph 資料治理
        DG[Data Governance]
        DQ[Data Quality]
        DP[Data Privacy]
    end
    
    subgraph AI治理
        AIG[AI Governance]
        AIP[AI Policy]
        AIR[AI Risk Mgmt]
        AIA[AI Audit]
    end
    
    CG --> ITG
    CG --> DG
    CG --> AIG
    ITG --> AIG
    DG --> AIG
    ISMS --> AIR
    SDLC --> AIP
    DP --> AIP

關鍵整合點：

與國際標準對齊

graph LR
    subgraph 企業AI治理框架
        POLICY[AI治理政策]
        RISK[AI風險管理]
        AUDIT[AI稽核]
    end
    
    subgraph 國際標準
        ISO42001[ISO/IEC 42001<br/>AI管理系統]
        NISTRM[NIST AI RMF<br/>風險管理]
        EUAI[EU AI Act<br/>法規遵循]
    end
    
    POLICY --> ISO42001
    RISK --> NISTRM
    AUDIT --> EUAI
    ISO42001 --> NISTRM
    NISTRM --> EUAI

NIST AI RMF 1.0 四大核心功能對應：

NIST AI 600-1 生成式 AI 風險概覽（2024 年 7 月發布）：

針對生成式 AI 獨有的 12 類風險進行分類，與本手冊第 10 章對應：

NIST 2025-2026 發展動態：

• 政策環境轉變：美國於 2025 年 1 月以 EO 14179 取代原 EO 14110，並於 2025 年 7 月發布「America’s AI Action Plan」，指示 NIST 修訂 AI RMF（移除錯誤資訊、DEI 與氣候變遷之引用），政策重心轉向創新加速；企業引用 AI RMF 時應留意後續修訂版本之差異
• Cyber AI Profile（NIST IR 8596）：2025 年 12 月公開徵詢初稿，將 AI 相關風險整合入網路安全框架（CSF 2.0），涵蓋「以 AI 防禦」「防禦 AI 系統」「防禦 AI 賦能之攻擊」三大面向，為 AI 與資安治理整合之重要參考（對應本手冊第 6.2、8 章）
• 關鍵基礎設施 Profile：2026 年 4 月發布 AI RMF 關鍵基礎設施應用概念文件，特定產業（能源、金融、通訊）可預期後續產業別指引

📋 實務案例

案例：某金融機構開發團隊使用 GitHub Copilot 撰寫交易系統 API，未經審核直接將 AI 產出的程式碼提交，導致 SQL Injection 漏洞進入生產環境。

教訓：

1. AI 產出程式碼必須經過與人工撰寫相同等級的 Code Review
2. 涉及交易系統屬「高風險」，需額外安全掃描
3. 需建立 AI 使用追溯機制，事後可追查問題來源

2. AI 在 SSDLC 各階段治理

2.0 SSDLC 全景圖

graph LR
    R[Requirement] --> D[Design]
    D --> Dev[Development]
    Dev --> T[Testing]
    T --> Dep[Deployment]
    Dep --> M[Maintenance]
    
    R --- RG[Gate: 需求審查]
    D --- DG[Gate: 設計審查]
    Dev --- DevG[Gate: Code Review]
    T --- TG[Gate: 測試通過]
    Dep --- DepG[Gate: 上線審核]
    M --- MG[Gate: 變更管理]

每個階段的 AI 治理遵循統一框架：

┌─────────────────────────────────────────┐
│  AI 使用方式 → 風險識別 → 控制措施     │
│  → 審核點（Gate）→ 產出文件（Artifact） │
└─────────────────────────────────────────┘

2.1 Requirement（需求階段）

AI 使用方式

風險

• AI 可能產出不完整或錯誤的需求（Hallucination）
• 輸入舊系統程式碼可能包含敏感業務邏輯
• AI 產出可能缺乏產業特定知識（如金融法規）

控制措施

1. 需求驗證：AI 產出的需求必須由 BA/SA 逐項驗證
2. 輸入過濾：禁止將含客戶資料的文件直接餵入 AI
3. 交叉比對：AI 產出需與原始需求文件交叉比對
4. 領域知識補充：AI 產出需經具備金融領域知識的人員審核

審核點（Gate）

• AI 產出需求已經 BA/SA 逐項確認
• 未輸入敏感資料至 AI 工具
• 需求文件標註 AI 輔助產出部分
• 通過需求審查會議

產出文件

2.2 Design（設計階段）

AI 使用方式

風險

• AI 可能建議不適合的架構（如過度設計）
• 產出的 Schema 可能有效能問題
• 架構建議可能不符合企業標準

控制措施

1. 架構審查：AI 產出的架構設計需經 SA 審查
2. 標準對照：與企業架構標準（Clean Architecture）對照
3. 效能考量：DB Schema 需經 DBA 審核
4. 安全設計：安全設計需經資安人員確認

審核點（Gate）

• 架構設計通過 SA 審查
• DB Schema 通過 DBA 審核
• 安全設計通過資安審查
• 設計文件標註 AI 輔助產出部分

產出文件

2.3 Development（開發階段）— AI Coding

AI 使用方式

風險

控制措施

1. Prompt 規範：

   ✅ 允許：描述功能需求、提供介面定義
   ❌ 禁止：輸入客戶資料、密碼、API Key、營業秘密

2. Code Review 強化：

   • AI 產出程式碼標記為 [AI-Generated]
   • 需至少一位資深工程師 Review
   • 高風險模組需兩位 Reviewer

3. 自動化檢查：

   # CI Pipeline AI Code Check
   stages:
     - ai-code-scan:
         - SAST (SonarQube)
         - Dependency Check (OWASP)
         - License Check
         - Code Style (Checkstyle)

4. 安全掃描：所有 AI 產出必須通過 SAST/DAST

審核點（Gate）

• AI 產出程式碼通過 Code Review
• SAST 掃描無高/嚴重漏洞
• 通過單元測試（覆蓋率 ≥ 80%）
• 通過 Coding Standard 檢查
• License 合規檢查通過
• AI 使用紀錄已登錄

產出文件

2.4 Testing（測試階段）

AI 使用方式

風險

• AI 產出的測試可能覆蓋不足（只測 Happy Path）
• 測試資料可能不夠邊界值
• AI 可能產出與實作耦合的測試（形同虛設）

控制措施

1. 測試覆蓋率要求：

   • 單元測試：≥ 80%
   • 分支覆蓋率：≥ 70%
   • AI 產出測試需人工補充邊界案例

2. 測試品質審查：

   • 測試是否真正驗證業務邏輯
   • 是否包含負面測試
   • 是否包含邊界值測試

3. 測試資料管控：

   • 禁止使用真實客戶資料
   • AI 產出測試資料需脫敏

審核點（Gate）

• 測試覆蓋率達標
• 含負面測試與邊界值測試
• 測試資料不含敏感資料
• Integration Test 通過
• Performance Test 通過（如適用）

產出文件

2.5 Deployment（部署階段）

AI 使用方式

風險

• AI 產出的部署設定可能有安全配置缺失
• 容器設定可能暴露不必要的 port
• 權限設定可能過於寬鬆

控制措施

1. 部署設定審查：AI 產出的部署設定需經 DevOps 審查
2. 安全基線：對照企業安全基線檢查
3. 最小權限：確認遵循最小權限原則
4. 環境隔離：禁止 AI 直接存取生產環境設定

審核點（Gate）

• 部署設定通過 DevOps 審查
• 安全基線檢查通過
• Staging 環境驗證通過
• 回滾計畫已備妥

2.6 Maintenance（維護階段）

AI 使用方式

風險

• 緊急修復時可能跳過審查流程
• AI 修復可能引入新問題
• 版本升級建議可能不完整

控制措施

1. 緊急變更流程：即使使用 AI 快速修復，仍需事後補審
2. 影響分析：AI 修改需評估影響範圍
3. 回歸測試：所有 AI 修改需通過回歸測試

審核點（Gate）

• Hotfix 通過 Code Review（可事後補審）
• 回歸測試通過
• 變更紀錄已登錄
• 影響分析已完成

📋 實務案例

案例：開發團隊使用 Claude Code 進行 Spring Boot 2 → 3 升級，AI 建議的 Migration 步驟遺漏了 javax → jakarta namespace 變更中的某些 edge case，導致部分模組在 Staging 環境啟動失敗。

教訓：

1. Framework 升級屬「中風險」，需 SA 審核 AI 建議的完整性
2. 需建立升級 Checklist，不可完全依賴 AI
3. 需在 Staging 完整驗證後才進入 Production

3. AI Coding 工具治理

3.1 工具對照與管理

主流 AI 開發工具比較（2026 年更新）

治理提醒：AI 開發工具之模型版本與功能迭代極快（數月甚至數週為週期，如上表 Anthropic/Google 產品線於本次修訂期間即有變動），本表僅供選型參考；治理重點應放在「資料傳輸路徑、Retention 政策、企業管控能力、稽核能力」四項結構性條件，而非特定模型版本。工具清冊應由 AI 治理小組每季覆審一次，避免以過時之模型名稱作為採購或合規判斷依據。

工具選用原則

flowchart TD
    A[選擇 AI 工具] --> B{資料敏感度?}
    B -->|高敏感| C[僅使用企業版<br/>啟用 No Retention]
    B -->|中敏感| D[使用 API 版<br/>透過 Secure Proxy]
    B -->|低敏感| E[可使用標準版<br/>遵循基本規範]
    
    C --> F{是否已通過<br/>資安評估?}
    D --> F
    E --> G[登錄使用紀錄]
    F -->|是| G
    F -->|否| H[提出資安評估申請]

3.2 Prompt 管理（Prompt Governance）

Prompt 分級

Prompt 使用規範

## ✅ 允許的 Prompt 內容

- 功能需求描述（不含客戶資料）
- 公開的技術規格（如 OpenAPI Spec）
- 通用的設計模式討論
- 開源框架使用問題
- 程式碼結構與邏輯問題

## ❌ 禁止的 Prompt 內容

- 客戶姓名、身分證字號、帳號
- 資料庫連線字串、密碼、API Key
- 內部 IP 位址、網路架構圖
- 未公開的營業秘密或商業策略
- 客戶交易資料（即使已部分遮蔽）
- 內部稽核報告或法遵文件

Prompt Template 管理

建立公司內部 Prompt Registry，統一管理常用 Prompt：

# prompt-registry/code-generation/spring-boot-controller.yaml
name: "Spring Boot Controller 產生"
version: "1.0"
risk_level: "Level 2"
template: |
  請產出一個 Spring Boot REST Controller：
  - 資源名稱：{resource_name}
  - 操作：{operations}  # CRUD
  - 驗證：使用 Jakarta Validation
  - 錯誤處理：使用統一例外處理
  - 回傳格式：統一 Response 格式
  
  注意事項：
  - 不使用 Lombok
  - 遵循 Clean Architecture
  - 加入適當的 Log
  
prohibited_inputs:
  - 客戶資料
  - 連線資訊
  - API Key

3.3 輸出驗證（Output Validation）

驗證流程

flowchart TD
    A[AI 產出程式碼] --> B[自動化檢查]
    B --> C{通過?}
    C -->|否| D[退回修改]
    C -->|是| E[人工 Code Review]
    E --> F{通過?}
    F -->|否| D
    F -->|是| G[合併至主分支]
    
    subgraph 自動化檢查
        B1[Compile Check]
        B2[Unit Test]
        B3[SAST Scan]
        B4[Style Check]
        B5[License Check]
    end
    
    B --> B1
    B --> B2
    B --> B3
    B --> B4
    B --> B5

驗證項目清單

AI 產出標記機制

在 Git commit 中標記 AI 輔助：

# Commit Message 格式
git commit -m "[AI-Assisted] feat: 新增訂單查詢 API

Tool: GitHub Copilot
Prompt: 產生訂單查詢 REST API（遵循 Clean Architecture）
Review: @senior-dev-001
Risk-Level: Medium"

3.4 Code Review 政策

AI 產出 Code Review 要求

Code Review Checklist（AI 產出專用）

## AI Code Review 檢查項目

### 安全性
- [ ] 無 SQL Injection 風險（使用 Parameterized Query）
- [ ] 無 XSS 風險（適當 Escape）
- [ ] 無硬編碼密碼/Token
- [ ] 輸入驗證完整
- [ ] 適當的權限檢查

### 正確性
- [ ] 業務邏輯正確（對照需求文件）
- [ ] 邊界條件處理
- [ ] 例外處理適當
- [ ] 無 AI Hallucination（使用不存在的 API）

### 品質
- [ ] 符合 Clean Architecture 分層
- [ ] 命名規範遵循
- [ ] 無重複程式碼
- [ ] 適當的日誌記錄
- [ ] 效能考量（N+1 Query 等）

### 合規
- [ ] 無敏感資料殘留
- [ ] 無授權衝突的程式碼片段
- [ ] AI 使用紀錄已登錄

3.5 禁止事項

絕對禁止清單

情境判斷指引

Q: 可以把資料庫 Schema（不含資料）給 AI 嗎？
A: ✅ 可以，但需移除：
   - 註解中的業務說明（如涉及營業秘密）
   - 欄位名稱若直接暴露敏感資訊需重命名
   
Q: 可以把 Error Log 給 AI 分析嗎？
A: ⚠️ 有條件：
   - 移除所有 IP 位址
   - 移除所有使用者資訊
   - 移除 Token/Session ID
   
Q: 可以讓 AI 存取 git repo 嗎？
A: ⚠️ 有條件：
   - 僅限該專案程式碼
   - 確認 repo 無 secrets（已有 .gitignore）
   - 使用企業版工具（有 data retention policy）

3.6 AI Hallucination 控制

常見 Hallucination 類型

防控措施

1. 編譯即驗證：所有 AI 產出必須通過編譯
2. 測試即驗證：必須有對應的單元測試
3. IDE 輔助：利用 IDE 的即時錯誤提示
4. Reference Check：核對 AI 提及的 API/Library 是否存在
5. 版本鎖定：在 Prompt 中明確指定技術版本

# 在 Prompt 中明確指定版本，減少 Hallucination
prompt_template: |
  技術約束：
  - Java 21
  - Spring Boot 3.2.x
  - Jakarta EE 10
  - JUnit 5.10
  - Maven 3.9
  
  請勿使用：
  - javax.* (已遷移至 jakarta.*)
  - Spring WebMVC 舊版 API
  - 未在 pom.xml 中宣告的相依套件

📋 實務案例

案例：開發者使用 Copilot 產出 Spring Security 設定，AI 使用了 WebSecurityConfigurerAdapter（已在 Spring Security 5.7 廢棄），導致升級後編譯錯誤。

控制措施：

1. 在 Custom Instructions 中明確標註使用版本
2. CI Pipeline 加入 Deprecated API 檢查
3. 建立企業 Prompt Template 包含版本約束

4. 公司 AI 治理章程（Policy）

4.1 AI 使用政策

政策名稱：AI 工具使用管理辦法

發布單位：資訊安全管理委員會
適用範圍：全公司資訊系統開發人員
生效日期：____年____月____日

第一條　目的

為規範本公司人員使用人工智慧（AI）工具進行軟體開發，確保資訊安全、個人資料保護及法規遵循，依據台灣《人工智慧基本法》、金管會「金融業運用 AI 核心原則」、《個人資料保護法》及《資通安全管理法》等法規，特訂定本辦法。

第二條　適用範圍

本辦法適用於本公司所有使用 AI 工具進行軟體開發、維護、測試之人員，包含正式員工、約聘人員及外包廠商。

第三條　核准工具

本公司核准使用之 AI 開發工具如下：

未經核准之 AI 工具一律禁止使用（Shadow AI 禁令）。

第四條　使用原則

1. 人類負責原則：AI 產出之所有程式碼，由提交者負完全責任
2. 最小輸入原則：僅提供完成任務所必要之最少資訊給 AI
3. 驗證原則：所有 AI 產出必須經過驗證方可使用
4. 紀錄原則：AI 使用行為須留存紀錄供稽核

第五條　禁止事項

嚴禁下列行為：

1. 將客戶個人資料輸入任何 AI 工具
2. 將系統密碼、API Key、憑證輸入 AI 工具
3. 將未公開之財務資料、營業秘密輸入 AI 工具
4. 未經 Code Review 直接將 AI 產出部署至生產環境
5. 使用未經核准之 AI 工具
6. 關閉或繞過 AI 安全管控機制

第六條　教育訓練

所有使用 AI 工具之人員，須於使用前完成以下訓練：

1. AI 治理政策說明（2 小時）
2. AI 工具安全使用實務（4 小時）
3. Prompt Engineering 基礎（2 小時）
4. 年度複訓（2 小時/年）

第七條　違規處理

第八條　修訂

本辦法由 AI 治理委員會每年至少檢討一次，必要時隨時修訂。

4.2 AI 開發規範

規範名稱：AI 輔助軟體開發作業規範

一、程式碼品質要求

AI 產出之程式碼須符合以下標準：

quality_gates:
  compilation: "zero_errors"
  unit_test_coverage: ">= 80%"
  branch_coverage: ">= 70%"
  sonarqube_quality_gate: "passed"
  security_vulnerabilities: "zero_critical_high"
  code_smells: "< 5 per class"
  duplicated_lines: "< 3%"

二、版本控制要求

# AI 產出程式碼的 Commit 規範
# Format: [AI-Assisted] <type>: <subject>
# 
# Types: feat, fix, refactor, test, docs
# 
# Body 須包含：
# - Tool: 使用的 AI 工具
# - Risk-Level: High/Medium/Low
# - Verified-By: reviewer ID

# 範例：
git commit -m "[AI-Assisted] feat: 新增客戶查詢 Service

Tool: Claude Code
Risk-Level: Medium
Verified-By: @senior-dev-001
Prompt-ID: PR-2024-0042"

三、分支策略

gitGraph
    commit id: "main"
    branch feature/AI-xxx
    commit id: "AI generated code"
    commit id: "human review fix"
    commit id: "test added"
    checkout main
    merge feature/AI-xxx id: "merged after review"

• AI 產出程式碼須在 feature branch 開發
• 禁止直接 push 至 main/develop branch
• PR 須標記 ai-assisted label

四、文件要求

AI 產出的程式碼需附帶：

1. 對應的單元測試
2. 必要的 JavaDoc
3. 更新相關設計文件（如有變更）

4.3 資料使用規範

資料分級與 AI 使用限制

脫敏處理規則

// 脫敏處理範例 - 將真實資料替換為虛擬資料後再給 AI

// ❌ 禁止：直接將含敏感資料的程式碼給 AI
String sql = "SELECT * FROM CUSTOMER WHERE ID = 'A123456789'";

// ✅ 正確：脫敏後提供
String sql = "SELECT * FROM {TABLE} WHERE ID = :id";
// 然後描述：「請幫我優化這個查詢，TABLE 是客戶表，ID 是主鍵」

4.4 模型使用規範

模型選用原則

模型版本管理

• 新模型版本上線前需經 AI 治理小組評估
• 評估項目：準確度、安全性、合規性、成本
• 重大版本升級需進行 Pilot 測試

模型風險管理生命週期（Model Risk Management, MRM）

隨著金管會「金融業運用人工智慧（AI）指引」明確要求「AI 系統生命週期風險管理」，且業界已出現「以 AI 治理 AI（AI 管 AI）」之監理趨勢，模型使用不應僅止於選型與版本管理，須建立正式的 MRM 生命週期，對應 NIST AI RMF 之 Measure（量測）與 Manage（管理）功能：

與既有制度整合：MRM 生命週期不另建平行審批流程，而是將 3.1（工具選用）、4.5（供應商評估）、6.3（風險評估）、9.1（KPI/KRI）等既有機制串接為一致的模型治理主線；高風險場景（1.3 風險分級）之模型變更應額外觸發 6.3 AI 系統影響評估（AISIA）重新評估。

4.5 第三方 AI 管理

供應商評估清單

OECD 負責任 AI 盡職調查框架（六步驟 RBC Due Diligence）

OECD 於 2026 年 2 月發布「負責任 AI 盡職調查指引」（OECD Due Diligence Guidance for Responsible AI），將「負責任商業行為（Responsible Business Conduct, RBC）」之六步驟盡職調查框架套用於 AI 價值鏈。其核心觀念是：企業對 AI 造成之負面影響的責任，不因採用第三方模型或服務而移轉——無論企業是 AI 的開發者、整合者或使用者，都應在自身於價值鏈中的位置上執行相稱的盡職調查。本手冊將其六步驟對應至既有治理機制如下：

AI 供應鏈盡職調查實務要點：

1. 角色定位：先釐清企業在各 AI 使用場景中的價值鏈角色（模型使用者 vs. 系統整合者 vs. 資料提供者），盡職調查深度與角色影響力相稱
2. 上游穿透：對基礎模型供應商，要求揭露訓練資料政策、安全測試結果（可參照 GPAI Code of Practice 之透明度文件）；無法穿透時應以契約條款與替代控制（如輸出過濾）補強
3. 下游責任：企業將 AI 產出提供給客戶時，即成為下游影響之連結點，需將透明度告知與申訴管道納入產品設計
4. 與既有制度整合：RBC 盡職調查不需另建平行制度，應整合至既有之供應商管理、風險評估與 ISMS 流程中

供應商定期覆審

• 頻率：每年至少一次
• 觸發條件：供應商重大變更、安全事件、法規變動
• 負責單位：AI 治理小組 + 採購部門

供應鏈與第四方風險

企業直接簽約之 AI 工具供應商（第三方）本身往往架構於其他基礎模型供應商之上（例如 IDE 工具內建之模型選項、透過雲端平台轉售之 API），形成「第四方」風險——企業對其缺乏直接契約關係與可見度，卻仍須承擔其資料處理與安全瑕疵之後果：

實務作法：於供應商評估清單（4.5）新增「是否揭露子處理者/底層模型」一項；對無法穿透揭露之工具，以契約條款（如資料使用限制、稽核權）與技術控制（輸出過濾、Secure Proxy）作為替代補償措施，並優先納入 9.3 Phase 3 之供應商年度覆審範圍。

5. 標準作業程序（SOP）

5.1 AI 開發流程 SOP

SOP 編號：AI-SOP-001

flowchart TD
    A[接收開發任務] --> B[評估 AI 風險等級]
    B --> C{風險等級?}
    C -->|高| D[填寫 AI 使用申請表<br/>送 AI 委員會審核]
    C -->|中| E[主管核准]
    C -->|低| F[自行遵循規範]
    D --> G[開始開發]
    E --> G
    F --> G
    G --> H[使用 AI 工具產出程式碼]
    H --> I[自我驗證<br/>編譯+測試+掃描]
    I --> J{通過?}
    J -->|否| H
    J -->|是| K[提交 Code Review]
    K --> L{Review 通過?}
    L -->|否| H
    L -->|是| M[合併至主分支]
    M --> N[登錄 AI 使用紀錄]

作業步驟

5.2 Prompt 使用 SOP

SOP 編號：AI-SOP-002

步驟一：確認 Prompt 內容安全性

檢查清單：
□ 不含客戶個資
□ 不含認證資訊（密碼/Key/Token）
□ 不含未公開財務數據
□ 不含內部網路資訊
□ 敏感欄位已脫敏

步驟二：選擇或建立 Prompt

1. 優先查詢 Prompt Registry 是否有適用範本
2. 若無，依據 Prompt Template 結構撰寫
3. 標明技術版本約束

步驟三：執行並記錄

# AI 使用紀錄格式
record:
  date: "2026-05-06"
  developer: "員工編號"
  project: "專案名稱"
  tool: "GitHub Copilot"
  prompt_id: "PR-2026-0001"  # 若使用 Registry 範本
  prompt_summary: "產出訂單查詢 Service"  # 摘要，不記錄完整 Prompt
  risk_level: "Medium"
  output_verified: true
  reviewer: "@senior-dev-001"

步驟四：驗證 AI 產出

依據「AI 產出驗證 SOP（AI-SOP-004）」執行

5.3 AI Code Review SOP

SOP 編號：AI-SOP-003

目的

確保 AI 產出之程式碼符合安全、品質及合規要求。

適用範圍

所有標記為 [AI-Assisted] 的 Pull Request。

作業流程

flowchart TD
    A[收到 AI-Assisted PR] --> B[確認風險等級]
    B --> C[執行自動化檢查]
    C --> D{自動化通過?}
    D -->|否| E[退回開發者]
    D -->|是| F[人工 Code Review]
    F --> G[逐項檢查 AI Review Checklist]
    G --> H{全部通過?}
    H -->|否| I[標註問題<br/>退回修改]
    H -->|是| J[核准合併]
    J --> K[記錄 Review 結果]

Review 重點（AI 產出特有）

1. Hallucination 檢查：確認使用的 API/Library 確實存在
2. 安全性檢查：AI 常忽略的安全問題（如未驗證輸入）
3. 業務正確性：AI 不理解業務背景的邏輯錯誤
4. 效能問題：AI 常產出的效能隱患（如 N+1 Query）
5. 風格一致性：是否符合專案既有風格

5.4 AI 產出驗證 SOP

SOP 編號：AI-SOP-004

驗證層次

驗證指令範例

# L1: 編譯
mvn compile

# L2: 單元測試 + 覆蓋率
mvn test jacoco:report

# L3: 靜態分析
mvn sonar:sonar

# L4: 安全掃描
mvn org.owasp:dependency-check-maven:check

# L5: 整合測試
mvn verify -P integration-test

5.5 AI 事件通報 SOP

SOP 編號：AI-SOP-005

事件分類

通報流程

flowchart TD
    A[發現 AI 事件] --> B[初步判斷嚴重度]
    B --> C{緊急?}
    C -->|是| D[立即電話通報<br/>資安長 + 直屬主管]
    C -->|否| E[填寫事件通報單]
    D --> F[啟動緊急應變]
    E --> G[AI 治理小組評估]
    F --> H[事件處理]
    G --> H
    H --> I[Root Cause 分析]
    I --> J[改善措施]
    J --> K[結案報告]

通報單內容

incident_report:
  id: "AI-INC-2026-001"
  date: "2026-05-06"
  reporter: "員工編號"
  severity: "高/中/低"
  type: "資料外洩/安全漏洞/合規違反/品質問題"
  description: "事件描述"
  ai_tool: "使用的 AI 工具"
  impact: "影響範圍"
  immediate_action: "已採取的立即措施"
  root_cause: "（事後補填）"
  corrective_action: "（事後補填）"

6. 驗證與稽核機制（Validation & Audit）

6.1 AI 產出驗證方法（Test Strategy）

測試金字塔（含 AI 考量）

graph TB
    subgraph 測試金字塔
        E2E[E2E Test<br/>少量 / 高成本]
        INT[Integration Test<br/>適量 / 中成本]
        UNIT[Unit Test<br/>大量 / 低成本]
    end
    
    subgraph AI特殊驗證
        HAL[Hallucination Check<br/>API/Library 存在性]
        SEC[Security Scan<br/>SAST/DAST]
        PERF[Performance Check<br/>效能基線對比]
    end
    
    UNIT --> INT --> E2E
    HAL --> SEC --> PERF

AI 產出專用測試策略

驗證自動化 Pipeline

# .github/workflows/ai-code-validation.yml
name: AI Code Validation

on:
  pull_request:
    labels: ['ai-assisted']

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Compile Check
        run: mvn compile -q
        
      - name: Unit Test + Coverage
        run: mvn test jacoco:report
        
      - name: Coverage Gate
        run: |
          COVERAGE=$(grep -o 'Total[^%]*%' target/site/jacoco/index.html | grep -o '[0-9]*')
          if [ "$COVERAGE" -lt 80 ]; then
            echo "❌ Coverage $COVERAGE% < 80%"
            exit 1
          fi
          
      - name: SonarQube Scan
        run: mvn sonar:sonar
        
      - name: OWASP Dependency Check
        run: mvn org.owasp:dependency-check-maven:check
        
      - name: License Check
        run: mvn license:check
        
      - name: Checkstyle
        run: mvn checkstyle:check

6.2 安全掃描（SAST / DAST）

SAST（靜態應用安全測試）

DAST（動態應用安全測試）

AI 產出常見安全問題

// ❌ AI 常產出的不安全程式碼

// 1. SQL Injection
String query = "SELECT * FROM users WHERE name = '" + name + "'";

// 2. 未驗證輸入
@PostMapping("/api/order")
public Order createOrder(@RequestBody Order order) {
    return orderService.create(order); // 未驗證
}

// 3. 硬編碼 Secret
private static final String API_KEY = "sk-xxxxx";

// 4. 不安全的反序列化
ObjectInputStream ois = new ObjectInputStream(input);
Object obj = ois.readObject(); // 不安全

// ✅ 正確的做法

// 1. Parameterized Query
@Query("SELECT u FROM User u WHERE u.name = :name")
User findByName(@Param("name") String name);

// 2. 輸入驗證
@PostMapping("/api/order")
public Order createOrder(@Valid @RequestBody OrderRequest request) {
    return orderService.create(request);
}

// 3. 外部化設定
@Value("${api.key}")
private String apiKey;

// 4. 安全的反序列化
ObjectMapper mapper = new ObjectMapper();
mapper.activateDefaultTyping(/* 限制允許的類別 */);

6.3 AI 風險評估

風險評估矩陣

AI 特定風險評估項目

ai_risk_assessment:
  project: "專案名稱"
  date: "2026-05-06"
  assessor: "評估人"
  
  risks:
    - id: "R001"
      category: "資料外洩"
      description: "敏感資料透過 AI API 傳輸"
      likelihood: "中"
      impact: "高"
      risk_level: "高"
      controls:
        - "Secure Proxy 過濾敏感資料"
        - "DLP 工具監控"
        - "教育訓練"
      residual_risk: "低"
      
    - id: "R002"
      category: "程式碼品質"
      description: "AI 產出含安全漏洞"
      likelihood: "高"
      impact: "高"
      risk_level: "極高"
      controls:
        - "SAST/DAST 掃描"
        - "強制 Code Review"
        - "自動化測試"
      residual_risk: "低"
      
    - id: "R003"
      category: "Hallucination"
      description: "AI 使用不存在的 API"
      likelihood: "中"
      impact: "低"
      risk_level: "低"
      controls:
        - "編譯檢查"
        - "IDE 整合"
      residual_risk: "極低"

AI 系統影響評估（對齊 ISO/IEC 42005:2025）

前述風險評估以「對企業的風險」為主體；ISO/IEC 42005:2025 進一步要求以「對個人與社會的影響」為主體進行 AI 系統影響評估（AI System Impact Assessment, AISIA）。兩者互補：風險評估回答「這個 AI 會傷害公司什麼」，影響評估回答「這個 AI 會傷害誰」。高風險 AI 應用（見 1.3 風險分級）應同時完成兩者。

AISIA 執行要點：

與既有制度整合：AISIA 可與隱私影響評估（PIA）、EU AI Act 基本權利影響評估（FRIA）共用資料蒐集與利害關係人分析，避免重複作業；評估結果納入 AI Risk Assessment 表（11.3）之附件歸檔，作為 ISO/IEC 42001 條款 6 之佐證文件。

6.4 稽核流程（Audit Checklist）

稽核頻率

AI 治理稽核 Checklist

## AI 治理稽核檢查表

### A. 政策與規範
- [ ] AI 使用政策已公告且員工知悉
- [ ] AI 開發規範已納入開發流程
- [ ] 禁止事項清單已明確公告
- [ ] 教育訓練紀錄完整
- [ ] 政策已對齊《人工智慧基本法》七大原則
- [ ] 政策已對齊金管會六大核心原則

### B. 工具管理
- [ ] 僅使用核准之 AI 工具
- [ ] AI 工具設定符合安全要求（No Retention 等）
- [ ] Secure Proxy 運作正常
- [ ] API Key 管理符合規範
- [ ] AI 供應商年度覆審已完成
- [ ] 模型風險管理（MRM）生命週期各階段紀錄完整（4.4）
- [ ] 供應商子處理者/底層模型揭露已取得並留存（4.5）

### C. 開發流程
- [ ] AI 產出程式碼均有 Code Review 紀錄
- [ ] AI 使用紀錄完整
- [ ] Commit Message 含 AI 標記
- [ ] SAST/DAST 掃描結果正常
- [ ] AI Agent 使用符合權限分級規範

### D. 風險管理
- [ ] AI 風險評估已執行
- [ ] 高風險專案有額外管控
- [ ] 事件通報機制運作正常
- [ ] 改善措施已落實
- [ ] 生成式 AI 風險已納入評估範圍
- [ ] AI Agent 失控事件應變流程已納入事件通報 SOP（7.2.6）
- [ ] 對外發布之生成式內容已依標記合規要求處理（13.1）

### E. 合規
- [ ] 符合《人工智慧基本法》要求
- [ ] 符合金管會 AI 核心原則要求
- [ ] 個資保護措施落實（含 PIA）
- [ ] 資安管理法要求符合
- [ ] 供應商管理紀錄完整
- [ ] EU AI Act 風險分級已對照（如適用）

### F. ISO/IEC 42001 對齊（選項）
- [ ] AI 管理系統範圍已界定（條款 4）
- [ ] 高階管理層承諾與政策已建立（條款 5）
- [ ] AI 風險與機會已識別與評估（條款 6）
- [ ] AI 系統影響評估已執行並文件化（條款 6，方法論對齊 ISO/IEC 42005:2025）
- [ ] 支持資源與教育訓練已到位（條款 7）
- [ ] AI 系統營運控制已實施（條款 8）
- [ ] 績效監控與內部稽核已執行（條款 9）
- [ ] 持續改善機制已建立（條款 10）
- [ ] 如尋求認證：驗證機構符合 ISO/IEC 42006:2025 要求（已取得對應認可）

6.5 Logging & Traceability

日誌架構

graph LR
    DEV[開發者] --> PROXY[AI Secure Proxy]
    PROXY --> AI[AI API]
    PROXY --> LOG[Audit Log]
    LOG --> SIEM[SIEM 系統]
    LOG --> DASH[Dashboard]
    
    subgraph 記錄內容
        L1[Who: 使用者]
        L2[When: 時間]
        L3[What: 操作類型]
        L4[Tool: AI 工具]
        L5[Risk: 風險等級]
    end

Log 記錄規範

{
  "timestamp": "2026-05-06T10:30:00+08:00",
  "user_id": "EMP001",
  "project": "order-service",
  "ai_tool": "github-copilot",
  "action": "code_generation",
  "risk_level": "medium",
  "prompt_hash": "sha256:abc123...",
  "prompt_category": "service_generation",
  "output_size_bytes": 2048,
  "validation_result": "passed",
  "reviewer": "EMP002",
  "metadata": {
    "language": "java",
    "framework": "spring-boot",
    "module": "order-service"
  }
}

注意：

• 不記錄完整 Prompt 內容（可能含敏感資訊）
• 記錄 Prompt Hash 供追溯
• 記錄 Prompt Category（從 Registry 對應）
• 保留期限：至少 3 年（依金管會要求）

7. AI 風險管理（Risk Management）

7.1 風險總覽

mindmap
  root((AI 風險))
    資料外洩
      Prompt 含敏感資料
      AI 記憶洩漏
      API 傳輸攔截
    模型偏誤
      訓練資料偏見
      特定場景失效
      文化/語言偏差
    Hallucination
      不存在的 API
      錯誤的業務邏輯
      虛構的設定值
    法規風險
      個資法違反
      金管會指引不符
      跨境傳輸
    Vendor Lock-in
      單一供應商依賴
      API 變更風險
      定價調整
    營運風險
      服務中斷
      成本失控
      人才流失

7.2 各風險詳細分析與控制

7.2.1 資料外洩風險

技術控制措施：

# Secure Proxy 設定
secure_proxy:
  filters:
    - type: "regex"
      pattern: "[A-Z][12]\\d{8}"  # 身分證字號
      action: "block_and_alert"
    - type: "regex"
      pattern: "\\d{4}-\\d{4}-\\d{4}-\\d{4}"  # 信用卡號
      action: "block_and_alert"
    - type: "keyword"
      keywords: ["password", "api_key", "secret"]
      action: "warn"
    - type: "entropy"
      threshold: 4.5  # 高亂度字串（可能是 Key）
      action: "block_and_alert"

7.2.2 Hallucination 風險

防控策略：

1. 技術約束：在 Prompt 中明確指定版本
2. 即時驗證：編譯 → 測試 → 掃描
3. 知識庫對照：與企業內部知識庫交叉驗證
4. 多工具交叉：用不同 AI 工具交叉驗證重要邏輯

7.2.3 法規風險

7.2.4 Vendor Lock-in 風險

控制措施：

graph LR
    A[AI Gateway<br/>統一介面] --> B[GitHub Copilot]
    A --> C[Claude Code]
    A --> D[OpenAI Codex]
    A --> E[Google Gemini]
    
    F[抽象層設計] --> A
    G[多供應商策略] --> A
    H[標準 API 介面] --> A

• 建立 AI Gateway 抽象層，避免直接依賴單一供應商 API
• 維持至少兩個 AI 供應商的能力
• 定期評估新供應商
• Prompt 設計保持供應商中立（不使用特有語法）

7.2.5 成本失控風險

7.2.6 AI Agent 失控風險

隨著第 10.3 節所述 Agentic AI（可長時間自主運行、可呼叫工具、可多 Agent 協作）之採用增加，其失控情境有別於傳統「單次生成」風險，須獨立分析：

事故分類與應變：AI Agent 失控事件應依 5.5 AI 事件通報 SOP 之嚴重度分級通報，並額外記錄「任務範圍」「已執行操作清單」「是否已回滾」三項資訊；凡涉及 Agent 存取生產環境或執行不可逆操作者，一律視為「緊急」等級，立即啟動應變並事後檢討是否違反 10.3 權限分級規範。

8. 技術落地架構（Architecture）

8.1 AI Gateway 架構

graph TB
    subgraph 開發端
        IDE[VS Code + Copilot]
        CLI[Claude Code CLI]
        WEB[Web UI]
    end
    
    subgraph AI Gateway
        LB[Load Balancer]
        AUTH[Auth Service]
        PROXY[Secure Proxy]
        DLP[DLP Filter]
        ROUTER[Model Router]
        CACHE[Response Cache]
        AUDIT[Audit Logger]
        RATE[Rate Limiter]
    end
    
    subgraph AI Providers
        CP[GitHub Copilot]
        CL[Claude API]
        OA[OpenAI API]
        GM[Gemini API]
    end
    
    subgraph 後端服務
        PR[Prompt Registry]
        LOG[Audit Log DB]
        MONITOR[Monitoring]
        ALERT[Alert System]
    end
    
    IDE --> LB
    CLI --> LB
    WEB --> LB
    LB --> AUTH
    AUTH --> PROXY
    PROXY --> DLP
    DLP --> ROUTER
    ROUTER --> CACHE
    ROUTER --> CP
    ROUTER --> CL
    ROUTER --> OA
    ROUTER --> GM
    
    PROXY --> AUDIT
    AUDIT --> LOG
    LOG --> MONITOR
    MONITOR --> ALERT
    
    ROUTER --> PR
    RATE --> ROUTER

元件說明

8.2 Prompt Registry 設計

# prompt-registry 結構
prompt-registry/
├── code-generation/
│   ├── spring-boot-controller.yaml
│   ├── spring-boot-service.yaml
│   ├── jpa-repository.yaml
│   └── junit-test.yaml
├── code-review/
│   ├── security-review.yaml
│   └── performance-review.yaml
├── refactoring/
│   ├── legacy-to-modern.yaml
│   └── framework-upgrade.yaml
└── documentation/
    ├── javadoc.yaml
    └── api-spec.yaml

Prompt 版本管理

# 範例：spring-boot-controller.yaml
metadata:
  id: "CG-001"
  name: "Spring Boot Controller 產生"
  version: "2.1.0"
  author: "AI Governance Team"
  last_updated: "2026-05-01"
  risk_level: "Level 2"
  approved_by: "SA Lead"
  
constraints:
  java_version: "21"
  spring_boot_version: "3.2.x"
  architecture: "Clean Architecture"
  
template: |
  請產出 Spring Boot REST Controller：
  - 資源：{resource}
  - 操作：{operations}
  - 使用 Jakarta Validation
  - 統一例外處理
  - 遵循 Clean Architecture（Controller → UseCase → Repository）
  
  技術約束：
  - Java 21
  - Spring Boot 3.2
  - jakarta.* namespace
  
prohibited_inputs:
  - 客戶資料
  - 認證資訊
  
validation_rules:
  - "must_compile"
  - "must_pass_checkstyle"
  - "must_have_test"

8.3 Audit Log 系統

日誌分層

graph TB
    subgraph Application Layer
        A1[AI Request Log]
        A2[AI Response Log]
        A3[Validation Result Log]
    end
    
    subgraph Infrastructure Layer
        I1[Network Traffic Log]
        I2[API Gateway Log]
        I3[Proxy Access Log]
    end
    
    subgraph Business Layer
        B1[Code Review Log]
        B2[Deployment Log]
        B3[Incident Log]
    end
    
    A1 --> ELK[ELK Stack]
    A2 --> ELK
    A3 --> ELK
    I1 --> ELK
    I2 --> ELK
    I3 --> ELK
    B1 --> ELK
    B2 --> ELK
    B3 --> ELK
    
    ELK --> DASH[Kibana Dashboard]
    ELK --> ALERT[Alert Rules]
    ELK --> REPORT[Compliance Report]

日誌保留政策

8.4 Secure Proxy 設計

資料過濾流程

sequenceDiagram
    participant Dev as 開發者
    participant Proxy as Secure Proxy
    participant DLP as DLP Engine
    participant AI as AI Provider
    participant Log as Audit Log
    
    Dev->>Proxy: AI Request (含 Prompt)
    Proxy->>DLP: 掃描敏感資料
    
    alt 包含敏感資料
        DLP-->>Proxy: 阻擋 + 告警
        Proxy-->>Dev: 拒絕請求 + 原因
        Proxy->>Log: 記錄違規
    else 安全
        DLP-->>Proxy: 通過
        Proxy->>AI: 轉發請求
        AI-->>Proxy: AI 回覆
        Proxy->>Log: 記錄使用
        Proxy-->>Dev: 回覆結果
    end

DLP 規則設定

dlp_rules:
  - name: "Taiwan ID"
    pattern: "[A-Z][12]\\d{8}"
    action: "block"
    severity: "critical"
    
  - name: "Credit Card"
    pattern: "\\d{4}[- ]?\\d{4}[- ]?\\d{4}[- ]?\\d{4}"
    action: "block"
    severity: "critical"
    
  - name: "Email"
    pattern: "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}"
    action: "warn"
    severity: "medium"
    
  - name: "IP Address"
    pattern: "\\b(?:\\d{1,3}\\.){3}\\d{1,3}\\b"
    action: "warn"
    severity: "low"
    
  - name: "JWT Token"
    pattern: "eyJ[A-Za-z0-9-_=]+\\.[A-Za-z0-9-_=]+\\.?"
    action: "block"
    severity: "high"
    
  - name: "Connection String"
    pattern: "(jdbc|mongodb|redis)://[^\\s]+"
    action: "block"
    severity: "high"

8.5 DevSecOps 整合

CI/CD Pipeline 整合 AI 治理

graph LR
    subgraph 開發
        A[Code + AI] --> B[Commit]
    end
    
    subgraph CI Pipeline
        B --> C[Build]
        C --> D[Unit Test]
        D --> E[SAST]
        E --> F[Dependency Check]
        F --> G[License Check]
        G --> H[AI Compliance Check]
    end
    
    subgraph CD Pipeline
        H --> I[Deploy to Staging]
        I --> J[DAST]
        J --> K[Integration Test]
        K --> L[Performance Test]
        L --> M[Deploy to Prod]
    end
    
    subgraph AI Governance
        H --> N{AI-Assisted<br/>Label?}
        N -->|是| O[額外安全掃描]
        O --> P[AI Audit Log]
    end

GitHub Actions 整合範例

# .github/workflows/ai-governance.yml
name: AI Governance Pipeline

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-compliance:
    if: contains(github.event.pull_request.labels.*.name, 'ai-assisted')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Check AI Commit Convention
        run: |
          # 驗證 commit message 含 [AI-Assisted] 標記
          git log --oneline origin/main..HEAD | while read line; do
            if ! echo "$line" | grep -q "\[AI-Assisted\]"; then
              echo "⚠️ Commit missing [AI-Assisted] tag: $line"
            fi
          done
          
      - name: Enhanced Security Scan
        run: |
          mvn compile
          mvn spotbugs:check -Dspotbugs.includeFilter=ai-security-rules.xml
          
      - name: AI Usage Log
        run: |
          echo "Recording AI-assisted PR metrics..."
          # 記錄至 AI Audit System

9. 管理層決策建議（Executive Guide）

9.1 KPI / KRI

Key Performance Indicators（KPI）

Key Risk Indicators（KRI）

9.2 AI 成本控管

成本結構

成本最佳化策略

graph TD
    A[成本最佳化] --> B[模型分級使用]
    A --> C[Prompt 最佳化]
    A --> D[Cache 機制]
    A --> E[用量管控]
    
    B --> B1[簡單任務: 小模型/Copilot]
    B --> B2[複雜任務: Claude/GPT-4]
    
    C --> C1[減少冗餘 Token]
    C --> C2[使用 Prompt Template]
    
    D --> D1[常見問題快取]
    D --> D2[相似 Prompt 合併]
    
    E --> E1[每人每月額度]
    E --> E2[專案預算上限]

9.3 導入策略（Phase 1~3）

Phase 1：基礎建設（1-3 個月）

Phase 2：擴大應用（3-6 個月）

Phase 3：成熟優化（6-12 個月）

9.4 組織設計（AI Governance Team）

組織架構

graph TB
    BOARD[董事會/高階管理層] --> AIGC[AI 治理委員會]
    
    AIGC --> TEAM[AI 治理小組]
    AIGC --> CISO[資安長]
    AIGC --> CTO[技術長]
    
    TEAM --> POLICY[政策制定]
    TEAM --> RISK[風險管理]
    TEAM --> AUDIT[稽核監控]
    TEAM --> TRAIN[教育訓練]
    
    subgraph AI治理小組成員
        M1[AI 架構師]
        M2[資安專家]
        M3[合規人員]
        M4[資深工程師代表]
    end

RACI 矩陣

R=Responsible, A=Accountable, C=Consulted, I=Informed

10. 生成式 AI 治理專章（Generative AI Governance）

隨著大型語言模型（LLM）與生成式 AI 技術快速普及，其獨特風險態樣需要專門的治理框架。本章依據 EU AI Act 通用目的 AI（GPAI）專章、NIST AI 600-1 生成式 AI 風險概覽及金管會指引，建立生成式 AI 專屬治理機制。

10.1 生成式 AI 風險特論

生成式 AI 獨有風險

生成式 AI 與傳統 AI 風險比較

10.2 大型語言模型（LLM）使用規範

LLM 選用評估矩陣

GPAI Code of Practice 對企業選用 LLM 之意涵

EU 的 GPAI Code of Practice 正式版（2025 年 7 月 10 日發布，8 月 1 日獲歐盟執委會與 AI Board 認可）雖以模型提供者為規範對象，但其三章結構為企業評估 LLM 供應商提供了現成的檢核基準：

實務建議：將「是否簽署 GPAI Code of Practice 或提供等效文件」納入 4.5 供應商評估清單，作為透明度面向之具體佐證；此一檢核同時滿足 OECD 盡職調查步驟 2（識別上游風險）之要求。

LLM 使用護欄（Guardrails）

llm_guardrails:
  input_controls:
    - name: "敏感資料過濾"
      type: "DLP"
      action: "block_and_alert"
    - name: "Prompt Injection 偵測"
      type: "pattern_matching + ML"
      action: "block_and_log"
    - name: "Token 長度限制"
      type: "rate_limit"
      max_tokens_per_request: 8000
      
  output_controls:
    - name: "有害內容過濾"
      type: "content_safety"
      action: "filter_and_log"
    - name: "程式碼安全掃描"
      type: "inline_sast"
      action: "warn"
    - name: "事實一致性檢查"
      type: "reference_validation"
      action: "flag_for_review"
      
  operational_controls:
    - name: "使用量監控"
      type: "rate_limiter"
      max_requests_per_user_per_day: 500
    - name: "成本監控"
      type: "budget_alert"
      monthly_budget_per_project: "USD 1000"

10.3 AI Agent 與自動化工作流治理

隨著 AI Agent（如 Claude Code、GitHub Copilot Agent）能自主執行多步驟任務，需建立額外治理機制：

AI Agent 權限分級

AI Agent 使用準則

1. 最小權限原則：AI Agent 僅授予完成任務所需的最低權限
2. 人工審核閘門：所有 AI Agent 的輸出須經人工確認後方可採用
3. 操作可逆性：AI Agent 的操作應可回滾，不得執行不可逆操作
4. 日誌完整性：AI Agent 的所有操作需完整記錄
5. 隔離環境：AI Agent 不得直接存取生產環境

Agentic AI 進階治理要點（2026 年增補）

隨著 AI Agent 從「單一工具」演進為「可長時間自主運行、可呼叫外部工具、可多 Agent 協作」的工作模式，治理需擴及以下面向：

上述控制不改變 10.3 之權限分級架構：無論 Agent 能力如何提升，Level 4（完全自主）仍不建議使用，人工審核閘門為不可移除之底線。

10.4 生成式 AI 倫理框架

倫理原則（對齊 UNESCO AI 倫理建議書與台灣 AI 基本法）

倫理審查機制

對於高風險 AI 應用場景，須通過倫理審查：

flowchart TD
    A[AI 應用提案] --> B{是否涉及自動化決策<br/>影響個人權益?}
    B -->|是| C[倫理影響評估]
    B -->|否| D{是否涉及<br/>敏感群體?}
    D -->|是| C
    D -->|否| E[標準治理流程]
    C --> F[AI 倫理委員會審查]
    F --> G{審查結果}
    G -->|通過| H[附帶條件執行]
    G -->|有條件通過| I[修改後重審]
    G -->|不通過| J[禁止實施]

11. 附錄（Templates）

11.1 AI 使用申請表

# AI 使用申請表

## 基本資訊
- 申請日期：____年____月____日
- 申請人：______________（員工編號：________）
- 所屬部門：______________
- 專案名稱：______________

## AI 使用說明
- 使用工具：□ GitHub Copilot  □ Claude Code  □ Codex  □ Gemini
- 使用目的：
  □ 程式碼產生  □ Code Review  □ 測試產生
  □ 文件產生    □ Refactoring   □ Bug Fix
  □ 其他：______________

## 風險評估
- 風險等級：□ 高  □ 中  □ 低
- 是否涉及客戶資料：□ 是  □ 否
- 是否涉及核心業務邏輯：□ 是  □ 否
- 是否涉及生產環境：□ 是  □ 否

## 資料安全確認
- [ ] 確認不會將客戶個資輸入 AI
- [ ] 確認不會將認證資訊輸入 AI
- [ ] 確認不會將營業秘密輸入 AI
- [ ] 確認已完成 AI 安全使用訓練

## 核准
- 主管簽核：______________ 日期：__________
- AI 治理小組（高風險時）：______________ 日期：__________

11.2 Prompt Template 範例

範例一：Spring Boot Service 產生

id: "PT-001"
name: "Spring Boot Service Layer"
version: "1.0"
risk_level: "Level 2"

prompt: |
  請產出一個 Spring Boot Service 類別：
  
  需求：
  - 服務名稱：{service_name}
  - 功能：{功能描述}
  - 使用 Constructor Injection
  - 加入 @Transactional（適當位置）
  - 使用 Log4j2 記錄日誌
  - 例外使用自訂 BusinessException
  
  技術約束：
  - Java 21
  - Spring Boot 3.2
  - Clean Architecture（Application Layer）
  - 不使用 Lombok
  
  品質要求：
  - 方法需有 JavaDoc
  - 適當的 Input Validation
  - 統一回傳格式

範例二：JUnit 測試產生

id: "PT-002"
name: "JUnit Test Generation"
version: "1.0"
risk_level: "Level 1"

prompt: |
  請為以下類別產出完整的 JUnit 5 測試：
  
  目標類別：
  {paste_class_here}
  
  測試要求：
  - 使用 @ExtendWith(MockitoExtension.class)
  - Mock 所有外部依賴
  - 包含正向測試（Happy Path）
  - 包含負向測試（例外情境）
  - 包含邊界值測試（null / empty / 超長）
  - 使用 @DisplayName 標註測試名稱
  - 覆蓋率目標 ≥ 80%
  
  技術約束：
  - JUnit 5.10
  - Mockito 5.x
  - AssertJ

範例三：逆向工程分析

id: "PT-003"
name: "Legacy Code Analysis"
version: "1.0"
risk_level: "Level 2"

prompt: |
  請分析以下舊系統程式碼，產出：
  
  1. 業務邏輯摘要（用中文）
  2. 資料流程圖（Mermaid）
  3. 建議的現代化架構
  4. Migration 步驟
  
  程式碼：
  {paste_legacy_code_here}
  
  注意：
  - 程式碼中的變數名稱可能是縮寫，請推測其意義
  - 忽略程式碼中的硬編碼值（已脫敏）
  - 著重於業務邏輯而非技術實作

11.3 AI Risk Assessment 表

# AI 風險評估表

## 專案資訊
- 專案名稱：______________
- 評估日期：____年____月____日
- 評估人員：______________
- 核准人員：______________

## 風險評估

| # | 風險項目 | 說明 | 可能性(1-5) | 影響(1-5) | 風險值 | 控制措施 | 殘餘風險 |
|---|---------|------|------------|----------|--------|----------|----------|
| 1 | 資料外洩 | | | | | | |
| 2 | 程式碼漏洞 | | | | | | |
| 3 | Hallucination | | | | | | |
| 4 | 合規違反 | | | | | | |
| 5 | 服務中斷 | | | | | | |
| 6 | 成本超支 | | | | | | |
| 7 | 授權衝突 | | | | | | |
| 8 | 品質不足 | | | | | | |

## 風險等級判定
- 風險值 = 可能性 × 影響
- 1-6：低風險（綠）
- 7-14：中風險（黃）
- 15-25：高風險（紅）

## 總體風險等級：□ 高  □ 中  □ 低

## 結論與建議
______________________________________________

## 簽核
- 評估人員：______________ 日期：__________
- 主管：______________ 日期：__________
- AI 治理小組：______________ 日期：__________

11.4 Code Review Checklist（AI 產出專用）

# AI 產出 Code Review Checklist

## PR 資訊
- PR 編號：#________
- 開發者：______________
- AI 工具：______________
- 風險等級：□ 高  □ 中  □ 低
- Review 日期：____年____月____日

## 安全性檢查
- [ ] 無 SQL Injection（使用 Parameterized Query / ORM）
- [ ] 無 XSS（適當 Output Encoding）
- [ ] 無 CSRF 風險
- [ ] 無硬編碼機密（密碼/Token/Key）
- [ ] 輸入驗證完整（長度/格式/白名單）
- [ ] 適當的存取控制（Authorization）
- [ ] 無不安全的反序列化
- [ ] 無敏感資料日誌輸出

## 正確性檢查
- [ ] 業務邏輯正確（對照需求文件）
- [ ] 邊界條件已處理
- [ ] 例外處理適當且有意義的錯誤訊息
- [ ] 無 AI Hallucination（API/Library 確實存在）
- [ ] 併發安全（Thread Safety）
- [ ] 資源正確釋放（Connection / Stream）

## 品質檢查
- [ ] 符合 Clean Architecture 分層規範
- [ ] 命名清楚且符合慣例
- [ ] 無重複程式碼（DRY）
- [ ] 方法長度合理（< 30 行）
- [ ] 類別職責單一（SRP）
- [ ] 適當的日誌記錄（Level 正確）

## 效能檢查
- [ ] 無 N+1 Query
- [ ] 適當的索引使用
- [ ] 無不必要的 DB 呼叫
- [ ] 集合操作效率合理
- [ ] 無記憶體洩漏風險

## 測試檢查
- [ ] 單元測試覆蓋率 ≥ 80%
- [ ] 含負面測試
- [ ] 含邊界值測試
- [ ] 測試有意義（非形式化）

## 合規檢查
- [ ] Commit Message 含 [AI-Assisted] 標記
- [ ] 無授權衝突的程式碼
- [ ] AI 使用紀錄已登錄
- [ ] 無殘留敏感資料

## Review 結果
- [ ] ✅ 核准合併
- [ ] 🔄 需修改後重審
- [ ] ❌ 拒絕（重大問題）

## 備註
______________________________________________

## Reviewer 簽名：______________ 日期：__________

12. AI 素養與教育訓練體系（AI Literacy & Training）

EU AI Act 第 4 條明確要求 AI 系統之提供者與部署者須確保其人員具備充分的 AI 素養（AI Literacy），台灣《人工智慧基本法》亦將人才培育列為核心目標。本章建立系統化的 AI 素養培訓體系，確保組織各層級人員具備適當的 AI 治理知識與技能。

12.1 AI 素養框架

AI 素養能力模型

EU AI Act AI 素養要求（第 4 條）

EU AI Act 第 4 條自 2025 年 2 月起即已適用，要求：

• AI 系統提供者與部署者應採取措施，確保其人員及代理其運營之人員，在 AI 素養方面具有充足的訓練水準
• AI 素養之範圍與內容應考量：技術知識、經驗、教育背景、AI 系統使用的脈絡、以及受影響之個人或群體
• 此義務適用於所有 AI 風險等級，為 EU AI Act 最早生效之規定之一

數位發展部 AI 評測體系與素養結合

數位發展部「AI 產品與系統評測中心（AIEC）」參考 NIST、ISO 與歐盟規範建立評測制度，其語言模型評測涵蓋十項評測面向；企業可據此建立對應的素養培訓內容：

台灣《人工智慧基本法》之人才培育對應

《人工智慧基本法》將人才培育列為國家推動重點，並以七大原則要求 AI 運用具備人類自主與問責等素養基礎。企業培訓體系（12.2）可與政府資源銜接：

• 對接「AI 新十大建設」之人才培育計畫與產業課程資源
• 參與 AIEC 評測知識推廣活動，將評測方法內化為內部驗證能力
• 追蹤數位發展部風險分類框架，將分級概念納入全員基礎課程（L1）

12.2 分層培訓體系

培訓課程架構

graph TB
    subgraph 基礎層_全體員工
        A1[AI 治理政策說明 2h]
        A2[AI 安全意識 1h]
        A3[AI 倫理基礎 1h]
    end
    
    subgraph 應用層_開發人員
        B1[AI 工具安全使用實務 4h]
        B2[Prompt Engineering 基礎 2h]
        B3[AI 產出驗證實務 2h]
    end
    
    subgraph 進階層_技術主管
        C1[AI 風險評估實務 3h]
        C2[AI Code Review 專題 2h]
        C3[AI 架構治理 2h]
    end
    
    subgraph 管理層_高階主管
        D1[AI 治理策略 2h]
        D2[AI 法規趨勢 2h]
        D3[AI 投資決策 1h]
    end
    
    A1 --> B1
    A2 --> B1
    B1 --> C1
    C1 --> D1

各層級培訓內容

12.3 培訓成效評估

評估指標

持續學習機制

• 月度 AI 治理通報：彙整國內外 AI 治理最新動態，推送至全體員工
• 季度案例研討：以實際案例（含公司內部與業界）進行研討
• 年度紅隊演練：模擬 AI 安全事件，演練應變流程
• 知識庫維護：持續更新企業 AI 治理知識庫（含 FAQ、Best Practice）

13. 跨境資料傳輸與多法域合規（Cross-border & Multi-jurisdiction）

隨著企業使用之 AI 工具多為跨境雲端服務（如 OpenAI 位於美國、Anthropic 位於美國、Google 橫跨多國資料中心），跨境資料傳輸之法規遵循已成為 AI 治理不可迴避的課題。

13.1 跨境資料傳輸治理

AI 工具資料流向分析

graph LR
    subgraph 台灣_企業端
        DEV[開發者]
        PROXY[AI Gateway / Proxy]
    end
    
    subgraph 美國
        COPILOT[GitHub Copilot<br/>Microsoft Azure]
        CLAUDE[Claude API<br/>Anthropic / AWS]
        OPENAI[OpenAI API<br/>Azure / OpenAI]
    end
    
    subgraph 歐盟
        GCLOUD[Gemini<br/>GCP EU Region]
    end
    
    subgraph 亞太
        AWS_AP[Amazon Q<br/>AWS AP Region]
    end
    
    DEV --> PROXY
    PROXY --> COPILOT
    PROXY --> CLAUDE
    PROXY --> OPENAI
    PROXY --> GCLOUD
    PROXY --> AWS_AP

跨境傳輸法規要求

資料在地化評估

生成式內容標記合規（Content Provenance / Watermarking）

EU AI Act 第 50 條要求 AI 生成或處理之內容（文字、圖像、音訊、影片）需可辨識標記；企業對外發布之生成式 AI 產出（如行銷素材、客服回覆、對外報告）應建立對應機制：

實務提醒：機器可讀標記之過渡期僅適用於「Digital Omnibus 修正案生效前已上市之既有系統」，企業若於過渡期後導入新工具或新版本，仍須自 2026 年 8 月即符合標記要求，不可一概適用 12 月期限（詳見 1.3 節說明）。

13.2 多法域合規矩陣

企業 AI 使用之法域合規對照

合規差異處理原則

1. 最高標準原則：當不同法域要求存在差異時，採行最嚴格之標準
2. 屬地管轄優先：優先遵循營運所在地之法規要求
3. 預防性合規：針對即將生效之法規提前準備（如 2026 年 8 月 EU AI Act 主要透明度義務、2026 年 12 月既有系統標記過渡期屆滿與新增禁止實踐、2027 年 12 月 Annex III 高風險義務、台灣個資法修正條文與 AI 基本法子法之施行）
4. 文件化紀錄：所有合規決策與差異分析須留存文件供稽核

13.3 國際合作與互認機制

標準互認趨勢

企業全球合規建議

flowchart TD
    A[識別 AI 使用場景] --> B[分析涉及法域]
    B --> C[進行法域合規差異分析]
    C --> D{是否存在衝突?}
    D -->|是| E[法務評估 + 採最嚴格標準]
    D -->|否| F[依最高標準建立統一政策]
    E --> G[建立合規矩陣文件]
    F --> G
    G --> H[定期覆審<br/>至少每半年一次]
    H --> I{法規是否更新?}
    I -->|是| C
    I -->|否| H

檢查清單（Checklist）

新進成員快速上手清單

第一天

• 閱讀本手冊第 1 章（治理架構）
• 閱讀本手冊第 4.1 節（AI 使用政策）
• 閱讀本手冊第 10 章（生成式 AI 治理專章）
• 完成「AI 治理政策說明」線上課程（2h）
• 簽署 AI 使用承諾書

第一週

• 完成「AI 工具安全使用實務」訓練（4h）
• 完成「Prompt Engineering 基礎」訓練（2h）
• 熟悉 Prompt Registry 使用方式
• 瞭解 AI 風險分級判斷方式
• 在 Pilot 環境實際操作 AI 工具

開始使用 AI 開發前

• 確認已通過所有必要訓練
• 瞭解所屬專案的 AI 風險等級
• 瞭解 Code Review 流程（第 3.4 節）
• 瞭解 AI Agent 權限分級（第 10.3 節）
• 知道如何登錄 AI 使用紀錄
• 知道事件通報流程（第 5.5 節）
• 完成 AI 素養基礎課程（第 12.1 節）
• 瞭解跨境資料傳輸限制（第 13.1 節）

日常開發

• 每次使用 AI 前檢查 Prompt 安全性
• AI 產出必經「編譯 → 測試 → 掃描」驗證
• Commit 加上 [AI-Assisted] 標記
• PR 加上 ai-assisted label
• 定期登錄 AI 使用紀錄

禁止事項（牢記）

• ❌ 不輸入客戶個資
• ❌ 不輸入密碼/API Key/Token
• ❌ 不輸入營業秘密
• ❌ 不跳過 Code Review 直接合併
• ❌ 不使用未核准的 AI 工具
• ❌ 不關閉安全掃描

管理者快速參考

文件結束
本手冊由 AI 治理委員會維護，如有疑問請聯繫 AI 治理小組。
下次預定修訂日期：2027 年 1 月（或於重大法規變動時隨時修訂）