企業導入 AI，第一關不是模型，而是散落在 Excel 裡的資料

從資料倉儲往上走，AI 才能進入日常工作

把資料整理好，不代表企業轉型已經結束。它比較像把地基打穩，讓後續的資料分析、BI 儀表板、自然語言問答和 AI Agent 有一個可以依循的資料來源。資料底座若沒有權限、版本與定義，上層 AI 很可能只會更快產生一份看似完整、實際上口徑不一致的答案。

McKinsey 2026 年《State of AI》調查顯示，近九成受訪者表示所屬組織至少在一項業務功能中定期使用 AI，44% 表示 AI 已在企業層級擴大部署，高於前一年的 38%。但「有在用」不等於「已經全面得到財務回報」：37% 的受訪者表示 AI 對企業 EBIT 有正面貢獻，比例與上一年大致相近；約 6% 被歸為 AI 高績效組織。這些數字很值得企業停下來想一想，AI 的使用範圍擴大了，卻不表示每一個試點都已形成可衡量的營運價值。7

McKinsey 另一份分析也指出，工作流程重新設計，是受訪組織能否在生成式 AI 上看到 EBIT 影響的關聯因素之一；在使用生成式 AI 的受訪者中，21% 表示所屬組織已根本性地重新設計至少部分工作流程。這是調查中的相關性觀察，不代表只要改流程就一定提高獲利，更不是對每家企業的因果保證。但它讓我們看到，企業不能只把 AI 另外加在舊流程旁邊，而應該問：哪些決策、交接、等待或重複整理可以重新設計？8

對很多企業來說，資料入倉之後，第一個可落地的改變未必是全自動的 AI Agent，而是縮短取得答案的時間。以前每個月由同事花幾小時合併 ERP、倉庫與銷售報表，現在可以先把固定流程自動化，讓主管以自然語言詢問庫存週轉、通路銷量或品項變化。下一步再把這些查詢結果連到補貨、客服或預算流程，讓資料不只出現在儀表板上，而是成為實際行動的依據。

《數位時代》2026 年對電獺與 AotterClam AI 的報導，以企業每月整理業績、會計和庫存資料的情境說明資料工程的問題，也報導了傳統企業在考慮重建 ERP 後，轉而檢視舊系統輸出報表、另建資料倉儲的做法。這是個別企業的案例，不應直接推論每一家企業都不必更換 ERP；但它指出一個常被忽略的選項：若舊系統仍支撐核心營運，企業可以先改善跨系統資料使用方式，再評估是否需要整套汰換。9

數據治理不是把資料鎖起來，而是讓資料在正確範圍內被使用

資料倉儲是否能查詢，只是治理的一部分。真正的治理，還包含資料來源和使用目的、資料品質、欄位定義、保存期限、敏感度、權限、稽核紀錄、異常處理和責任歸屬。資料如果完全不能使用，就無法創造價值；但如果每個人和每個模型都能不受限制地看見所有資料，同樣不是成熟的治理。

台灣《人工智慧基本法》在 2025 年 12 月 23 日經立法院三讀通過。數位發展部整理的七大原則包括永續發展與福祉、人類自主、隱私保護與資料治理、資安與安全、透明與可解釋、公平與不歧視，以及問責。這些原則把資料治理放進 AI 發展的基本框架之中，也提醒企業：導入 AI 不只涉及模型能力，還牽涉資料如何取得、誰負責、如何揭露以及出了問題如何追溯。12

歐盟 AI Act 採取風險分級方式，不是對所有 AI 使用情境套用完全相同的要求。對特定高風險系統，相關規則涵蓋資料集品質、風險管理、活動紀錄、文件、人工監督、穩健性與資安等面向；歐盟官方時程亦經後續調整，部分高風險用途規則延至 2027 年起適用。因此，企業應依服務市場、實際用途與資料類型確認適用義務，不宜把「歐盟 AI 法」簡化成每一套內部 AI 工具都需履行同一份清單。13

我們在規劃資料治理時，會把問題拉回日常操作。銷售資料誰能看？客服紀錄是否含有個資？主管查詢結果能不能下載？使用外部 AI 模型時，哪些欄位會送出？原始檔案保存多久？如果某位同事離職或角色調整，權限何時撤銷？資料修正後，舊報表和模型答案如何更新？這些問題看起來比「模型有多聰明」不那麼吸睛，卻決定了企業能不能放心把 AI 放進工作流程。

2025 年人工智慧科技基金會對數據治理的專家訪談，也指出資料治理需要從策略和應用場景出發，不能只交由 IT 部門定義欄位、安裝工具。業務主管最清楚資料要支援哪個決策，資料團隊則能把定義轉成標準、品質檢查和資料血脈；兩者需要一起負責。訪談提出的治理能力，包括資料可被發現、可被授權存取、可除錯及可部署到真實流程，正好呼應企業需要把資料由「存得住」推進到「用得好」。6

要把治理變成可執行的工作，企業可以替每一個重要資料集建立一份簡潔的資料契約。契約不必寫成厚厚一本規範，但至少要列出來源系統、資料負責人、使用目的、每筆資料代表的粒度、更新頻率、必要欄位、允許值、品質門檻，以及資料異常時應通知誰。當新的 Excel 格式或欄位版本進來，團隊才能判斷這是正常演進，還是需要暫停匯入的重大變更。

例如，門市每日銷售表若承諾在每天上午九點前更新，企業就應定義遲到多久算異常、缺少哪些門市要先告警、金額與前一日相差多少需要核對。對商品庫存而言，則可設定負庫存、未匹配商品代碼和不合理的單日跳動等檢查。這些門檻不是要把所有特殊情況一律當錯，而是讓負責人知道哪些差異可以自動接受、哪些必須先釐清，避免資料品質只靠月底才有人發現。

權限也要依任務拆解，而不是只分「管理員」和「一般使用者」。財務主管可能需要看全公司彙總營收，店長只需要看所屬門市，分析人員可能可以使用去識別化的客戶分群資料，卻不需要取得電話或地址。角色權限若能細到資料集、欄位或列級，便可讓不同職務取得完成工作所需的最少資料。對敏感欄位還可以考慮遮罩、假名化或彙總查詢，降低資料外洩後的直接識別風險。

操作紀錄同樣要設計得有用。只記錄「某人使用過系統」不足以追查問題；企業可能還需要知道哪一份原始資料被處理、套用哪個規則版本、哪幾列被隔離、誰批准重跑，以及最後有哪些報表或查詢受到影響。當 AI 參與問答時，還要確認查詢內容、模型來源、回傳資料範圍與下載行為是否依政策留存。稽核日誌也可能含有敏感資訊，不能因為它是用來保護資料，就忽略日誌本身的權限和保存期限。

最後，企業應把資料保存、刪除和修正納入同一條生命週期。當個資已超過必要保存時間、客戶要求刪除，或上游系統更正了交易紀錄，原始層、清理後資料、彙總表與已排程報告要如何同步處理？備份裡的資料何時輪替？歷史報表是否必須依法留存？這些問題最好在導入前就與法務、資安和業務負責人確認。資料倉儲能把資料整合起來，治理制度則要確保整合後的資料仍依照企業規範被使用。