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

版本：v3.0
適用對象：管理團隊 + 開發團隊
最後更新：2026-05-06
分類：企業內部標準文件（技術白皮書等級）
文件編號：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 年由立法院三讀通過，為我國首部 AI 專法，確立以下基本原則：

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

金管會於 2023 年 10 月正式發布「金融業運用AI核心原則與相關推動政策」，適用於銀行、證券、保險等金融機構，為金融業 AI 治理最重要的監管指引：

ISO/IEC 42001:2023 AIMS 核心要求

ISO/IEC 42001 是全球首個 AI 管理系統（AIMS）國際標準，於 2023 年 12 月正式發布。企業可依此標準建立、實施、維護並持續改善 AI 管理系統，並取得第三方認證：

1.2 三道防線（Three Lines of Defense）

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

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

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

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

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

第三道防線：內部稽核

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

1.3 AI 風險分類

EU AI Act 風險分級對照（Regulation 2024/1689）

EU AI Act 已於 2024 年 8 月 1 日正式生效，建立全球首個全面性 AI 監管框架。歐盟委員會已於 2025 年 2 月同步發布《禁止 AI 實踐指南》與《AI 系統定義指南》，協助利害關係人理解法規範圍。以下為其風險分級制度與企業對照：

企業行動建議：即使營運範圍不在歐盟，EU AI Act 具域外效力（Article 2(1)），若 AI 系統之輸出在歐盟境內使用，仍可能受規範。建議企業及早進行差距分析，尤其是使用 LLM 之場景需關注 GPAI 合規要求。

企業內部 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
AI管理系統]
        NISTRM[NIST AI RMF
風險管理]
        EUAI[EU AI Act
法規遵循]
    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 章對應：

📋 實務案例

案例：某金融機構開發團隊使用 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 開發工具比較（2025 年更新）

工具選用原則

flowchart TD
    A[選擇 AI 工具] --> B{資料敏感度?}
    B -->|高敏感| C[僅使用企業版
啟用 No Retention]
    B -->|中敏感| D[使用 API 版
透過 Secure Proxy]
    B -->|低敏感| E[可使用標準版
遵循基本規範]
    
    C --> F{是否已通過
資安評估?}
    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 測試

4.5 第三方 AI 管理

供應商評估清單

供應商定期覆審

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

5. 標準作業程序（SOP）

5.1 AI 開發流程 SOP

SOP 編號：AI-SOP-001

flowchart TD
    A[接收開發任務] --> B[評估 AI 風險等級]
    B --> C{風險等級?}
    C -->|高| D[填寫 AI 使用申請表
送 AI 委員會審核]
    C -->|中| E[主管核准]
    C -->|低| F[自行遵循規範]
    D --> G[開始開發]
    E --> G
    F --> G
    G --> H[使用 AI 工具產出程式碼]
    H --> I[自我驗證
編譯+測試+掃描]
    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[標註問題
退回修改]
    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[立即電話通報
資安長 + 直屬主管]
    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
少量 / 高成本]
        INT[Integration Test
適量 / 中成本]
        UNIT[Unit Test
大量 / 低成本]
    end
    
    subgraph AI特殊驗證
        HAL[Hallucination Check
API/Library 存在性]
        SEC[Security Scan
SAST/DAST]
        PERF[Performance Check
效能基線對比]
    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: "極低"

6.4 稽核流程（Audit Checklist）

稽核頻率

AI 治理稽核 Checklist

## AI 治理稽核檢查表

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

### B. 工具管理
- [ ] 僅使用核准之 AI 工具
- [ ] AI 工具設定符合安全要求（No Retention 等）
- [ ] Secure Proxy 運作正常
- [ ] API Key 管理符合規範
- [ ] AI 供應商年度覆審已完成

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

### D. 風險管理
- [ ] AI 風險評估已執行
- [ ] 高風險專案有額外管控
- [ ] 事件通報機制運作正常
- [ ] 改善措施已落實
- [ ] 生成式 AI 風險已納入評估範圍

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

### F. ISO/IEC 42001 對齊（選項）
- [ ] AI 管理系統範圍已界定（條款 4）
- [ ] 高階管理層承諾與政策已建立（條款 5）
- [ ] AI 風險與機會已識別與評估（條款 6）
- [ ] 支持資源與教育訓練已到位（條款 7）
- [ ] AI 系統營運控制已實施（條款 8）
- [ ] 績效監控與內部稽核已執行（條款 9）
- [ ] 持續改善機制已建立（條款 10）

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
統一介面] --> 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 成本失控風險

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
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 選用評估矩陣

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 不得直接存取生產環境

10.4 生成式 AI 倫理框架

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

倫理審查機制

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

flowchart TD
    A[AI 應用提案] --> B{是否涉及自動化決策
影響個人權益?}
    B -->|是| C[倫理影響評估]
    B -->|否| D{是否涉及
敏感群體?}
    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 產品與系統評測指引」之七大評測面向，建立對應的素養培訓內容：

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
Microsoft Azure]
        CLAUDE[Claude API
Anthropic / AWS]
        OPENAI[OpenAI API
Azure / OpenAI]
    end
    
    subgraph 歐盟
        GCLOUD[Gemini
GCP EU Region]
    end
    
    subgraph 亞太
        AWS_AP[Amazon Q
AWS AP Region]
    end
    
    DEV --> PROXY
    PROXY --> COPILOT
    PROXY --> CLAUDE
    PROXY --> OPENAI
    PROXY --> GCLOUD
    PROXY --> AWS_AP

跨境傳輸法規要求

資料在地化評估

13.2 多法域合規矩陣

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

合規差異處理原則

1. 最高標準原則：當不同法域要求存在差異時，採行最嚴格之標準
2. 屬地管轄優先：優先遵循營運所在地之法規要求
3. 預防性合規：針對即將生效之法規提前準備（如 2026 年 8 月 EU AI Act 高風險規定）
4. 文件化紀錄：所有合規決策與差異分析須留存文件供稽核

13.3 國際合作與互認機制

標準互認趨勢

企業全球合規建議

flowchart TD
    A[識別 AI 使用場景] --> B[分析涉及法域]
    B --> C[進行法域合規差異分析]
    C --> D{是否存在衝突?}
    D -->|是| E[法務評估 + 採最嚴格標準]
    D -->|否| F[依最高標準建立統一政策]
    E --> G[建立合規矩陣文件]
    F --> G
    G --> H[定期覆審
至少每半年一次]
    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 治理小組。
下次預定修訂日期：____年____月____日