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

<KeyTakeaways>
  <p>企業部署 Claude Enterprise 怎麼收尾？先用支出上限與模型預設管理消耗，再用 Compliance API、OpenTelemetry 和保留期限建立可見性，最後把五項決策串成可執行的 rollout；實際功能依版本、合約與組織設定而異。</p>
</KeyTakeaways>

前一篇 [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 堂課（本篇涵蓋第 9–14 課，另加課程測驗） |
| 總時長 | 2.5 小時 |
| 測驗 | 1 個測驗：10 題、10 分鐘 |
| 完成 | 完成徽章 |
| 先決條件 | 不假設任何先前經驗；有 Claude Enterprise 組織的 Owner 存取權限有助於跟著練習 |
| 適合對象 | 正在為公司設定 Claude，且負責維持它運作的人 |

先把前一篇的五項決策放在桌上：

| 決策 | 課堂 | 要回答的問題 |
|---|---|---|
| 1 · 結構與身分 Structure & Identity | 4、5 | 幾個組織？裡面有哪些群組？ |
| 2 · 存取權 Access | 6、7 | 每個群組能用哪些介面與連接器？ |
| 3 · 治理 Governance | 8 | 誰能建立、分享自訂內容，自由度多高？ |
| 4 · 支出 Spend | 9、10 | 上限設在哪裡，升級處理由誰負責？ |
| 5 · 可見性 Visibility | 11、12 | 能衡量什麼，資料保留多久？ |

本篇從第 4、5 項開始，最後回頭看五項決策怎麼互相牽動。

## Spend：支出上限要先設計好

### 9. 支出上限

企業方案的使用量會轉成組織層級的支出問題。課程先把上限拆成三層，避免把「某位成員的額度」誤認成「某個群組的共享預算」。

| 層級 | 說明 |
|---|---|
| 組織上限 organization ceiling | 組織某月可動用的總額；任何群組上限或個別覆寫都不能讓人超出 |
| 群組上限 group caps | 群組每位成員繼承的個人限額，依該群組的典型使用量定大小 |
| 個別成員覆寫 per-member overrides | 特定成員自己的限額，可高於或低於群組數字 |

群組上限下方還有座位預設限額，成員在套用群組上限或覆寫前會先拿到這個數字。當一位成員同時屬於兩個都有上限的群組，組織層級的「多群組支出限額」會決定採用較高或較低的群組上限。這裡的規則需要管理員先選好，和前一篇談到的多群組權限聯集不同。

成員達到上限時，使用量會暫停，不會排隊等下個月執行。成員可以在應用程式裡提出增加額度的請求，再交給 Admin 或 Owner 核准。大型組織也可能用自己的工單系統處理，或透過 Spend Limits API 列出、核准、拒絕請求和設定限額。

上限的設計可以先從三個問題開始：

- 群組上限是依「典型成員」估算，還是依人數平均分配？
- 哪些人確實需要個別覆寫，哪些人其實應該被放進另一個群組？
- 誰可以處理日常請求，哪些涉及群組或組織上限的變更要交給預算負責人？

比較穩的做法，是把第一次設定當成起始數字，記下設定日期，再用第一個月的使用量重新基準化。用量還未知時可以先設得保守一些，讓每次請求成為證據；有月底分析或季節性負載的群組，則可以提前留下尖峰空間，減少臨時申請。

課程用 Pluto 的案例示範這個取捨：少數 Platform 工程師的 Claude Code 用量遠高於群組典型值，因此給他們個別覆寫，沒有直接提高整個 Platform 群組的上限。後者會讓所有成員一起拿到更高額度，包含原本用量很低的人。

:::tip
設上限時就一起決定升級分工。增加請求送進來後，負責人應該能判斷這是合理的工作成長、預設模型太昂貴，還是群組邊界本身需要調整。
:::

### 10. 管理支出

支出管理的起點是先理解帳單在量什麼。典型 Enterprise 合約會包含每位成員的平台費，以及用 tokens 計量的共用消耗量；實際計費方式仍要以合約為準。Claude 讀取的提示和產生的回應越長，消耗量通常越高；Cowork 與 Claude Code 這類會自行執行多個步驟的代理型介面，也可能比單次聊天消耗更多。

這裡有一個很實用的判斷：支出增加時，先看使用設定，再決定要不要調高上限。

| 設定 | 對支出的影響 |
|---|---|
| 模型預設值與努力程度 | 多數成員不會主動切換模型；把中階模型設為預設，並為例行工作限制 effort，通常比一直調高上限更能控制支出 |
| 組織指示 | 可以提醒成員只帶入必要檔案、除非需要否則保持簡短，把最高 effort 留給真正複雜的工作；它是軟性引導 |
| 自訂功能 | Skill 只在需要時載入，比每次重貼一大段提示更一致，也可能減少重複 token |
| 代理型任務 | Cowork 的排程任務可能在擁有者沒有持續查看時繼續消耗共用池，因此要定期檢查和刪除不再需要的排程 |

提高上限前，可以固定做三個檢查：確認額外支出是否合理、判斷同一群組反覆申請是用量成長還是上限基準不對，以及定期找出達到上限和長期用量偏低的群組。這讓申請變成重新檢視設定的訊號。

課程把支出資料分成三種檢視方式：

| 介面 | 回答什麼 | 適用 |
|---|---|---|
| 分析儀表板 | 依模型查看支出趨勢、最大消耗者和用量上升處 | 定期審查 |
| Analytics chat | 用白話問一次性的支出問題 | 不需要報告的臨時查詢 |
| Analytics API | 把用量與成本資料程式化匯入財務工具 | 對帳與費用分攤；由 Primary Owner 產生金鑰 |

Analytics API 讀取用量，Spend Limits API 則處理成員上限。兩者解決的問題不同，管理員不能只看其中一邊。

Pluto 的做法是把中階模型設成組織預設，每月檢視儀表板。當 Platform 在第二個月達到上限，審查發現大部分支出來自最強模型執行例行 pull-request 摘要，於是調低 Engineering 角色的預設模型，維持上限不變。這個案例把「支出太高」拆成了可以實際調整的設定。

## Visibility：能見度要在上線前準備

### 11. 能見度：您能衡量的內容

可見性由三個部分組成：Compliance API 記錄內容、OpenTelemetry 觀察運作狀況，retention 決定內容保留多久。

為什麼要在成員取得存取權之前設定？因為記錄開啟前發生的活動，之後無法重新建構。可見性也不只是為了出了問題才追查；它讓管理員能回答誰接觸過資料、Claude 在敏感對話中產生了什麼，以及某段內容會保留多久。

Compliance API 主要處理對話內容、檔案內容和活動摘要。它和 audit logs 的差別要先分清楚：audit logs 只記錄誰在何時做了什麼等中繼資料，不含提示與生成內容；完整資料匯出則是另一個由 Primary Owner 使用的整批提取功能。需要逐案查看對話內容時，只有稽核日誌是不夠的。

Compliance API 的存取金鑰建立時就要決定範圍。Primary Owner 的金鑰可以涵蓋母組織下的組織，Owner 的金鑰則只涵蓋該 Owner 所屬組織；Primary Owner 也能建立只限單一子組織的金鑰。啟用後還要指定誰負責閱讀和審查，並把資料接到公司既有的 SIEM 或安全工具流程裡。

OpenTelemetry 的角色比較像觀察各介面的運作狀況：使用模式、效能，以及依介面可能包含的部分對話內容。Claude Code 的文件記載有選擇加入的提示記錄，預設遙測以營運資料為主；Cowork 的匯出預設包含提示內容，若政策不允許，就要在 collector 過濾。課程的建議是把內容記錄交給 Compliance API，遙測則交給平台團隊既有的可觀測性堆疊。

Retention 需要另外討論。預設可以無限期保存，直到管理員或成員刪除；自訂期限則依排程刪除，計時從對話最後一則訊息或專案最後一次更新開始。最短自訂期限是 30 天，沒有零保留選項。

Compliance API 的資料還有不同的保留模式：活動摘要和遠端工作階段記錄固定保留六年；Cowork 與 Claude Code 的本機工作階段記錄，在設定有限期限時依該期限，沒有設定時則保留六年。因此，縮短成員端的保留期限，不等於合規記錄也會同步縮短。

:::caution
保留期限可以調整，但期限縮短後被刪除的歷史內容無法復原。這項設定要先和法務、合規或風險負責人取得共識，再讓成員開始累積工作成果。
:::

### 12. 採用訊號

採用分析要分成廣度 breadth 和深度 depth。廣度看 Claude 是否擴散到不同群組，深度看活躍成員對 Claude 的依賴程度。兩者都是領先指標，能指出要往哪裡查，無法單獨證明工作成果。

| 訊號 | 類型 | 告訴你什麼 | 偏低時檢視 |
|---|---|---|---|
| 活躍成員，依群組分 | 廣度 | 使用是否集中在少數群組 | 存取權與知曉度 |
| 每週回訪的成員 | 廣度 | 成員是持續使用還是只試用一次 | 導入與期望 |
| 每位活躍成員的對話數 | 深度 | 成員對 Claude 的依賴程度 | 介面與連接器是否符合工作流程 |
| 使用中的 Skills 及／或 Projects | 深度 | 工作成果是否累積成可重複使用的流程 | 是否允許有效做法擴散 |
| 連接器使用情況 | 深度 | 哪些工具真的被放進工作流程 | 連接器範圍是否合適 |

看到數字偏低時，不要直接把它當成推行失敗。Pluto 的 Ops 群組在四週後停留在約 10% 成員活躍，課程先把它視為廣度訊號，再去問存取權與知曉度。結果發現 Ops 主要是外勤人員，尚未接受團隊啟用課程；解法會偏向補上教育訓練，和調整產品設定是兩件不同的事。

採用指標也不適合直接變成成員配額。若把「每週使用幾次」變成考核目標，成員會開始為數字工作。比較好的做法，是把第 1 課寫下的推出目標轉成 pacing targets：哪些群組應在何時活躍、什麼廣度和深度算正常、哪個群組落後時第一步要檢查什麼。

## Your rollout plan：五項決策連成一條路

### 13. How the decisions connect

前一篇把五項決策拆開整理，這一課要求把自己的答案和 Pluto 的答案並排，看看改變一項設定會牽動什麼。

| 決策 | Pluto 的答案 | 與目標的關聯 |
|---|---|---|
| 1 · 結構與身分 | 單一組織；群組對應組織架構圖，再加上跨單位工程群組與專屬 `payments-eng` 群組 | 五個單位共用推行計畫與使用量池，受規範職能仍有自己的控制邊界 |
| 2 · 存取權限 | 各群組使用 chat 與 Cowork；Engineering 和 Platform 優先使用 Claude Code；連接器依群組範圍設定，`payments-eng` 僅唯讀 | 先讓一般工作流程開始運作，受規範群組等可見性準備好再開放高風險介面 |
| 3 · 治理 | 多數群組可建立，審查後推廣；Payments & Trust 先核准 | 讓一般單位累積有效做法，也避免受規範職能的自訂內容未經檢查就擴散 |
| 4 · 支出 | 組織上限、依典型使用量設定群組上限，首次審查後給少數 Platform 工程師覆寫；中階模型預設、每月審查 | 讓成員能持續工作，調整設定時也能看到用量與上限的關係 |
| 5 · 可見性 | Compliance API 接入既有安全審查流程，遙測送到可觀測性堆疊；依受規範群組設定保留期限；逐群組看採用 | 成員上線前就留下記錄，後續可以用證據檢查各單位是否按計畫推進 |

這張圖最重要的地方，是看出結構排在最前面。新增一個群組，不只要替它開一個介面，還要設定連接器範圍、支出上限和分析儀表板篩選器。把一名成員從一般 Engineering 群組移到 `payments-eng`，也會同時改變他的介面、連接器、治理態勢、上限和後續稽核記錄。

受規範職能也應該被當成一個整體來設計。以 Payments & Trust 為例，它可以使用和鄰近單位相同的基本介面，但 Claude Code 要等可見性報告準備好才開，連接器維持唯讀，自訂內容採先核准，增加支出前先審查，組織保留期限則依它的要求設定。這組設定彼此相容，管理流程也比較容易說清楚。

課程最後把 work-along 手冊整理成啟動會議可以使用的三步驟：

1. 先檢查難以復原的設定：網域認領、組織數量、群組對應和保留期限。
2. 把每個未決事項寫下阻礙因素、解除條件和決定期限；只有負責人姓名還不算完整計畫。
3. 依照結構 → 存取權限 → 治理 → 支出 → 可見性 → 依群組上線的順序排定負責人與開始日期。

### 14. 當新產品推出時

新的 Claude 介面推出後，不需要把整套 Enterprise 設計推倒重來。組織邊界、群組與角色、治理態勢、支出上限和可見性設定通常會延續，但每個新介面都要重新回答三個問題：

1. **誰可以使用？** 哪些群組的日常工作真的需要它，什麼時候導入？
2. **它帶來了什麼？** 它有沒有新的設定或連接器，讓既有的授權方式需要調整？
3. **它是否改變了風險？** Claude 是否取得新的資料範圍、更高的自主性，或觸及新的使用者？

課程用 Claude Tag 示範這個方法。Claude Tag 是 Team 與 Enterprise 的測試版功能，讓團隊在 Slack 頻道中以 `@Claude` 委派任務。Primary Owner 或 Owner 可以選擇 Claude 能存取的頻道，以及它要連接的工具、資料和程式碼庫。

它在頻道中的身分和私訊中的身分不同：頻道內以 Claude Tag 自己的身分運作，權限附著在頻道範圍，頻道裡的每個人看到相同能力；私訊與助理面板則沿用成員自己帳戶的能力，用量也算在成員自己的席位與限制裡。

Pluto 因此沒有預設把 Claude Tag 開給所有頻道，而是逐一選擇已經在 Slack 討論串中進行工作的單位。訪客頻道維持預設封鎖，Payments & Trust 則完全關閉。這個新產品讓存取權、治理和支出重新檢查，可見性只需要確認它已經落在既有範圍內。

## 測驗：Deploying Claude Enterprise with Confidence Q&A

有 10 題。以下保留題目與正確答案。

### Q1. 某個群組在第二個月達到上限並要求提高上限。您的每月使用量審查顯示，該群組的大部分支出都用於以最強大的模型執行日常任務。您會先變更哪項設定？

答案：該角色的預設模型或努力程度，將日常工作移出昂貴的模型。

### Q2. 兩個群組在第一天就要求使用某個專門介面。其中一個群組的日常工作明顯需要它；另一個群組的情況則不明確。您會怎麼做？

答案：現在就授予明確需要的那一個，等另一個群組的工作需要出現時再逐步導入。

### Q3. 以下哪一項一旦啟用就無法復原？

答案：網域宣告。

### Q4. 為什麼您要在成員取得存取權之前，而不是之後，設定好可見性？

答案：在開始記錄之前發生的活動，之後無法重建。

### Q5. 哪種情況最明確地表明應該運行多個組織，而不是一個？

答案：兩個業務單位各自使用獨立的身分提供者，且沒有共用登入。

### Q6. 一位成員有一個設為 100 的個別成員覆寫值，其群組上限為 40，而組織上限還有充足的空間。該成員的有效上限是多少？

答案：100，因為個別成員覆寫值直接優先。

### Q7. 一位使用自訂角色的成員屬於兩個群組。其中一個群組的角色包含某個連接器，另一個則沒有。該成員會獲得什麼？

答案：該連接器，因為成員的權限是所屬群組權限的聯集。

### Q8. 一位成員回報某個連接器對他們顯示出來，但無法運作。哪一道關卡被關閉了？

答案：成員關卡，因為該成員尚未連接自己的帳戶。

### Q9. 推出四週後，分析數據顯示總使用量很高，且幾乎全部集中在一個群組。這個數字告訴您什麼？

答案：採用情況集中在一個群組，尚未普及到其他群組。

### Q10. 在一個組織中，任何人都可以為自己建立自訂項目，但任何要在整個組織範圍內發布的內容都會先經過審查，哪一個步驟是關卡？

答案：在整個組織範圍內發布，因為被審查的是推廣動作。

## 小結

這門課最讓我意外的是，它透過課程把 Claude 進入企業後要面對的治理工作完整攤開來。它不只介紹這項 AI 工具，也談到身分與權限、介面與連接器、自訂內容、支出和可見性。讀到這裡，我覺得這門課的對象很清楚：它是給 IT 管理者和 Enterprise Owner 的治理課程。Claude 進入企業後需要的權限管理、工具管理和後台控制，已經有一套相對完整的解決方案，而且產品本身也準備了對應的控制點。

這也讓我重新理解 Team 方案和 Pro 方案的差異。在我對照的方案價格中，使用量只增加約 1.25 倍，價格卻增加約 50%；我會把這個價差理解成企業治理能力的成本。IT 可以在後台設定誰能使用哪些連接器，關閉不希望開放的私人或敏感資料來源，也能在組織內統一發布 Skill 和 Plugin。這是我根據方案差異做出的理解，不是官方公開的成本拆分。

後台的使用量分析也能回頭影響設定：如果某個群組花了很多錢，原因只是用最高階模型處理日常工作，管理員就能調整該群組或角色的預設模型、限制 effort，必要時再設定個人或群組的使用上限。這讓 Claude Enterprise 更像 Claude 進入公司的 total solution：從權限、連接器和自訂內容，到支出、稽核和採用情況，都放進同一套治理流程裡。它也讓我更想把 Enterprise 部署看成一份可以持續更新的決策手冊：雲端服務和本機代理留下什麼資料、誰能讀、使用量怎麼算、改設定會牽動哪裡，都先寫下來。接下來的課程會再回到 AI Fluency 和模型能力，我也想拿這套「先定義決策，再看訊號」的方式，對照自己的多 agent 工作流程。