import KeyTakeaways from '../../../components/KeyTakeaways.astro';

企業部署 Claude Enterprise 該從哪裡開始？先依序決定結構與身分、存取權限、治理，再把每項決策交給真正能承諾結果的負責人；本篇整理第 1–8 課，功能與權限細節仍會依版本、合約與組織設定而變動。

 前一天的 [Introduction to Agent Skills](/posts/introduction-to-agent-skills/) 還在討論怎麼把工作方法整理成 Skill，這堂 [Claude Academy 官方課程：Deploying Claude Enterprise with confidence](https://academy.claude.com/zh-TW/courses/deploying-claude-enterprise-with-confidence) 馬上把問題拉到公司層級：當 Claude 要從少數人的工具變成公司基礎設施，管理員要先決定哪些事情？ 答案不在某個單一設定頁裡。這門課把部署拆成五項彼此相依的決策，先從計畫、結構與身分開始，再談存取權限、治理、支出和可見性。這篇先整理前八課，涵蓋前三項決策。 ## 課程資訊一覽 | 項目 | 內容 | |---|---| | 官方課名 | 自信地部署 Claude Enterprise：塑造您部署方案的五項決策（Deploying Claude Enterprise with confidence: The five decisions that shape your rollout） | | 堂數 | 14 堂課（本篇涵蓋第 1–8 課） | | 總時長 | 2.5 小時 | | 測驗 | 1 個測驗（10 題，安排在下一篇） | | 完成 | 完成徽章 | | 先決條件 | 不假設任何先前經驗；有 Claude Enterprise 組織的 Owner 存取權限有助於跟著練習 | | 適合對象 | 正在為公司設定 Claude，且負責維持它運作的人 | 課程希望學員最後能做出五項配置決策、說明選擇與日後變更的代價，並把隨堂練習手冊（work-along companion）整理成可以帶進啟動會議的部署方案。它教的是判斷框架，逐步操作則會連到說明中心文章。 這五項決策的順序是： | 順序 | 決策 | 要回答的問題 | 課號 | |---|---|---|---| | 1 | 結構與身分 Structure & Identity | 幾個組織？裡面有哪些群組？ | 4、5 | | 2 | 存取權 Access | 每個群組能用哪些介面與連接器？ | 6、7 | | 3 | 治理 Governance | 誰能建立、分享自訂內容，自由度多高？ | 8 | | 4 | 支出 Spend | 上限設在哪裡，升級處理由誰負責？ | 9、10 | | 5 | 可見性 Visibility | 能衡量什麼，資料保留多久？ | 11、12 | ## 計畫：先決定要怎麼做，再開始設定 ### 1. 五個決策與框架 課程把讀者放在管理員，具體來說是擁有 Owner 權限的人。全公司上線 Claude，通常也不會只是在 SSO（single sign-on，單一登入）後面加一個入口；你還要先定義組織邊界、群組、介面、連接器、治理方式和衡量結果。 五項決策有依賴順序：結構決定後續設定要掛在哪裡，存取權限決定誰能使用哪些介面，治理決定自訂內容怎麼擴散，支出與可見性則要讓推出計畫能持續運作、也能被檢查。 其中有四項設定特別難回頭： | 設定 | 課 | 為什麼難回頭 | |---|---|---| | 網域認領 domain claiming | 3 | 會把使用該 email 網域的個人帳戶納入組織，啟用後無法復原 | | 組織拓樸 | 4 | 合併或拆分組織，都可能需要重新佈建成員 | | 群組結構與對應 | 5 | 改變 IdP 群組到 Claude 角色的對應，會一起改變涵蓋成員的存取權 | | 資料保留 retention | 11 | 期限縮短後，被刪除的舊對話無法復原 | 每堂決策課都用三段式框架整理：先說清楚「您的決策」，再列出「您可以做出的選擇」，最後交代「若您日後變更此決策」會付出什麼代價。這讓部署討論保留一個重要問題：現在選的設定，日後要不要改，改起來有多痛？ 課程也把推出目標拆成兩部分：一是成功長什麼樣，要具體、可以衡量；二是公司特有的限制條件。Pluto 這個虛構的金融科技公司有五個業務單位，其中 Payments & Trust 受金融法規約束，因此它的目標同時要求各單位在本季結束前開始日常使用 Claude，Payments & Trust 則不能出現安全升級事件。 這個例子很有用，因為它讓「快點全員開放」和「先守住風險邊界」之間的取捨變得具體。隨堂練習手冊則把每課的決策、理由和待確認事項留下來，最後可以帶進啟動會議。 ### 2. 擁有者與導入 沒有明確擁有者的決策，很容易在跨部門討論裡停住。課程不要求你照公司既有職稱找人，而是看誰能對結果負責、誰能做出承諾： | 決策 | 尋找對象 | 要帶給他們什麼 | |---|---|---| | 結構與身分 | Owner、維運 IdP 的人、了解目錄結構的 IT 維運 | 提議的群組結構與依賴的目錄群組 | | 存取權 | Owner、帶頭使用 Claude 的團隊代表、資料風險負責人 | 群組能用的介面與連接器、導入順序、寫入授權流程 | | 治理 | Owner、變革管理或 AI Center of Excellence 負責人、必要時的資安負責人 | 治理態勢、成員要求與審查方式 | | 支出 | Owner、財務夥伴或能承諾預算的人 | 提議的上限與使用情境 | | 可見性 | Owner、安全、法務或合規負責人 | 選項、建議與日後變更代價 | 通常最容易落在其他人手上的，是支出與可見性。管理員可以整理選項，卻不一定能替公司承諾預算或資料風險。 課程中的 intake questionnaire 會先問第一波要納入哪些職能、誰負責 IdP 與佈建、是否有受規範資料、是否有預算負責人，以及公司有幾份合約、幾個 IdP。它的價值在於提早標出需要額外關注的決策，不讓部署到了最後才發現缺一位關鍵負責人。 ### 3. 先決條件：先確保不會把自己鎖在門外 部署過程會在幾個地方交錯進行： | 地方 | 管什麼 | 你在這裡做什麼 | |---|---|---| | 組織設定 | 群組與角色、連接器、治理、支出、可見性 | 改「群組被允許做什麼」 | | 身分提供者 IdP | 群組定義與成員資格 | 改「群組裡有誰」 | | [Claude Platform](https://platform.claude.com/) 的 Claude Console | API 金鑰與開發人員存取 | 管理獨立的 API 存取 | | Claude Code 的受管理設定 | 檔案、命令與網路目的地邊界 | 由平台或工程負責人維護 | 最常見的混淆是把「群組成員是誰」和「群組能做什麼」放在同一個地方處理。前者去 IdP 改，後者在組織設定改。 課程列出六項先決條件，前四項在開始群組設定前就要完成： | 先決條件 | 為何重要 | |---|---| | 至少兩位成員直接被指派 Owner | 避免群組同步設定錯誤，把管理團隊鎖在門外 | | IdP 連線設好、SSO 強制啟用 | Claude 才能透過 IdP 讀取群組 | | IdP 的佈建應用程式設定完成 | 群組與成員資格才會推送過來 | | 網域已驗證且認領功能已啟用 | 網域內的新帳戶才會進入組織控制範圍 | | 為 Claude 群組訂命名慣例 | 在群組建立前先取得共識，之後重新同步也比較清楚 | | 確定帳務負責人 | 後續支出決策需要 | 至少兩位 Owner 是鎖定保險。若採用角色對應，要先把這些人放進對應到 Owner 的 IdP 群組，再儲存對應規則。啟用後，直接指派可能救不回被自動移除的管理權限；Primary Owner 才有其他角色沒有的最終操作能力。課程建議把 Primary Owner 留給不參與日常管理的人，日常管理者則取得涵蓋工作所需的最低權限。 :::caution 網域驗證和網域認領是兩個步驟。驗證代表你證明了網域所有權；認領則會把使用該網域信箱的個人帳戶導入組織。認領啟動後，已有個人帳戶的成員有 30 天遷移期，原個人帳戶最後會停用；自訂 Skill 不會隨個人帳戶自動遷移，已連接的應用程式授權也需要重新處理。發起前要先通知成員，並把可選擇的遷移方式、期限與聯絡窗口說清楚。 ::: ## 結構與身分：組織和群組是後續權限的地基 ### 4. 一個組織還是多個組織 組織是一個圍繞成員、群組、設定與資料的邊界。組織之間不共享專案、對話、產出物或自訂 Skill，因此課程把「單一組織」當成預設值。 只有三種情況足以支持多組織： | 觸發條件 | 什麼時候適用 | |---|---| | 獨立合約 | 事業單位和 Anthropic 簽的是各自獨立的合約，不只是同一帳單的成本中心 | | 無法合併的 IdP | 公司有不同 IdP，無法合併成一個共用登入邊界 | | 必要的資料隔離 | 法規或合約要求某部分資料與其他部分隔離 | 單位需要不同的支出上限、連接器或安全態勢，通常可以先在同一組織內用群組與角色處理。日後拆分或合併組織，可能要重新驗證網域、佈建與遷移成員；反過來說，先維持一個組織，未來新增獨立的第二個組織，通常比較容易。 成員進入組織有兩種常見方式：JIT（just-in-time，即時佈建）在首次登入時建立成員，但不會同步群組；SCIM 目錄同步則會事先同步成員和群組資格，成員換團隊時也跟著更新。要選哪一種，取決於公司需要多少自動化和群組準確度。 ### 5. 您的群組 群組是幾乎每項控制都會掛上的單位。它把具名成員放在一起，再透過 RBAC（role-based access control，角色式存取控制）把權限附加上去： | RBAC 元件 | 負責什麼 | |---|---| | 成員 | 實際使用 Claude 的人 | | 群組 | 一組具名成員，可由 SCIM 同步或手動建立 | | 角色 | 附加到群組上的權限集合 | 課程把角色分成三類：Primary Owner、Owner、Admin 這些管理員角色負責誰能改設定；User 這類使用者角色負責成員能使用哪些功能、模型和工具；自訂角色則用來表達內建角色不夠細的權限需求。 自訂角色可以分別設定功能、模型、連接器和管理員權限，但這些設定只對採用自訂角色的成員生效。內建角色成員仍會沿用組織層級已啟用的介面、模型與連接器。 這裡有一個很容易踩到的邊界：**聯集規則 union rule**。成員同屬多個群組時，最後得到的是所有群組權限的聯集；範圍較窄的群組無法扣掉另一個群組已經授予的權限。要守住較嚴格的資料邊界，就要把成員放進獨立群組，並確保他們不再同時屬於那個授予廣泛權限的群組。 常見的群組結構有三種： | 選擇 | 適用情境 | |---|---| | 反映公司組織架構圖 | 控制只需要依部門區分，IdP 裡已有相同結構 | | 依風險分層 | 某個受規範職能需要比一般部門更嚴格的連接器、治理或可見性控制 | | 混合 | 日常控制依部門，但另有一條跨部門的風險邊界需要獨立群組 | 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 取得了工作脈絡，也可能取得更大的行動範圍。 要讓成員真的用到資料，三道關卡都要打開： | 關卡 | 控管內容 | 誰設定 | |---|---|---| | 組織關卡 | 連接器是否在組織可用 | Owner / Primary Owner | | 角色關卡 | 群組角色是否包含該連接器 | Owner / Primary Owner | | 成員關卡 | 成員是否連接自己的來源帳戶並授權 Claude | 成員本人 | 企業管理授權 EMA（Enterprise-managed authorization）可以把第三道關卡改由組織的 IdP 集中佈建。支援 EMA 的連接器，範圍內的成員首次登入時就能取得授權，離職流程也能沿用 IdP；其他連接器仍要由成員自行連接。MCP（Model Context Protocol）則是建構這類連接器的開放標準。 管理員最需要先做的取捨，是唯讀還是讀寫： | 選擇 | 適用情境 | |---|---| | 唯讀，範圍限定在工作資料所在的群組 | 多數組織的起點，先讓 Claude 讀取文件、工單或儀表板 | | 寫入，分階段並經核准 | 工作流程確實需要建立工單、更新頁面等動作，且資料風險負責人已核准 | 讀取與成員在來源服務裡的權限一致；成員本來看不到的資料，連接器也不會替他打開。寫入則要另外看 Claude 能否建立、修改或刪除內容，必要時把工具設定為需要核准或封鎖。Pluto 因此讓一般群組先唯讀，Engineering 在工作流程明確需要時才取得工單系統的寫入權限，`payments-eng` 則維持唯讀。 ## 治理：管理自訂內容怎麼擴散 ### 8. Governing customizations 治理要回答的是：一位成員設定的內容，有多少能觸及其他人？課程把自訂項目分成三類： - **Skill 與 Plugin**：Skill 把指示、腳本和資源包成可重複使用的工作流程；Plugin 可以把 Skill、連接器和 Subagent 一起打包安裝。Plugin 不能替群組增加原本沒有的連接器或能力。 - **Project**：帶有自己的脈絡與檔案的工作空間，能否公開分享取決於專案共用設定。 - **Organization instructions**：放進成員和 Claude 對話裡的常駐指引，例如公司架構、對外文案語氣或引用內部資料時要附上來源。 治理的核心是避免自訂內容無限制擴散：近似的 Skill 變多、未測試的工作流程被當成已審查內容、Project 共用範圍不小心碰到敏感資料。課程把它拆成三個問題：自訂項目執行時能做什麼？誰能建立和使用？要怎麼從建立者擴散到其他人？ 執行能力、建立權限與發佈範圍是不同層次。要讓 Skill 執行，組織層級要先開啟「程式碼執行與檔案建立」和「技能」；誰能建立，取決於自訂角色；誰看得到，則由發佈控制決定。 技能有四項彼此獨立的發佈控制： | 控制 | 預設 | 說明 | |---|---|---| | 擁有者佈建 | — | Owner 上傳後出現在成員的 Skill 清單，只有 Owner 能新增或移除 | | 技能共用 | 開 | 成員可直接與特定同事分享，對方可以使用但不能編輯 | | 與群組共用 | 關 | 可以和開啟群組資源共用的群組分享 | | 與組織共用 | 關 | 可以發佈到組織目錄，任何人都能找到並安裝 | 產品本身沒有一個「審查後才能發佈」的完整流程。若組織要採用「建立 → 審查 → 推廣 → 擴散」，審查者核准後由 Owner 佈建，這套流程需要由公司自己維持。 治理態勢可以這樣選： | 選擇 | 適用情境 | 做法 | |---|---|---| | 開放建立，審查後擴散 | 想讓成員實驗，又有 CoE 或推廣小組能審核 | 技能共用開、組織共用關，通過審查後由 Owner 佈建 | | 集中式 | 已有專責團隊負責製作和維護工具 | 技能共用與組織共用都關，只由 Owner 佈建 | | 完全開放 | 小型或高信任組織，成員本來就會互相檢查 | 讓各項共用控制都開啟 | Pluto 讓多數群組自由建立，群組內可以共用，跨群組擴散則要經審查；Payments & Trust 採先核准制，內容核准前完全不共用。這不是五個部門各自發明一套例外，而是一個能對應風險邊界的治理態勢。 ## 測驗：Deploying Claude Enterprise with Confidence Q&A 本篇範圍涵蓋第 1–8 課，官方測驗安排在下一篇，共 10 題。因此這裡沒有可保留的題目。 ## 小結 這八課把企業導入 Claude 的起點整理成一條依賴鏈：先確認組織邊界和群組，再決定每個群組能使用哪些介面與連接器，最後定義 Skill、Plugin 和 Project 要怎麼建立、審查與擴散。每一步都要回頭對照推出目標，也要先找到真正能對結果負責的人。 我原本以為企業部署會先從 SSO 和權限表開始，讀完這半段後，反而更想先拿一張紙寫下「誰負責哪個決策」和「哪個設定改了會牽動什麼」。設定頁可以晚一點打開，決策順序先排好，至少不會在還沒想清楚群組邊界前，就開始替每個部門亂發權限。