成熟度衡量的是組織能力，不是工具數量

企業的成熟度應以是否能持續創造、衡量與控制業務價值來判斷，而非採購了多少套生成式 AI 工具。若客服人員各自使用公開模型撰寫回覆，雖然看似效率提升，卻可能沒有權限控管、知識來源或品質紀錄；這仍屬於個人試用，而不是組織能力。

真正成熟的團隊會把 AI 連結到明確流程，例如縮短報價整理時間、降低缺貨率或減少客服轉人工比例，並建立資料責任人、使用規範、錯誤回報與改善節奏。這種能力可跨部門複用，才不會因為單一專案負責人離職，讓模型、提示詞與作業知識一併消失。

對製造、零售與貿易業而言，成熟度也可能因應用而不同。企業可能已能用傳統預測模型安排安全庫存，卻尚未具備讓 AI Agent 存取訂單系統的權限設計；因此診斷時應分別評估生成式 AI、預測模型與自動化流程，而不是用單一分數掩蓋風險差異。

• 以可重複的業務成果衡量，而非工具採購數量
• 將資料、流程、權責與模型監控一併納入判斷
• 依 AI 類型分開診斷，避免平均分數造成誤判

用五級路徑辨識目前所處位置

最實用的分級方式，是把能力由初始、受管理、穩健、量化管理到優化分成五級。初始級通常由少數熱心員工自行嘗試；受管理級已有專案目標與負責人；穩健級建立跨部門流程；量化管理級可持續追蹤成效與風險；優化級則能依數據快速調整，並把經驗複製到更多場景。

可採用明確分數判定：1级初始级（A＜1.0）、2级受管理级（1.0≤A＜2.0）、3级稳健级（2.0≤A＜3.0）、4级量化管理级（3.0≤A＜4.0）、5级优化级（4.0≤A≤5.0）。分級的目的不是取得漂亮稱號，而是讓經營層看見下一級必須補足的能力與投資順序。

另一類模型以級別 100 – 初始、級別 200 – 可重複、級別 300 – 定義、級別 400 – 勝任、級別 500 – 高效描述演進。兩種說法可互相對照：前者強調管理深度，後者強調流程可複製性；企業應選擇一種作為內部共同語言，避免不同部門各自使用不同標準。

• 初始：有想法但缺乏共用流程與責任分工
• 穩健：具備跨部門標準作業與可用資料
• 優化：以量測、回饋與治理持續擴大價值

成熟不等於一次到位，而是能做出正確的停止決策

成熟的投資管理，包含在證據不足時果斷停止。高達 95% 的新型 AI 工具專案投資尚未帶來理想報酬，常見問題是企業先承諾大型建置費，再回頭尋找使用情境。相反地，先界定假設、資料前提和成功門檻，才能避免技術可行卻沒有現場採用的結果。

例如需求預測專案不該只問模型是否能預測，而要先定義預測誤差、缺貨率、庫存週轉與規劃人員採納率。若歷史銷售資料遺漏促銷、斷貨或退貨原因，模型再先進也只能放大錯誤假設；此時應先補資料與流程，而非急著擴充算力。

因此，成熟度提升的第一個成果往往不是正式上線，而是一份可供 Go／No-Go 決策的報告。它應清楚載明哪些需求可做、哪些資料不足、預期效益如何計算，以及若暫緩開發，下一輪驗證需補齊什麼條件。

• 先驗證假設，再承諾大規模預算
• 把暫緩或停止列為正常且有價值的決策
• 以業務指標與採用率共同判斷成敗

以七大能力域避免只評估模型技術

完整診斷應涵蓋策略與領導、業務價值、資料與知識、技術與架構、治理與風險、人才與文化、營運與規模化七大能力域。已有調查以 7大能力域、22个能力项、五级成熟度等级建立量表；這種設計的優點是能找出真正瓶頸，例如模型團隊很強，但資料存取與法遵審核仍讓專案無法上線。

每個能力域都要對應可觀察證據。策略面可檢查是否有高階主管授權、投資優先順序與年度目標；資料面可檢查資料字典、擁有者、更新頻率與敏感資料分類；營運面則檢查是否有版本控管、事件通報、人工接管與服務等級目標。

