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

談企業導入 AI，大家很容易先問：「要選哪個模型？要用 ChatGPT、Claude，還是自己架一套？」但我們這幾年跟企業交流後，常看到的第一個實際問題不是模型排行榜，而是更基礎、也更容易被忽略的事：公司資料到底在哪裡？誰知道它代表什麼？能不能以可信任的方式整理起來，讓不同部門和不同工具重複使用？

很多企業並不是沒有資料。相反地，資料多到每個部門都有自己的版本。ERP 裡有一份、POS 裡有一份、電商後台有一份，業務同事寄來的 Excel 又是一份；人資、客服、庫存、會計也各自維護熟悉的工作表。平常需要做報告時，大家會先把檔案找齊，再手動整理欄位、刪掉小計列、對照代碼、確認日期格式，最後才開始回答真正的業務問題。資料明明已經存在，卻要先花大量人力把它翻譯成機器看得懂、同事也能信任的樣子。

這種落差不只是我們在客戶現場看到的個案。Salesforce 的《State of Marketing》相關統計指出，84% 的受訪行銷人員使用第一方數據，但只有 31% 對跨來源資料整合能力感到完全滿意。這兩個比例放在一起看很有意思：企業逐漸知道自己的資料很重要，卻仍有不少團隊無法把各處資料整理成一致、可用的整體。1

PwC 2026 年對美國 767 位營運與供應鏈主管所做的調查，也呈現類似的現實。89% 的受訪者表示，科技投資尚未完全帶來原先期待的成果；87% 指出資料品質不佳影響了數位計畫創造價值的能力。這不是在說每家企業的數據都一團亂，而是提醒我們：如果把系統買進來、把 AI 帳號開通，卻沒有同步處理資料品質、系統銜接和工作流程，投入未必會自動變成成效。2

所以，去年我們開始把技能點投入一件看起來沒有那麼炫、但實際上很關鍵的工作：讓 AI 協助企業清理與整理資料。現在走過一年，產品逐步成熟，我們推出 AotterClam AI。這不是要再多做一個聊天視窗，而是希望幫企業把散在舊系統、報表與檔案裡的資料，整理成可以治理、可以更新，也能被後續 AI 和 BI 工具使用的資料基礎。

為什麼大家談 AI，最後卻常常先卡在 Excel？

我們電獺做數據相關工作十多年，熟悉資料工程與數據治理的日常。外界認識我們，可能是從電獺少女開始；但電獺一路從創作工具、內容產品，走進數據廣告、第一方資料應用，再到企業 AI，背後始終在處理同一類問題：怎麼縮短資訊變成價值的時間。當我們在媒體與廣告科技現場長期處理使用者行為資料，就會知道資料收進來只是開始。真正困難的是整理、定義、權限、用途，以及日後能不能繼續更新。10 11

第一方數據的討論，過去常出現在行銷和廣告領域，現在則愈來愈接近企業營運的核心。它不只是品牌直接蒐集到的會員或交易資料，也包括企業在合法、合理的業務關係中累積的訂單、庫存、客服互動與服務紀錄。這些資料能不能被掌握，關係到企業是否能在自己的營運情境裡建立分析能力，而不是每次都仰賴外部平台提供的概略答案。

這股趨勢也不是把「第一方」三個字貼上去就完成了。eMarketer 引述 2024 年的調查指出，在一項 B2B 行銷人員調查中，67% 把資料合規與準確性列為重要優先事項；另一項全球行銷人員調查則有 84% 表示會運用客戶、第一方及交易資料來理解受眾。這些數字反映的是特定調查對象和當時的市場情境，不代表每一家公司都已經具備成熟的資料治理能力；但它們清楚說明，企業開始同時在意資料能不能用，以及用的方式是否合規、是否準確。3

我們也想特別提醒，第一方資料不等於「自己拿到的資料就可以任意使用」。資料從何而來、蒐集時告知了什麼、允許拿來做哪些用途、誰可以看、保存多久、能不能與其他來源串接，都必須有清楚規範。真正有價值的第一方資料，是在合法與透明的關係中累積、能被組織持續管理的資料資產，而不是換個名稱繼續做過度蒐集或無限制追蹤。

