# 範例客戶完整案例：醫院 / 醫療機構

更新日期：2026-05-13

## 0. Benchmark-grade Summary（Tool 3.5 九欄位）

> **此案例符合 Tool 3.5 Cases-as-Benchmarks 紀律** ── 客戶可拿此表 30 分鐘自助算差距。

| # | 必填欄位 | 本案例 |
| --- | --- | --- |
| 1 | 產業 + 規模 | 醫療（醫學中心），約 1,200 人 |
| 2 | 起點 L-level + 證據 | L1 部分 + APQC 11.x = 0 |
| 3 | 終點 L-level + 證據 | L4 + APQC 11.x = 3 |
| 4 | 跨越期間 | 12-18 個月 |
| 5 | 跨越的 RM Category | APQC 4.0 Deliver、APQC 11.0 Knowledge、Tiger AI L1-L4 |
| 6 | 每階段投入 | 估 NT$ 600-900 萬 / 30-40 人月 |
| 7 | Key wins（可量化） | 病患 onboarding 加速、行政摘要時間降 50%、HIS/EMR 串接 Agent |
| 8 | Key failures（踩過的雷） | 若早期忽略護理 frontline 抗拒、若忽略法遵簽核流程 |
| 9 | 適用條件 | ≥ 500 床醫院、有法遵專責、地端 LLM 部署能力 |

**部署模式 / 代號**：全地端（HIPAA + 個資法強合規） ／ 代號 （無代號）


**Evidence Level**：🔵 **L0 — AI-Simulated Teaching Case**（AI 模擬教學案例，在 Tool 8.9 Evidence Hierarchy 之下）

> ⚠️ **本案例由 AI 模擬產生，並非真實客戶資料**。
>
> - **目的**：作為教學示範、方法論講解、Stage 1-8 工具表套用練習用
> - **來源**：AI 依據產業常識 + 方法論架構合成出符合 Tool 3.5 九欄位 Benchmark-grade 格式的虛構案例
> - **所有數字**（時間 / ROI / 投入人月 / 預算 / KPI）**僅為示例**，**不可**作為：
>   - 對外客戶宣傳依據
>   - 顧問合約 ROI 承諾
>   - 學術引用之 empirical evidence
>   - 對任何單一真實公司的對比結論
>
> 證據等級依 Tool 8.9 Evidence Hierarchy：L1 自評 · L2 文件 · L3 系統 log · L4 第三方稽核 · L5 縱貫 KPI ── **本案例屬 L0（pre-evidence）**，低於 L1。
>
> **真實 longitudinal 案例**需透過 [`../90_References/PILOT_STUDY_PROTOCOL.md`](../90_References/PILOT_STUDY_PROTOCOL.md) 18-24 個月實證研究完成後才會替換。在此之前，請以**AI 模擬教學案例**對待本檔內容。

> 詳細案例細節見下方各章節。本表為 [`../03_Consulting_Report/CONSULTING_TOOLKIT_TEMPLATES.md`](../03_Consulting_Report/CONSULTING_TOOLKIT_TEMPLATES.md) Tool 3.5 規範的標準摘要。

---


## 1. 案例定位

本案例示範醫院如何使用「企業 AI 轉型成熟度診斷與導入方案」，在高敏感資料與高度法規要求下，從 AI 使用盤點、課程能力建置，到顧問診斷報告形成可落地 Roadmap。

案例產業：醫療機構 / 區域醫院  
公司規模：約 1,500 人  
主要部門：醫務行政、護理、門診、客服中心、病歷室、資訊室、品質管理、財務、人資  
主要系統：院內 Email、Excel / Sheets、SharePoint / Notion、HIS、EMR、LIS、PACS、掛號系統、客服系統、內部 API  
建議部署：全地端或嚴格 Hybrid  
核心原則：病患資料、病歷、檢驗、影像與個資不得直接上公有雲；所有臨床相關輸出必須人工審核

## 1.1 案例交付邏輯

本案例不是要證明醫院可以立刻做醫療診斷 AI，而是示範如何在高敏感資料環境下，用顧問方法安全推進 AI。

完整交付流程：

