ERP、CRM 與 Excel 都在用，AI 卻看不到資料：企業系統整合從哪裡開始

非工程主管也能讀懂 API、權限、資料契約、RAG 與 Agent 的整合指南。整合的第一個工程不是接模型，而是建立資料地圖與讀寫權限；API 查精確數據、RAG 查知識、AI 整理文字，各有邊界。 本文提供可由主管拿來討論及驗收的做法，所有情境數字均為教學假設，並非個別企業成效承諾。

專題編輯：Derek Chou｜AI 技術與架構編輯

第一章｜ERP、CRM、Excel 都有資料，為何 AI 還是無法回答

企業常以為導入 AI 就能讓模型直接理解所有系統，實際上模型沒有天然的企業資料權限。ERP 的交易紀錄、CRM 的商機進度、Excel 的人工彙整與文件庫的 SOP 具有不同的資料更新頻率、授權範圍與欄位語意。若直接把資料複製到聊天工具，可能造成版本過期、權限外洩或不可追溯的回答；若讓模型直接寫進 ERP，則可能把模型的不確定性變成真實交易錯誤。

因此 AI 整合應先完成業務資料地圖，分清資料來自哪個系統、誰是主檔擁有者、哪個系統有寫入權、何時更新、哪些欄位涉及機密與個資。盤點後再比較 API、RAG、Agent 或資料庫連線，並逐步驗證資料契約、權限隔離與錯誤處理是否可行。

第二章｜先理解五種不同元件的責任

前端是員工看見的介面，例如客服檢索頁、業務詢價助手或管理儀表板。後端是控制身份、商業規則、排程、資料轉換與日誌的服務。API 是程式之間交換請求與回應的介面；它是否安全、穩定，仍取決於身份驗證、授權、資料驗證及介面設計。資料庫保存持續性紀錄；主檔、資料關係與存取規則則需依業務設計。AI 模型或 Agent 則負責自然語言理解、文件整理、提出建議或在授權範圍內協調工具。它們是相互配合的層，不應混成「模型懂所有事」。

例如員工詢問某客戶最近三筆訂單是否延遲，系統應先驗證員工身份與客戶存取權，再由後端透過 API 查 ERP 訂單時間、物流狀態及 CRM 客戶備註。模型能把取得的資料整理成易讀解釋，但不應直接修改交期或推測缺失資料。對缺少權限的紀錄，應明確回覆無法提供，不可試著使用其他人帳號繞過限制。

第三章｜API 介接前要做的資料契約

資料契約最基本包含欄位名稱、型態、必要性、單位、允許值、來源、更新延遲、錯誤格式與版本。例如「金額」若沒標明稅前稅後、幣別和小數精度，後續模型即使正確擷取文字，也可能產生錯誤比較。對日期欄位要確認時區與更新時間；對客戶 ID 要確認不同系統是否使用同一識別碼，不可依公司名稱模糊匹配就自動合併資料。

整合方案需要明確區分讀與寫。唯讀查詢可以先用最小權限服務帳號；寫入則要建立審核、冪等鍵、日誌、重試與回滾條件。若系統採用過時或沒有文件的 API，應先進行相容性評估，而不是把「有網路」當成能連接。ERP 或 CRM 廠商的授權條款、API 額度及變更通知也應納入維運預算。

第四章｜RAG 適合文件檢索，不是 ERP 交易計算的萬能解法

檢索增強生成（RAG）通常是先從知識來源找出相關內容，再讓模型根據取回的段落回覆，適合政策、SOP、產品規格、內部知識問答。Microsoft 的 RAG 文件將它說明為利用專有內容支援模型回答的模式，並列出內容準備、多來源存取與授權等挑戰。引用來源是否正確、資料是否更新，仍要由系統驗證。Microsoft 官方文件

RAG 不自動保證回答正確，也不等於資料庫的即時交易查詢。對即時庫存、價格、訂單狀態等需要精確最新值的問題，通常應透過可驗證 API 查詢，必要時再交給模型做文字整理。