中小企業不必複製大型企業所有制度，但不能省略責任歸屬。即使只有十人團隊，也應指定業務產品負責人、資料窗口與最終核准者。這能降低『大家都能用、卻沒有人對結果負責』的風險，並讓外部供應商的建議能落入企業自己的作業流程。

• 七大能力域應同時檢查，而非只測模型準確率
• 每一題要有文件、紀錄或數據作為佐證
• 小型團隊可簡化制度，但不可省略責任人

設計一致的題目、配分與評分校正

評估應採取可稽核的配分規則，而非由單一主管憑印象打分。建議每個能力項先定義『全部满足要求=1.0分、大部分满足=0.8分、部分满足=0.5分、不满足=0.0分』，再由業務、資訊、資安與財務代表各自評分，最後討論差異最大的項目。

例如『企業知識庫是否可用』不能只問資料是否存在，而要確認文件是否有版本、權限是否隨人員異動更新、回答能否顯示來源，以及錯誤答案能否回報。把抽象問題拆成可驗證條件，才能降低自評偏高，也能讓不同廠區或事業部使用同一套標準比較。

評分會議應保留證據連結與爭議紀錄。若資訊部認為已具備存取控制，現場卻指出外包人員仍可下載敏感報表，分數不應直接取平均，而要列為風險缺口與改善任務。這種校正過程本身，就是建立跨部門共同語言的重要步驟。

• 以四段配分取代模糊的好、普通、差
• 採多角色評分，找出認知落差
• 保留佐證與爭議，讓下次評估可追蹤

以六步流程讓診斷能被複製

建議採取六步標準化流程：界定範圍、蒐集證據、跨部門評分、校正差異、確認優先缺口、核定行動計畫。先限定評估範圍非常重要，例如先評估客服知識庫，而不是把全公司所有 AI 構想一次納入，否則資料量過大、結論也難以落地。

第二到第四步的核心是證據與校正。訪談不僅要問管理者，也要問實際輸入資料、覆核回覆與處理例外的同仁；同時抽樣查看提示詞、權限設定、事故紀錄與 KPI 儀表板。這能避免制度文件寫得完整，現場卻以私下試算表和私人帳號完成工作的落差。

最後兩步要把缺口轉成待辦事項，而非停在報告結論。每項行動都應標記業務所有者、技術所有者、完成證據、依賴條件與檢核日期。如此一來，下季重新評估時可比較分數變化與實際效益，而不是重複討論同一批抽象問題。

• 先縮小範圍，再把方法複製到其他場景
• 訪談、文件與系統抽樣要交叉驗證
• 每一個缺口都要有責任人與完成證據

高階主管要先定義價值假設與投資邊界

有效的 AI 策略，應先回答哪個流程的哪個決策要改善，以及改善後誰受益。例如採購部門若希望降低急單，不能只設定『導入預測 AI』，而要指定預測週期、可接受誤差、採購建議的核准流程，以及缺貨和庫存成本的計算方式，才能判斷投資是否值得。

近75%的企业已将AI整合至自身业务战略当中，但策略文件不等於執行能力。可將每個候選場景放入價值、可行性、風險與採用難度四象限：高價值且資料完整者優先 PoC；高風險的自主代理則先限制在查詢或草稿產生，不應直接賦予下單、付款或修改主檔權限。

預算也應分成探索、驗證、正式化與維運，而不是把全部費用塞進開發案。領先企業的投入趨勢顯示，2018年，领军者将自身技术总预算的15%专门用于AI；2021年，这一比例已增至27%；到2024年，这些企业计划在此领域投入41%的预算。重點不在照抄比例，而在保留治理、資料改善與營運監控的資源。

• 用流程 KPI 定義價值，而非以模型名稱定義專案
• 依價值、可行性、風險與採用難度排序
• 預算需涵蓋驗證、上線與持續維運

資料治理決定回答是否可信與可追溯

資料與知識的成熟標準，是讓使用者知道答案從何而來、是否仍然有效、誰有權閱讀。企業知識庫聊天機器人至少要保留來源文件、段落連結、版本日期與權限標籤；若模型無法找到足夠證據，系統應明確回答不知道或轉交人工，而不是產生看似合理的內容。