而進入企業 AI 的情境後，資料瓶頸會以很務實的方式出現。很多公司使用的核心系統已經運作多年，ERP、POS、倉儲或訂單系統可能各自有自己的資料庫，但系統之間沒有適合的 API，或是 API 雖存在，企業卻沒有預算、權限或專人把它接好。實務上，現場最常用的對外出口仍是 Excel 或 CSV：每週匯出一份銷售表、每天寄一封報表信，或在月底由同事把不同部門的工作表合併。

不應該因為資料以 Excel 形式交付，就把它當成沒有價值的資料。這些工作表往往承載著企業多年營運經驗，只是表格設計原本服務的是人，不是資料管線。第一列可能是合併儲存格的標題，第二列才是欄位名稱；同一欄裡有日期、文字和註記；一張工作表裡還混著明細、小計、合計與備註。不同部門甚至會用不同名稱指同一個欄位，或用同一個名稱表示不同概念。

例如「金額」可能是未稅金額、含稅金額、扣除折讓後的淨額，也可能只是尚未扣退款的訂單總額。表格看起來都叫金額，拿來相加卻會得到完全不同的營運結論。又例如，一列資料可能代表一張訂單，也可能代表一張訂單中的一個商品品項。如果系統不知道資料的粒度，就把訂單總額複製到每個商品列，總營收很容易被重複計算。這些不是 AI 靈不靈光的小問題，而是商業定義沒有被寫清楚時，任何報表或模型都可能出錯的根源。

我們從去年起接觸許多 Generative BI、data lakehouse 與 semantic layer 解決方案。這些工具能協助企業查詢、分析和呈現資料，但多數使用情境通常假設資料已經過整理，並放進可分析的資料庫或資料倉儲。換句話說，它們很擅長處理「已經準備好的資料」，不一定會替企業解決最前面的資料盤點、欄位清理、規則定義、關聯建立和排程更新。

這就是企業常見的導入順序問題：大家急著看見 AI 問答，卻還沒先把資料準備好。現場資料分散在系統、附件和不同版本的試算表中，導入專案便得先花時間找資料、問人、確認欄位，再設法把它們放進同一個可分析環境。傳統作法多半需要顧問與系統整合團隊逐案盤點，投入數週甚至更長時間，才可能建立第一版可供分析的資料倉儲。這不代表顧問或 SI 沒有價值，而是企業常常需要先完成一段費時的資料工程，才能開始討論 AI 能替業務做什麼。

台灣在地調查也讓這個問題更具體。資策會數位轉型研究院與人工智慧科技基金會的 2025 年製造業 AI 普及度調查，將傳統製造業與資通訊科技業分開觀察。報告指出，傳統製造業受訪樣本中，35.8% 導入 ERP 或 MES 等資訊系統，跨系統 API 整合比例為 13.2%；傳統製造業進入 AI 導入驗證或規模化階段的比例為 22.7%，也低於資通訊科技業的 39.1%。這份研究的樣本規模有限，分組樣本各為 53 家傳統製造業與 74 家資通訊科技業，因此不應直接推論成整個台灣產業的精確普查結果；但它很清楚呈現出一種結構性落差：有系統，不代表系統彼此打得通；有資料，也不等於資料已經能支撐 AI。4

當企業找我們討論資料清理時，常聽到的答案是：「先找人把資料抽出來，做 ETL，整理好再入倉。」ETL 指的是擷取、轉換和載入資料的流程，本來就是資料工程的重要工作。然而，如果每一種報表都要從頭客製一套處理程式，資料格式一改就需要重修，後續換人也得重新理解過往規則，導入成本就很難降低。企業所需要的不是假裝資料清理很簡單，而是把大量重複、可描述、可驗證的步驟，整理成能被重用的規則。

