判斷框架
導入前先回答四個問題
工具展示很容易，能不能進入日常營運，取決於開工前是否把問題定義清楚。
01 BUSINESS
問題是否值得解？
盤點耗時、錯誤、等待與營收流失，確認它不是一次性需求，也不是只靠加一個欄位就能解決。
02 DATA
資料是否能合法使用？
確認來源、品質、權限、保存期限與敏感程度，避免模型做好後才被資安或法務喊停。
03 OPERATION
誰會使用、誰要負責？
定義人機分工、例外處理、覆核與升級機制，避免 AI 變成沒有人敢採用的黑盒子。
04 VALUE
成效如何衡量？
以基準線比較節省時間、錯誤率、完成率與風險，不用「看起來很聰明」當驗收標準。
ROI
AI ROI 不是只算 API 費用
完整成本應包含資料整理、系統串接、人工覆核、教育訓練、資安治理與後續維運。
| 評估面向 | 應記錄的基準線 | 可驗收的改善 |
|---|---|---|
| 時間 | 每件平均處理時間、等待時間 | 週期縮短比例、每月節省工時 |
| 品質 | 錯誤率、退件率、重工次數 | 錯誤下降、一次完成率提高 |
| 營收 | 漏接、流失、回覆速度 | 轉換率、留存或服務量提升 |
| 風險 | 敏感資料暴露、無法追溯的決策 | 可稽核率、人工覆核與例外處理覆蓋 |
先設定「不做」與「停止」條件
如果資料不能合法取得、問題發生頻率太低，或人工流程已經足夠便宜，就不應為了追趕潮流硬做 AI。
DELIVERABLES
一次導入診斷應該產出什麼
場景清單與優先順序
依商業價值、可行性、資料條件與風險排序，清楚說明哪些先做、哪些不要做。
投資與回收假設
列出基準線、預期改善、必要成本與驗證週期，讓內部提案有共同判斷標準。
下一階段驗收條件
定義試做範圍、品質指標、人工覆核與停止條件，避免 PoC 成為沒有終點的展示案。
FAQ
常見問題
沒有 AI 團隊也能開始嗎？
可以。評估階段需要的是熟悉流程、資料與決策的人，不需要先成立工程團隊或購買平台。
一定要先做 PoC 嗎？
不一定。若問題、資料或責任邊界尚未清楚，先做 PoC 只會把不確定性帶進開發。應先完成診斷，再決定是否試做。
元域智能會指定工具或廠商嗎？
不會。建議以需求、風險與總持有成本為依據，架構與驗收標準可交由不同團隊執行。