我們公司幾個月前才因為「Cowork 沒有稽核紀錄」這個理由，禁止員工用它處理客戶資料，現在應該立刻解禁嗎？
不建議立刻解禁，比較穩妥的順序是先確認三件事再調整政策。第一，確認 Compliance API 是否已經在你們組織開通，如果之前完全沒用過，需要先透過既有的 Compliance Access Key 啟用新的 session 端點，這不是自動生效的。第二，確認實際處理客戶資料的部署環境是不是落在這次覆蓋範圍內——如果是透過 Bedrock 或 Vertex AI 部署，這次更新目前還沒有涵蓋到。第三，跟你們的法遵或稽核部門確認，本機 session 目前還沒有刪除端點這件事，會不會抵觸公司既有的資料保存或刪除政策。
這三項確認清楚之後，解禁本身在技術上是站得住腳的，因為稽核缺口確實已經被補上了；但政策調整通常還牽涉到內部治理流程，值得走一次正式的重新評估，而不是因為看到這篇文章就立刻改變原本的限制。
新的 session 端點回傳的逐字稿，跟原本透過 OpenTelemetry 串流出去的事件資料，實際用途上差在哪？
兩者最核心的差異在資料的形狀跟穩定性。OpenTelemetry 串流出來的是即時、逐一事件的維運資料，格式設計是給監控儀表板跟即時告警用的，資料本身不保證長期保存或結構穩定；Compliance API 回傳的則是伺服器端保存的完整 session 逐字稿，是為了稽核跟電子文件揭露（eDiscovery）這類需要回頭查證特定時間點發生了什麼事的場景設計的，資料格式跟保存機制相對穩定。
實務上可以把兩者理解成互補而非取代的關係：OpenTelemetry 適合用來問「現在系統整體運作正常嗎、有沒有異常事件正在發生」，Compliance API 適合用來問「三個月前某位員工的某次 session 裡具體發生了什麼」。如果你們組織兩種需求都有，繼續讓兩套機制並行運作，會比只依賴其中一種更能覆蓋完整的合規需求。
本機 session 目前沒有刪除端點，這代表什麼實際風險？員工的資料是不是永遠刪不掉了？
這不代表資料完全刪不掉，而是代表目前刪除這件事還沒辦法透過 Compliance API 這個管道，由管理員在中央集中執行。使用者自己電腦上的本機對話紀錄，理論上使用者本人依然可以在自己的裝置上手動處理；真正受影響的，是企業合規團隊或管理員想要「透過 API、集中、批次地」把特定使用者或特定時間範圍的本機 session 紀錄清除掉這個能力，這部分官方明確標示目前還做不到。
對受資料刪除規範約束的組織（例如需要處理用戶提出的刪除請求、或有明確資料保存期限規定的產業）來說，這個缺口值得認真看待，建議在正式把本機 session 資料的稽核跟保存流程納入標準作業程序之前，先跟法遵團隊確認這個限制是否會造成實際的合規落差，而不是假設「現在能讀取了，代表整個資料生命週期都已經可控」。
這次更新標示是「Enterprise 客戶的 beta」，後來又更新成 GA，這個時間差是不是代表功能還不夠穩定？
這個時間差比較合理的理解方式，是產品發布的常見節奏，不必然代表功能本身不穩定。從公告本身的更新紀錄可以看到，8 月 11 日發布時 Cowork 跟 Claude Code 的覆蓋範圍就已經是這次更新的核心內容，8 月 26 日的更新是把這兩者的狀態從 beta 正式轉為 GA，同時新增了 Microsoft 365 外掛程式（Excel、Word、PowerPoint、Outlook）跟 Claude Science 的 beta 覆蓋——這代表核心的 Cowork／Claude Code 覆蓋範圍是在這兩週內從 beta 走到了 GA，是功能成熟度提升後的正常升級路徑，不是核心功能本身在這段期間內出了狀況又修正。
如果你的組織對「beta」跟「GA」的內部風險承受度不同（例如 beta 階段的功能還不能用在受監管的正式作業流程），現在可以直接引用 GA 狀態來說明這項功能已經達到組織內部通常要求的穩定性門檻，不需要再等待進一步的狀態變化。
如果你最近查過關於 Claude Cowork 合規性的資料，很可能會看到一個講法反覆出現：Cowork 完全不在 Anthropic 的三大合規機制（Audit Logs、Compliance API、Data Exports）覆蓋範圍內，企業安全團隊沒辦法拉出一份報告，證明某個使用者的 Cowork session 到底存取過哪些檔案。這個講法在 2026 年上半年是對的，但現在已經過時了——Anthropic 在 8 月 11 日發布公告，Compliance API 正式擴大涵蓋 Cowork（桌面版、網頁版、手機版）跟 Claude Code，8 月 26 日更新為這項功能已經正式全面上線（Generally Available），不再是 beta 階段。這篇整理這個變化具體改變了什麼、對 Enterprise 團隊的實際意義，以及目前還留下哪些沒解決的缺口。
在這次更新之前，Cowork 的對話紀錄只儲存在使用者自己的電腦本機，不受 Anthropic 標準資料保存政策管轄，管理員也無法集中管理或匯出。這代表如果一名員工用 Cowork 處理了敏感資料，公司端沒有任何集中化的紀錄可以回頭稽核；唯一能取得的可見度來源，是透過 OpenTelemetry 把 Cowork 事件串流到自己的 SIEM 系統，但這個管道本質上是維運監控用的事件資料，不是穩定的稽核紀錄格式，而且串流出去的內容預設就包含明文的使用者提示詞內容，等於是在你架設監控管道的同時，也把敏感內容原封不動送到了另一個系統。
依官方部落格公告，新的 session 端點會回傳每一次 Cowork 或 Claude Code session 完整、伺服器端保存的逐字稿，把提示詞、回覆跟工具呼叫紀錄整合成單一一筆 session 紀錄。每一筆紀錄包含兩類資料：session 內容（提示詞跟回覆、工具呼叫內容涵蓋網頁跟 MCP、技能跟產出物內容，都以逐字稿文字的形式保存），以及 session 中繼資料（已驗證的使用者 ID 跟 email、組織 ID、session 跟每則訊息的 ID、時間戳記）。這代表現在企業合規團隊真的可以拉出「某位使用者在某個時間點的 Cowork session 裡，Claude 呼叫了哪些工具、存取了哪些內容」這種層級的具體紀錄。
這裡有一個容易被忽略的區分：Cowork session 分成本機（在使用者自己電腦上執行）跟遠端（透過網頁版或手機版觸發、在 Anthropic 雲端環境執行）兩種。官方文件說明，Compliance API 兩種都能取得逐字稿，但本機 session 的對話紀錄本質上還是儲存在使用者自己的電腦上，Enterprise 管理員可以透過 Compliance API 取回這些內容，但目前還沒有提供刪除端點——也就是說，你能讀取本機 session 的紀錄，但還沒辦法透過 API 集中刪除它們，這是這次更新之後仍然留下的一個實際限制。
官方公告明確列出這次 beta（現已 GA）不包含的範圍：網頁版的 Claude Code、透過 Claude Platform 存取的 Claude Code、以及跑在 Amazon Bedrock、Google Cloud Vertex AI 或 Microsoft Foundry 上的 session。如果你的組織是透過這些雲端平台部署 Claude，這次的 Compliance API 擴大覆蓋範圍還沒有把你們涵蓋進去，仍然需要依賴既有的監控方式。這也代表在為組織評估合規現況時，不能只看「Cowork 現在有沒有被涵蓋」這個籠統的問題，還要進一步確認自己的實際部署環境是不是落在這次擴大覆蓋的範圍內。
官方特別強調，這次新增的端點是附加性質的（additive）：已經在拉取 Compliance API 資料的組織，既有資料不會有任何變化；已經串接 OpenTelemetry 的組織，也可以讓它繼續運作，Compliance API 可以並行使用，不需要額外建置任何基礎架構。這代表如果你的組織已經為了彌補「Cowork 沒有稽核紀錄」這個缺口，投入資源建了一套 OpenTelemetry 串流管道，這套投資不會因為 Compliance API 現在涵蓋 Cowork 而報廢，兩者可以並存，Compliance API 提供的是更穩定、結構化的逐一 session 稽核紀錄，OpenTelemetry 則繼續承擔即時維運監控的角色，兩者的用途本來就不完全重疊。
如果你的組織之前因為「Cowork 沒有稽核軌跡」這個理由，限制員工只能用一般 Claude 對話介面處理受監管的工作，這是重新評估這條限制是否還站得住腳的時機——這個理由在 8 月中旬之前是成立的，現在已經不成立了。但在放寬限制之前，值得先確認幾件事：你的組織是不是已經開通 Compliance API（如果還沒有，需要先透過既有的 Compliance Access Key 啟用新的 session 端點）；你的實際部署環境是不是落在這次覆蓋範圍內（自建 Cowork 桌面版／網頁版／手機版適用，但透過 Bedrock、Vertex AI、Microsoft Foundry 部署的不適用）；以及本機 session 目前還沒有刪除端點這件事，是否會影響你組織的資料保存政策。網路上還在流傳的「Cowork 完全沒有稽核能力」這個講法，現在已經是過時資訊，但過時資訊的殘留期通常比實際變化發生的時間長得多，值得在跟同事或主管溝通合規現況時，直接引用這次更新的官方公告，而不是沿用幾個月前寫的分析文章。