因此，我們開始問一個看似很簡單的問題：Excel 格式千變萬化，是否仍有一些穩定的資料處理原子，可以被明確描述？一份表要怎麼讀、哪些列該排除、欄位要轉成什麼型別、如何判斷一筆紀錄、如何與另一張表建立關聯，以及新檔進來後要怎麼更新。這些工作當然不會因為加上 AI 就自然變得毫無風險，但它們可以被拆成定義、規則、驗證和執行，而不是每次都只依賴某位同事記得「以前大概是這樣做」。

經過數月研究，我們把資料科學與資料工程中反覆出現的處理方式，整理成一套宣告式語法。所謂宣告式，是把目標與規則清楚寫出來，例如「這欄代表訂單日期」「小計列不要進明細」「以訂單編號與品項編號識別一筆資料」「金額以扣除折讓後的淨額計算」，而不是只留下一段難以接手的手工流程。AI 可以先分析沒看過的 Excel，提出欄位、格式和關聯的初步理解；接著由熟悉業務的人檢查和修正，把核定後的定義保存下來，再交給固定流程處理之後的檔案。

資料進來也不必只靠同事手動上傳。如果企業原有 ERP 能定期匯出報表，可以沿用既有排程寄送 Excel 或 CSV；如果系統有 API，也可以直接串接。匯出檔到達後，系統再依核定定義清理、驗證、更新和入倉。以 AotterClam AI 官方產品說明為例，目前列出 Excel 與 CSV 檔案匯入、API 與排程同步，以及以報表郵件附件自動處理等方式；實際可用的來源、格式和部署方式，仍要依企業環境逐案確認。5

這個設計思路的重點，不是讓 AI 永遠代替人判斷，而是把 AI 最適合的工作放在「協助理解未整理資料、提出候選規則」的位置；把業務確認放在「判斷欄位與指標的意思」的位置；再把固定規則交給可重現的資料流程去執行。這樣做，資料工程不會因為每次匯入都要重新呼叫模型、重新猜一次而失去穩定性，業務人員也不必在每次查詢時重新講解整張表的背景。

六項我們最在意的產品特色

1. Deterministic：理解一次，之後依核定規則處理

第一次遇到一張陌生表格時，AI 可以協助辨識可能的標題列、欄位名稱、日期格式、合計列與資料粒度。它不是直接把猜測當成正式真相，而是先提出一份可供檢查的定義。當使用者確認「每一列代表什麼」「哪一欄才是實際金額」「哪些列不該進分析」之後，系統就把這些判斷保存成正式規則。

下次同一種格式的檔案進來，資料管線依照已核定定義執行，不需要再次消耗模型資源去推測每個欄位的用途。這就是 deterministic 的核心：不把每次清理都當作新對話，而是讓已經通過業務確認的步驟成為可以重複執行的程序。

但 deterministic 並不等於永遠不會出錯。資料來源可能改版，供應商可能把欄位重新命名，甚至同一個系統不同部門匯出的檔案也可能格式不同。固定規則遇到不相容的變動時，正確的作法不是硬把錯誤資料塞進倉儲，而是偵測結構改變、暫停或隔離受影響資料，再請人確認。穩定性來自明確規則與變更管理，不是宣稱「AI 一次學會，以後什麼都不用管」。

2. Replayable：可以重跑，而且不會因為重送就把數字灌大

企業資料匯入幾乎一定會遇到重送。報表寄錯又補寄、同一個檔案上傳兩次、排程中斷後重新執行，或會計月底修正上個月的紀錄，都是日常情境。若系統只把每次收到的內容往資料表後面新增，重跑一次便可能讓營收、訂單數或庫存量憑空增加一倍。

因此，系統需要知道什麼條件能辨識同一筆業務資料。可能是訂單編號加商品明細編號，也可能需要結合門市代碼、交易日期和流水號。這個識別方式應由企業的業務定義決定，不能只以檔名或列號當作永久唯一鍵。當相同紀錄再次出現，系統要能依規則更新既有資料，或把它辨識為重複項目，而不是不加判斷地累加。