1. 現況資料蒐集：盤點院內系統、資料分級、AI 使用現況與法規限制。
2. 問卷診斷：完成 10 題快速診斷與 25 題課前診斷。
3. 風險評估：判斷可自動、需審核、禁止的 AI 場景。
4. 訪談評估：訪談醫務行政、客服中心、護理、資訊室、品質管理。
5. As-Is 流程盤點：繪製病患服務客服流程與院內 SOP 查詢流程。
6. L1-L5 能力評估：逐級定義 input、process、output、evidence。
7. 課程與工作坊：先做 L1 治理與 L2 Skill，再做 L3 低風險 Workflow。
8. 顧問診斷報告：產出部署建議、治理設計、Roadmap、ROI 與後續 SOW。

每一階段都必須留下可驗證 deliverables，尤其是醫療場景必須保留 Log、人工審核與責任歸屬。

## 2. 客戶故事

這家醫院已經有部分行政與醫護同仁開始嘗試使用 AI。行政人員會用 AI 改寫公告、整理會議紀錄；客服人員會用 AI 草擬回覆；資訊室也聽過 n8n、自動化與 Agent。

但醫院管理層非常謹慎：

- 病患資料不能外流。
- 醫療建議不能由 AI 自動決策。
- 醫護人員工作繁忙，沒有時間學複雜工具。
- 內部 SOP、公告、規章、病患服務流程很多，但查找效率低。
- 客服中心常被重複問題佔用，例如掛號、看診流程、報到、檢查前注意事項。
- 資訊室擔心 AI 導入後變成更多維運負擔。

因此本案的策略不是一開始做醫療診斷 AI，而是先從低風險、高重複、高行政負擔的場景開始：

1. 院內 AI 使用入口與規範。
2. 醫院行政與客服 Skill 化。
3. n8n 串接客服、知識庫、表單、內部 API。
4. Hermes Agent 作為行政與客服輔助，不直接做臨床決策。
5. 後續再評估 ClawTeam 用於品質管理、病患服務改善與行政專案協作。

## 3. 問卷填答摘要

### 3.1 10 題快速診斷結果

| 題號 | 構面 | 分數 | 觀察 |
| --- | --- | ---: | --- |
| Q1 | AI 工具入口 | 1 | 同仁零星使用外部 AI，院內尚無統一入口 |
| Q2 | AI 使用頻率 | 2 | 行政與客服有個人使用，醫護端較少 |
| Q3 | Prompt / SOP / Skill | 1 | 有大量 SOP，但尚未轉成 AI Skill |
| Q4 | 新人套用 Skill | 1 | 新人仍依賴主管與資深同仁說明 |
| Q5 | 系統串接 | 0 | 尚未串 HIS、客服系統或知識庫 |
| Q6 | 自動流程 | 1 | 有部分表單流程，但 AI 未進入流程 |
| Q7 | Agent 任務 | 0 | 尚未有 Hermes Agent |
| Q8 | 多 Agent 協作 | 0 | 尚未有 ClawTeam 場景 |
| Q9 | 治理與紀錄 | 2 | 有資安與個資意識，但 AI 使用治理尚未建立 |
| Q10 | ROI 指標 | 1 | 想降低行政與客服負擔，但未定義 KPI |

總分：9 / 40  
快速判定：L0-L1  
主要缺口：統一 AI 入口、資料分級、Skill 化、可稽核 Workflow

### 3.2 25 題課前診斷摘要

| 構面 | 平均分數 | 判斷 |
| --- | ---: | --- |
| 工具使用 | 1.8 | 零星使用，缺正式入口與規範 |
| 知識沉澱 | 1.6 | SOP 豐富，但尚未 AI Skill 化 |
| 流程自動化 | 1.0 | 多數流程仍依賴人工查詢與轉述 |
| 系統整合 | 0.8 | HIS / EMR / 客服系統未串 AI |
| Agent 應用 | 0.2 | 尚無 Agent |
| 執行導入與變革治理 | 2.2 | 資安意識高，但 AI 治理細則不足 |

初判成熟度：整體 L1 尚未穩定  
建議目標：90 天內建立受控 AI 入口、資料分級規範、3-5 個低風險 Skill，完成 1 個客服行政 Workflow PoC

## 4. 公司屬性與部署模式判斷

### 4.1 公司屬性

