分享之前：AI 隱私不能只靠一句承諾

引言：對話正逐漸成為你的人生

你打開一個 AI 助理，想請它幫你寫一則難以回覆的訊息。你貼上對方的內容，說明彼此的關係，並補充幾個你未曾在其他地方分享的細節。另一天，你上傳一份合約、討論一個尚未完成的想法，或連接你的收件匣，讓助理理解哪些事情需要你留意。

這些行為都不像是在公開發表。你只是在尋求幫助。

然而，這些資訊可能會流經基礎設施、儲存系統、審查流程，以及法律義務，而這些大多從對話視窗中根本看不見。助理帶來的感受可以很私密，但它處理你資料的方式，往往遠遠還沒達到這種期待。

我的立場很簡單：AI 隱私不應只取決於公司在收到你的資訊之後承諾會怎麼做。它也應取決於其系統一開始就能阻止哪些資訊進入模型。 政策很重要，但背後必須有技術保護作為支撐。

這篇文章是在 Dvina 團隊的支持下完成的。文中檢視了 ChatGPT、Claude、Cursor、Perplexity、Manus、Meta 的 Muse，以及 Dvina 的已記錄事件與當前做法。目的在於說明：隨著 AI 越來越深入我們的生活，隱私為何必須成為核心的工程優先事項——以及 Dvina 正如何承擔這項責任。

這些事件告訴了我們什麼

這種擔憂並非假設性的。但不同類型的證據揭示的是不同的問題。已確認的資料外洩、經授權的人工作業審查，以及關於研究濫用的指控，不應被描述得彷彿是同一件事。

ChatGPT 在 2023 年的資料外洩：系統本身的失誤。

2023 年 3 月 20 日，一個軟體錯誤讓部分 ChatGPT 使用者看見了另一位活躍使用者對話紀錄中的標題。OpenAI 表示，在某些情況下，新建立對話的第一則訊息也可能曾經可見。其調查指出，在特定九小時期間內處於活躍狀態的 Plus 訂閱者中，有 1.2% 的付款相關資訊可能曾遭到曝露。完整卡號並未外洩。OpenAI 已修補該錯誤，並通知受影響的使用者。1

這件事帶來的教訓，不是同樣的漏洞至今仍未修補，而是：光有隱私承諾，本身並不能阻止系統把資訊回傳給錯誤的人。隔離機制、存取檢查，以及可被曝露的可識別資訊量，全部都很重要。

《紐約時報》訴訟：刪除遇上法律義務。

2025 年，OpenAI 面臨法院命令，要求其保存原本會被刪除的資料。其 10 月更新表示，對新資料進行無限期保存的廣泛義務已於 2025 年 9 月 26 日結束，但一組範圍有限的歷史資料仍受法律保全令約束。原始保存要求排除了某些產品與零資料保留安排。2

後續發展必須分開來看：2025 年 12 月，Reuters 報導法官在著作權案件中要求 OpenAI 提交 2,000 萬筆匿名化聊天紀錄，駁回其反對意見，並以去識別化與保護性防護措施作為依據。這是證據開示命令，不是把所有人的私人聊天公開到網路上。3

綜合來看，這些事件說明了為什麼「刪除」設定無法解決所有與保留資訊有關的問題。一旦副本已經存在，使用者無法控制的外部義務就可能影響它接下來會如何被處理。在爭議開始之前先減少不必要的保留，才能降低這種暴露風險。

人工審查：即使沒有發生外洩，也可能被允許存取。

OpenAI 的消費者文件明確允許授權人員與服務供應商基於特定目的進行有限存取，包括安全調查、支援、法律事務，以及符合資格的模型改進。Anthropic 的消費者指引則允許指定員工為了執行使用政策而審查對話，另有與使用者同意提供回饋相關的獨立存取機制。4, 8

這些都是文件記載的存取途徑，不是傳聞。它們並不表示員工會閱讀每一段對話；但它們確實表明，看似私密的聊天介面，不一定能在技術上阻止供應商存取內容。

Anthropic 目前的文件又補充了一個重要的企業端案例。其指定的 Covered Models 在某些先前採用零資料保留的部署中，現在要求保留 30 天，並搭配受控的人工作業審查與例外規定。這項規則在模型、平台與適用資格上都有邊界；它不是對所有 Claude 產品的一體適用變更。消費者方案則被描述為不受影響，因為那些介面本來就會保留輸入與輸出。9

