Deploying Claude Enterprise with Confidence（上）：結構、存取權限與治理

前一天的 Introduction to Agent Skills 還在討論怎麼把工作方法整理成 Skill，這堂 Claude Academy 官方課程：Deploying Claude Enterprise with confidence 馬上把問題拉到公司層級：當 Claude 要從少數人的工具變成公司基礎設施，管理員要先決定哪些事情？

答案不在某個單一設定頁裡。這門課把部署拆成五項彼此相依的決策，先從計畫、結構與身分開始，再談存取權限、治理、支出和可見性。這篇先整理前八課，涵蓋前三項決策。

課程資訊一覽

課程希望學員最後能做出五項配置決策、說明選擇與日後變更的代價，並把隨堂練習手冊（work-along companion）整理成可以帶進啟動會議的部署方案。它教的是判斷框架，逐步操作則會連到說明中心文章。

這五項決策的順序是：

計畫：先決定要怎麼做，再開始設定

1. 五個決策與框架

課程把讀者放在管理員，具體來說是擁有 Owner 權限的人。全公司上線 Claude，通常也不會只是在 SSO（single sign-on，單一登入）後面加一個入口；你還要先定義組織邊界、群組、介面、連接器、治理方式和衡量結果。

五項決策有依賴順序：結構決定後續設定要掛在哪裡，存取權限決定誰能使用哪些介面，治理決定自訂內容怎麼擴散，支出與可見性則要讓推出計畫能持續運作、也能被檢查。

其中有四項設定特別難回頭：

每堂決策課都用三段式框架整理：先說清楚「您的決策」，再列出「您可以做出的選擇」，最後交代「若您日後變更此決策」會付出什麼代價。這讓部署討論保留一個重要問題：現在選的設定，日後要不要改，改起來有多痛？

課程也把推出目標拆成兩部分：一是成功長什麼樣，要具體、可以衡量；二是公司特有的限制條件。Pluto 這個虛構的金融科技公司有五個業務單位，其中 Payments & Trust 受金融法規約束，因此它的目標同時要求各單位在本季結束前開始日常使用 Claude，Payments & Trust 則不能出現安全升級事件。

這個例子很有用，因為它讓「快點全員開放」和「先守住風險邊界」之間的取捨變得具體。隨堂練習手冊則把每課的決策、理由和待確認事項留下來，最後可以帶進啟動會議。

2. 擁有者與導入

沒有明確擁有者的決策，很容易在跨部門討論裡停住。課程不要求你照公司既有職稱找人，而是看誰能對結果負責、誰能做出承諾：

通常最容易落在其他人手上的，是支出與可見性。管理員可以整理選項，卻不一定能替公司承諾預算或資料風險。

課程中的 intake questionnaire 會先問第一波要納入哪些職能、誰負責 IdP 與佈建、是否有受規範資料、是否有預算負責人，以及公司有幾份合約、幾個 IdP。它的價值在於提早標出需要額外關注的決策，不讓部署到了最後才發現缺一位關鍵負責人。

3. 先決條件：先確保不會把自己鎖在門外

部署過程會在幾個地方交錯進行：

最常見的混淆是把「群組成員是誰」和「群組能做什麼」放在同一個地方處理。前者去 IdP 改，後者在組織設定改。

課程列出六項先決條件，前四項在開始群組設定前就要完成：

至少兩位 Owner 是鎖定保險。若採用角色對應，要先把這些人放進對應到 Owner 的 IdP 群組，再儲存對應規則。啟用後，直接指派可能救不回被自動移除的管理權限；Primary Owner 才有其他角色沒有的最終操作能力。課程建議把 Primary Owner 留給不參與日常管理的人，日常管理者則取得涵蓋工作所需的最低權限。

結構與身分：組織和群組是後續權限的地基

4. 一個組織還是多個組織

組織是一個圍繞成員、群組、設定與資料的邊界。組織之間不共享專案、對話、產出物或自訂 Skill，因此課程把「單一組織」當成預設值。

只有三種情況足以支持多組織：

單位需要不同的支出上限、連接器或安全態勢，通常可以先在同一組織內用群組與角色處理。日後拆分或合併組織，可能要重新驗證網域、佈建與遷移成員；反過來說，先維持一個組織，未來新增獨立的第二個組織，通常比較容易。

成員進入組織有兩種常見方式：JIT（just-in-time，即時佈建）在首次登入時建立成員，但不會同步群組；SCIM 目錄同步則會事先同步成員和群組資格，成員換團隊時也跟著更新。要選哪一種，取決於公司需要多少自動化和群組準確度。

5. 您的群組

群組是幾乎每項控制都會掛上的單位。它把具名成員放在一起，再透過 RBAC（role-based access control，角色式存取控制）把權限附加上去：

課程把角色分成三類：Primary Owner、Owner、Admin 這些管理員角色負責誰能改設定；User 這類使用者角色負責成員能使用哪些功能、模型和工具；自訂角色則用來表達內建角色不夠細的權限需求。

自訂角色可以分別設定功能、模型、連接器和管理員權限，但這些設定只對採用自訂角色的成員生效。內建角色成員仍會沿用組織層級已啟用的介面、模型與連接器。

這裡有一個很容易踩到的邊界：聯集規則 union rule。成員同屬多個群組時，最後得到的是所有群組權限的聯集；範圍較窄的群組無法扣掉另一個群組已經授予的權限。要守住較嚴格的資料邊界，就要把成員放進獨立群組，並確保他們不再同時屬於那個授予廣泛權限的群組。

