跳到主要內容

IL 202 · 模組 4

準備度審查

把七個面向的證據、缺口、責任人與期限整理成一份完整的 Enterprise AI Readiness Review。

開始第一節
已完成 0 / 4

學習目標

  • 為七個準備度面向逐項標記狀態並附上證據。
  • 把每個缺口寫成具體的補救條件,包含責任人與期限。
  • 看懂一份完整的 Readiness Review 範例,並找出其中刻意保留的錯誤。

七個面向與四種狀態

60 分鐘

七個面向、四種狀態、四種最終建議

Readiness Review 把 Module 1-3 的產出(資料盤點與資料流向圖、存取矩陣與整合測試紀錄、異常演練與 runbook)整理成七個面向的狀態判斷,讓 Sponsor 與治理審查者能一次看到「這個專案準備好進入 Pilot 了嗎」。

七個準備度面向與資訊來源
面向主要證據來自
資料準備度Module 1 資料盤點、資料流向圖
安全準備度Module 2 最小權限矩陣、撤權演練
隱私準備度Module 1 資料分類、Module 2 存取範圍
整合準備度Module 2 整合測試紀錄
治理準備度核准的 Charter、決策權責紀錄
營運準備度Module 3 異常演練、runbook
人員準備度使用者訓練與接受度、Module 3 演練參與情形
四種狀態
狀態意義
ready該面向已有足夠證據,沒有已知缺口
conditional可在附條件下進入下一階段,條件需有責任人與期限,且不能阻礙目前核准的試行範圍
not_ready有 blocking 缺口,未結案前不能進入 Pilot
not_applicable該面向不適用於本專案,需要理由與審查者核准,不能用來規避未完成的工作

注意

常見錯誤:把「還沒有時間做」標記成 not_applicable。not_applicable 只能用在「這個面向確實不適用」的情境,例如專案完全不涉及個人資料時,隱私準備度才可能標記 not_applicable,而且需要審查者核准這個判斷。

重點: 七個面向各自獨立判斷,任何一個面向是 not_ready 且屬於 blocking 缺口,整個專案就不能進入 Pilot。

缺口、責任人與期限

60 分鐘

把缺口寫成可以被追蹤的補救條件

一個缺口如果沒有寫清楚「誰負責、什麼時候要完成、完成的證據是什麼」,就只是一句抱怨,不是可以被追蹤的條件。conditional 狀態必須附上這三項,否則不能算是「附條件就緒」。

Readiness Item 必填欄位
欄位說明
面向對應七個面向之一
狀態ready/conditional/not_ready/not_applicable
證據對應 Module 1-3 產出的具體文件或紀錄
缺口尚未滿足的具體項目
是否 blocking是否會阻礙目前核准的試行範圍
責任人具名或具體角色
期限具體日期,不是「盡快」
核准人確認此條件可接受的審查者

不合格的缺口描述

安全準備度:conditional。缺口:權限還要再確認一下。

合格的缺口描述

面向與狀態
安全準備度:conditional(非 blocking,可在此條件下進入小範圍試行)。
缺口
AI 工具的 API key 撤權延遲未通過演練(見 Module 2 撤權演練),需改為即時撤銷機制。
責任人與期限
技術管理員(王小明,合成角色),2026-03-15 前完成並重新演練。
核准人
資安負責人已核准以此條件先行進入小範圍試行。

資訊

blocking 缺口未結案,不能讓專案進入 Pilot;conditional 只能用在「不妨礙目前核准試行範圍」的殘餘條件,且必須有到期日與補救負責人。前期初篩(IL 101/IL 201)不能取代這裡的完整 Readiness Review。

重點: 沒有責任人與期限的缺口,不能標記為 conditional,只能算是 not_ready。

完整範例:找出其中的錯誤

60 分鐘

完整範例(SYN-CS-001):找出其中刻意保留的錯誤

以下是示範服務公司 A 客服知識助理(SYN-CS-001)的 Readiness Review 草稿,其中刻意保留一處常見錯誤。閱讀時請先自己找出問題,再往下看修訂說明。

