預設保存之後，AI應用的資料責任多了一層

2026年10月26日，Google調整了Generate Content的預設設定：新的付費專案預設保存請求，既有專案維持原設定。建立專案因此不只是選擇帳單歸屬，也是在選擇資料如何留下來。更新說明

這項區別容易被忽略，因為應用程式可以給出相同答案，卻留下不同紀錄。產品團隊遷移服務時，通常先測試回答是否正確、業務流程是否仍能運作。這類測試並不能說明誰以後可以查看對話、哪些副本仍然存在，以及一筆被保存的失敗案例最終會用於什麼。需要審閱的不只是模型呼叫，還包括呼叫結束後資訊的去向。

功能沒有變化，紀錄未必相同

設想一家零售商把客服助理遷移到新專案。提示詞、顧客介面和退款規則都沒有改變，功能測試也順利通過。工程師仍需另行回答：新環境繼承的是原有的資料設定，還是僅僅相同的應用程式碼？

這是假設情境，並非已發生的事故。它說明設定為什麼應當進入發布檢查。正常回覆證明系統具備某一種能力，恰當的紀錄生命週期則證明另一件事，兩者不能互相替代。只問助理「能不能用」，可能漏掉一個使用者從回答中完全看不到的變化。

這裡存在真實的取捨。顧客投訴助理誤讀訂單時，保留的互動紀錄有助於還原錯誤。缺少足夠證據，團隊可能修復一個想像出來的問題，或者始終無法重現真正的故障。但對排查有用的紀錄，也可能包含與排查無關的資訊。提高可觀察性與減少不必要留存，並不是只能二選一的口號，而是需要針對具體流程協調的設計目標。

副本可能比最初的用途活得更久

Google政策區分一般日誌留存、資料集留存與可選擇的模型改進共享。日誌政策

本文關注的是用途轉換。假設工程師發現一段失敗對話，移除明顯的身分資訊，再把它保存為評測樣本。這個樣本的價值，恰恰在於以後還要反覆使用。即使文字看起來沒有太大變化，原對話也已經從日常操作介面消失，這次轉換仍需要明確的負責人和用途。

去掉姓名並不必然使案例無法關聯到個人。訂單細節、地點與特殊遭遇組合起來，仍可能讓熟悉背景的人認出當事人。反過來，如果把所有細節都替換成通用占位內容，又可能抹掉造成錯誤的條件。一個有用的評測案例應保留需要測試的機制，而不是自動保留整段對話。能否做到，要看任務本身，不能預先假定。

因此，蒐集故障證據與維護可重複使用的測試，是兩個不同問題。前者問當時發生了什麼，後者問哪些特徵必須保留，才能發現同類錯誤再次出現。把兩者分開，團隊更容易作出具體判斷。例如，地址驗證失敗的測試可能需要保留某種格式歧義，而不需要某位真實顧客的完整購買紀錄。

這也改變了「刪除完成」的理解。業務人員看不到原始紀錄，並不自動回答評測樣本是否仍有用途、誰可以存取、何時應再次審查。這裡不是在推斷某個系統存在漏洞，而是在指出：資訊複製之後，責任也需要跟隨複製後的物件。只盯著最初那一筆請求，容易把後續使用當成理所當然。

一個開關解釋不了所有用途

Google另有濫用監測流程。因此，關閉開發者日誌不應被描述為消除服務商持有的所有紀錄。濫用監測文件

對評估AI應用的採購方來說，「資料會不會保存」只是起點。更有幫助的解釋，是說明每一種留存副本的用途、負責人，以及什麼事件會使該用途結束。同一份資訊可能被用於調查故障、辨識服務濫用或建立測試集合；即使它們來自同一次請求，也不意味著這些決定可以合併處理。

同樣，不能因為請求被保留，就斷言它一定用於通用模型訓練。儲存、存取與再次使用是不同概念。把它們壓縮成一個隱私標籤，雖然容易宣傳，卻不利於實際評估。合理的回應既不是預設違規，也不是預設絕對安全，而是把文件中的控制與應用的真實設定對照起來。

一種可行的審閱方式，是從日常工程邊界入手：建立專案、遷移環境、匯出除錯案例，以及把案例納入評測集。每經過一個邊界，都需要有人確認當前用途和存取範圍是否仍然合適。這是一種操作層面的分析框架，不代表完成這些步驟就能自動滿足法律要求，也不意味著所有團隊都需要相同的留存策略。

預設日誌可能幫助發現原本悄無聲息的錯誤。關閉日誌可能減少部分留存，卻也可能使團隊無法解釋失敗。判斷取決於需要什麼證據、流程涉及哪些敏感內容，以及是否有更合適的替代辦法。本文沒有檢查任何客戶的設定，也沒有發現或認定資料外洩事件。

這次變化帶來的實際提醒，比支持或反對日誌本身更具體：重新建立一個應用，並不必然複製它原有的資料處理假設。除了使用者看得見的功能，這些假設也應當被重新核對。