AI agent 權限設定指南：讀取、草擬、發送、更新、刪除如何分？

AI agent 權限設定，不是簡單問「這個員工本身有沒有權限」。更實際的做法，是把 AI agent 的工作拆成幾類動作：可以讀取甚麼資料、可以草擬甚麼內容、可以建立哪些任務、可以更新哪些紀錄、哪些動作需要人手審批，以及哪些權限第一階段不應開放。

對香港中小企而言，AI agent 的安全落地通常不是一開始便全面自動化，而是先讓 AI 做資料讀取、摘要、草擬和任務準備；至於對外發送、更新正式紀錄、匯出資料、刪除資料這類會影響客戶、金錢、訂單或個人資料的動作，應該加入人手審批、audit trail，甚至暫時禁止。

如果你仍在判斷公司應否導入 AI agent、CRM、ERP 或 WhatsApp 工作流，可先閱讀 AI 代理商業系統 Hong Kong 指南。本文假設你已準備讓 AI agent 接觸業務系統，重點集中在權限設定。

先看結論：AI agent 權限要按動作分級

AI agent 不應直接繼承老闆、管理員或某個員工帳戶的全部權限。較穩妥的做法，是為 AI agent 定義獨立身份、指定用途、可用工具、資料範圍、審批規則和停用方式。

最少可分成五個動作層級：

這個分級比單純問「AI 有沒有權限」更有用，因為 AI agent 的風險通常不是來自讀取一段文字，而是來自它可以調用甚麼工具、執行甚麼動作，以及是否有人在關鍵位置覆核。

為甚麼不應讓 AI agent 使用管理員權限？

不少公司在測試 AI 自動化時，會為了方便而用一個權限很高的帳戶連接 CRM、ERP、電郵、WhatsApp 或內部工具。短期看似快，長遠很容易出問題。

常見風險包括：

• AI agent 讀到與任務無關的客戶、員工或財務資料；
• AI agent 可以更新不應更新的欄位；
• 員工分不清楚是誰觸發了某個 AI 動作；
• 發生錯誤時，audit trail 只見到通用管理員帳戶；
• 離職、轉崗或工作流改動時，權限未有同步收窄；
• prompt injection 或錯誤指令一旦成功，就可以觸發高風險工具。

較好的做法，是把 AI agent 視為一個獨立的營運身份。這個身份只應有完成指定流程所需的最小權限，例如只可讀取某類線索、只可草擬回覆、只可建立指定任務，而不是可以任意修改整個 CRM 或 ERP。

這個方向亦符合多個公開研究和官方技術指引的共通原則。AWS Well-Architected Generative AI Lens 將代理式工作流的最小權限和權限邊界列為安全實踐；Microsoft AI security benchmark 提到敏感或高影響 AI 動作應加入人手覆核；MCP authorization 指引 亦提醒，當 MCP server 會處理用戶資料或管理動作，就要有授權、存取控制和審計能力。香港角度可再參考 PCPD 的 Artificial Intelligence: Model Personal Data Protection Framework，重點包括 AI 治理、風險評估、人手監督和持續監察。

權限設定要分四條線：資料、工具、動作、工作流

AI agent 權限不應只停留在登入角色。真正落地時，至少要分四條線。

1. 資料範圍：可以讀哪些資料

例如：

• 只可讀公開產品或服務資料；
• 只可讀自己負責部門的客戶紀錄；
• 只可讀某個線索或訂單的相關資料；
• 不可讀付款資料、身份證明文件、員工資料或管理層備註；
• 不可批量匯出所有客戶資料。

資料範圍愈清楚，AI agent 愈不需要靠猜測工作。

2. 工具範圍：可以用哪些工具

例如：

• 可用 CRM 查詢；
• 可用 WhatsApp 草稿工具，但不可直接發送；
• 可用報價草稿工具，但不可確認最終價格；
• 可建立任務，但不可改訂單狀態；
• 可用 ERP 查詢，但不可改庫存。

每一個已連接工具都應該當成一個風險入口。尤其當 AI agent 透過 MCP、API 或自動化平台連接系統時，不應一次過開放所有工具。

3. 動作範圍：可以做哪類動作