製造業常見的困難是 ERP、MES、品管紀錄與設備資料各自分散，且產品編碼、單位與時間粒度不一致。此時最先要做的不是訓練更大模型，而是建立共同主資料、資料品質規則與異常處理程序；否則需求預測與良率分析會因同一物料不同名稱而產生互相矛盾的結論。

涉及個資、客戶報價、配方或圖面時，還需分級資料敏感度，設定保留期限、遮罩方式、跨境傳輸規則與存取日誌。幾乎所有受訪者（97%）都認為監管會造成一定程度影響，77%表示合規是整個企業的優先事項之一；治理應在設計期完成，而非發生外洩後才補救。

• 知識庫回答須顯示來源、版本與權限依據
• 先處理主資料與品質規則，再追求模型複雜度
• 敏感資料要有分類、日誌、保留與刪除機制

LLMOps 與 MLOps 讓模型能在正式環境運作

正式營運需要的不是一次性部署，而是可追蹤、可回復、可監控的模型生命週期。傳統預測模型應監控資料分布、預測誤差與模型漂移；生成式 AI 則要追蹤檢索命中率、引用完整性、幻覺率、提示注入嘗試、延遲、單次成本與人工接管比例。

推論架構的選擇應以資料敏感度、回應速度、尖峰流量、模型可攜性與總持有成本決定。雲端 API 啟動快、彈性高，但要確認資料處理條款與用量成本；私有部署較能控制資料與模型版本，卻需負擔 GPU、維運與容量規畫。沒有一套方案適合所有流程。

無論採何種架構，都應建立版本登錄、測試集、核准流程與回滾機制。客服知識庫若更新了退貨政策，必須能確認哪一版文件、檢索設定與模型版本產生過哪些回答；這些紀錄不僅方便除錯，也是在稽核、客訴或事故調查時保護企業的必要證據。

• 預測模型重點監控漂移與誤差
• 生成式 AI 重點監控引用、幻覺、安全與成本
• 每次更新都要能定位版本並快速回滾

PoC 的目標是取得投資證據，而非做出展示品

高品質 PoC 應在小範圍內同時驗證技術可行性、業務效益與現場可用性。例如庫存預測 PoC 可以用既有銷售與庫存資料，比較多個預測模型，再把結果放進下單建議畫面，請採購人員檢視是否能解釋、修正與採納，而不是只展示一個準確率圖表。

開始前要明確寫下假設與基準線：目前人工整理報價需多久、客服首次回覆率多少、缺貨成本如何計算、哪些例外必須轉人工。PoC 的成功指標應同時包含品質、效率、成本、風險與採用，例如引用正確率、處理時間、每次查詢成本、敏感資料誤用事件與每週活躍使用者。

ALION 的實務做法強調先進行現場調查，使用接近正式業務的資料與環境製作最小原型，並把結果整理為 Go／No-Go 的依據。這能防止需求模糊時就直接進入大型開發，也讓『現在不該做』成為能節省後續成本的有效結論。

• 以真實資料與工作情境驗證，而非只做展示
• 成功指標須同時衡量品質、效率、風險與採用
• PoC 交付物應支援 Go／No-Go 決策

用階段門檻管理 PoC 風險與資源

PoC 建議依序完成目標與 KPI、範圍與資料、原型實證、效益判斷四個階段。每一階段都設置可停止的門檻：資料抽樣若無法支持基本品質就先補資料；模型若達不到最低標準就調整問題；現場若不願採用就重新設計介面與權責，而非直接擴增功能。

相較於一開始就寫完厚重規格書，小規模原型能讓經營者和現場用同一個可操作介面討論。它也能驗證隱性工作，例如業務員如何判斷報價例外、品管如何處理儀器異常、客服何時必須升級案件；這些往往沒有記在流程圖上，卻是正式上線成敗關鍵。

月費 20 萬日圓起的上游工程訂閱模式，提供需求梳理、設計文件與示範製作，適合仍在確認題目與資料條件的團隊。若後續進入正式開發，針對 1,000 萬日圓規模的開發案，上游工程約需 3 個月（約 60 萬日圓）的費用可自正式開發預算扣抵；實際範圍仍應依個案估價。