安全監控有其正當目的。工程上的挑戰，在於如何達成這個目的，同時把監控系統與審查人員可接觸到的敏感資訊降到最低。以安全為理由，並不會讓隱私問題就此消失。

數學爭議：尚未解決的指控，卻是真實存在的信任問題

2026 年 9 月圍繞 OpenAI 的 Navier–Stokes 公告所引發的爭議，提出了另一種擔憂：當協助私人研究的助理，隸屬於一家本身也在進行研究的公司時，會發生什麼事？

這場爭議涉及尚未發表的數學研究與署名歸屬。報導指出，數學家 Tristan Buckmaster 與 Levent Alpöge 在工作中使用了 AI 工具，而 Buckmaster 質疑他們的私人材料是否曾對 OpenAI 的成果有所貢獻。10

OpenAI 對這種說法提出異議。其公開回應表示，在發表之前，無論是其研究人員或其代理人，都沒有看過這兩人的研究。在一則日期為 9 月 10 日的更新中，OpenAI 進一步表示，調查已排除 Buckmaster 在前兩個月內的 Codex prompts 對該成果造成任何影響，包括透過訓練造成的影響。這項有時間範圍限制的說法，比部分報導中較早的敘述更為具體。11

目前公開說法仍有爭議。此處檢視的資料來源，並未能獨立證明 OpenAI 曾使用那些私人對話來產出其成果。

儘管如此，這場爭議仍揭露了一個值得明確回答的問題：當人們把尚未完成的作品帶進 AI 時，是什麼在保護這些作品的資訊價值？ 從證明中移除作者姓名，並不會讓證明本身消失。把商業策略去識別化，也不會讓該策略變成公共財。

這就是為什麼強而有力的隱私保護，必須同時涵蓋身分與內容。使用者應該能夠清楚了解，他們的資料是否可能進入訓練、研究、評估或審查流程——以及有哪些技術控制措施在落實這些邊界。

四個絕不該被混為一談的問題

許多混淆，來自把「私密」視為單一屬性。實際上，一段對話會如何被處理，是由四個彼此分開的問題所決定。

訓練： 內容是否能用來協助開發或改進模型？選擇退出改變的是一種原本被允許的資訊用途；它不一定會改變資訊是否已被傳輸或儲存。

存取： 哪些系統與哪些人可以檢視它？傳輸中與儲存中的加密很重要，但這並不會自動阻止獲授權的服務為了處理或審查而解密內容。

保留： 什麼會被留下、留在哪裡、留多久？從介面中移除聊天、刪除正式環境紀錄、讓備份到期，以及將資料排除於未來訓練之外，都是不同的操作。

操作： 已連線的助理可以讀取、變更或傳送什麼？一旦它能透過你的帳戶執行工作，隱私也取決於權限設定與對外傳資料的控制。

有用的隱私比較，會把這些問題分開來看。付費訂閱、訓練開關，或私人任務標籤，都無法一次回答這四個問題。

服務如何比較

下表聚焦於個人使用情境，除非另有說明。它總結的是已審閱的文件內容，而不是獨立安全稽核的結果。

服務	訓練立場	需要另外理解的界線
ChatGPT	個人內容可用於改進；控制項會排除新的對話與 Codex 任務。Temporary Chat 不包含在內。4, 5	已授權存取與資料保留仍是另外的問題。Codex 也有獨立的完整環境訓練設定。
Claude	消費者模型改進取決於使用者選擇；回饋與安全相關用途有另外的規則。Incognito 不納入一般改進。6	審查與保留的例外情況仍然適用。某些商業 Covered Models 還有額外的保留要求。7–9
Cursor	Privacy Mode 會將客戶資料排除在 Cursor 訓練之外，並說明供應商不保留資料的安排，但仍受已載明例外情況限制。12	請求仍會經過 Cursor 的後端。濫用調查、快取，以及特定模型的說明都很重要。
Perplexity	消費者 AI 訓練資料收集預設為啟用，包括 Pro 與 Max；使用者可對未來資料選擇退出。13	選擇退出不會停止為服務營運或法律遵循而進行的處理。Enterprise 條款不同。
Manus	Team 文件列出可選擇退出訓練；本次審查無法確認個人方案的最終訓練規則。15	個人任務預設為私人，描述的是分享可見性，而不是對供應商使用的完整限制。14
Meta’s Muse	上線文件說明，預設會以經過淨化的互動資料進行訓練，並提供選擇退出機制。16	訓練前的淨化，不等於推論前的遮罩。上線時的營運者限制，與規劃中的 Confidential VM 也不同。
Dvina	對話、檔案、提示詞與工作區資料不會用來訓練 AI 模型。17, 18	自動遮罩處理的是更早一道界線：偵測到的個人識別資訊會在模型處理前先被替換。

