多數企業講的「AI 導入」，本質上是把 AI 能力接進既有的 ERP、CRM 等核心系統，讓資料能被 AI 讀取與處理，而不是從零訓練一個新模型。因此真正決定成敗的，不是選了哪個模型，而是這個模型能不能真的碰到企業內部的資料。
我做了十九年軟體工程，近兩年轉做企業 AI 導入顧問。會做這個選擇，是因為我在客戶現場反覆看到同一件事：卡住的不是 AI，是資料。
McKinsey《The state of AI in 2025》調查（調查期間 2025 年 6 月 25 日至 7 月 29 日，1,993 位受訪者、涵蓋 105 個國家，2025 年 11 月發布）顯示，88% 的受訪者表示所屬組織已在至少一個業務職能中經常使用 AI，但只有 39% 認為 AI 對企業層級的 EBIT（稅前息前淨利）產生任何程度的影響，而且這 39% 當中多數表示可歸因於 AI 的 EBIT 還不到 5%。報告也指出，高績效企業從根本重新設計工作流程的比例，接近其他企業的三倍。
工具買了、模型接了，但如果資料進不來、流程沒有跟著調整，AI 就只是一個孤立的展示。
台灣企業的 ERP，比想像中更封閉
台灣許多企業使用的 ERP 系統對外部串接的支援相當有限，光是把資料匯出，或是為某張報表額外開一支查詢 API，都可能是一筆不小的額外費用。這是 AI 落地時卡關的第一道牆，而且與 AI 模型的能力無關。
這件事在公開調查中有直接的量化證據。PwC《2026 臺灣企業領袖調查》（2025 年 10 至 12 月執行，216 份有效樣本，全數為公開發行以上公司）發現，認為自身企業「最常使用的工具，可存取所有文件和資料」的臺灣企業比例只有 31%。換句話說，將近七成的企業，手上的 AI 工具根本碰不到自己的資料。同一份調查也顯示，臺灣企業在「技術環境有助於整合 AI」這項關鍵能力上，與全球及亞太的差距超過 20 個百分點。
人工智慧科技基金會《2026 台灣產業 AI 化大調查》則指出，仍有 43% 的企業資料被設備廠商鎖住，導致應用受限。這正是我在現場遇到的狀況的另一種樣貌：資料實體上存在，但企業自己拿不到。
ERP 廠商本身也承認這個結構問題，只是他們的解方是換一套系統。輔翼科技對零售業 ERP 自動化趨勢的分析提到，台灣許多電商平台的對帳單並不支援 API，只能提供格式複雜的 Excel，企業必須先把這些雜亂的資料翻譯並標準化，AI 才有辦法真正判讀；該文也把「API-First 的開放架構」列為實現自動化的必備條件之一。鼎新數智的分析則把「資料孤立」與「系統封閉」列為傳統 ERP 累積下來的五大數位瓶頸之中的兩項，並指出 AI Agent 要橫向解析並跨系統串聯資料，前提是先打破資訊孤島。
需要說明的是，上述兩份都是 ERP 廠商發布的內容，立場上會傾向導向自家產品。我引用它們，是因為連廠商自己都不否認封閉性的存在；至於封閉到什麼程度、要不要因此換系統，則是另一回事。
近兩年，我在客戶端遇到的 ERP 整合困難
在近兩年協助企業導入 AI 的過程中，我遇到的最大瓶頸多半不是模型準確率，而是資料的匯出與匯入格式。ERP 雖然都能匯出資料，卻只能匯出成專屬格式且必須手動操作，導致大量時間耗費在整理 Excel 上。
第一個例子，是一家想把營運資料拿出來做分析的客戶。乍聽之下是很基本的需求，但實際執行時才發現，他們的 ERP 雖然能夠匯出資料，卻只能匯出成系統自己專屬的格式，而且必須手動操作，沒有自動化的匯出流程；如果想針對特定資料表做即時查詢或串接，ERP 廠商會把「開放查詢 API」列為額外收費項目，費用相當高昂。結果就是，大量時間並不是花在建模或分析本身，而是花在把手動匯出的 Excel 檔案一筆一筆整理成可用的格式。（待補：每月投入的整理工時，以及導入後的變化）
第二個例子，是一家從事國際貿易的客戶。他們希望針對貿易單據做自動化 AI 處理，例如自動辨識、分類與核對單據內容。但因為使用的是全地端、非常封閉的 ERP 系統，光是把資料查詢出來、轉換成 AI 可以處理的格式，就要花費非常多的時間與人力。不是 AI 看不懂單據，而是 AI 根本拿不到乾淨、即時的資料。（待補：單據處理的件數規模與人力投入）
這兩個案例的共通點是：問題都不是出在 AI 能不能理解資料，而是出在資料能不能被安全、即時地送到 AI 面前。這一關，需要的是懂 ERP 架構、懂 API 串接、懂資料格式轉換與權限控管的人。
不用改 ERP，也能做 AI 自動化：三種務實解法
企業不需要等 ERP 廠商開放 API，也不必砸大錢做系統改造才能開始自動化。實務上的做法取決於 ERP 的型態：網頁型 ERP 可以用 vibe coding 開發瀏覽器插件，全地端 ERP 可以建立資料庫 schema 讓 AI Agent 讀取，兩者都能搭配 Excel 的程式化處理。
網頁型 ERP：用 Vibe Coding 開發 Chrome Extension
很多網頁型 ERP 在輸入資料時，除了上傳 Excel 之外，還需要人工去勾選、關聯許多其他表格的欄位，或是手動執行銷帳之類的重複操作。這類固定流程、固定步驟的操作，很適合透過 vibe coding 開發一支瀏覽器插件，讓插件自動上傳指定格式的 Excel、自動勾選並關聯對應欄位，省下大量重複的網頁操作時間。
具體做法是結合 Chrome DevTools MCP 與 Chrome Extension 開發：讓 AI 先透過 DevTools 觀察 ERP 網頁的 DOM 結構、Console 訊息與 Network 請求，再據此產生對應的瀏覽器插件，接著讓 AI 自己操作瀏覽器完成測試，最後由人驗收、回報錯誤，AI 再修正程式碼，形成可以反覆迭代的開發循環。這套流程把開發插件的最低技能門檻，從「會寫 Chrome Extension」降成「會描述流程、會操作 DevTools、會看錯誤訊息、會測試與驗收」。
#### 為什麼不直接讓 AI Agent 操作 ERP？
現在的 computer use 已經可以讓 AI Agent 直接操作電腦與瀏覽器，技術上完全做得到。我不建議把 ERP 直接交給 AI Agent 操作，主要顧慮不是它做不做得到，而是資料的去向。
AI Agent 每執行一個步驟，都必須把當下的畫面截圖或頁面內容送進模型才能判斷下一步。ERP 畫面上是什麼？客戶名單、報價、成本結構、庫存、薪資。這代表企業最敏感的營運資料，會隨著每一次操作被持續送出企業邊界。Chrome DevTools MCP 的官方說明本身就明白提醒：這個工具會把瀏覽器內容暴露給 MCP 客戶端，不要在其中放入不想被分享的敏感或個人資料。
瀏覽器插件的差別在於資料的流向。開發階段確實需要讓 AI 看過頁面結構，但那是一次性的，而且可以用測試環境或去識別化資料進行；插件完成之後，執行期跑的是已經寫死的程式邏輯，資料留在瀏覽器與 ERP 之間，不會每執行一次就外送一次。此外，固定流程用確定性的程式碼執行，在稽核軌跡、失敗可重現性與單位成本上，也都優於每次重新推理的機率性判斷。
這個顧慮在台灣特別值得重視。PwC 的同一份調查發現，臺灣企業在「負責任的 AI」與風險管理等治理面向的比例只有 28%，與全球的 51% 相差 23 個百分點，形容起來就是有油門卻沒有剎車。人工智慧科技基金會的調查則指出，企業內部有 61.8% 的 AI 應用完全脫離公司的管控。在治理尚未跟上的情況下，把核心系統的操作權整個交給雲端 AI Agent，風險並不對稱。
地端 ERP：建立 DB Schema，讓 AI Agent 讀取資料
如果是全地端、封閉式的 ERP，通常沒有網頁介面可以操作，插件這條路就走不通。這種情況下比較可行的做法，是先盤點並建立資料庫的 schema 文件，讓 AI Agent 先理解資料庫的結構與欄位關聯，再透過 AI 撰寫讀取特定資料的程式，直接向資料庫拿資料，做到資料的自動同步。這個做法不需要 ERP 廠商額外開放 API，只要拿得到資料庫的唯讀權限，就能讓 AI 持續取得乾淨、結構化的資料。
這個做法還有一個容易被忽略的好處：既然最終是透過程式取得資料，就可以在中間包一層自己的 API，針對不同的 Agent 給予不同的讀取權限。負責分析營收的 Agent 只看得到訂單與金額，負責處理單據的 Agent 只看得到單據相關的資料表，薪資、成本這類敏感欄位可以整個不開放。相較於把整個資料庫的唯讀權限直接交出去，這一層讓權限收斂到「這個 Agent 該看什麼」的顆粒度，也讓每一次存取都有明確的紀錄可以追。
Excel 自動化處理
除了以上兩種串接方式，Excel 的自動化處理同樣是被低估但很實用的一環。很多企業的資料交換，最終還是會落在 Excel 檔案上。透過程式化的方式做 Excel 的合併、拆分、整理，可以大幅減少資料在轉換過程中耗費的人力，更快把原始資料整理成日常作業實際需要的格式。
這兩種解法的限制與風險
瀏覽器插件與資料庫直讀都不是萬用解。前者受制於 ERP 廠商的使用條款與網頁改版，後者受制於權限取得與維護合約，兩者都需要在動手之前先確認清楚，而不是做完才發現不能用。
網頁型 ERP 開發插件，動手前至少要確認四件事：
- 使用條款：部分 ERP 廠商的合約會限制以自動化方式操作系統介面，需要先確認是否違反條款或影響保固。
- 改版維護成本：ERP 網頁一旦改版，插件的選擇器就可能失效。要事先講清楚後續由誰維護、多久檢查一次。
- 權限與稽核：插件是以登入者的身分執行操作，代表它拿到的權限就是這個人的權限。需要規劃操作紀錄與稽核軌跡，避免出事後查不出是誰做的。
- 開發階段的資料曝光：讓 AI 觀察 DOM 時，頁面上的實際資料會一併被送出。建議在測試環境或以去識別化資料進行。
地端 ERP 直讀資料庫，同樣有三個前提：
- 唯讀權限取得：不少 ERP 廠商將資料庫視為封閉範圍，願不願意開唯讀帳號要先談。
- 維護合約風險：部分合約載明第三方直接存取資料庫將影響原廠支援，這件事必須白紙黑字確認。
- 欄位語意逆向工程：多數封閉式 ERP 沒有 schema 文件，欄位命名也未必直觀，盤點本身就是一筆隱藏成本。
我的判斷原則很簡單：這兩條路都是在既有系統之外做加法，不動 ERP 本體，因此風險可控、可以先小範圍試；但只要牽涉到條款與權限，就必須在專案啟動前談定，不能邊做邊談。
AI 研究員、系統整合商、跨界顧問：三種視角的差異
企業導入 AI 時真正的角色分工，不是「AI 研究員對上軟體工程師」這麼簡單。市場上更常見的對照組是傳統系統整合商，他們懂串接卻不熟悉 AI 的能力邊界；而同時具備兩邊視角的人相對稀缺。
| 關注面向 | AI 研究員視角 | 系統整合商（SI）視角 | 跨界顧問視角 |
|---|---|---|---|
| 核心問題 | 模型準確率、演算法選擇 | 系統能否照規格串通、如期交付 | 資料能否即時取得，且值不值得串 |
| 優先處理 | 訓練資料品質、模型調參 | 介面規格、專案排程、驗收條件 | API 串接可行性、權限控管、AI 能力邊界 |
| 成功指標 | 模型評估指標（如準確率、召回率） | 系統通過驗收並結案 | 流程真正被使用，且維護得下去 |
| 最常遇到的卡點 | 資料樣本不足或標註品質不佳 | 需求變更、既有系統文件缺失 | 資料孤島、跨部門權限、廠商條款 |
| 典型盲點 | 低估企業系統的整合複雜度 | 高估 AI 能做的事，或低估它能做的事 | 需要同時說服 IT 與業務單位 |
Gartner 在 2025 年的預測指出，超過 40% 的代理式 AI（agentic AI）專案將在 2027 年底前被取消，主要原因包括成本攀升、商業價值不明確與風險控管不足；該預測也特別提到，把 AI 代理人整合進既有系統的技術複雜度很高，經常會打亂原本的工作流程，需要付出高昂的修改成本。
這個風險在台灣同樣存在。CIO Taiwan《2026 CIO Insight 調查報告》顯示，44% 的企業有超過一半的資料仍待清洗，同時近半數 CIO 正積極評估導入代理式 AI。一邊資料還沒整理乾淨、一邊搶著上 Agent，正是專案容易中途被取消的典型結構。
懂 AI 的人多半來自演算法背景，但企業要導入的是日常軟體與作業流程
市場上對 AI 理解夠深的人，多半來自演算法與模型研究；但企業真正需要導入 AI 的地方，是 ERP、CRM 這類最日常的企業軟體，以及每天重複發生的資料處理與表單作業。這中間存在明顯的能力落差。
懂 AI 演算法的人，不見得懂這些企業系統是怎麼長出來的、微服務架構是怎麼串起來的、一套完整的軟體開發流程與方法該怎麼落地；而真正懂這些系統與流程的人，過去多半也沒有機會深入接觸 AI。
這個落差在中小企業端尤其明顯。依據經濟部中小及新創企業署於 2025 年委託工業技術研究院進行的中小企業 AI 運用現況研究調查（聚焦員工數 10 至 199 人的企業），高達 63.9% 的中小企業把「尚無明確應用需求」視為最大挑戰。這不是企業不想用 AI，而是沒有人幫他們把 AI 能力和自己的營運痛點對起來，而做這件事需要同時看得懂技術與流程。
PwC 的調查也支持這個判斷：臺灣僅有 15% 的企業 AI 關鍵能力較齊備，低於全球的 21%；而在這群能力較齊備的企業中，表示營收因 AI 增加的比例是 55%，是其他企業（23%）的 2.4 倍。PwC 的結論是，如果企業直接導入 AI 工具，AI 工具很可能只是成本，打好關鍵能力基礎才更有機會從 AI 受益。
企業要的不是一個更聰明的模型，而是一個能被安全、穩定放進既有系統裡的解法。
常見問題
企業導入 AI 一定需要 AI 研究背景的人才嗎？
不一定。多數企業導入 AI 遇到的困難，是資料能否被 AI 系統穩定讀取、既有系統能否串接，這些更仰賴軟體工程與實作經驗，而非模型研究能力。真正需要模型研究能力的，通常是要自行訓練專屬模型的情境。
為什麼台灣企業的 ERP 系統特別封閉？
許多台灣企業使用的 ERP，對外部資料查詢或串接的支援有限，部分廠商甚至將「開放特定資料表的查詢 API」列為額外收費項目。PwC《2026 臺灣企業領袖調查》顯示，只有 31% 的臺灣企業認為最常使用的工具可存取所有文件和資料。
AI 導入卡關時，通常是模型不準，還是資料進不來？
以實務觀察來說，更常見的卡點是資料進不來，例如系統不支援即時 API、資料格式不統一、需要額外付費才能開放查詢，而不是模型本身的準確率不夠。
開發 ERP 瀏覽器插件，會不會違反 ERP 廠商的使用條款？
有可能，這件事必須在動手前確認。部分 ERP 廠商的合約會限制以自動化方式操作系統介面，或載明第三方直接存取資料庫將影響原廠支援。建議在專案啟動前就把插件開發與資料庫唯讀權限的範圍談清楚，避免上線後才發現影響保固。
為什麼不直接讓 AI Agent 操作 ERP，而要另外開發插件？
主要顧慮是資料流向。AI Agent 每執行一步都要把畫面內容送進模型判斷，等於讓客戶名單、報價、成本等敏感資料持續離開企業邊界；瀏覽器插件在開發完成後執行的是固定程式邏輯，資料不會每跑一次就外送一次，稽核軌跡也比較清楚。
企業想導入 AI，但 ERP 無法即時提供 API，該怎麼辦？
常見做法是先盤點哪些資料表是真正必要的，評估用唯讀檢視表、批次匯出或既有匯出功能取代即時 API，再視預算決定是否額外開通查詢介面，不必一開始就要求全面即時串接。
軟體工程背景轉 AI 顧問，需要重新學 AI 模型嗎？
需要補足模型相關知識，但既有的軟體開發、資料架構與維運經驗不會因此浪費，這些反而是判斷 AI 方案能不能真的落地的關鍵基礎，是單純學模型理論無法取代的。
延伸閱讀
- 我沒有離開技術，而是開始看見技術以外的問題：想知道我為什麼從軟體工程師轉做企業 AI 顧問，可以從這篇職涯故事看起。
- 關於張可佳｜企業 AI 導入／轉型顧問：完整的背景經歷、服務範圍與合作方式。
參考資料
- McKinsey《The state of AI in 2025: Agents, innovation, and transformation》（2025 年 11 月）
- PwC Taiwan《2026 臺灣企業領袖調查：厚積至深 銳意薄發》（2026 年 1 月）
- 人工智慧科技基金會《2026 台灣產業 AI 化大調查》
- CIO Taiwan《2026 CIO Insight 調查報告》
- 經濟部中小及新創企業署／工業技術研究院〈中小企業 AI 運用現況研究調查〉相關報導
- Gartner〈Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027〉（2025 年 6 月）
- 輔翼科技〈2026 營運趨勢：ERP 流程自動化〉（ERP 廠商觀點）
- 鼎新數智〈ERP+AI 如何落地？用「流程再造」實現企業智慧升級〉（ERP 廠商觀點）
- Chrome DevTools MCP 官方專案
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
最後更新：2026-08-25