可重跑也讓修正有了正規流程。假設我們發現過去把日期讀成文字、折讓欄位漏減，或同一張訂單的商品列被錯誤加總，只要保留原始檔案、處理定義的版本與執行紀錄，就能先修正規則，再重新處理受影響的期間。這使資料結果可以追溯，也讓企業有機會回答「這個數字怎麼來的」「哪個版本的規則產生這份報表」。

要注意的是，重播資料並不是無限保存所有原始檔案的理由。原始資料是否含有個人資料、保留期限如何設定、誰有權重新執行、舊版本是否應刪除或遮罩，都必須納入企業既有的資料政策。重跑能力解決的是技術可恢復性，不會自動替公司完成資料保留與個資管理責任。

3. Reviewable：AI 怎麼理解資料，能讓人檢視和修正

很多資料整理經驗只存在資深同事腦袋裡。大家知道「報表上面那兩列不要」，知道某個欄位雖然寫「狀態」卻代表出貨狀態，也知道兩份清單要用哪組代碼才能對起來。短期看來，問那位同事是最快的辦法；長期看來，這些關鍵知識如果沒有被記錄，就會隨著工作交接、組織調整或人員離開而消失。

Reviewable 的意思，是把 AI 對資料的理解攤開來檢查：欄位如何命名、欄位型別是什麼、每一列代表訂單還是訂單品項、哪些欄位可以加總、哪些資料應該排除、不同來源如何連接。業務人員能補充領域知識，資料人員可以核對技術設定，管理者則能確認指標定義是否符合經營口徑。這不是為了增加簽核，而是要把原本只靠口耳相傳的資料規則，變成組織可以共同維護的資產。

可檢視也應該包含變更紀錄。當某個欄位定義從「銷售額」改成「已扣除退款的淨銷售額」，企業要能知道是誰在什麼時候調整了規則，受影響的儀表板有哪些，舊報表是否仍採用舊口徑。資料定義不是一次建好就永遠不變，它會跟著商業流程、產品型態和法規要求演進；可追蹤的版本管理，可以避免同一個名稱在不同部門各自代表不同數字。

4. Validatable：資料先通過檢查，再往分析和 AI 問答流動

自動化不應該只是讓錯誤跑得更快。資料欄位不存在、日期格式不符合預期、商品代碼找不到對應商品、訂單總額與明細加總差距太大，這些問題都應該在資料進入分析層之前被指出來。

我們把驗證想成一道品質閘門。基本檢查可以確認欄位是否存在、型別是否正確、必要欄位有沒有空值、主鍵是否重複。接著再加上業務規則，例如交易日期不能晚於匯入日期太多、折扣不能大於原始金額、已取消訂單不應列入有效營收，或每家門市每週都必須有資料。對財務或庫存資料而言，與原始 ERP 匯總數字做對帳也很重要，否則看起來格式正確的檔案，仍可能在某個轉換步驟中漏掉一整批資料。

驗證結果不必只有「通過」或「失敗」兩種。若錯誤涉及高風險欄位，例如交易金額或個人識別資訊，系統可以先隔離資料並請人確認；若只是非關鍵備註多了新格式，也可以先標記警示並繼續處理其他欄位。把警示等級與業務影響分開，才能避免不是完全停工，就是忽略所有異常的兩難。

人工智慧科技基金會在 2025 年台灣產業 AI 化調查中，透過專家訪談談到資料標準、資料品質與應用場景必須一起考量。資料不只是被保存下來就算治理完成，還要知道它是否能支援實際決策、是否有負責人、能不能在資料改變時被發現並修正。6

5. Evolvable：新來源進來，既有資料可以逐步長出新關聯

企業不需要等到所有部門都完成資料盤點，才開始第一個分析專案。一開始只有銷售明細，就先回答「最近哪些商品賣得最好」；後來加入庫存表，可以看到「哪些商品銷售增加，庫存卻逐漸不足」；再接上客戶或會員資料，才有機會理解「不同客群購買什麼商品、回購時間多久」。資料模型可以依照真實需求逐步擴張，而不是一開案就要求一次收齊整個企業所有來源。

