POC 通常不難。挑一個痛點明確的流程、找兩三位願意配合的同事，兩週內做出一支能用的 AI Agent，多數企業都做得到。難的是接下來：當第一支變成三十支、使用者從三個人變成三個部門，管理問題才開始出現，而且它們不是技術問題。
誰可以建 Agent、誰可以把自己的做法推廣給全公司、這個月花掉多少錢、上週那筆錯誤的出貨通知是哪一步決定的。這四個問題在 POC 階段都不存在，因為那時候人就在旁邊看著。規模一放大，看著的人就不夠了。
難題一：誰可以建，誰可以停
第一支 Agent 通常是某個熱心的同事做的。第十支開始就會冒出一個很現實的問題：如果這個人離職，他建的東西歸誰？
EgentWrX 把 Agent 綁在「職務」上，不是綁在人身上。清單裡一列等於一組「擁有者＋職務」配對。這個設計的好處在交接：職務還在，Agent 就還在。
權限用五個內建角色劃分，都是唯讀不可修改的：擁有者、管理員、單位主管、單位成員、唯讀成員。實務上決定風險大小的不是權限項數，是範圍——單位範圍的角色只看得到自己單位與子單位，多廠區或多事業部的公司最該先設定這一項。
每個 Agent 的子代理上限預設 8，到上限之後新增會失敗，但不會有錯誤訊息——導入初期有人說「加不進去」，先查這個數字。Agent 一多就容易失控，這件事我們在多派幾個 AI Agent，不等於多做幾件事裡談過。
難題二：一個人的做法，怎麼變成全公司的
POC 最常見的成果不是 Agent 本身，是某位資深同事把他的判斷邏輯寫成了規則。接下來的問題是：這條規則要不要推廣？誰有資格說它對？
EgentWrX 把這件事拆成兩段。技能由同事在前台自己建，但要推廣給全公司，必須經過後台的審查佇列核准。這道閘的意義不在增加流程，在於讓「一個人的習慣」跟「公司的規定」分開：前者留在他自己的 Agent 上，後者才進技能庫。
記憶是自動累積的，所以管得更嚴。寫入政策按範圍分級：使用者自己 Agent 範圍直接入庫、單位範圍要審核，升到全公司範圍則依記憶型別分成審核與核可兩級。另有一條不受政策表控制的固定例外：含個資的記憶一律隔離。
知識庫還有一個分界。資料放的範圍有單位、專案、Agent 三種，差別在人走了以後：放在單位範圍的資料不會隨人離職消失，放在個人 Agent 範圍的會。 離職保留天數預設 90 天，而且保留清理的執行不可還原，所以離職流程的正確順序是先轉移擁有權、再清理。
難題三：花掉的錢，誰在看
EgentWrX 的預算分四層：租戶、單位、成員、Agent，任一層先滿就先擋。這裡有兩個坑，都藏在設定細節裡。
只設上限等於只做告警。 每一層的「觸發行為」必須選「擋下」才會真的攔住；不選的話額度用完只發告警，工作照跑。告警門檻預設 80%。
AI 憑證預算不是第五層閘門。 它超過不會擋單，只反映在報表上。真正的閘門是那四層。
長時間執行的工作另有三個不可調的固定值：60 分鐘詢問是否續跑、續跑後上限 90 分鐘、單一工作花費上限 3 美元，實務上就是單次跑掉的成本天花板。
難題四：出事了，能不能回溯到那一步
這一題決定的不是效率，是你敢不敢把 AI Agent 放進真正要緊的流程。
EgentWrX 的稽核日誌覆蓋 55 種資源類型，並提供「驗證完整性」重算整條雜湊鏈，資安審查時可以當場按給對方看，紀錄再透過匯出中心交出去。有個細節值得主動跟客戶資安說明：管理者下載稽核紀錄這個動作本身也會記入稽核。
三個限制該講在前面，而不是等客戶自己撞到。工作流的「交棒前需人工核可」不能事後補勾，接續一旦建立就只能移除重建，所以不確定的環節一開始就先加。沒有任何一頁能列出全公司所有待審核的接續邊，只能從總覽數字知道有幾條再逐條進節點圖找，所以「誰負責定期看」要寫成人的責任。例行任務連續失敗 5 次會自動暫停，而且暫停後不會自動恢復，要人工重啟。
工作流另有執行防護，被擋通常代表流程設計有問題，往上調不是解法。這一層跟平台的執行框架是同一回事，我們在選 AI Agent 平台，別只問用哪個模型裡拆過它為什麼比模型選擇更決定可靠度。
合規時程已經在走
前面四件事你可以選擇晚一點處理，歐盟的時間表不會等。
歐盟《人工智慧法》（EU AI Act）2024 年 8 月 1 日生效，義務分階段適用。依歐盟執委會公布的時程：禁止性規範與 AI 素養義務自 2025 年 2 月 2 日適用；治理規則與通用 AI 模型義務自 2025 年 8 月 2 日適用；法規一般適用日為 2026 年 8 月 2 日。高風險系統的期限在 2026 年的修法（Digital Omnibus）中往後調整，執委會頁面目前列出的是：特定高風險領域的系統自 2027 年 12 月 2 日適用，嵌入受管制產品中的高風險系統自 2028 年 8 月 2 日適用。
其中兩條義務落在部署者身上，也就是使用 AI 的企業，不只是供應商。
AI 素養（第 4 條）。 條文要求 AI 系統的提供者與部署者「應盡其最大努力採取措施，確保其員工與代表其操作及使用 AI 系統的其他人員具備足夠的 AI 素養」，並要求考量這些人的技術知識、經驗、教育與訓練，以及系統的使用情境。這條 2025 年 2 月就已適用。
人工監督與日誌保留（第 26 條）。 第 2 項要求部署者「將人工監督指派給具備必要能力、訓練與權限，並獲得必要支援的自然人」。第 6 項要求保留高風險 AI 系統自動產生的日誌，期間須與系統預期用途相稱，且至少六個月。
這是歐盟法規，是否直接適用於你的公司要看 AI 系統與其產出有沒有進入歐盟市場，屬個案認定。但兩件事跟台灣製造業直接相關：歐洲客戶把合規要求寫進採購條款時，你需要拿得出角色權限、人工核可與稽核紀錄；而稽核問卷已經在用共同語言：美國 NIST 發布的《AI 風險管理框架》（AI RMF 1.0）雖屬自願性採用，其治理、對照、量測、管理四項核心功能已經是不少客戶問卷的結構。
Anthropic 公布 Claude Enterprise 時列出的企業控制項，也是單一簽入與網域管理、角色型存取權限、稽核日誌與 SCIM 這一組。
治理不是政策文件，是設定得出來的參數
多數公司的 AI 治理是一份文件。文件不會擋住任何一次超額的 API 呼叫，也不會在有人把個資寫進共用記憶時攔下來。
判斷一個平台能不能承接治理，看三件事能不能在畫面上設定並留下紀錄：誰能做什麼（角色與範圍，不只是帳號密碼）、哪些動作要人核可（而不是靠在提示詞裡叮嚀）、做過的事查不查得到（而且紀錄本身可驗證）。這三件在 EgentWrX 對應的是後台的角色權限、技能審查佇列與記憶寫入政策、四層預算、稽核鏈與匯出中心。
順序也重要。第二階段踩到的坑，多半是第一階段沒設邊界留下來的：組織與角色先設好，比事後從三十支 Agent 裡倒推誰該有什麼權限容易得多。這是智慧方案把導入拆成種子團隊與組織整合兩段的原因，FDE 方法論談的是同一件事的前半段。
POC 證明的是技術可行，第二階段要證明的是這件事管得住。