當 AI 功能產生不正確的結果時，第一個問題總是：「誰會審查？誰決定接受還是拒絕？」
如果從開始就沒有明確的 RACI，團隊會感到困惑、延遲發生，或更糟的是——每個人都認為「這不是我的工作」。
本指南教 BA 如何為 AI 功能構建治理框架。
1. RACI 對 AI 為何重要
| 情景 | 沒有治理 | 明確的 RACI |
|---|---|---|
| 提示產生錯誤輸出 | 整個團隊混亂，沒人確定 | BA 立即識別：AI 團隊擁有，產品批准 |
| 安全事件 | 誰跟進？誰決定回滾？ | 明確的上報路徑 → SOP |
| 發布延遲 | 等待誰的批准？ | 明確的所有者、SLA、go/no-go 標準 |
2. AI 功能的 RACI 矩陣
RACI = Responsible（負責）、Accountable（負責人）、Consulted（諮詢）、Informed（知悉）
| 活動 | 產品 | BA | 資料/AI | 工程 | QA | 合規 |
|---|---|---|---|---|---|---|
| 定義 AI 要求 | A | R | C | C | - | C |
| 提示設計與調整 | - | R | R | - | - | - |
| 測試 AI 輸出品質 | - | C | R | - | R | - |
| 安全/偏差測試 | - | - | R | - | C | A |
| 生產發布批准 | A | R | C | R | - | A |
| 事件回應 | C | R | A | C | C | - |
| 模型回滾決定 | A | C | A | R | - | - |
圖例：
- R（負責）= 執行實際工作
- A（負責人）= 最終負責（必須是 1 人）
- C（諮詢）= 決策前請求意見
- I（知悉）= 決策後通知
3. 需要 RACI 的關鍵決策點
1. 提示變更批准
情景：AI 團隊想更新提示以改善輸出
活動：提示變更批准
負責：AI 工程師（提出變更 + 測試）
負責人：產品經理（最終是/否決定）
諮詢：BA（影響分析）、QA（回歸測試）
知悉：工程主管（效能影響）
程序：
1. AI 工程師草擬提示變更 + A/B 測試結果
2. BA 審查：對驗收標準有影響嗎？
3. QA 在黃金測試集上執行回歸測試
4. 產品經理：批准或拒絕
5. 如果批准：部署到 staging → 最終 QA 測試 → 生產
2. 安全閾值決定
活動：信心閾值調整（例：0.75 → 0.80）
負責：資料科學家（分析精度與上報率之間的權衡）
負責人：合規 / 法務（最終批准、承擔法律風險）
諮詢：BA（對業務工作流程的影響）、產品（對 UX 的影響）
決策標準：
- accuracy_delta（例：+2%）
- escalation_rate_delta（例：+8%）
- business_impact（成本、使用者體驗）
→ 綜合、合規決定
3. Go/No-Go 生產發布
活動：生產發布決定
負責：QA（執行 UAT）、BA（驗證業務標準）
負責人：產品經理（最終 go/no-go 決定）
諮詢：資料/AI（品質指標）、工程（技術準備）
知悉：支援/營運（準備好處理上報？）
必須通過的標準：
☐ 精度 ≥ 閾值
☐ 0 個關鍵缺陷
☐ 業務 UAT 簽核
☐ 回滾程序已測試
☐ 監控儀表板實時運作
☐ 上報操作手冊準備就緒
4. 事件回應與上報
情景：AI 輸出造成傷害（誤診、不正確的財務決定）
嚴重等級 → 回應所有者：
- P0（立即客戶傷害）：CEO/CRO 決定上報/暫停
- P1（重大缺陷）：1 小時內產品 + 工程 + 合規
- P2（次要缺陷）：4 小時內 BA + AI 團隊
- P3（改善）：定期衝刺積壓
上報路徑：
使用者報告 → QA 記錄票券
↓
QA 嚴重等級 P0/P1？→ 立即通知
↓
值班工程師 + BA + 合規
↓
分析：回滾？快速修復？監控？
↓
產品決定：暫停功能 / 限制使用者 % / 完全回滾
4. BA 要填入的 RACI 範本
# RACI 矩陣：[AI 功能名稱]
## 核心團隊
| 角色 | 名字 | 電郵 | 可用性 |
|------|------|------|------|
| 產品經理 | ... | ... | ... |
| BA | ... | ... | ... |
| 資料科學家 | ... | ... | ... |
| AI 工程師 | ... | ... | ... |
| QA 主管 | ... | ... | ... |
| 工程主管 | ... | ... | ... |
| 合規官員 | ... | ... | ... |
## 決策矩陣
| 決策 | 負責 | 負責人 | 諮詢 | 知悉 | 時間表 |
|------|------|--------|------|------|--------|
| 提示設計批准 | AI Eng | 產品 | BA、QA | Eng 主管 | 開發前 |
| 精度閾值 | Data Sci | 合規 | BA、產品 | AI Eng | UAT 前 |
| UAT 簽核 | BA | 產品 | QA | 全部 | UAT 結束 |
| 生產發布 | QA | 產品 | 全部 | 營運 | 發布日 |
| 事件 > P1 | BA | 產品 | Data Sci、Eng | 全部 | 1 小時內 |
| 回滾決定 | Eng 主管 | 產品 | 全部 | - | 立即 |
5. 上報操作手冊
偵測到 AI 輸出疑慮
│
├─→ 客戶受影響？否
│ └─→ 記錄票券、標準程序
│
└─→ 是
├─→ 嚴重等級？
│
├─→ P0（立即傷害）
│ ├─→ 立即暫停 / 將 AI 限制為 5%
│ ├─→ 通知產品 + 工程 + 合規
│ ├─→ 開始事件事後分析
│ └─→ 決定：回滾或快速修復
│
└─→ P1（重大問題）
├─→ 2 小時內調查
├─→ 如果根本原因 = 提示 → AI 團隊修復 + 測試
├─→ 如果根本原因 = 資料 → 資料團隊驗證資料品質
├─→ 如果不清楚 → 上報給資深人員（BA 審查）
└─→ 實施修復 → 測試 staging → 生產
6. 常見的反模式
❌「每個人擁有決策」→ 延遲、指責 ✅ 每個決策有明確的 A（負責人）所有者
❌「合規檢查一切」→ 速度慢 ✅ 安全相關合規為 A，其他為 C
❌「資料品質沒有 R」→ 缺陷漏過 ✅ AI 處理前資料驗證有明確的 R
❌「上報不清楚」→ 事件處理不當 ✅ 上報操作手冊根據嚴重等級明確分配所有者
總結
AI 治理並不複雜：
- 為每個決策明確定義 RACI（提示、閾值、發布、事件）
- 分配明確的負責人（1 人，不是委員會）
- 記錄上報路徑含嚴重等級
- 每季度審查 — 如果團隊/程序變化則更新 RACI
具有明確治理的團隊能更快、更自信、更有責任心地交付 AI 功能。