最近陪一家中小企業導入 AI Agent 時，我問了一個很基本的問題：「你們後台的操作紀錄，看得出來哪一筆是真人做的、哪一筆是 AI Agent 做的嗎？」對方愣了一下——公司裡的 AI Agent，用的是行銷專員自己的帳號登入系統。也就是說，操作紀錄上永遠只會寫「王小姐」，不管這筆是她本人改的，還是 AI 幫她改的。
這不是特例，是我陪跑好幾家企業導入 AI Agent 時最常見的起手式：先把 AI 塞進現有帳號裡，圖個方便，沒人想過等哪天出事，要怎麼證明「這筆到底是誰做的」。
我的答案很直接：導入 AI Agent 前，先幫它辦一張「身分證」。公司裡每一個會動手做事、會留下紀錄的角色，都該先分清楚是真人、是員工共用帳號，還是 AI Agent——這件事沒做，後面的權限設計、事故究責、客訴處理，全部都是空談。
為什麼「共用帳號」是最容易被忽略的風險
多數中小企業導入 AI Agent 的第一步，不是申請新帳號，而是把既有的員工帳號、API 金鑰、LINE 官方帳號後台直接借給 AI 用。原因很現實：申請一個新身分要走 IT 流程、要重新設權限，麻煩；借用現成帳號，馬上就能跑。
問題是，系統的操作紀錄只認帳號，不認「這次是誰在按」。只要 AI Agent 借用了員工帳號，往後不管是自動回覆客服訊息、自動調整廣告出價，還是自動修改訂單資料，紀錄裡都只會顯示那位員工的名字。
平常沒事，這個混淆不會被發現。真正麻煩的時刻，是出事的那一刻：客戶投訴訂單金額不對、廣告帳戶被停用、客服講錯話惹怒客人——老闆第一句話通常是「這是誰做的」，但後台紀錄給不出答案，因為真人和 AI 共用同一個身分，根本分不開。
三種身分，缺一不可：真人、員工共用帳號、AI Agent
我看過的中小企業系統裡，操作者其實只有三種身分，但幾乎沒有一家公司把它們清楚分開過：
- 真人本人——員工用自己的帳號、自己的判斷在操作，出錯了找得到人負責。
- 員工共用帳號——多人共用一組登入，或部門共用一支 LINE 官方帳號後台，本身就已經有究責上的模糊地帶，AI 進來只是雪上加霜。
- AI Agent——照設定好的規則自動執行，速度快、不會累，但也不會臨場判斷「這件事現在該不該做」。
這三種身分該用的判斷邏輯完全不一樣。真人做錯了，多半是一時疏忽，補救就好；AI Agent 做錯了，通常是規則設計本身有漏洞，同一個錯誤會不斷重複發生，直到有人發現規則有問題為止。如果系統分不出這三種身分，公司連「這是不是規則出了問題」都無法判斷。
一張「代理人身分表」怎麼做？
身分表不需要一開始就做到完美，但一定要具體到「看得出來、查得回去」。建議先用一張表，把公司裡每一個會動手操作系統的角色都列出來。
| 欄位 | 要填什麼 | 為什麼重要 |
|---|---|---|
| 角色名稱 | 例如：客服 AI Agent、廣告出價 AI Agent、行銷專員本人 | 先確定「誰」在系統裡留下紀錄 |
| 登入方式 | 獨立帳號／API 金鑰，還是借用某位員工帳號 | 借用帳號＝身分無法從紀錄還原，是最該優先修正的項目 |
| 可操作範圍 | 能看、能改、能對外發送的資料與功能 | 範圍越大，出事時影響越大，越該先盤點 |
| 負責窗口 | 這個 AI Agent 出問題時，第一個要找誰 | 沒有窗口，出事時只會互踢皮球 |
| 紀錄留存方式 | 操作紀錄存在哪裡、能保留多久 | 究責與客訴處理時，這是唯一能拿出來對質的證據 |
把公司裡所有的 AI Agent 照這張表盤點一輪，通常會發現：有一半以上都在借用某個員工的帳號登入，而且從來沒有人正式核准過這件事——它只是某次「先跑起來再說」留下的暫時作法，一直沒人回頭處理。
沒有身分表，出事時會卡在哪
身分不清楚，平常看不出差別，但下面這幾種情境一發生，代價就會很具體：
- 客訴究責卡關：客人投訴 AI 客服講錯話，公司想追溯是哪一次對話出錯，卻發現同一個帳號底下真人和 AI 的紀錄混在一起，得花額外時間人工比對。
- 金流爭議說不清：訂單金額被自動調整過，財務要核對是系統規則觸發、還是有人手動改的，如果操作者身分沒有分開紀錄，只能靠「猜」——這也是為什麼哪些交易一定要真人確認，得先建立在「分得清是誰在操作」的基礎上，否則規則設了也對不起來。
- 離職交接出現斷點：AI Agent 借用的是某位員工的帳號，這位員工離職、帳號被停用，AI 也跟著停擺，卻沒人第一時間發現，直到流程卡住才被找出來。
- 稽核與究責沒有依據：不管是內部覆盤，還是客戶要求說明處理過程，公司都需要拿出「當時是誰、用什麼身分做的」，身分不清楚，這件事就無從交代。
這些情境的共同點是：問題不是 AI 做錯了什麼，而是公司說不清楚「當時是誰在做」。這正是身分表要解決的第一層問題——比「AI 能不能做這個決定」更前面一步。
從身分表開始，才輪得到權限矩陣
很多老闆導入 AI Agent 時，會直接跳去想「這件事能不能讓 AI 自己決定」，但這其實是第二層問題。第一層問題永遠是：系統分不分得出來，這是真人做的、還是 AI 做的。分不出來，權限設得再細也沒用，因為出事時根本查不回去是誰執行了那個決定。
身分表做完之後，才有基礎往下走：哪些身分可以自己做決定、哪些必須交回真人確認、金流類任務要卡在哪一關——這些屬於AI Agent決策權限矩陣的範疇，也是我們陪企業導入 AI Agent 時，接下來會處理的第二步。
執行已經被 AI 自動化了，但「誰該為這次執行負責」，還是得靠人先想清楚、先寫下來。這件事沒有捷徑，也不該外包給工具自己決定。
導入 AI Agent 前，先把身分與權限梳理清楚
我們先聊聊你公司裡 AI Agent 目前是怎麼登入、怎麼被管理的，再一起判斷身分表、權限矩陣該怎麼設計最合適。沒有貨架上的標準方案，因為每間公司的系統與流程都不一樣。
用 LINE 預約免費諮詢AI Agent身分表：老闆最常問的4個問題
「代理人身分表」跟 AI Agent 權限矩陣有什麼不同？
身分表解決的是「這是誰做的」，權限矩陣解決的是「這件事能不能讓它做」。順序上身分表要先做：系統要先分得出真人、員工共用帳號、AI Agent 三種身分，權限規則才有意義；否則就算權限設計得再細，出事時也查不回去是哪個身分執行了那個決定。
AI Agent 一定要有自己的帳號嗎？可以繼續用員工帳號登入系統嗎？
短期內借用員工帳號先跑起來可以理解，但這只能是暫時做法，而且必須是「被正式記錄下來的暫時做法」，不是沒人管的預設狀態。中長期一定要讓 AI Agent 有自己可辨識的身分（獨立帳號或 API 金鑰），操作紀錄才能清楚區分是真人做的還是 AI 做的。
沒有身分表，實際上會卡在哪些狀況？
最常見的是客訴究責與金流爭議：客人投訴 AI 客服講錯話、訂單金額被自動調整，公司想查是哪一次操作出錯，卻發現真人和 AI 的紀錄混在同一個帳號底下，只能靠人工慢慢比對，甚至根本查不出來。
中小企業資源有限，身分表要做到多細？
不需要一開始就做到完美，但要具體到「查得回去」：至少要記錄角色名稱、登入方式（獨立帳號或借用哪個帳號）、可操作範圍、出事時的負責窗口，以及操作紀錄留存在哪裡。把公司裡所有 AI Agent 照這五個欄位盤點一輪，通常就能先看出哪些帳號正在被借用而沒人正式核准過。