| 項目 | 判斷 |
| --- | --- |
| 產業 | 醫療 / 醫院 |
| 資料敏感度 | 極高，包含病患個資、病歷、檢驗、影像、費用資料 |
| 法規與稽核 | 高，需符合個資、醫療資料治理、內部稽核要求 |
| 系統封閉度 | 高，HIS、EMR、LIS、PACS 多為內網核心系統 |
| IT 能力 | 中高，有資訊室，但維運負擔大 |
| 雲端政策 | 核心醫療資料不得上雲，一般行政資料需審核 |
| 導入風險 | 個資外洩、錯誤醫療建議、權限誤用、責任歸屬不清 |

### 4.2 建議部署模式

建議採全地端或嚴格 Hybrid。

部署原則：

- 病患個資、病歷、檢驗、影像與 HIS / EMR 資料不得直接送公有雲。
- L1 OpenWebUI 建議使用院內受控環境。
- L2 Skill 可先處理行政 SOP、客服 FAQ、院內規章、表單流程。
- L3 n8n 串接時需以查詢權限最小化為原則。
- L4 Hermes Agent 初期只做行政輔助、客服摘要、內部查詢，不做醫療診斷或治療建議。
- 所有對病患輸出的內容都需人工確認。
- 所有流程需保留 Log、輸入、輸出、操作者與時間戳。

## 5. 建議課程比例

| 模組 | 比例 | 原因 |
| --- | ---: | --- |
| L1 OpenWebUI | 30% | 建立受控入口、AI 使用規範、資料分級與安全意識 |
| L2 Knowledge Codification | 35% | 將行政 SOP、客服 FAQ、病患服務流程轉為可複用 Skill |
| L3 n8n Workflow AI | 25% | 從低風險行政與客服流程開始做 PoC |
| L4 Hermes Agent | 10% | 設計行政 / 客服輔助 Agent，但保留人工審核 |
| L5 ClawTeam | 0% | 暫不進入多 Agent 團隊，待治理成熟後再規劃 |

課程產品包建議：一日工作坊 + 顧問診斷專案  
若資訊室與管理層參與度高，可升級為二日導入營

## 6. 課程中應產出的工作資產

### 6.1 L1 產出

- 醫院 AI 使用規範草案。
- 資料分級原則：公開、內部、敏感、醫療核心資料。
- OpenWebUI 院內使用流程。
- 行政與客服常用 Prompt。

### 6.2 L2 產出

優先建立 5 個低風險 Skill：

1. 院內公告改寫 Skill。
2. 會議紀錄整理 Skill。
3. 病患服務 FAQ Skill。
4. 掛號與報到流程說明 Skill。
5. 檢查前注意事項摘要 Skill。

注意：檢查前注意事項 Skill 必須引用院方核准內容，不可由 AI 自行產生醫療判斷。

### 6.3 L3 產出

優先完成 1 個 PoC：

> 病患服務 FAQ 與客服案件整理 Workflow

流程：

1. 客服系統或 Email 收到病患服務問題。
2. AI 判斷問題類型，例如掛號、報到、批價、檢查注意事項、文件申請。
3. 從院內核准 FAQ / SOP 知識庫查詢答案。
4. 若涉及個人病情、病歷、檢驗或醫療建議，標記為人工處理。
5. 產生客服回覆草稿。
6. 人工確認後回覆。
7. 將案件分類與處理結果寫入 Sheets 或客服系統。

### 6.4 L4 產出

Hermes Agent 任務卡：

名稱：病患服務客服輔助 Agent  
目標：協助客服人員分類問題、查詢核准 FAQ、產生回覆草稿與追蹤案件。  
可用工具：病患服務 FAQ Skill、掛號流程 Skill、檢查注意事項摘要 Skill、n8n 客服 Workflow、知識庫查詢。  
限制：不得提供診斷、治療、用藥建議；不得查詢或輸出病患個資；涉及病情一律轉人工。  
輸出：問題分類、FAQ 來源、回覆草稿、人工處理標記、案件摘要。

## 7. 八階段顧問診斷分析

### Stage 1：As-Is Snapshot 現況掌握

觀察：

- 行政與客服有零星 AI 使用，但缺正式規範。
- 院內 SOP 與 FAQ 很多，但查找成本高。
- 病患服務問題重複性高。
- 資訊室對資料外流與維運風險高度敏感。

輸出：

- AI 使用盤點。
- 客服案件 As-Is Process Map。
- 資料分級與系統盤點。

### Stage 2：Reference Model Alignment 標準模型引入