• 每個階段都要有繼續、調整或停止的門檻
• 讓現場以可操作原型回饋，而非只閱讀文件
• 把需求定義、設計與原型保留為後續資產

用 ROI 敘事讓財務、現場與資訊部門共同決策

AI 的 ROI 不應只寫成節省人力，而要拆成可驗證的收益與成本。收益可包含減少重工、降低缺貨、提高客服一次解決率、縮短交期與降低風險損失；成本則要包含資料清理、整合、模型推論、資安、教育訓練、人工覆核與維運。這樣才能避免上線後才發現用量成本或例外處理吃掉效益。

一項針對 59 個國家的 1,000 位高層訪談顯示，74% 的公司尚未從 AI 技術中取得實質性回報，僅 26% 開始跨出小規模實驗，產生明確效益。差異通常不在是否擁有最新模型，而在是否選對問題、持續衡量，並把成果嵌入原有的決策與獎酬流程。

經營層報告最好同時呈現保守、基準與樂觀情境，並列出資料品質、採用率與供應商依賴等假設。若預期效益必須依賴九成使用者改變習慣，就應把教育、主管支持與人工過渡流程列入投資計畫，而不是把採用率當成必然發生的結果。

• ROI 同時計入收益、維運成本與風險成本
• 以多情境試算取代單一樂觀數字
• 把採用率和流程變革視為財務假設

AI 治理要先界定責任、權限與可接受風險

可落地的治理制度，第一步是釐清誰能提出用途、誰能核准資料、誰能發布模型、誰要處理事故。對低風險的文案草稿，流程可以較輕；但涉及報價、排程、信用、醫療或付款的系統，必須有人工覆核、職務分權、稽核軌跡與明確的停用權限。

負責任 AI 不只是倫理宣言，也包括模型限制的公開說明。例如知識庫助理要告訴使用者回答依據哪些文件、是否可能過期，以及何時轉人工；預測系統要定期檢查是否對特定客戶、產品或地區造成系統性誤差，並保留調整與申訴機制。

治理小組應納入業務、資訊、資安、法務、人資與風險管理角色，且依專案風險分級開會。只有6%的中国受访企业已实施负责任AI实践，但50%的企业有志在2024年底之前采取这一行动。這反映企業普遍知道治理的重要性，卻仍需要把原則轉化為日常的核准表、測試清單與事件流程。

• 依用途風險分級，不以單一規範套用全部案例
• 高風險決策保留人工覆核與停用機制
• 將治理原則轉成角色、表單、測試與稽核紀錄

人才策略的重點是人機協作與角色再設計

提升採用率的關鍵，是讓員工理解 AI 幫他減少哪一種重複工作、保留哪一種專業判斷。例如客服人員可讓系統先檢索條款、整理回覆草稿與標示不確定處，再由人員判斷客訴情緒、特殊承諾與升級處理；這比宣稱『AI 取代客服』更容易建立信任與正確使用習慣。

訓練不能只教提示詞技巧，還要教資料分級、來源查核、錯誤回報、不得輸入的內容與人工接管條件。主管則需要學會看採用儀表板：哪些角色真的節省時間、哪些人只在測試期使用、哪些流程因例外太多而沒有改善，並依結果調整流程與教育。

專案能力也需從單一資料科學家擴大為產品與營運團隊，包括業務產品負責人、資料工程、資安、介面設計、模型維運與變革管理。若所有知識集中在外部廠商或一名工程師，即使系統上線，也難以持續優化並因應人員、資料或法規變化。

• 訓練焦點是查核、判斷與回報，不只是操作工具
• 用角色別採用數據找出阻力來源
• 建立跨職能團隊，降低對單一專家的依賴

將採用率與安全事件納入固定營運指標

AI 系統上線後，建議每週或每月檢視使用深度，而不只看登入人數。可觀察指標包括目標角色的活躍率、建議採納率、人工改寫比例、轉人工率、處理時間、使用者滿意度，以及錯誤回報是否在承諾時限內完成處理。這些數據能顯示系統是在真正改變流程，還是只成為偶爾展示的工具。

安全與品質指標同樣要進入營運檢討，例如未授權存取嘗試、敏感資料曝光、提示注入攔截、來源缺失回答、模型漂移、延遲與成本異常。對具行動能力的 Agent，還要紀錄每一次工具呼叫、授權範圍、失敗原因與人工接管結果，才能在事故後追溯責任。

