修訂痕跡會把刪除的細節傳給收件人

AI 助理即使遵從刪除要求，仍可能在解釋修改時洩露已刪除的細節。研究人員分析了 26,753 個修訂要求，發現 8.8% 的修訂回覆中留下了被移除內容的痕跡。如果起草工具不把私人的編輯評論放進交接內容，主管就能只把可用的時段表傳給承包商。

從 AI 撰寫的訊息中刪除一句話，並不總能刪除其中的資訊。主管可能會在把時程表傳給承包商前，移除員工的醫療預約，但助理仍可能補上一句：「我移除了醫療預約。」承包商現在就知道主管原本想保密的內容。把助理完整回覆轉寄出去的團隊也會面臨同樣的問題：完成的訊息和助理私下的編輯歷史可能會以同一個套件送達。

隱藏的第二則訊息

人們越來越常使用 AI 助理為其他人起草電子郵件、報告、程式碼註解和工作文件。在起草過程中，使用者可能加入一項事實，之後又要求助理移除或替換它。要求的正文可以是乾淨的，但前言、後記或評論卻可能解釋消失了什麼。

這種解釋就是修訂痕跡：一份面向收件人的編輯說明。對負責起草的人來說，它聽起來可能很有幫助；但對即將收到結果的人來說，它不一定安全。像「刪除這個」這樣的指令，也不是一道牢靠的存取控制界線。同一則回覆可能把原本要給收件人的資訊，和產生這些內容的私人過程資訊混在一起。

這個問題類似一般文件系統中的修訂追蹤、評論、中繼資料和失敗的遮蔽。但語言模型可以在普通散文中重現這個問題，不需要顯示可見的標記層。

解釋如何洩露修改內容

研究人員將此描述為一條獨立的揭露管道：模型在正文中遵從修改要求，接著又在解釋修改時把撤回的項目帶回來。他們分析了三個公開對話資料集中的 26,753 個修訂要求，發現 8.8% 的修訂回覆中出現修訂痕跡。

接著，他們建立了 RevLeakBench，一套涵蓋私人對話和 AI 代理的 100 項測試。在測試中，讀者只能看到被視為交付內容的部分，並試圖找回被撤回的項目。在對話案例中，讀者有 13.7% 的機率找回該項目。相比於使用者只是決定不傳送的資訊，個人資訊更常被找回。

這項結果指出了一個簡單但重要的區別。從要求產出的文件中移除文字還不夠。系統還必須決定，自身解釋的哪些部分屬於收件人。若轉寄介面把助理的完整回覆視為文件，就無法在這兩者之間劃出可靠的界線。

研究人員測試了建立這條界線的方法。要求助理只回傳交付內容，降低了修訂痕跡的比例，也減少了找回內容的情況。移除已辨識的編輯句子的輸出篩選器，則進一步將找回率降至 1.3%，以對話測試而言如此。但這個篩選器需要兩類資訊：撤回項目的代稱，以及必須保留的內容註記。實際工具必須從互動過程或其他元件取得這些限制條件。

安全交接應該是什麼樣子

在工作聊天中，主管可以移除醫療預約，而承包商只會收到可用的時段。畫面上不會有指出該預約的解釋句子。工具必須強制執行只交付給收件人的交接，而不是轉寄其編輯評論。

同樣的界線也可能適用於程式碼審查。工程師可能會從範例設定中移除憑證或內部端點。公開評論會包含修正後的範例，而篩選機制會移除指出該祕密的句子，同時保留協作者仍需要的技術指示。

這個未來取決於工具能否可靠地把必要內容和私人的起草歷史分開。它也取決於篩選器是否知道哪些內容被撤回，以及收件人仍需要什麼。這套基準測試不涵蓋多語言、長時間執行或可執行程式碼的情境，因此這條界線尚未在所有地方接受測試。但它的核心教訓已經很清楚：「刪除」必須表示內容不在交接內容中，而不只是不存在於文件的主要段落裡。

來源

arXiv, “Nothing to See Here'': Unintended Disclosure through Revision Traces of LLM Deliverables