RAG 類系統要驗收版本、索引更新、來源引用和權限隔離：已撤銷帳號的存取應被拒絕、不同事業部不能取得未授權內容，且回答應採用適用的文件版本。若找不到支持答案的段落，應回覆資料不足，而不是把一般知識當作公司政策。特別敏感的資料不宜預設上傳公共雲端服務，應按企業資訊政策選擇方案。

第五章｜何時需要 AI Agent，何時只需要後端服務

如果任務固定，例如每天從 ERP 匯出報表、比對訂單並寄出摘要，常規排程服務與規則引擎可能就足夠。如果使用者以自然語言詢問不同條件、需要依輸入選擇查詢工具，模型或 Agent 才可能提供介面價值。若 Agent 可以查價、發信、建立採購單、修改 CRM，權限應依工具逐項最小化，並在不可逆動作前加入人工核准。

將架構畫成五層：員工介面、身份與權限、API／工作流編排、企業系統及資料來源、稽核與監控。AI 不是繞過權限的捷徑，也不應讓模型直接拿到資料庫管理員密碼。OWASP 的 LLM 安全指引將提示注入等風險列為需要防範的議題；企業應結合傳統應用安全與 AI 特有風險，而不是只靠「請勿洩漏資料」的提示詞。OWASP 提示注入指引

第六章｜PoC 的驗收清單要包含系統失敗

除了成功讀取資料，更應測試沒有權限、資料缺漏、ERP API 超時、舊版欄位、重複事件、模型輸出格式錯誤、來源衝突與服務不可用。每種狀況都要確認系統行為：拒絕、等待、進人工佇列、切換唯讀或恢復原流程。必須驗證日誌不洩漏機密、錯誤不導致重複交易、模型版本更新不破壞既有資料契約。

驗收單位是「成功完成且符合規定的工作任務」，不是模型回答多少題。管理者可要求廠商提供架構圖、資料流向、權限矩陣、API 契約、測試報告、部署 SOP 和維運回復計畫；這些文件比一句「採用最新模型」更能說明交付成熟度。若供應商不能說明哪些系統真正可連接，只能列為待驗證，不應簽署保證串接全部系統的契約。

第七章｜開發與外包的責任邊界

企業可自行負責需求、資料權限與業務驗收，系統商負責 API 與既有系統修改，AI 團隊負責模型介接、評測與安全防護，雲端或基礎設施夥伴負責部署、網路與維運。這只是分工示例，正式契約需指明每個交界面的責任人。當 AI 回答錯誤時，要能追查是來源資料錯、API 類型錯、檢索抓錯、模型推論錯，還是人工流程不完整，不能讓各家供應商互相推責。

對正在比較外部顧問的公司，最有價值的第一份交付是系統現況與可行性盤點：列出哪些 API 已取得合法存取、哪些無法串、哪些資料必須留在內網、需要誰批准、可能替代的低成本方案。只有釐清條件，才有資格估算工期與成本。天地人企業 AI 服務可協助進行需求與協作方向的討論，但具體開發、軟硬體與系統權限仍須專案確認，不預先承諾所有整合都能交付。

一份可拿進系統商會議的資料契約

假設公司想讓業務查詢客戶最近三筆訂單。第一份文件應先約定以下內容，不急著決定介面上要放哪個聊天模型。這是教學範例，不是任何 ERP 或 CRM 的現成 API 規格。

特別注意「查不到」有不同意思：客戶不存在、使用者沒有權限、系統暫時不可用，或查詢條件錯誤。介面可依資訊揭露政策給使用者合適訊息，但系統內部必須保留可供維運判斷的原因；不能把逾時說成沒有訂單，也不能藉由錯誤訊息洩露不該知道的客戶資料。

讓權限落在系統控制，不落在模型承諾

服務帳號能讀取全部資料，不代表每位使用者都應透過 AI 取得全部資料。除了帳號權限，還要在每次查詢帶入並驗證使用者範圍，讓後端、查詢層或文件檢索層確實過濾。使用者要求「忽略限制」時，模型即使產生越界查詢，下游也應拒絕。