同一個 CRM 工具內，也要分讀取、建立、更新、刪除。AI 可以查找客戶紀錄，不代表可以合併客戶、刪除客戶或修改客戶階段。

文章中最值得落地的判斷是：

• 讀取通常可較早開放；
• 草擬應該保留人手覆核；
• 建立任務可在限定規則下開放；
• 更新要按欄位風險審批；
• 發送、匯出、刪除要特別保守。

4. 工作流範圍：只限哪條流程

一個 AI agent 不需要同時處理全公司所有流程。第一階段可以只限：

• 網站查詢到 CRM 跟進；
• WhatsApp 查詢摘要；
• 報價準備；
• 教育中心課程查詢；
• B2B 訂單狀態查詢；
• 內部服務申請分派。

範圍愈窄，團隊愈容易測試、審批和修正。

哪些動作需要人手審批？

不是所有 AI agent 動作都需要主管逐一批准。太多審批會令流程變慢，也會令同事繞過系統。較實際的做法，是按風險分級。

這樣做的好處，是低風險工作仍然可以加快，高風險工作則保留責任分工。

每個 AI agent 都要有一位最終問責人

除了權限和審批，每個 AI agent 都應該有一位清楚指定的最終問責人。重點是「一位」，不是「一組人」、「IT 部門」、「營運團隊」或「大家一起負責」。

可以有很多人參與設計、使用、審批和監察同一個 AI agent，但最終問責人應該是一個具名員工。當 AI agent 權限要擴大、出現錯誤、audit trail 顯示異常、員工想繞過審批，或客戶查詢某個 AI 輔助動作時，公司需要知道最後由誰決定和跟進。

這裡可借用 RACI 概念：

RACI 入面最容易被忽略的是 Accountable，即最終問責。負責執行、需要諮詢和需要知會的人都可以是一班人，但最終問責人不應是一班人。若一個 AI agent 牽涉 CRM、WhatsApp 和 ERP，仍然應該指定一位員工，對這個 AI agent 的用途、權限、審批規則和停用決定負責。

實務上，每個 AI agent 上線前至少應記錄：

• AI agent 名稱和用途；
• 最終問責人的姓名和職位；
• 問責人不在時的替代審批安排；
• 可讀資料和可用工具；
• 哪些動作需要前線同事確認、主管審批或雙重審批；
• audit trail 由誰定期檢查；
• 哪些情況要暫停 AI agent 或收窄權限。

這樣做不是為了增加文件，而是避免「系統出了事，但每個人都以為不是自己負責」。AI agent 愈接近真實業務流程，責任分工愈要清楚。

壞設定與較安全設定

以下例子可以幫團隊更快理解權限邊界。

這些設定不只是技術安全，也會影響員工是否願意使用系統。當同事知道 AI 不會自行亂改資料或亂覆客，採用阻力通常會低很多。

CRM、ERP、WhatsApp 場景如何分權限？

CRM：先由讀取和建立任務開始

若公司正在整理銷售查詢和跟進紀錄，可參考 CRM software 這類客戶資料層的角色。AI agent 第一階段可以：

• 讀取指定線索的基本資料和溝通紀錄；
• 摘要客戶背景；
• 草擬下一步跟進；
• 建立跟進任務；
• 標記缺漏欄位。

但不應一開始便自動：

• 改客戶負責人；
• 改客戶階段；
• 合併或刪除客戶；
• 匯出全公司客戶名單；
• 對外承諾價格或服務範圍。

WhatsApp：草擬不等於發送

很多香港公司最想讓 AI 幫手處理 WhatsApp。這件事可行，但權限要分清楚。若使用 WhatsApp Business API 連接受控工作流，AI agent 可以先負責整理對話、找出客戶需要、草擬回覆和提醒職員。

第一階段不建議讓 AI 在無人覆核下大量發送訊息，尤其是涉及價格、名額、課程安排、投訴或敏感個案。較穩妥的模式是：

AI 草擬 -> 職員修改 -> 職員發送 -> 系統記錄版本

ERP / inventory：查詢可以較早，更新要保守

若 AI agent 接觸 B2B ordering system 或 inventory management system 相關流程，最重要是不要混淆「查詢狀態」和「改變狀態」。

AI 可以協助：

