多數企業講的「AI 導入」，本質上是把 AI 能力接進既有的 ERP、CRM 等核心系統，讓資料能被 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 檔案一筆一筆整理成可用的格式。
| 欄位 | 內容 |
|---|---|
| 背景 | 網頁型 ERP 客戶，想把營運資料匯出做分析 |
| 問題 | ERP 只能匯出成系統專屬格式，且須手動操作、無自動化匯出流程；針對特定資料表開放查詢 API 是額外高昂收費項目 |
| 介入 | 評估以瀏覽器插件（Chrome DevTools MCP + Vibe Coding）取代人工手動匯出與整理，讓固定格式的上傳、勾選、關聯欄位動作自動化 |
| 結果 | 待補：每月投入的整理工時，以及導入後的變化 |
| 限制 | 因保密考量隱去公司名稱、產業別與確切資料規模；本文尚未取得量化前後對照數字，暫以「待補」標示，避免用形容詞包裝成已驗證的成效 |
第二個例子，是一家從事國際貿易的客戶。他們希望針對貿易單據做自動化 AI 處理，例如自動辨識、分類與核對單據內容。但因為使用的是全地端、非常封閉的 ERP 系統，光是把資料查詢出來、轉換成 AI 可以處理的格式，就要花費非常多的時間與人力。不是 AI 看不懂單據，而是 AI 根本拿不到乾淨、即時的資料。
| 欄位 | 內容 |
|---|---|
| 背景 | 從事國際貿易的客戶，使用全地端、封閉式 ERP 系統，希望對貿易單據做自動化 AI 處理 |
| 問題 | 全地端封閉式 ERP 沒有 API 可串接，光是把資料查詢出來、轉換成 AI 可處理的格式，就要耗費大量時間與人力；問題不在 AI 看不懂單據，而在 AI 拿不到乾淨、即時的資料 |
| 介入 | 評估建立資料庫 schema 文件，讓 AI Agent 理解資料表結構後直接向資料庫（唯讀權限）取得結構化資料，取代人工整理 |
| 結果 | 待補：單據處理的件數規模與人力投入的前後對照 |
| 限制 | 因保密考量隱去公司名稱、單據類型與確切件數；同樣尚未取得量化前後對照數字，暫以「待補」標示 |
這兩個案例的共通點是：問題都不是出在 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 本體，因此風險可控、可以先小範圍試；但只要牽涉到條款與權限，就必須在專案啟動前談定，不能邊做邊談。
常見問題
ERP 沒有開放 API，企業還能導入 AI 嗎？
可以，不需要等 ERP 廠商開放 API 才動手。做法依 ERP 型態而定：網頁型 ERP 用 Vibe Coding 開發瀏覽器插件執行固定流程，全地端 ERP 建立資料庫 schema 讓 AI Agent 直接讀取資料，兩者都能搭配 Excel 的程式化處理，不必先對 ERP 動手術。
企業想導入 AI，但 ERP 無法即時提供 API，該怎麼辦？
常見做法是先盤點哪些資料表是真正必要的，評估用唯讀檢視表、批次匯出或既有匯出功能取代即時 API，再視預算決定是否額外開通查詢介面，不必一開始就要求全面即時串接。
網頁型 ERP 跟全地端 ERP，AI 整合的做法有什麼不同？
網頁型 ERP 有網頁介面可操作，適合搭配 Chrome DevTools MCP 開發瀏覽器插件，讓插件自動完成上傳、勾選、關聯欄位等重複動作。全地端、封閉式 ERP 通常沒有網頁介面，插件這條路走不通，比較可行的做法是先盤點資料庫 schema，再讓 AI Agent 依 schema 直接讀取結構化資料。
開發 ERP 瀏覽器插件，會不會違反 ERP 廠商的使用條款？
有可能，這件事必須在動手前確認。部分 ERP 廠商的合約會限制以自動化方式操作系統介面，或載明第三方直接存取資料庫將影響原廠支援。建議在專案啟動前就把插件開發與資料庫唯讀權限的範圍談清楚，避免上線後才發現影響保固。
為什麼不直接讓 AI Agent 操作 ERP，而要另外開發插件？
主要顧慮是資料流向。AI Agent 每執行一步都要把畫面內容送進模型判斷，等於讓客戶名單、報價、成本等敏感資料持續離開企業邊界；瀏覽器插件在開發完成後執行的是固定程式邏輯，資料不會每跑一次就外送一次，稽核軌跡也比較清楚。
資料庫直讀封閉式 ERP，資料安全嗎？
安全性取決於權限設計，而不是技術本身。做法是只申請資料庫的唯讀權限，並在中間包一層自訂 API，依 Agent 職責切分讀取範圍——例如負責營收分析的 Agent 只看得到訂單與金額，薪資、成本等敏感資料表完全不開放，讓每一次存取都留下可追蹤的紀錄。
AI 導入卡關時，通常是模型不準，還是資料進不來？
以實務觀察來說，更常見的卡點是資料進不來，例如系統不支援即時 API、資料格式不統一、需要額外付費才能開放查詢，而不是模型本身的準確率不夠。
為什麼台灣企業的 ERP 系統特別封閉？
許多台灣企業使用的 ERP，對外部資料查詢或串接的支援有限，部分廠商甚至將「開放特定資料表的查詢 API」列為額外收費項目。PwC《2026 臺灣企業領袖調查》顯示，只有 31% 的臺灣企業認為最常使用的工具可存取所有文件和資料。
企業導入 AI 一定需要 AI 研究背景的人才嗎？
不一定。多數企業導入 AI 遇到的困難，是資料能否被 AI 系統穩定讀取、既有系統能否串接，這些更仰賴軟體工程與實作經驗，而非模型研究能力。真正需要模型研究能力的，通常是要自行訓練專屬模型的情境。
參考資料
延伸閱讀
- 老舊 ERP 沒有資料庫文件怎麼辦？用 AI 反推資料表關係與查詢 SQL：同樣聚焦 ERP、企業資料整合，可接著比較不同情境的做法。
- 如何串接 Email、ERP 與企業資料，自動執行完整工作流程？：同屬「智慧營運」主題，可延伸理解相近問題的判斷方式。
- 中小企業導入 AI 從哪裡開始？從工作流程找出真正值得做的專案：同樣聚焦 AI 導入，可接著比較不同情境的做法。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-08-25