稽核軌跡的最後一哩：誰動了你的資料，包含 Google 自己

前面幾篇都在講「企業內部的身份怎麼被稽核」，但還有一塊常被忽略的拼圖：**當你的 AI workload 出問題需要 Google 支援團隊協助時，Google 工程師存取你環境的紀錄，你看得到嗎？**這正是 Access Transparency 要解決的問題。

Access Transparency 是什麼

Access Transparency 提供近乎即時的日誌，記錄 Google 員工在特定情境下（例如你開了支援案件、或系統自動化維運觸及你的資源）存取你的內容或設定的行為，包含存取的原因、涉及的資源、操作類型。

待實測提醒：Access Transparency 目前的產品適用範圍與開通條件（例如是否綁定特定支援方案等級、涵蓋哪些 GCP 服務）會隨 Google Cloud 的方案調整而變動，發布前請直接查證 Access Transparency 官方文件 確認目前的開通門檻與涵蓋範圍，避免文章寫的條件跟讀者實際看到的方案不符。

為什麼這對 AI 治理特別重要

企業導入 AI workload 後，資料的敏感度往往比一般運算工作負載更高——訓練資料可能包含客戶個資、Prompt 記錄可能包含商業機密。如果金融、醫療業的稽核要求延伸到「連雲端服務商員工的存取都要留痕」，Access Transparency 補的正是這一塊：把「我方的稽核軌跡」（IAM、Cloud Audit Logs）跟「服務商的稽核軌跡」接起來，形成完整的責任鏈。

跟 Cloud Audit Logs 的關係

Access Transparency 不是取代 Cloud Audit Logs，是互補。Cloud Audit Logs 記錄「你的環境裡發生了什麼」（誰用哪個身份呼叫了哪個 API），Access Transparency 記錄「Google 員工為什麼、如何存取了你的環境」。兩者疊在一起看，才是完整的稽核軌跡——尤其在需要向監理機關證明「資料存取全程可追溯」的場景，缺一不可。

這篇的檢查清單

• [ ] 是否已確認組織的 Google Cloud 方案是否涵蓋 Access Transparency？
• [ ] 是否已建立流程，定期比對 Access Transparency 日誌與內部支援案件紀錄？
• [ ] 稽核報告是否同時涵蓋「內部身份存取」與「服務商存取」兩條軌跡？