API 金鑰與資料庫密碼應由後端依部署方式安全取得，不放進提示詞、版本庫或回覆內容。OWASP 的 Secrets Management 指引強調細緻的最小權限及憑證生命週期管理；本文將其轉成採購要求：確認誰能存取、如何輪替、如何撤銷，以及出事後如何查紀錄。OWASP 憑證管理指引

第一階段若只需要查詢，就不授予建立訂單或修改客戶的權限。日後新增寫入時，另列可寫欄位、參數限制、核准程序、結果讀回與恢復方法。不要把一個可任意執行 SQL 的介面，當成所有整合需求的通用工具。

八種失敗情境，要求供應商交出可核對結果

成功查到一筆資料只能證明一條路徑可用。驗收應預先指定測試帳號、資料、動作與正確答案；以下為建議清單，不是本文已完成的企業實機測試。

對寫入後逾時的情境，必須先處理「結果不明」：原請求可能已完成，不能換一個新事件直接重送。AWS 的冪等 API 說明可供設計參考，但目標系統是否支援、保存多久、參數衝突如何回應，都要實際核對。AWS 官方工程文章

此處所稱恢復，不保證能撤回每個動作。已寄出的訊息或外部交易可能無法復原，因此在執行之前就要設權限與核准；必要時規劃補償處理及人工接管，而不是承諾任何錯誤都能一鍵回滾。

沒有 API 時，下一步應該查什麼

先向原系統商確認正式介面、授權匯出、唯讀報表或核准的資料交換方式，再比較資料延遲、操作權限與維護成本。有些需求可以先以受控匯出資料完成唯讀分析，不必立刻取得寫入能力；若要求即時交易，就不能把每天匯出的檔案包裝成即時串接。

若考慮操作介面的自動化，需另外測試介面變動、登入逾時、重複提交與失敗回復，並確認供應商條款及企業權限。相關評估可延伸閱讀ERP 沒有 API 時的整合評估。本文的重點則是跨系統資料契約與共同驗收，兩者應一起對照。

管理者應帶走的交付清單

可下載系統整合工作卡（ZIP，內含 CSV），從訂單查詢、庫存詢問或價格權限等十種教學情境挑一列，逐欄填入實際觸發、授權資料、最小輸出、限制、驗收指標與負責人。現況件數及工時採相同觀察期間，未知欄位先標待量測，並在決議註記契約與測試證據位置。這是討論與追蹤範本，不會自動驗證 API，也不應填入真實金鑰或客戶個資。

要求供應商交付可讀的資料地圖、欄位契約、使用者與服務權限矩陣、接口測試結果、版本清單、部署與停用方式，以及維運聯絡與責任。每份文件都要對應目前實作，不能只有售前簡報。

最後選一個角色，從登入、查詢、資料來源、回覆到錯誤接手完整走一次。由業務負責人確認答案可用，系統與資料負責人確認邊界正確，再決定是否擴大。單純看到聊天視窗回答流暢，還不足以判定整合完成。

若公司準備評估整合，可先整理既有 ERP／CRM、需要查詢或寫入的工作、資料限制與系統商窗口，透過天地人企業 AI 導入顧問與陪跑服務討論需求。實際可連接範圍、開發責任、成本與時程，須依介面及授權確認。

來源與方法說明

官方來源已於 2026 年 11 月 10 日核對；Microsoft 文件用於說明 RAG 的基本模式與治理問題，OWASP 文件用於提示注入和憑證控制，AWS 文件用於重試的副作用與冪等性。本文的契約表、整合分工及驗收案例為編輯整理的建議，沒有在真實企業 ERP／CRM 進行實測，也不代表所有產品都支援所述能力。

本文由 TARAISG AI 編輯計畫協助編製，專題編輯為虛擬策展角色，身分說明見連結的編輯頁。圖片為架構方法示意，並非實際軟體介面；法律、資安與產業特殊要求，仍應由相應負責人依具體資料與系統確認。