企業 AI 準備度評估：盤點資料、流程、人才與治理

企業 AI 準備度評估，究竟要評估什麼？

企業 AI 準備度評估，是在投入某個 AI 應用前，確認組織是否具備可合法使用的資料、可描述的工作、足夠的能力，以及對錯誤負責的治理機制。評估單位應是「哪個團隊、完成什麼任務、使用哪些資料、輸出交給誰」，而不是公司買了多少帳號。AWS 的評估指南把場景、目標、資料與基礎設施一起檢視；這支持從工作問題出發的方向，不代表有一張放諸四海皆準的成熟度分數。[S1]

為什麼買好工具，工作仍然接不起來？

員工可能已會下提示詞，卻不知道報價規則哪一份才是現行版；資訊部門已接好模型，業務主管仍無法說清楚什麼答案能寄給客戶。這些缺口分別出在知識、流程與決策責任。若只測模型寫得順不順，就會把上游問題誤認成模型能力不足，增加訂閱費卻沒有縮短真正的交付時間。

第一步：圈定一個可觀察的任務

先請業務負責人描述一件最近做過的工作，帶著去識別化輸入、實際成品與退件紀錄一起走一次。記下工作開始的觸發、結束的驗收、每次交接及例外。建議用「客服人員依核准維修條款整理回覆草稿，由值班主管確認後寄出」取代「導入智慧客服」；前者能指出資料、使用者、核准點與責任，後者還無法測試。這是本文的評估操作建議。

第二步：以四個面向收證，不靠印象打分

• 資料：列來源、內容維護者、更新日期、使用目的與權限；抽查現行版、過期版、互相矛盾及找不到答案的文件，確認能辨識它們。
• 流程：提供一份正常案件與一份例外案件，畫出輸入、處理、交接、核准與回復。問清楚現在誰能決定、AI 出錯時交給誰。
• 人才：讓實際使用者完成一題任務、指出一題錯誤、處理一題無答案。會操作介面不等於知道何時不能相信結果。
• 治理：用測試帳號演練無權限文件、撤回授權、取消作業與錯誤通報，留下操作紀錄和結果；規則寫在簡報裡不能算控制已生效。

NIST AI RMF 將風險管理放進系統的設計、使用與評估生命週期，並採自願、可依情境調整的架構。[S2] 因此，評估不應只在採購時填一次問卷；資料來源、使用目的或可執行動作改變時，都應重新看相關缺口。

第三步：把缺口寫成可完成的工作

一筆缺口至少包括：觀察到的事實、證據位置、影響的任務、風險、補救動作、應負責的角色、驗收方法與相依條件。例如「維修條款兩版並存，客服無法判斷」可轉成「由條款維護者標示有效版本，搜尋只帶入有效版；測試題同時放入兩版，輸出應指出現行條款與日期」。不要寫成「加強資料治理」，因為這種句子無法判定何時完成。

另一種缺口可能是「資料有維護者，但離職帳號仍可讀取」。可把處理工作拆成確認有效身分來源、建立撤權時點、清查服務帳號及補測既有連線；驗收則由管理者與測試者分工，分別留下權限變更與讀取結果。若目前只能人工定期清查，就明列暫行控制與覆查責任，不把尚未實作的自動撤權寫成已完成。

第四步：分清可試行、先補缺口與暫不進行

建議先判斷硬條件，再看整體成熟度。沒有可用資料權利、沒有成果責任人，或無法限制高影響動作時，不應以其他面向高分抵銷。可試行的場景，則先限資料、限使用者、限輸出用途；例如只產出草稿、不能自動寄送。單一場景暫緩不表示全公司不能用 AI，也可能改從公開資料分類、內部整理等較低風險工作開始。

假設情境：維修服務公司的內部知識助理

假設團隊希望縮短查維修條款的時間。評估發現操作手冊有版本與維護者，客訴紀錄卻含個資且用途未確認。可把第一階段限為核准手冊查詢，先不接客訴資料；由客服測「可回答」「應拒答」「版本衝突」三類問題。假設題目包括已下架零件、未核准補償與跨區保固，便能檢查系統是否會越界承諾。這是方法示例，並非 AiTOM 客戶案例或實際改善數字。

評估成果要如何驗收？

驗收看另一位接手者能否重做判斷：依清單找得到相同來源、看得懂缺口、用測試帳號重現權限限制，並知道試點遇到什麼情況必須停。建議交付場景說明、資料清冊、流程圖、缺口登錄、測試紀錄與試點決策六份材料，讓每個結論能回到證據。缺口數量變少不必然代表更成熟；沒有被檢查的面向也可能讓清單看起來漂亮。

可把重現紀錄做成「測試身分、資料版本、問題、預期行為、實際結果、證據、判定者」七欄。以撤回讀取權為例，測試者先確認原本可取得的文件，再由管理者撤權，以相同身分重新查詢；預期不只是不顯示文件名稱，答案、引用與先前快取也不應繼續透露受限內容。若只有介面遮蔽而底層仍可取回，該缺口不能標完成。交付時列明快取與既有對話是否已納入測試，並由接手角色確認未測項、暫時限制與下一次檢查的觸發條件，避免一張通過截圖被沿用到權限已改變的情境。

常見錯誤與適用限制

平均分最容易掩蓋關鍵風險；只訪談主管容易看不到第一線的例外處理；只查靜態文件容易把寫了規則當成做到了。本文不把成熟度等同資安認證、法律合規或生產環境驗收。涉及人事、授信、醫療等高影響用途，需要領域專業人員另訂評估與監督要求，不能沿用一般文書助理的門檻。

一定要先整理完所有資料，才可以開始嗎？

不用。先整理試點真正需要的資料範圍，確認來源、權限、版本與維護責任即可。若一開始要求全公司資料整頓完畢，往往會拖成無法驗收的大工程；但也不能用試點名義，把不明來源的資料直接送進外部服務。

準備度要用幾分才算及格？

沒有通用及格分。先為場景列不可妥協條件，再評估其餘缺口可否在受控試行中補齊。若使用量很小，可以採證據清單而不做總分；管理者需要的核心資訊是能做什麼、還缺什麼、誰來補，以及風險是否被限制。

多久需要重新評估一次？

以變更觸發比單看日曆更實用。新增敏感資料、開放外部使用者、從草稿改為自動執行，或更換模型與供應商時，都應重查受影響的能力。固定檢視週期可作補充，但不能取代重大變更前的檢查。

來源依據與證據界線

1. S1 · Assessment considerations and prerequisites

   AWS · 查閱 2026-10-22

   支持以場景、資料、組織與技術前提評估；本文缺口欄位與情境是編輯建議，不是AWS成熟度認證。

2. S2 · Artificial Intelligence Risk Management Framework (AI RMF 1.0)

   NIST · 查閱 2026-10-22

   支持全生命週期、依情境調整的自願風險管理；不提供本文通用及格分或保證。