然而，新增資料也不是把兩張表用看起來相似的文字欄位直接接在一起。商品名稱可能有縮寫、空格或新舊品名；不同系統的客戶編號也可能各自獨立。關聯建立時，要確認雙方的識別鍵是否穩定、資料是否一對多或多對多、歷史紀錄是否需要保留，以及未匹配的項目要如何處理。若把「台北門市」和「台北店」錯誤視為兩家店，或把兩家同名客戶合併，後續 AI 解讀再流暢也救不了資料模型的錯誤。

讓模型可演進的另一個好處，是企業可以把每次新增來源當成擴大資料價值的機會。過去只有月營收時，管理者只能看結果；加上促銷活動與庫存變化後，就能比較活動前後的庫存週轉和銷售差異；若再納入客服反映，還能追查熱賣品的退貨原因。資料之間的關聯逐步增加，舊資料也可能因新脈絡而回答更多問題。

6. Query-ready：清洗資料時，也把業務語意一併留下

清除空白、統一日期、修正錯字，只是資料整理的一部分。若資料進倉後還是不知道「商品」「訂單」「客戶」各指什麼，不知道哪個欄位是正式營收，也不清楚兩張表該如何連接，那麼 AI 問答每次仍得重新猜一次，甚至可能在看起來合理的答案裡犯下不容易察覺的錯誤。

因此，我們希望在資料清理階段，一起建立最基本的語意層（semantic layer）。語意層會把資料欄位轉換成企業真正使用的概念：一筆銷售的粒度是什麼、淨營收如何計算、退款應該如何扣除、產品分類採用哪個代碼、日期以交易日還是出貨日為準，以及不同資料集的關聯如何建立。這樣做的目的，是讓 BI 工具或 AI 查詢時有一套明確的業務語境，不用看到欄名後便自行推測。

同一個指標在不同情境下也可能有不同版本。財務部門可能以發票認列的營收為準，營運團隊可能以已出貨訂單觀察銷售，行銷部門則想看扣除取消訂單後的活動轉換。這些口徑不一定要強行統一成一個答案；更務實的作法，是把每個指標的名稱、計算方式、適用場景和負責人說清楚，並在使用者提問時讓系統知道該套用哪一種口徑。

當資料粒度、關聯和指標計算方式被明確描述，AI 的工作就不只是把中文問題翻譯成資料庫查詢。它也能根據語意層辨認問題中提到的是哪種銷售額、哪個期間、哪個商品維度，以及哪些資料不應被混加。當然，語意層仍需要業務負責人核定；它不是一個能從欄位名稱自動推導所有商業邏輯的魔法模組。

從資料倉儲往上走，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 參與問答時，還要確認查詢內容、模型來源、回傳資料範圍與下載行為是否依政策留存。稽核日誌也可能含有敏感資訊，不能因為它是用來保護資料，就忽略日誌本身的權限和保存期限。

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

部署方式、模型選擇與導入建議

不同企業對資料留存與模型服務的要求不一樣。有些可以在公有雲環境使用受控服務，有些則必須放在企業私有雲、VPC 或內部機房。AotterClam AI 官方資料列出企業私有雲與地端部署選項，並說明可設定角色與權限、操作紀錄，也提供本地推論或連接外部 AI 模型等不同方式。5

談到「資料不離境」或「資料不出公司」，我們會建議把這句話拆成具體的資料路徑來核對。資料庫本身放在哪裡？備份和日誌存在哪個區域？模型推論在哪裡執行？使用者問問題時，系統會把哪些欄位、摘要或查詢結果送往模型？支援人員能否接觸資料？服務供應商的子處理者有哪些？只回答「我們架在地端」還不夠，因為一個企業系統通常還包含備份、監控、更新、外部模型和維運通道。

同樣地，BYOK（Bring Your Own Key）通常指企業自備模型服務的 API 金鑰；BYOAI 則常用來描述企業選擇或帶入自己的 AI 模型與服務。它們是採用模型與費用管理方式，不代表資料自動獲得保護，也不等於個人版 ChatGPT 或 Claude 訂閱一定包含企業 API 權限。實際能否連接、如何計費、資料是否用於模型訓練、日誌保留多久，都應該依模型供應商的服務條款與企業部署設定確認。

