到目前為止，您應該已經為您的 Claude Enterprise 部署做出了具體的決策：它們要嘛已經確定，要嘛已經整理好並交給負責人處理。本課程讓您將自己的決策與 Pluto 的決策並列比較，思考改變其中任何一項會引發什麼後果，並反思一個受監管職能部門的各項答案是如何相互契合的。
您的五項答案
如果您還記得，Pluto 在第 1 課中設定的目標是：在本季結束前，讓每個業務單位都在日常工作中使用 Claude，並以各單位的每週活躍使用量作為衡量標準，同時 Payments & Trust 部門不得出現任何一次安全升級事件。右側欄位（「與目標的關聯」）會對照此目標來解讀 Pluto 的每一項答案。
請打開您的工作手冊，在往下檢視表格時，逐一檢視您對每項決策的填寫內容。此表格對應工作手冊中的決策記錄，並填入 Pluto 的答案以供比較。
| 決策 | Pluto 的答案 | 與目標的關聯 |
|---|---|---|
| 1 · 結構與身分 第 4 課與第 5 課 | • 單一組織 • 群組對應組織架構圖，外加一個跨單位的工程群組 • 一個專屬的 payments-eng 群組 | 單一組織讓所有五個單位處於同一個推行計畫與同一個使用量池中；payments-eng 群組在不需要第二個組織的情況下，隔離了受監管職能部門的設定。 |
| 2 · 存取權限 第 6 課與第 7 課 | • 每個群組都可使用 Claude chat 與 Claude Cowork • 工程部與平台部優先使用 Claude Code（payments-eng 則等到可見性報告就緒後才開放） • 連接器依群組設定範圍，payments-eng 僅限唯讀 | 在各處都開放 chat 與 Cowork，讓 Claude 融入每個單位的日常工作；暫緩開放 Claude Code 與具寫入權限的連接器給 payments-eng，可在不明顯影響採用率的情況下，維護「不升級」的限制條件。 |
| 3 · 治理 第 8 課 | • 大多數群組採開放建置、審核後推廣 • Payments & Trust 採先核准制 | 開放建置讓四個一般單位能推廣有效的做法；先核准審核則確保 Payments & Trust 的客製化內容不會演變成升級事件。 |
| 4 · 支出 第 9 課與第 10 課 | • 組織上限 • 群組上限依典型使用量設定 • 在首次使用量審查後，為少數使用量遠高於群組水準的平台工程師設定個別成員覆寫值 • 中階預設模型 • 每月審查支出上限與申請 | 依典型使用量設定的支出上限，讓成員能持續工作而非被暫停，因此不會抑制採用率；每月審查在支出攀升時調整的是設定本身，而不只是上限數字。 |
| 5 · 可見性 第 11 課與第 12 課 | • 合規 API 接入現有的安全審查流程 • 遙測資料傳送至可觀測性堆疊 • 組織層級的保留期限設定為 Payments & Trust 所要求的較短期限 • 逐群組檢視採用情況 | 記錄在成員加入之前就已啟用，因此 Payments & Trust 的疑問能得到證據而非升級事件；逐群組檢視能顯示每個單位在本季結束前是否如期進行。 |
若您的答案與 Pluto 的不同，那正是您組織獨特特性的展現：請將這項差異追溯回您在第 1 課中寫下的推行目標。如果您發現難以解釋某項決策，在與利害關係人分享之前，值得再仔細檢視一次。
預測連鎖反應
結構排在最前面，其他決策都將各自的設定附加到結構所定義的群組上，而可見性則橫跨讀取這一切。既然您已經了解每項設定的內容，這張地圖還有第二種用途：預測當您變更某項設定時，其下游會發生什麼變化。
舉例來說，在 Pluto 新增一個群組，就需要一個介面授權（第 6 課）、一個連接器範圍（第 7 課）、一個上限（第 9 課），以及一個儀表板篩選器（第 12 課），之後群組中的成員才能正式上線。
下方的互動小工具會將一項變更套用到決策地圖中，並顯示下游會發生哪些變化，從起點一路呈現到影響所及之處。
受監管職能部門：一種姿態，而非五個例外
如果您有受監管的職能部門，本節將檢查其五項答案是否構成單一的整體姿態，而非五個各自獨立的例外；Pluto 的 Payments & Trust 就是實際範例。
- 結構：其成員位於自己專屬的群組中，因此聯集規則不會賦予他們超出自身群組角色範圍的權限（第 5 課）。
- 存取權限：與其他鄰近單位使用相同的介面，但 Claude Code 要等到可見性報告就緒後才開放（第 6 課），連接器則僅限唯讀（第 7 課）。
- 治理：採先核准制，而 Pluto 其餘部分則可自由建置並在群組內分享，超出群組範圍的內容則需經審核者審查（第 8 課）。
- 支出：群組上限與其他群組的設定方式相同，每一筆增額申請在核准前都會先經過審查（第 9 課）。
- 可見性：正是因為他們，Pluto 組織層級的保留期限才設定為較短的那個窗口，並開啟合規 API，且在安全審查中指定一位讀取者（第 11 課）。
請將工作手冊中的這些項目視為一組整體重新檢視。一個群組透過一般系統來處理，沒有任何特殊機制：這正是它能站得住腳的原因。如果您的整個組織都受到監管，那麼這一組設定就是您的基準線。
設定資源
當某項決策在啟動前需要再次檢視時，本課程中每項設定背後的文章都收錄在以下兩個集合之一中。
- Team 與 Enterprise 方案（在新分頁中開啟）：完整的 Team 與 Enterprise 管理員文章集，供您重新閱讀任何一項決策。
- 管理員管理（在新分頁中開啟）：您現在重新檢視的各項設定背後的操作說明文章。
課程活動
再三個步驟，就能將您的工作手冊轉化為您在利害關係人啟動會議上提出的推行計畫。
- 檢視難以復原的設定：確認工作手冊第 13 課檢查清單上的四項設定（網域認領、組織數量、群組對應、保留期限）都已確定，或已交給負責人並訂有決定期限。
- 結清所有未決事項：針對每項仍未決定的決策，寫下阻礙因素、解除阻礙所需的條件，以及決定期限。僅有負責人姓名並不構成計畫；若未決事項缺少這些要素，推行計畫就會在此停滯。
- 排定計畫順序：工作手冊列出了順序（先結構，再存取權限、治理、支出、開啟可見性，最後依群組上線）；為每個步驟指定負責人與開始日期。
→ 請將此記錄在工作手冊的第 13 課章節中。
下載項目
接下來是什麼
最後一課將說明當新介面推出時會發生什麼：您的哪些答案可以原封不動地沿用，哪些決策則需要重新執行一次。