先定義 AI 助手可以知道什麼
把 ERP 接進 AI 助手時，第一個問題不該是用哪個模型，而是這個助手在業務流程裡扮演什麼角色。查訂單狀態、彙整應收帳款、提醒庫存異常、協助業務準備客戶拜訪，這些任務需要的資料深度不同，風險也不同。若一開始把整個 ERP 資料庫當成可搜尋知識庫，後面很容易遇到權限過寬、答案不可追溯、資料外洩難以調查的問題。
實務上，我們會把資料分成幾類：可以被多數員工查詢的主檔資料、只允許特定角色看的交易資料、帶有個資或商業敏感性的欄位，以及不適合讓 AI 直接讀取的資料。這個分類不需要一次做到完美，但必須能被系統執行。也就是說，分類結果要能對應到 API 權限、資料表欄位、查詢條件、遮罩規則與稽核紀錄，而不是停留在文件裡。
選擇資料接法：同步、即時查詢，或混合
ERP 資料接進 AI 助手，常見有三種做法。第一種是把部分資料同步到搜尋索引或向量資料庫，適合商品、規格、客戶備註、作業規範這類讀取頻繁、變動節奏可控的資料。優點是回應快，也比較容易做語意搜尋；缺點是必須處理資料新鮮度、刪除同步與權限同步。
第二種是由 AI 助手在需要時呼叫後端 API，即時查 ERP。這種方式適合訂單狀態、庫存量、應收應付、審核進度等需要最新狀態的資料。優點是資料來源單一，較不容易回答過期資訊；缺點是 ERP API 必須承受查詢流量，也要設計好查詢範圍，避免模型產生過大的查詢或不合理的條件。
第三種是混合式架構：用索引處理語意檢索與文件脈絡，用即時 API 查交易狀態與授權資料。這通常是企業專案比較穩健的方向，但也代表工程團隊要清楚定義哪一類問題走哪一條路徑。不要讓模型自行決定所有資料來源，而是由後端工具層限制可用操作。
- 資料變動頻率：越即時的資料，越適合透過 API 查詢，而不是只靠離線索引。
- 權限複雜度：如果同一張資料表對不同角色可見欄位不同，權限必須跟查詢工具綁在一起。
- 回答可追溯性：重要決策相關的回答，應能回到來源單據、時間戳與查詢條件。
- 系統負載：AI 助手可能把自然語言問題拆成多次查詢，必須設定查詢上限與快取策略。
權限不是提示詞，必須在後端執行
很多 AI 整合風險來自一個錯誤假設：只要在 system prompt 寫清楚使用者不能看什麼，模型就會遵守。提示詞可以輔助行為，但不能作為安全邊界。真正的權限控制必須在身份驗證、後端 API、資料庫查詢與回傳欄位層執行。AI 助手應該拿不到使用者無權存取的資料，而不是拿到了再被要求不要講。
工程設計上，AI 工具呼叫應該繼承企業既有的使用者身份與角色，而不是共用一組全權限服務帳號。若必須使用服務帳號，也應由後端根據使用者身份重新套用列級、欄位級與功能級授權。回傳給模型的資料要做最小化，只給完成任務所需的欄位。例如查詢客戶未結訂單，不一定需要回傳完整聯絡人資料、付款條件或內部備註。
還要考慮提示注入。ERP 備註、客戶留言、供應商文件都可能包含看似指令的文字。這些內容進入 RAG 或工具回傳後，模型可能把資料內容誤當成系統要求。比較穩妥的做法是明確標示資料來源與資料角色，要求模型把外部內容視為資料而非指令，並在工具層限制任何寫入、匯出、寄送或審批動作。
把可觀測性與人工覆核做進流程
企業 AI 助手不是一次上線就結束。要能安全運作，必須記錄誰問了什麼、系統呼叫了哪些工具、查詢了哪些資料、模型引用了哪些來源，以及最後回覆了什麼。這些紀錄不是為了監控員工，而是為了除錯、稽核、權限檢查與事故回溯。沒有這些紀錄，當使用者說 AI 回答錯誤或看到不該看的內容時，工程團隊很難判斷問題是在權限、同步、檢索、模型推理還是前端呈現。
對高風險操作，AI 助手應停在建議或草稿，不應直接執行。例如建立採購單、改信用額度、釋放出貨、寄送報價、修改客戶主檔，通常都需要人員確認與系統原本的審批流程。AI 可以幫忙整理依據、填好欄位、指出異常，但最後的交易寫入要有明確的人類責任人。
安全接 ERP 的目標不是讓 AI 什麼都能做，而是讓它在清楚邊界內可靠地協助工作。從小範圍資料、唯讀任務與明確權限開始，逐步增加工具能力，通常比一開始追求全自動更容易落地。若企業內部缺少整合經驗，與熟悉 ERP、雲端、資料治理與 AI 工具鏈的團隊合作，可以少走許多架構上的彎路。