判定：

- 整體 L1 尚未穩定。
- 行政、客服具備 L2 Skill 化潛力。
- L3 需從低風險流程開始，不直接碰核心醫療資料。

輸出：

- L1-L5 成熟度評估表。
- 醫院可導入 / 不可導入 AI 場景分類。

### Stage 3：Best Practice Integration 最佳實務對標

醫院優先 AI 場景：

- 院內公告與行政文件改寫。
- 會議紀錄與交辦事項整理。
- 病患服務 FAQ。
- 掛號、報到、批價流程查詢。
- 檢查前注意事項摘要。
- 內部 SOP 查詢。
- 品質管理事件摘要。

暫不建議第一階段處理：

- 醫療診斷。
- 治療建議。
- 用藥建議。
- 未經核准的病歷自動摘要對外輸出。
- Agent 直接修改 HIS / EMR。

### Stage 4：Gap Analysis 差距分析

| 類型 | 發現 | 影響 |
| --- | --- | --- |
| Missing | 缺 AI 使用規範 | 同仁不知道哪些資料可用 AI |
| Missing | 缺資料分級與 AI 場景分級 | 導入容易卡在資安疑慮 |
| Missing | SOP / FAQ 未 Skill 化 | 查找效率低，客服回答不一致 |
| Broken | 病患重複問題人工處理 | 客服負擔高 |
| Redundant | 行政公告、會議紀錄、FAQ 回覆重複撰寫 | 浪費行政時間 |
| Missing | 缺 Log 與稽核機制 | 不符合醫療場景治理要求 |

### Stage 5：Problem Definition 核心問題定義

Executive Problem Statement：

> 醫院目前 AI 使用仍停留在零星個人嘗試，雖然行政與客服場景具備高重複性與導入價值，但因缺少資料分級、AI 使用規範、可稽核 Workflow 與人工審核機制，使 AI 難以安全進入院內流程。

### Stage 6：Benchmarking and Phased Goals 階段目標

90 天目標：

- 建立院內 AI 使用規範與資料分級。
- 建立 OpenWebUI 或受控 AI 入口。
- 完成 5 個行政 / 客服 Skill。
- 完成 1 個病患服務 FAQ Workflow PoC。
- 建立 Hermes Agent 任務卡與人工審核流程。
- 建立 AI 使用 Log 與初步 KPI。

### Stage 7：To-Be Design 未來藍圖

To-Be 架構：

- L1：院內 OpenWebUI 受控入口。
- L2：行政與客服 Skill Library。
- L3：n8n 串接客服系統、FAQ 知識庫、Email、Sheets、內部 API。
- L4：Hermes Agent 作為病患服務客服輔助 Agent。
- L5：後續可規劃 ClawTeam，例如「品質改善 Agent Team」或「行政專案 Agent Team」。

### Stage 8：Implementation and Change 導入與變革治理

治理建議：

- AI 場景分級：可自動、需審核、禁止。
- 資料分級：公開、內部、敏感、醫療核心。
- 對外回覆一律人工確認。
- Agent 不得提供醫療診斷、治療或用藥建議。
- HIS / EMR / LIS / PACS 初期不直接開放 Agent 查詢個資。
- 所有 AI Workflow 保留 Log。
- 建立資訊室、法遵 / 稽核、業務 Owner 三方審核。

## 8. 三階段 Roadmap

### Phase 1：0-30 天，AI 治理與 Skill 化

任務：

- 建立 AI 使用規範。
- 建立資料分級與場景分級。
- 建立受控 AI 入口。
- 產出 5 個行政 / 客服 Skill。

驗收：

- 完成 20-30 位種子人員訓練。
- 完成 5 個低風險 Skill。
- 完成 AI 可用 / 禁用資料清單。

### Phase 2：31-60 天，客服 FAQ Workflow PoC

任務：

- 建立病患服務 FAQ 知識庫。
- 用 n8n 串接客服系統、Email、FAQ、Sheets。
- 建立人工審核節點。
- 建立 Log 與錯誤通知。

驗收：

- AI 可分類常見問題。
- AI 可引用核准 FAQ 產生回覆草稿。
- 涉及病情或個資自動轉人工。
- 產出客服案件統計。

### Phase 3：61-90 天，Hermes Agent 與治理擴大

任務：