MCP 可以讓 AI 工具透過標準化方式連接資料服務，但 MCP 本身不是隱私保護協定，也不會自動決定資料應該開放到什麼程度。企業需要定義可供查詢的資料範圍、欄位遮罩、角色權限、查詢紀錄與外部模型的使用政策。若使用者只需要產品庫存與銷售趨勢，系統不應因為同一個資料庫裡有客戶電話或地址，就把那些欄位一併暴露給模型。

導入時，我們建議從一個明確的業務問題開始，不要先承諾「所有資料都要 AI 化」。企業可以先選一個有固定工作量、資料來源可取得、管理者也在意的場景，例如每月銷售彙整、門市庫存分析、供應商交期追蹤或客服問題分類。把目標問句說清楚，才能知道要接哪些資料、哪些欄位重要、驗證方式是什麼。

接著，盤點兩到三份最關鍵的來源文件或系統輸出。要找出每份資料的擁有人、更新頻率、欄位定義、保存規範、主鍵和已知例外。這一步不需要先把每個系統都換掉；先確認現有資料是否能按排程匯出、是否有權限讓系統讀取，以及資料能否在企業指定的環境內處理。若資料目前只能手動寄送，也先把寄送方式、檔案命名和收件規則定下來，讓流程穩定再談擴充。

再來，與業務一起定義「正確答案」的判準。若目標是每月淨銷售額，至少要說明取消訂單、退款、折讓、稅額和出貨時間如何計算；若目標是庫存週轉，則要約定期初庫存、期末庫存、在途貨品與缺貨天數如何處理。可以從最近三個月份挑出真實案例，和現有人工報表逐筆比對，確認差異落在哪些規則，不要只測一張漂亮的樣本檔。

接下來才安排驗證和擴充。先測試常見檔案，也要刻意測試錯誤檔、欄位改名、空值突然增加、重送重複檔、歷史資料回補和新代碼加入等情境。通過後再開始排程更新，並設定資料異常通知、版本保存和人工例外處理流程。當第二個來源加入時，企業就可以觀察資料關聯是否穩定，再決定是否把第三個部門納入。

成效衡量也要從開始前就設定。可以記錄同事每月整理資料的工時、從提問到取得可信答案需要的時間、人工重工或對帳差異的頻率、管理者在決策前等待報表的天數，或特定庫存和客服指標的變化。若只計算 AI 問答的使用次數，容易把「大家試用過」誤認為「業務流程改善了」。當企業能說清楚導入前後的差異，才知道下一筆預算該投在資料品質、流程自動化，還是更複雜的模型應用。

PwC 2026 年調查的另一個觀察值得納入導入策略：受訪營運主管中，89% 認為可採取行動的資料比追求全面完整的資料更重要，73% 認為資料不必完美也能創造價值。這不等於可以忽略資料錯誤，而是說企業不必等到所有資料都「百分之百乾淨」才開始。更實際的方式，是先針對一個高價值場景提高關鍵欄位品質，同時持續改善其餘資料，再以明確驗證與風險分級來守住底線。2

AotterClam AI 的位置：先讓資料能用，再選擇想用的 AI

AotterClam AI 的出發點，就是企業不一定能在短時間內重建所有 ERP，也不必先把資料搬到另一個不熟悉的系統，才開始做資料應用。依照我們目前的產品設計，AI 協助理解 Excel、CSV 等來源，產生可檢查的整理定義；資料再依固定規則驗證、整理和入倉，後續由企業使用權限管理、稽核紀錄、BI 儀表板與 AI 問答等功能。部署與模型選項，則依企業的雲端、VPC 或地端需求討論。5

這種方式和 AI-ERP 的差異，不應該被簡化成「哪一種一定比較好」。AI-ERP 適合企業正好要汰換核心營運系統、希望連流程與資料標準一起重新設計的情境；但如果舊 ERP 仍支撐大量日常作業，整套更換可能涉及資料遷移、流程重整、人員訓練、外部系統串接和停機風險。AotterClam AI 這類資料治理平台，則可以先處理不同來源已經吐出的資料，讓企業在維持核心系統的情況下增加跨系統分析能力。這是降低部分遷移成本的一條路，不代表每家公司都應該永遠不換 ERP。