• 查詢產品、庫存、訂單和交付狀態；
• 整理報價所需背景；
• 標記庫存不足、價格需確認或交付條件例外；
• 建立內部待辦。

但以下動作應由人手審批：

• 確認訂單；
• 改庫存；
• 改價格；
• 改付款條款；
• 改送貨或交付狀態；
• 取消或刪除訂單。

教育中心：AI 可協助整理，不能自行決定學生安排

在 教育中心管理系統 場景，AI agent 可協助整理家長查詢、學生背景、課程資料、試堂安排和跟進任務。但涉及學生安排、收費、補堂、投訴或特殊需要時，仍應由職員確認。

這個分界很重要：AI 可以幫職員更快看到完整背景，但不應在沒有審批下替職員作出教學或營運決定。

MCP、API 和工具權限要特別小心

當 AI agent 只是生成文字，風險通常較低。當 AI agent 開始透過 MCP、API 或自動化工具接觸系統時，權限設計就變得關鍵。

每個工具都應該回答幾條問題：

• 這個工具可以讀甚麼資料？
• 這個工具可以修改甚麼？
• 是否需要審批才可執行？
• 是否有記錄每次工具調用？
• 存取權杖是否只限這個用途？
• 出錯時會否交給人手處理？

不要只靠 prompt 寫「不要做危險動作」。真正安全的設計，是 AI agent 根本沒有相關權限，或者相關動作必須經過審批。Prompt 是行為指引，但權限才是邊界。

Audit trail 要記錄甚麼？

AI agent 上線前，應該先定義 audit trail。這不是事後補文件，而是令團隊敢用 AI 的基礎。

最少應記錄：

• 誰觸發了 AI agent；
• 哪個 AI agent 身份執行了工作；
• 這個 AI agent 的最終問責人是誰；
• AI 讀取了哪些資料類型；
• AI 調用了哪些工具；
• AI 生成了甚麼草稿或建議；
• 人手修改了甚麼；
• 誰批准或拒絕；
• 最後是否發送、更新或建立紀錄；
• 若出錯，交給誰處理。

沒有 audit trail 的 AI 工作流，即使大部分時間運作正常，也很難回答「誰批准了這個回覆」、「為何改了這個狀態」、「AI 根據甚麼資料作出建議」這些問題。

香港公司要注意個人資料和員工 AI 使用政策

香港公司導入 AI agent 時，應將個人資料視為權限設計的一部分。AI agent 不應因為方便而讀取全部客戶資料，也不應讓員工隨意把不必要的個人資料放入 AI 工具。

實務上可先定幾條內部規則：

• 哪些個人資料不可輸入 AI；
• 哪些欄位 AI 只可讀取，不可輸出到外部訊息；
• 哪些情況要遮蔽或最小化資料；
• 員工可如何使用 AI 輸出；
• AI 建議不可被視為未經核對的最終事實；
• 高風險或敏感個案要交由人手處理。

這篇文章不是法律意見，但從營運角度看，資料最小化、人手監督和清晰責任分工，都是 AI agent 權限設定不可缺少的一部分。

30 日權限推出節奏：先窄後闊

若你準備在公司開始第一條 AI 輔助工作流，可用以下 30 日節奏：

這個節奏比一開始全面開權限慢一點，但更容易讓團隊建立信任。AI agent 最有價值的地方，不是取代所有判斷，而是在受控範圍內幫人更快完成正確下一步。

oneflash 如何協助

oneflash 較適合已經有查詢、跟進、報價、訂單、通知或行政流程，但資料分散在網站表單、WhatsApp、CRM、Excel、電郵或不同後台之間的香港中小企。

若你準備讓 AI agent 接觸 CRM、ERP、WhatsApp 或內部工作流，第一步不一定是立即開發完整 AI agent，而是先做 AI 工作流權限診斷：

• 這條流程應由 AI 讀甚麼資料；
• 哪一位員工是最終問責人；
• 哪些工具可開放；
• 哪些動作只可草擬；
• 哪些動作要審批；
• 哪些權限第一階段應暫停；
• audit trail 要如何設計。

你可以先從一條高重複、低風險、可量度的流程開始，再逐步擴展。若想先確認公司是否已具備基本 AI 導入條件，可配合閱讀 AI 業務系統準備清單。

預約 AI 工作流權限診斷