- 建立病患服務客服輔助 Hermes Agent。
- Agent 可呼叫 FAQ Skill 與客服 Workflow。
- 建立 KPI Dashboard。
- 評估第二波 PoC：院內 SOP 查詢或品質事件摘要。

驗收：

- Hermes Agent 可產生問題分類、FAQ 來源與回覆草稿。
- 所有回覆保留人工確認。
- 管理層可看到客服處理效率與 AI 採用率。

## 9. ROI 指標

| KPI | 現況 | 90 天目標 |
| --- | --- | --- |
| 常見問題回覆草稿時間 | 5-10 分鐘 / 件 | 降至 1-3 分鐘 / 件 |
| 客服案件分類 | 人工分類 | AI 初步分類，人工確認 |
| FAQ 查找時間 | 依人員經驗 | AI 引用核准知識庫 |
| 行政會議紀錄整理 | 1-2 小時 / 次 | 降至 20-30 分鐘 |
| Skill 產出 | 無正式 Skill | 5 個低風險 Skill |
| Workflow PoC | 無 | 1 個客服 FAQ PoC |
| AI 使用治理 | 無正式紀錄 | 建立使用規範與 Log |

## 10. 最終顧問報告摘要

本案例的建議結論：

- 目前成熟度：整體 L1 尚未穩定。
- 目標成熟度：90 天內建立 L1 治理基礎，完成 L2 Skill 化與 1 個 L3 PoC。
- 建議部署：全地端或嚴格 Hybrid。
- 優先場景：病患服務 FAQ 與客服案件整理。
- 建議課程：一日工作坊 + 顧問診斷專案。
- 後續導入：病患服務客服輔助 Hermes Agent，第二波擴展到院內 SOP 查詢與品質事件摘要。

## 11. L1-L5 Input / Process / Output / Evidence

### 11.1 L1 Controlled AI Access：OpenWebUI

| 項目 | 定義 |
| --- | --- |
| Input | 院內公告、行政文件、會議紀錄、低敏感 FAQ、AI 使用現況問卷、資料分級規範 |
| Process | 建立院內受控 AI 入口，定義可用資料範圍，訓練 Prompt 基礎與醫療資料禁用規則 |
| Output | 院內 AI 使用規範、資料分級表、行政常用 Prompt、OpenWebUI 使用流程 |
| Evidence | AI 使用規範、資料分級清單、OpenWebUI 截圖、課程簽到、Prompt 練習成果 |
| 驗收標準 | 種子人員能完成行政摘要、公告改寫、會議紀錄整理；不得輸入病患個資與病歷資料 |

### 11.2 L2 Knowledge Codification：Antigravity / Claude Code / Codex

| 項目 | 定義 |
| --- | --- |
| Input | 院內核准 SOP、病患服務 FAQ、掛號報到流程、檢查前注意事項、行政公告範本 |
| Process | 將核准文件轉為 Skill，定義資料來源、適用範圍、禁止範圍、輸出格式與人工審核規則 |
| Output | 院內公告改寫 Skill、會議紀錄 Skill、病患服務 FAQ Skill、掛號流程 Skill、檢查前注意事項 Skill |
| Evidence | Skill Library、核准來源文件、Skill 版本、測試輸入輸出、Owner 名單 |
| 驗收標準 | 至少 5 個低風險 Skill；每個 Skill 均引用核准內容，不自行產生醫療判斷 |

### 11.3 L3 Workflow Automation：n8n

| 項目 | 定義 |
| --- | --- |
| Input | 客服問題、Email、客服系統資料、核准 FAQ / SOP 知識庫、Sheets 統計表、人工審核結果 |
| Process | n8n 接收問題，分類問題，查詢核准知識庫，判斷是否涉及病情 / 個資 / 醫療建議，產生回覆草稿並送人工確認 |
| Output | 問題分類、FAQ 來源、回覆草稿、人工處理標記、客服案件統計 |
| Evidence | n8n Workflow JSON、執行 Log、人工審核紀錄、知識庫來源連結、測試案例 |
| 驗收標準 | 至少完成 20 筆低風險客服測試；涉及病情、病歷、檢驗、用藥、治療一律轉人工 |

### 11.4 L4 Autonomous Agent：Hermes Agent