以下細節說明了，這些區別在日常使用中會在哪些地方變得重要。

ChatGPT 與 Claude：你採取的動作會改變適用規則。

OpenAI 允許使用者停用訓練，同時不必刪除一般聊天紀錄。Temporary Chat 會進一步改變對話的處理方式，但其文件仍允許進行濫用審查，並說明有 30 天的刪除期間。Codex 使用者也應區分帳戶層級的內容設定，以及其獨立的完整環境設定。4, 5

對 Claude 而言，回饋特別值得注意。Anthropic 表示，按下讚、倒讚或提交錯誤回報，可能涉及將相關對話儲存最長五年，並將其用於包括模型訓練在內的用途。啟用一般模型改進，也會讓符合資格的去識別化資料在訓練流程中保留最長五年。這些規則與一般聊天刪除並不相同。6, 7

因此，一個人可能會在同一個產品內做出數個隱私決定，卻沒有意識到那其實是彼此分開的決定。產品設計應在使用當下清楚呈現這些差異。

Cursor 與 Perplexity：產品標籤不是處理界線。

Cursor 的 Privacy Mode 對訓練與供應商保留資料提供了有意義的限制。它並不會讓編輯器變成僅限本機：Cursor 表示，即使使用者提供自己的 API key，請求仍會經過其後端。其文件也說明了暫時性的加密檔案快取，以及與濫用調查或指定模型相關的例外情況。12

Perplexity 則呈現了另一種區別。其 Free、Pro 與 Max 帳戶都適用消費者訓練控制，且資料收集預設為啟用。已公布的選擇退出機制適用於之後收集的資料，而不是追溯移除先前已用於訓練的資料。購買個人訂閱，並不會讓它變成 Enterprise 帳戶。13

在這兩種情況下，真正相關的問題是所選模式與帳戶改變了什麼——而不是產品名稱看起來暗示了什麼。

Manus 與 Muse：私人工作區仍需要明確界線。

Manus 表示，個人任務除非被分享，否則皆為私人。其 Team 文件也說明，擁有者可以存取團隊工作階段內容。這些都是有用的可見性規則，但它們並未建立個人訓練政策。本次審查無法取得完整的 Manus 隱私頁面，因此這個問題仍屬未經驗證，而不是以其他方案內容來補上。14, 15

Muse 的上線文件對於營運限制與技術性防止之間的差異，說明得異常明確。Meta 表示，上線時的 Secure VM 透過政策限制員工存取，但在營運、支援或保護服務有需要時，並不會阻止存取。原本描述為將以密碼學方式防止營運者存取的 Confidential VM，則被說明為即將推出，且仍處於有限測試中。規劃中的保護措施，不應被算作所有人都已可使用。 16

Muse 也會讓真正的連接器憑證遠離其主要代理，並將操作核准交由獨立的權限機制處理。這說明了一個有價值的原則：不應只是因為可能比較方便，就把祕密資訊或權限交給代理。16

把保護前移到暴露之前的節點

排除訓練，規範的是資料的一種用途。遮罩，改變的是可供處理的資料。限制保留，減少的是留下來的副本。權限控制，限制的是代理能做什麼。這些保護彼此互補，而它們各自作用的階段也很重要。

請看一個具體的請求範例：寫一封後續郵件給某位客戶，寄到特定的電子郵件地址。模型可能需要知道目的、語氣，以及相關承諾；但它未必需要客戶的真實姓名或地址，才能起草這封訊息。在推論前先將偵測到的這些識別資訊替換為占位符，可以在保留任務有用結構的同時，減少模型接收到的資訊。