Readiness Review 草稿(含刻意保留的錯誤)
面向狀態證據/缺口
資料準備度ready資料盤點與流向圖完成,過期/矛盾文件已標記並排除於自動回覆範圍。
安全準備度conditionalAPI key 撤權延遲缺口,技術管理員 3/15 前完成,資安負責人已核准。
隱私準備度not_applicable本專案不處理客戶個資,理由:客服案件只涉及產品問題,不含個人資料。
整合準備度ready唯讀整合測試通過,無寫入權限需求。
治理準備度readyCharter 與決策權責已核准。
營運準備度ready三種異常情境已演練並完成 runbook。
人員準備度ready客服人員已完成教育訓練。
最終建議Proceed with Conditions待安全準備度條件結案後可全面試行。

注意

找到問題了嗎?「隱私準備度:not_applicable,理由:客服案件只涉及產品問題,不含個人資料」,但案件本身通常會包含客戶姓名、聯絡方式或帳號等識別資訊,即使問題內容是產品問題。把「案件主題不是個資」誤當成「案件不含個資」,是常見的隱私準備度誤判。

錯誤版本

隱私準備度:not_applicable。理由:客服案件只涉及產品問題,不含個人資料。

修訂版本

重新分類
隱私準備度:conditional(不是 not_applicable)。案件確實可能包含客戶姓名、聯絡方式等個人資料,即使案件主題是產品問題。
缺口
尚未確認 AI 工具是否會把個人資料寫入草稿或傳送至外部服務,需補做資料流向圖的個資標註。
責任人與期限
隱私負責人,2026-03-20 前完成標註並重新評估。
核准人
待隱私負責人評估後,由治理負責人確認是否維持 Proceed with Conditions。

資訊

這個修訂說明本身就是本課程要求的「一個逐步完成的範例,包含至少一處錯誤及修訂說明」(見 IL 202 教材契約)。練習時,請對照自己專案的 Readiness Review 草稿,檢查是否也把「主題不是個資」誤判為「不含個資」。
自我檢測

範例中「隱私準備度:not_applicable,理由:客服案件只涉及產品問題」這個判斷,最主要的錯誤是什麼?

範例中「隱私準備度:not_applicable,理由:客服案件只涉及產品問題」這個判斷,最主要的錯誤是什麼?

重點: 最容易被忽略的隱私缺口,往往藏在「案件主題聽起來不敏感」的假設裡;隱私準備度要看的是資料本身,不是案件的表面主題。

評量與學習證明

15 分鐘

評量與學習證明

完成四個單元後,你需要在平台上提交一份完整的 Enterprise AI Readiness Review:七個面向(資料、安全、隱私、整合、治理、營運、人員)各自標記狀態並附上證據,最後提出一項最終建議。狀態本身是你的自我評估,會交由教師逐一確認或覆寫。

資訊

這不是一份加權評分的測驗。IL 202 沒有像 IL 101/IL 201 那樣的百分比配分表;教師審查的是「七個面向的狀態判斷是否有證據支持、最終建議是否合理」,屬於判斷,不是把分數加總起來。誠實揭露 not_ready 的面向,比為了「好看」而灌水更重要,公開誠實的落差揭露正是這份審查存在的目的。
  • 你需要完成:提交涵蓋七個面向狀態與證據、以及最終建議的 Readiness Review
  • 你會被評量:教師會逐一確認或覆寫你的七個面向狀態,並判斷最終建議是否有充分依據支持
  • 通過條件:七個面向皆未被確認為 NOT_READY,且最終建議被確認為有依據支持,兩項須同時成立
  • 實作證據:一筆通過的審查會為 il202.readiness-review 這項能力留下證據,作為企業 AI 準備度審查技能證書的依據

注意

這項審查不代表你的專案「已經核准上線」或「不再需要治理審查」;它只代表這份 Readiness Review 本身的品質與誠實度通過了教師確認。是否真正進入 Pilot,仍由你的組織依內部治理流程決定。

重點: 教師確認的是七個面向狀態的判斷品質與最終建議是否合理,不是把分數加總;誠實揭露缺口比讓每個面向看起來都 ready 更重要。

接下來做什麼?