導 AI 代理之前，先問一個俗氣的問題：你的客戶資料有幾個版本？

台中一家機械廠的業務副總，在 AI 助理的示範會議上問了一個很簡單的問題：「我們去年跟大立光做了多少生意？」

系統回了一個數字。副總皺眉：「不對啊，這個數字太小。」

後來查出來，ERP 裡有「大立光電」「大立光電股份有限公司」「Largan」三筆客戶，訂單分散在三個編號底下。AI 沒有錯，它老老實實地把「大立光」這一筆的金額加總告訴你。錯的是資料。

這場示範會的結論是「AI 還不成熟」。我覺得這個結論下得太快了。

事件背景

2026 年一份訪問了 1,000 位全球 C-level 主管的調查給出一個很有意思的數字：資料管理已經是 AI 落地最大的挑戰，佔 51%，超越了成本與人才。

這跟前兩年的敘事完全不同。2023、2024 年大家煩惱的是「找不到會做 AI 的人」「GPU 太貴」。兩年過去，模型變便宜了、工具變好用了，然後大家發現卡住的地方在更前面——資料拿不出來、對不起來、沒人敢背書。

同一時期，另一個變化把這件事的嚴重性推高了一個等級：AI 從「回答問題」變成「執行動作」。

這是本質差異。過去 AI 給你一份摘要，錯了你自己會發現。現在代理直接去 CRM 開單、去 ERP 建客戶、去發信給客戶——錯了就是已經發生的事，你只能事後補救。

本次重點

要讓代理安全上工，有三件資料基本功躲不掉：

• 主資料管理（MDM）：確保同一個客戶、產品、供應商在所有系統裡是同一筆。這是最基礎、也最常被跳過的。
• 實體解析（entity resolution）：判斷「陳志明」「陳志明先生」「CHEN CHIH-MING」是不是同一個人，並且要說得出為什麼。可解釋性在受監理產業不是加分項，是必要條件。
• 資料血緣與存取治理：這筆資料從哪來、誰動過、代理能看到哪些欄位。沒有這一層，出事時你連追查都做不到。

市場影響分析

對台灣使用者： 一般上班族最直接的感受，會是 AI 助理「講得很有自信但答案是錯的」。多數人的反應是不信任、然後不用。這其實是理性的反應——一個會編數字的助理，比沒有助理更危險。

要判斷你們公司的 AI 助理值不值得信，有個很土的測試法：問它一個你自己知道答案的問題。如果連這個都答錯，那它回答你不知道的問題時，你憑什麼相信？

對企業應用： 台灣企業的資料現況有幾個特別的問題。

第一是系統世代重疊。很多公司同時有跑了十五年的 ERP、五年前導的 CRM、去年上的雲端工具，三套系統對「客戶」的定義完全不同——ERP 用統編、CRM 用公司名、行銷工具用 Email。要合成一個人，中間的對應規則沒人說得清楚。

第二是集團子公司各自為政。同一個客戶在三家子公司分別開帳號、各自談價格，集團層級根本看不出「這家客戶總共貢獻多少」。這件事在導入 AI 之前只是報表不好看，導入之後會變成代理給錯報價。

第三是中文名稱的變體問題。全形半形、有沒有「股份有限公司」、英文名還是中文名、加不加「台灣」——這些在英文世界不存在的問題，在台灣是日常。這也是為什麼直接套用歐美的實體解析工具，效果常常不如預期，一定要拿自家資料實測。

市面上處理這一層的工具不少：Reltio 走即時與代理式 AI 路線、Semarchy 主打 DataOps 紀律、Profisee 深度綁 Microsoft 生態、CluedIn 用圖資料庫且採隨用隨付降低門檻。專攻比對本身的則有 Senzing 與 Data Ladder。選型的第一個問題不是功能比較，而是「跟我現有的資料棧合不合」。

對開發者： 如果你在做企業內部的 AI 代理，有一個設計原則我認為必須遵守：代理讀到的每一筆資料，都要能回答「這是哪裡來的」。

實務上這意味著幾件事。工具回傳給模型的內容要帶來源標記；代理的每一次寫入動作要留下完整軌跡；以及最重要的——當資料有衝突（同一個客戶有兩筆不同的信用額度）時，代理應該停下來問人，而不是自己挑一個。

這個設計會讓代理看起來「比較笨」，因為它會常常說「我查到兩筆不一致的資料，請確認」。但這種笨是對的。會自己猜的代理，才是真正的風險。

未來發展趨勢

我觀察到兩個方向。

第一，MDM 這類原本被視為 IT 內部事務的東西，正在變成 AI 的前置條件。過去 MDM 專案最難的是說服老闆為什麼要花錢做看不見的事；現在的說法變成「代理拿錯資料會出事」，這個論述有力得多。

第二，工具本身在往「為代理提供受治理脈絡」轉型。傳統 MDM 的產出是給人看的黃金紀錄，現在的產出是給代理呼叫的資料服務。這個轉變會重新定義這個市場，也會讓一批只做批次處理的舊工具被淘汰。

不過我要潑一點冷水：工具解決不了治理問題。 「客戶資料以誰的版本為準」「欄位定義誰說了算」「出錯誰負責」——這三個問題是組織政治，不是軟體功能。買了平台但沒有一個有實權的資料治理角色，專案會變成無止境的跨部門協調會。這是 MDM 專案失敗最常見的原因，二十年來沒變過。

TheAI學院 總結與評語

回到開頭那個機械廠的例子。他們後來做的事很簡單：花了六週，把 ERP 裡的客戶主檔做一次去重與正規化，訂出「統編是唯一識別碼」的規則，並指定財務部門為客戶主檔的擁有者。

再示範一次，數字對了。

評語：AI 專案的成敗，八成決定在你打開模型之前。先確認你的客戶資料只有一個版本，再談要用哪個模型。

給台灣讀者的具體建議，我講三個可以下週就開始做的事：

第一，做一次「自問自答測試」。 挑五個你自己知道正確答案的營運問題，去問公司的 AI 工具或直接查資料庫。答錯的那幾題，就是你的資料破口。這件事不用預算，一個下午就能做完。

第二，先指定「唯一真相來源」，再談買工具。 客戶資料以 ERP 為準還是 CRM 為準？產品資料以誰為準？這個決定不花錢，但它是後面所有事情的前提。決定不下來的話，買什麼系統都沒用。

第三，範圍要小。 別開一個「全公司資料治理」的專案，那注定做三年然後不了了之。挑一個代理最常用到的資料領域（通常是客戶），三個月做出乾淨的版本，用它證明價值，再往外擴。

延伸閱讀：站上的 AI 代理可觀測性與治理 談的是代理上線之後怎麼監控，跟這篇的「上線之前」剛好接得起來；AI 產出的程式碼誰來驗 則是同一個邏輯在開發端的版本。

資料來源

• McKinsey：The State of AI（Global Survey）
• Gartner Magic Quadrant for Master Data Management Solutions（各廠商官網轉載）
• Semarchy 官方調查說明

依公開資訊整理，各項調查數字以原始報告為準。