常見的群組結構有三種：

Pluto 採用混合模式：每個業務單位都有群組，再為受規範的工程師建立 payments-eng。這讓它可以在同一組織裡保持共同的部署方向，也避免付款工程師因為同屬廣泛的 Engineering 群組，意外繼承不該有的連接器權限。

存取權限：兩層開關和三道連接器關卡

6. 每個群組可使用的介面

Interface surface 指成員使用 Claude 的地方，例如 Claude chat、Claude Cowork、Claude Code 或 Claude for Microsoft 365。授予介面要經過兩層：

1. 組織層級開關是上限。組織沒開，任何人都不能用。
2. 角色授予決定群組裡的自訂角色成員是否真的拿到介面。

群組本身不會自動給權限，必須套用包含介面權限的角色。內建角色成員則會沿用組織層級已開啟的介面。

Claude Code 還有另一條邊界：Claude Code 的受管理設定。管理員決定哪些群組可以拿到 Claude Code，平台負責人則決定它能碰哪些檔案、命令和網路目的地。這兩件事要分開交給適合的人負責。

模型設定也會同時影響工作需求和支出。組織可以設定預設模型，自訂角色則可以覆寫預設值、限制可用模型和最高 effort。越高的 effort 通常代表模型投入更多 token；而多數成員不會主動改模型，所以預設值會影響大部分日常使用量。

介面導入可以採取三種節奏：

Pluto 先把 chat 和 Cowork 開給各群組，Claude Code 先給 Engineering 與 Platform；payments-eng 要等可見性報告準備好才開。這個暫緩與 Claude Code 的功能設定無關，對應的是它的風險條件。

7. 連接器

連接器讓 Claude 直接存取雲端硬碟、wiki 或工單系統，成員不必每次手動貼上內容。它的價值和風險來自同一件事：Claude 取得了工作脈絡，也可能取得更大的行動範圍。

要讓成員真的用到資料，三道關卡都要打開：

企業管理授權 EMA（Enterprise-managed authorization）可以把第三道關卡改由組織的 IdP 集中佈建。支援 EMA 的連接器，範圍內的成員首次登入時就能取得授權，離職流程也能沿用 IdP；其他連接器仍要由成員自行連接。MCP（Model Context Protocol）則是建構這類連接器的開放標準。

管理員最需要先做的取捨，是唯讀還是讀寫：

讀取與成員在來源服務裡的權限一致；成員本來看不到的資料，連接器也不會替他打開。寫入則要另外看 Claude 能否建立、修改或刪除內容，必要時把工具設定為需要核准或封鎖。Pluto 因此讓一般群組先唯讀，Engineering 在工作流程明確需要時才取得工單系統的寫入權限，payments-eng 則維持唯讀。

治理：管理自訂內容怎麼擴散

8. Governing customizations

治理要回答的是：一位成員設定的內容，有多少能觸及其他人？課程把自訂項目分成三類：

• Skill 與 Plugin：Skill 把指示、腳本和資源包成可重複使用的工作流程；Plugin 可以把 Skill、連接器和 Subagent 一起打包安裝。Plugin 不能替群組增加原本沒有的連接器或能力。
• Project：帶有自己的脈絡與檔案的工作空間，能否公開分享取決於專案共用設定。
• Organization instructions：放進成員和 Claude 對話裡的常駐指引，例如公司架構、對外文案語氣或引用內部資料時要附上來源。

治理的核心是避免自訂內容無限制擴散：近似的 Skill 變多、未測試的工作流程被當成已審查內容、Project 共用範圍不小心碰到敏感資料。課程把它拆成三個問題：自訂項目執行時能做什麼？誰能建立和使用？要怎麼從建立者擴散到其他人？

執行能力、建立權限與發佈範圍是不同層次。要讓 Skill 執行，組織層級要先開啟「程式碼執行與檔案建立」和「技能」；誰能建立，取決於自訂角色；誰看得到，則由發佈控制決定。

技能有四項彼此獨立的發佈控制：

產品本身沒有一個「審查後才能發佈」的完整流程。若組織要採用「建立 → 審查 → 推廣 → 擴散」，審查者核准後由 Owner 佈建，這套流程需要由公司自己維持。

治理態勢可以這樣選：

Pluto 讓多數群組自由建立，群組內可以共用，跨群組擴散則要經審查；Payments & Trust 採先核准制，內容核准前完全不共用。這不是五個部門各自發明一套例外，而是一個能對應風險邊界的治理態勢。

測驗：Deploying Claude Enterprise with Confidence Q&A

本篇範圍涵蓋第 1–8 課，官方測驗安排在下一篇，共 10 題。因此這裡沒有可保留的題目。

小結

這八課把企業導入 Claude 的起點整理成一條依賴鏈：先確認組織邊界和群組，再決定每個群組能使用哪些介面與連接器，最後定義 Skill、Plugin 和 Project 要怎麼建立、審查與擴散。每一步都要回頭對照推出目標，也要先找到真正能對結果負責的人。

我原本以為企業部署會先從 SSO 和權限表開始，讀完這半段後，反而更想先拿一張紙寫下「誰負責哪個決策」和「哪個設定改了會牽動什麼」。設定頁可以晚一點打開，決策順序先排好，至少不會在還沒想清楚群組邊界前，就開始替每個部門亂發權限。