新的流程從裝置端開始：裝置在本機加密訓練範例，並附上存取政策，說明哪些伺服器端工作負載可解密並處理資料。這些政策會發布至公開透明度日誌。在伺服器端，一組 TEE 會實作 KMS；在向根 TEE 發出解密金鑰之前，KMS 必須先確認遠端證明及政策相符。根 TEE 執行 Python 訓練迴圈，並將平行工作分派給工作者 TEE。由於明文只會存在於經證明的 TEE 內，且金鑰受政策控管，稽核人員便能追蹤資料從裝置上傳到 TEE 內處理的整個存取流程。

公開存取政策並支援可重現建置，是讓實際稽核得以進行的關鍵環節。稽核人員可檢視公開日誌項目，確認哪些工作負載獲准存取資料；也能從原始碼獨立重建 KMS 與資料處理二進位檔，驗證它們是否與經證明的映像檔逐位元一致。這大幅減輕了早期伺服器端聯邦學習方法所面臨的「黑箱」問題，並提供公開紀錄，串連裝置同意、授權程式碼，以及在 TEE 內執行的二進位檔。

即使程式碼執行經過證明且可供稽核，隱私保障仍取決於對外發布內容的限制。Google 的系統將可見產出限制為指標與經差分隱私處理的模型權重；裝置明文資料與中間梯度則留在 TEE 內。這種雙重做法——機密執行搭配差分隱私輸出——有助於兼顧實用性與可驗證的隱私保障，但前提是經證明的程式能正確實作差分隱私，且噪聲、訓練群體規模與抽樣策略都經過審慎調校。

TEE 能強化機密性與完整性，但並非萬靈丹。新一代 TEE 仍可能遭受特定側通道觀察；動態側載——用來保護專有模型元件——若缺乏嚴格限制，也會擴大攻擊面。Google 承認這些限制，並指出必須將所有與隱私相關的邏輯保留在可供證明的 Python 程式中，只將經充分稽核的輸入交由側載處理。稽核人員因此不應只驗證經證明的程式，也應查核側載產物的來源與預定用途範圍。

對產品團隊而言，這套架構提供一套明確做法，讓團隊無須盲目信任營運者，也能運用敏感資料訓練實用模型：發布存取政策、支援可重現建置、以證明機制控管金鑰，並且只發布經差分隱私處理的輸出。稽核人員應建立工具，自動比對日誌項目、證明資料與重建產物。評估類似設計的組織，則應為 TEE 運算能力編列預算、投入側通道緩解措施，並建立治理機制，將裝置同意內容對應至存取政策的具體定義。