| 項目 | 定義 |
| --- | --- |
| Input | 病患服務問題、FAQ Skill、掛號流程 Skill、檢查注意事項 Skill、n8n 客服 Workflow、人工審核規則 |
| Process | Hermes Agent 拆解任務，分類問題，呼叫 Skill / Workflow，引用核准 FAQ，標記風險，產生客服草稿 |
| Output | 問題分類、引用來源、回覆草稿、風險標記、人工處理建議、案件摘要 |
| Evidence | Agent 任務卡、權限表、可用工具清單、Agent 執行紀錄、人工接手紀錄 |
| 驗收標準 | Agent 不查詢個人病歷，不輸出診斷 / 治療 / 用藥建議；所有對外回覆人工確認 |

### 11.5 L5 Multi-Agent Organization：ClawTeam

| 項目 | 定義 |
| --- | --- |
| Input | 客服統計、行政流程資料、品質事件摘要、院內 SOP、改善專案目標 |
| Process | 多 Agent 分工：客服分析 Agent、品質改善 Agent、行政流程 Agent、IT 治理 Agent、專案整合 Agent |
| Output | 病患服務改善提案、客服 FAQ 缺口、品質事件改善建議、行政流程優化 Roadmap |
| Evidence | Agent Team 角色卡、任務分派紀錄、各 Agent 輸出、整合報告、主管與法遵審核紀錄 |
| 驗收標準 | L5 不作為第一階段上線目標；需等 L1-L4 治理、Log、人工 Gate 成熟後再試點 |

## 12. 評估流程與可驗證 Deliverables

| 階段 | 評估活動 | Deliverables | 驗證方式 |
| --- | --- | --- | --- |
| 診斷前 | 收集系統、資料分級、AI 使用現況 | 系統盤點表、資料分級草案、AI 使用盤點表 | 資訊室與管理單位確認 |
| 問卷 | 10 題與 25 題成熟度問卷 | 問卷結果、構面分數、成熟度初判 | 問卷原始資料與計分表 |
| 風險評估 | 場景分級：可自動、需審核、禁止 | AI 場景分級表 | 資訊室、法遵 / 稽核、業務單位確認 |
| 訪談 | 訪談客服、行政、護理、資訊室、品質管理 | 訪談紀錄、痛點清單 | 受訪者確認紀錄 |
| As-Is | 盤點病患服務客服流程 | As-Is Process Map | 客服中心與資訊室確認 |
| L2 | 建立低風險 Skill | 5 個 Skill、核准來源、Owner | Skill 測試輸入輸出 |
| L3 | 建立 n8n 客服 FAQ PoC | Workflow JSON、Log、人工審核紀錄 | 20 筆測試案件執行成功 |
| L4 | 建立 Hermes Agent 任務卡 | Agent 角色卡、權限表、工具清單 | Agent 測試紀錄與人工審核 |
| 顧問報告 | 八階段診斷與 Roadmap | AI 轉型診斷報告 | 管理層與資訊室簡報確認 |

## 13. Stage Gate 驗收設計

### Gate 1：L1 受控入口與資料分級

必備證據：

- 院內 AI 使用規範完成。
- 資料分級清單完成。
- OpenWebUI 或受控 AI 入口可用。
- 禁止輸入病患個資與病歷資料的規範已公告。

### Gate 2：L2 低風險 Skill Library

必備證據：

- 至少 5 個低風險 Skill。
- 每個 Skill 均有核准來源文件。
- 每個 Skill 有 Owner 與版本紀錄。
- Skill 不自行產生醫療診斷、治療或用藥建議。

### Gate 3：L3 客服 FAQ Workflow

必備證據：

- n8n Workflow 可執行。
- 可查詢核准 FAQ / SOP。
- 涉及個資、病情、檢驗、治療、用藥的問題會自動轉人工。
- 有 Log、人工審核與錯誤通知。

### Gate 4：L4 Hermes Agent

必備證據：

- Hermes Agent 任務卡完成。
- Agent 可呼叫至少 1 個 Skill 與 1 個 n8n Workflow。
- Agent 權限明確，不可查病歷，不可給醫療建議。
- 所有對外回覆人工確認。

### Gate 5：L5 ClawTeam 準備度

必備證據：

- L1-L4 已有穩定治理與 Log。
- 已定義可用於多 Agent 的非臨床或品質改善任務。
- 已設計法遵 / 稽核 / 業務三方人工 Gate。