這和直接傳送原始文字，並承諾在之後某個使用階段前再移除識別資訊，是不同的做法。

同樣的原則也不只適用於個人識別資訊。機密研究需要對研究內容本身設下控管；已連結的帳戶需要權限範圍明確且受限；保留的紀錄需要有明確的保存期限與可執行的存取限制。身分遮罩只是這套設計中的一個組成部分，不能取代對發明內容或文件實質內容的保護。

業界已有相關工作。OpenAI 在 2026 年 4 月發布了可於本機執行的 Privacy Filter，而 Meta 的 Muse 文件則描述了技術隔離，以及一套仍在開發中的更強機密運算設計。這些努力都支持了將隱私透過工程方式納入系統的主張。然而，工具的發布或路線圖本身，並不能證明每一段消費者對話現在都已獲得相應保護。16, 19

標準應該是：人們在今天實際使用的產品中，究竟能獲得什麼樣的保護。

Dvina：讓隱私成為日常互動的一部分

Dvina 的做法，是把這種更早期的保護帶進助理體驗中。根據其公開文件，系統會在人們輸入或上傳內容時，於本機偵測敏感個人資訊，將偵測到的個人資料加密，並在模型處理前以占位符替換。模型處理的是這些占位符，而不是原始偵測到的識別資訊。17, 18

這個差異具有實際意義。使用者不應該為了每一項任務都中斷流程，手動刪除姓名與聯絡方式，也不該只能依賴「模型收到之後會如何處理」的承諾。保護應該伴隨互動本身而來。

Dvina 也將使用者對話、檔案、提示詞與工作區資料排除在模型訓練之外。這樣的組合很重要：不訓練的承諾限制了再利用，而前處理保護則從一開始就限制了暴露給模型的個人資訊。17, 18

其他層面的措施也支撐了這種做法。Dvina 提到加密的對話儲存、已儲存訊息與使用者身分之間的分離，以及在歐盟託管並具備 GDPR 等級保護的資料。這些措施各自處理資料處理流程中的不同環節，而不是把全部負擔都交給單一的訓練偏好設定。17, 18

這項技術上的區別非常明確：在模型輸入中，偵測到的個人識別資訊會被替換，而周圍的任務內容仍可供處理。隱私因此成為資料流的一部分，而不只是使用者必須記得自行管理的一項偏好設定。

對我而言，這才是 AI 更有價值的方向：讓人們能把有意義的脈絡帶入工作，同時把系統設計成只揭露任務真正需要的那部分身分資訊。

結論：隱私將決定人們願意讓 AI 走進生活多深

AI 助理越能理解我們所處的情境，就越有用。這也帶來一項責任：必須保護支撐這種理解的資訊。若一方面要求人們提供更多存取權限，另一方面卻只多給一個設定頁面，這並不是充分的答案。

證據指出了幾種彼此不同的風險。軟體可能會在帳戶之間暴露資料。已儲存的對話可能成為法律要求調取的對象。即使沒有發生安全漏洞，也可能存在經授權的人工審查。即便指控尚未獨立成立，圍繞私人研究的爭議仍可能削弱信任。

這些風險需要的是工程上的投入，而不只是更好的措辭。敏感資料偵測、前處理保護、身分分離、有限保存，以及可執行的權限控制，都應該作為 AI 基礎安全能力而持續受到重視。助理的實用性與對使用者的保護，必須同步推進。

在 Dvina，我們正透過把模型處理前的保護納入產品基礎，協助引領這項轉變。 這個目標不是靠更強的宣稱來要求更多信任，而是要減少有多少信任只能建立在承諾之上。

人們應該能夠尋求協助、發展想法，並分享推進所需的脈絡，而不必把每一次對話都視為可能交出自己隱私的行為。建立這種信心，是 AI 接下來最重要的任務之一。

來源與範圍

資料來源於 2026 年 9 月 22 日查閱。本文依據供應商文件與具名報導撰寫；並非獨立的安全稽核。比較範圍主要聚焦於個人方案。商業方案、API，以及特定模型的例外情況，另行標示。數學章節區分了已報導的疑慮與 OpenAI 更新後的回應；兩者皆不構成獨立發現。由於無法取得 Manus 的完整隱私政策，其個人方案的訓練規則仍無法驗證。