其實電獺自己不久之前，在一家傳統企業的訪談過程中，發現直接重建 ERP 可能影響已經深度依賴舊系統的流程（因為都是人機協作，流程綁定員工），於是開始評估利用既有報表建立資料倉儲的替代方案。這個案例展示的是「先把系統輸出的資料整合起來」的價值；若企業舊系統已停止維護、存在重大資安風險，或已無法支援核心作業，重新建置仍可能是正確選擇。真正應該比較的，是整體轉型成本、營運風險、未來維護能力和預期效益，而不是只比較產品名稱裡有沒有 AI。9

電獺與福茂數位智能科技於 2026 年公布合作，內容包括共同開發企業級 AI 數據治理產品與服務，也希望將傳統產業的數位轉型經驗轉化為能提供給其他企業的解決方案。14我們的看法很直接：企業不需要為了追 AI 浪潮，把每一份資料都送給模型，也不需要先用一個聊天介面包裝所有問題。更重要的是先把資料管理成可理解、可追溯、可更新的組織資產，建立清楚的權限和用途，再依真正的工作需求選模型、接工具、改流程。模型會換、API 會改、價格會變，但企業對自己的產品、客戶、訂單與營運方式的理解，應該留在企業可以管理的資料基礎裡。

目前 AotterClam AI 在製造業、傳統產業、有任何使用類似鼎新 ERP、傳統 CRM、CDP 管理平台的企業，已經有很迅速的導入實例，或許與我們洽談後您會發現，其實不用大費周章的鏟土挖地、重新處理系統，也很便捷的後來居上，歡迎有類似需求的朋友填寫表單與我們交流。導入不必從寫出一份很大的 AI 願景開始，可以從一張每個月都要人工整理的報表、一個常常等不到答案的問題，或一段經常重複對帳的流程開始。先把問題說清楚、把資料盤點好，再一起判斷哪個部分值得自動化，會比先買一堆工具更接近真正的轉型。

最後也自我介紹一下：我們是電獺，是電獺少女的那個電獺。大家可能先認識我們的內容品牌，但電獺一路以來也持續做資料與科技產品，從應用工具、內容與廣告科技，走到第一方資料、數據治理和企業 AI。十多年來，我們關心的事情一直是怎麼把知識、內容和數據更快變成能被使用的價值；現在把這份經驗用在 AotterClam AI，希望讓企業不用先有一整支資料工程團隊，也能逐步把資料整理成自己的能力。

AI 很熱，資料卻不能只跟著熱度走。資料要有人定義、有人負責，也要能在規則改變時重跑、驗證和追查。當企業願意把這些看似不新鮮的基礎工作做起來，AI 才有機會從一次性的答案，變成可以長期累積的工作能力。

原作：豬排博士（電獺共同創辦人兼副執行長）｜改寫：電獺大叔（電獺共同創辦人兼執行長）

參考資料

1. Salesforce Marketing Statistics: First-Party Data and Data Unification
2. PwC 2026 Digital Trends in Operations Survey
3. EMARKETER: 2025 Trend, B2B Firms Are Laser-Focused on First-Party Data
4. 2025 製造業 AI 普及度調查報告
5. AotterClam AI 官方產品介紹
6. 人工智慧科技基金會：好數據才能讓 AI 落地，數據治理 1234 原則
7. McKinsey: The State of AI in 2026
8. McKinsey: The State of AI, How Organizations Are Rewiring to Capture Value
9. 數位時代：不只是少女！電獺打造 AotterClam AI，憑兩大核心肌群搶攻 B2B 企業市場
10. 電獺官方公司介紹
11. AotterTrek 官方介紹：第一方數據研發沿革
12. 數位發展部：立法院三讀通過人工智慧基本法
13. European Commission: AI Act Regulatory Framework
14. 電獺：福茂數位智能科技與電獺合作公告