AI Agent 權限管理，是界定 Agent 能使用哪些資料、工具與動作，以及哪些人能設定、審核、查看與追查結果。它同時處理 Agent 的執行邊界與人員的管理範圍。只管人員角色，Agent 仍可能取得過多資料或工具；只限制 Agent，又可能讓不需要的人修改設定或查看結果。兩層沒有一起說清楚，Agent 能做的事越多，管理責任反而越難劃分。
在 Data-DI 參與的企業專案中，我們發現業務對練 Agent 很適合讓企業看懂這兩層權限如何一起運作。Agent 要使用經過確認的教材，員工、主管、教材編輯者與系統管理者則各自需要不同的操作與查看範圍。對練背後還牽涉情境、評分規則、練習紀錄與管理報表，每一類資料都有不同的建立者、使用者與管理目的。這篇文章會先說明通用框架，再用我們協助客戶規劃業務對練與新人培訓的經驗，帶你看整套權限設計如何形成。
AI Agent 權限管理不是單純把帳號分成主管與員工，而是要同時處理兩層。第一層是 Agent 能讀取哪些資料、使用哪些工具、執行哪些動作，以及哪些動作必須先由人確認；第二層是哪些人能設定 Agent、審核內容、查看結果與回查紀錄。例如，客服 Agent 可以查詢某類客戶資料，不表示它也能修改訂單；能調整 Agent 回覆規則的人，也不一定需要看到所有使用紀錄。
我們在規劃業務對練 Agent 時，會先陪客戶梳理教材從建立、審核、發布到員工練習的流程，再決定 Agent 與每個角色需要哪些資料及操作權。五個核心問題如下：
這張表不是所有企業都要照抄的固定設定，而是建立權限框架時的起點。導入時，還要依企業制度、部署方式與平台能力，決定 Agent 能使用的資料與動作，以及教材、評分、個人紀錄及團隊報表分別由誰建立、審核、查看與匯出。接下來會用業務對練說明人員如何分工，也會在每個步驟確認 Agent 的使用範圍。
因為職稱相同，不代表每個人在對練流程中負責的工作相同。業務主管可能需要查看團隊的練習次數與能力缺口，教材審核者則要確認內容能否發布；兩者都可能被系統歸為「主管」，需要的資料與操作權卻完全不同。
我們在協助客戶規劃時，會先確認他在流程中要完成什麼工作。例如，員工要啟動對練並查看回饋；直屬主管要知道員工哪些能力需要加強；教材編輯者整理內容，審核者決定能否正式使用；系統管理者則處理後台帳號、角色與操作紀錄。只分主管與員工，無法清楚區分這些責任。
這也是我們規劃時會採用的「最小權限原則」：只開放每個角色完成工作所需的資料與操作權 [1]。例如，教材審核者需要確認內容並核准發布，但不因此取得修改員工練習紀錄的權限；主管需要查看團隊能力缺口，也不因此取得系統設定權。最小權限要讓每個人能順利完成工作，又不額外開放與職責無關的資料或動作。
因此，業務對練的角色應依「工作任務」劃分，而不是直接沿用組織職稱。企業可以先列出教材管理、內容審核、參與對練、查看個人結果、查看團隊趨勢及管理系統六類任務，再將必要權限交給對應角色。同一個人可以兼任多個角色，但每個角色為什麼需要這些權限，必須說得清楚。
在良興的業務對練案例中，人員審查是教材流程的關鍵 [2]。要理解這一關為什麼重要，我們先看看一份教材如何從資料整理，走到員工使用。
對練 Agent 要模擬客戶、回應員工的說法，必須先有產品知識與銷售教材作為依據。公開報導中的整套系統串接六大自動化關卡；若聚焦教材從資料整理走到員工使用的權限分工，可以整理成三步：
這裡的權限分工，不只是決定誰能打開教材，更重要的是誰能讓教材正式生效。AI 可以協助產生內容，但不代表產生完就能發布；負責整理內容的人，也不應因為有編輯權就自動取得核准權。企業需要保留一道明確的確認程序，避免尚未確認的資訊成為員工的練習依據。
良興案例也將教材存取與修改範圍分層管理，並保留文件上傳者與時間等可追溯資訊。當訓練內容需要回查時，就能確認資料來源與相關紀錄。
教材能否發布，和練習結果能被誰查看，是兩個不同的決定。前者確認訓練內容是否適合使用，後者要依主管指導員工的需要決定。
新人完成模擬對練後，主管需要知道他在哪裡遇到困難，才能安排下一步指導。例如，新人熟悉產品，卻不會追問客戶需求，主管就應先協助他練習提問，而不是再講一遍產品知識。
在我們參與的一個業務對練專案中，每輪練習都會產生評分、回饋與改善方向；主管則能查看練習次數與能力缺口，也就是員工在哪些能力上仍需要加強。這些結果讓主管有具體依據，決定下一次指導的重點。
至於主管是否需要查看對話內容，我們建議先看他要解決什麼問題，再決定開放範圍：
表格是權限規劃建議，不代表上述案例已開放主管查看對話。若企業決定開放，應先向員工說明誰能看、什麼情況下會看，以及紀錄會保存多久。讓員工在開始練習前，就知道自己的資料會如何被使用。
角色權限矩陣，就是把「誰需要哪些資料、能做哪些動作」放在同一張表裡，逐一確認。企業不必從所有權限都開放開始，再慢慢關閉；可以先依工作需要列出必要範圍，再檢查有沒有漏掉。
以下以業務對練為例。這是一份治理建議，不是平台預設設定；同一個人兼任多種工作時，也要分別確認各角色的權限。
使用這張表時，先確認每個角色能否順利完成工作，再問每一項開放是否有必要。例如，主管若只需要判斷新人下一步該練什麼，能力結果可能就足夠；如果需要釐清某次評分，再另外約定查看對話的條件。最後也別漏掉匯出權：能在系統內查看，不代表就能把整批員工資料下載帶走。
角色決定一個人能做什麼，負責範圍則決定他能處理誰的資料。例如，兩位店長都需要查看員工練習結果，但各自負責不同門市，就不必因此互相開放整間公司的員工紀錄。企業有多個部門或據點時，這是角色權限之外，還要另外確認的一層。
以下是以多門市企業為例的治理建議，不代表前述案例的實際設定：
尤其要分清楚：負責維護系統，不等於工作上需要閱讀員工的所有對話與評分。若排查問題確實需要查看內容，可以採取經核准、限於特定資料與期間的方式，而不是長期開放全部資料。
資料範圍也要隨人員異動更新。例如，員工調店後，新店長需要取得必要的指導資訊，原店長的查看權則要重新確認；離職或職務調整時，也應撤除不再需要的權限。設定完成不是終點，權限必須跟著工作責任改變。
導入前，企業要把權限需求寫成能設定、也能測試的清單。只寫「依職務開放」不夠，因為設定者仍不知道哪些教材、紀錄與動作應該開放。以下五項可以直接作為需求討論的起點：
清單完成後，還要以不同角色的測試身分實際操作。例如，員工能否看到自己的回饋、是否能查看同事紀錄；教材未經核准能否發布；店長能否取得其他門市的報表；撤除存取權後是否還能進入對練或取得資料。測試要同時確認「該做的做得到」與「不該做的做不到」，不能只測正常流程。
我們建議在小範圍概念驗證時就完成這些測試，確認權限符合工作需要，再擴大使用。若某個角色每次工作都得臨時請人提供資料，就檢查是否少開了必要權限；若能取得與職責無關的資料，則應縮小範圍。
AltaBots.ai 支援角色權限管理與操作紀錄，讓企業在導入 Agent 時，同時處理「誰能操作」與「事後如何回查」。但平台有這些能力，不代表企業的管理規則就會自動形成；前面的角色分工、資料範圍與審核程序，仍需要在導入時逐一確認。
角色權限管理，也稱為 RBAC，是將一組工作所需的權限指定給角色，再把使用者加入對應角色。企業不必替每個帳號重做一套規則，人員職務改變時，也能依新的責任調整角色。
這裡要分清後台管理與員工使用入口。Data-DI 的業務對練可以嵌入公司既有系統，員工不需另外建立對練平台帳號；但入口如何辨識員工、練習結果如何歸屬，以及誰能查看資料，仍要依串接方式確認，不能把後台帳號管理直接當成員工使用流程。
在回查方面，AltaBots.ai 提供兩類紀錄：
前者看人的操作，後者看 Agent 怎麼執行，兩者解決的問題不同。
我們協助客戶規劃時，會把培訓流程與權限需求一起討論。員工能查看哪些個人紀錄、主管能否查看對話，以及不同門市如何隔開資料，都應依實際部署與功能逐一驗證。
如果你過去用 Google 表單測驗新人對產品的熟悉程度，現在可以再往前一步：讓新人選擇常見客群，透過 Agent 進行語音對練，實際練習怎麼問需求、介紹產品與回應疑問。新人有機會多試幾次，主管也能根據練習結果，知道下一次該協助他改善什麼。
想讓新人從「知道答案」走到「能開口應對客戶」？歡迎與 Data-DI 討論業務對練 Agent 的應用方式。我們可以協助你把現有教材與常見客群轉成練習情境，也一起確認權限與串接需求，讓員工方便練習、企業有依據地管理。
[1] Microsoft。（2026.07）。Least privilege for AI agents（agentic identities + RBAC）。Microsoft Learn。
https://learn.microsoft.com/en-us/security/zero-trust/sfi/least-privilege-for-ai-agents
[2] 數位時代。（2026.06）。良興攜手 Data-DI 建置專屬 AI Agent。BusinessNext（Data-DI 贊助報導）。
https://www.bnext.com.tw/article/91282/data_di_2026
