前面幾篇都在防「資料靜止時」與「資料傳輸時」，那「資料運算時」呢

Day15、Day16 談的加密與去識別化，保護的是資料靜止（at rest）與傳輸（in transit）時的安全。但資料在被處理、被模型運算的當下（in use），傳統上是「明文存在於記憶體裡」的狀態——如果運算環境本身被入侵，這段明文資料一樣會外洩。Confidential Computing 要解決的正是這個「運算時」的資料保護缺口。

核心概念：可信任執行環境

Confidential Computing 透過硬體層級的可信任執行環境（Trusted Execution Environment），讓資料在記憶體中運算時保持加密狀態，即使是雲端服務商本身、或是運算節點的作業系統層級，理論上也無法直接讀取這段記憶體內容。這對本地部署模型（例如你在 GB10 上跑 Gemma）或是需要跟其他組織共享運算資源但不想曝露原始資料的場景特別關鍵。

GCP 底下的 Confidential Computing 家族包含幾種型態：Confidential VM（一般運算場景的機密虛擬機）、Confidential GKE Nodes（在 Kubernetes 節點層級提供機密運算）、以及 Confidential Space（主題二 Day17 會深入的多方協作機密運算場景）。

本地部署模型的機密運算場景

在紅/藍 GB10 架構的實務經驗裡，機密運算的價值特別體現在：當運算節點需要處理來自不同信任等級來源的資料（例如同時服務多個客戶的模型推論），或是模型權重本身屬於高度機敏資產（自行微調過、包含商業機密的模型）時，機密運算能確保即使實體節點被存取，記憶體內容依然無法被直接讀出。

對企業評估「要不要用機密運算」，一個實用的判斷標準是：如果你的威脅模型裡包含「雲端服務商員工」或「共用運算環境的其他租戶」作為潛在威脅來源，機密運算才有明確的價值；如果威脅模型只到「外部攻擊者」這一層，前面幾篇的 IAM、VPC-SC、加密控制通常已經足夠。

效能與成本的取捨

機密運算不是沒有代價的選項——記憶體加密會帶來額外的運算開銷，對高吞吐量的推論場景可能有明顯的效能影響。實務上建議先評估你的資料敏感度是否真的需要這一層防護，而不是預設對所有 AI workload 都套用機密運算。

待實測提醒：Confidential Computing 各項產品（Confidential VM、Confidential GKE Nodes）支援的機型與效能影響數據會持續更新，發布前請對照 Confidential Computing 官方文件 確認目前支援的硬體世代與實際效能損耗數字，避免文章裡的效能描述過時。

這篇的檢查清單

• [ ] 是否已釐清自己的威脅模型是否包含「服務商員工」或「共用租戶」這類威脅來源？
• [ ] 高敏感的自訓練模型權重是否評估過機密運算保護？
• [ ] 是否評估過機密運算對推論效能的實際影響，而非直接套用到所有 workload？