成功案例顯示規模化需要營運設計配合。Walmart 得以實現在年底前涵蓋全美 95% 家庭的快速送達；另一項冷鏈應用成功降低 30% 緊急冷藏警報，維護成本亦下降近兩成。這類成果並非單靠模型，而是資料、流程、現場回應與績效追蹤共同累積。

• 以採納率與人工改寫率判斷是否真正被使用
• 將安全、品質、延遲與成本放進同一儀表板
• 具行動權限的 Agent 必須保留完整操作紀錄

前30天先對齊場景、基準與責任人

前 30 天最重要的任務，是把診斷結果收斂成一個優先場景與一套共同的成功定義。選擇時可優先考慮高頻、規則可說明、資料已有基礎且錯誤可人工攔截的流程，例如內部知識查詢、報價文件摘要、採購需求整理或需求預測輔助，而非一開始就讓 Agent 直接執行高風險交易。

此階段應完成流程走讀、資料盤點、利害關係人訪談與基準量測，並指定業務負責人、資料負責人、技術負責人和風險核准者。每個角色要知道自己須提供什麼證據，例如業務端確認例外情境，資訊端確認介接限制，資安端確認資料分類與存取方式。

30 天結束時的產出應是一頁式專案章程：問題、目標 KPI、範圍、排除事項、使用者、風險、資料來源、決策節點與預計成本。若這份文件無法讓現場與經營層用相同語言說明專案，代表需求尚未穩定，不宜直接進入正式開發。

• 鎖定一個高價值、可控風險的優先場景
• 完成基準量測與四類責任人的分工
• 以一頁式章程作為進入 PoC 的門檻

第31至60天以原型測試真實流程

第 31 至 60 天的目標，是用最小原型驗證真正的工作流程，而不是追求完整功能。知識庫助理可先納入少量高使用率文件，測試權限、引用、回答品質與人工轉接；預測專案可選一個產品群或廠區，與既有人工方法平行比較，確認誤差與作業負荷是否改善。

測試資料要保留未參與設計的案例，並刻意納入難例、過期文件、權限不足情境與惡意提示。使用者測試時，除了記錄正確率，也要觀察他們為何不採用建議：可能是介面不符合工作節奏、答案無法解釋、責任不清楚，或系統沒有處理例外的退場機制。

每週檢討應以證據調整，而不是依直覺追加功能。若回答品質不佳，先分辨問題出在文件品質、檢索、提示設計、模型選擇或使用者提問方式；若成本過高，則檢查快取、文件切分、模型路由與尖峰流量。這能讓團隊在擴大前掌握真正成本結構。

• 以平行測試比較 AI 與既有作法
• 刻意測試難例、權限與安全邊界
• 用問題根因決定改善方向，不盲目加功能

第61至90天以營運門檻決定擴大或暫緩

第 61 至 90 天應根據預先約定的門檻決定是否正式化。除了 KPI 是否達標，也要檢查資料責任人是否到位、資安與法務是否核准、維運團隊能否處理事件、成本是否可承擔，以及使用者是否已把新流程納入日常工作。只要其中一項未達標，就應明確列出補強條件，而非勉強上線。

若決定擴大，先複製到相近的流程或單位，並建立共用元件，例如身分驗證、權限控管、提示詞版本、評測集、日誌、成本儀表板與人工接管介面。這種平台化做法能減少每個部門重新採購、重複串接與各自承擔資安風險的情況。

若決定暫緩，也要保存資料盤點、測試結果、設計文件與程式碼，讓未來條件成熟時可延續。成熟的組織不把 No-Go 視為失敗，而是視為避免錯誤投資的成果；這也是從試點走向規模化前，最值得建立的決策紀律。

• 以 KPI、治理、成本與採用四類門檻共同決策
• 擴大時優先建置可複用的平台能力
• 暫緩時保留驗證資產，避免下次從零開始

參考來源

McKinsey AI 調查：https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai；NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework；Microsoft Responsible AI：https://www.microsoft.com/ai/responsible-ai；ISO/IEC 42001 概覽：https://www.iso.org/standard/81230.html