換掉名字,不等於藏住了人:發往外部模型前的假名化與推斷泄露
把工作文檔中的姓名與證件號換成佔位符再發給外部大模型,只有在整篇文檔零漏檢且佔位符經模型生成後仍能原樣還原時才成立。最新預註冊基準與隱私評估表明,在合成文檔上,最佳現有開源工具在多數長文檔中仍會漏掉至少一處完整個人資訊,而攜帶記憶的助手即便做到直接泄露近乎為零,仍可能因主動提出的額外照顧而在外發回覆中暴露敏感屬性。
名字換成了佔位符,為什麼文檔和回覆還在泄密
設想員工讓外部大模型起草覆函,或讓帶持久記憶的助手向外部協調方訂差旅。常見做法是在請求前做可逆假名化:把姓名、證件號、地址換成佔位符,模型返回後再在本地還原;對帶記憶的助手,還可能在系統提示詞中要求不對外透露隱私。
這依賴兩個前提:一是整篇文檔零漏檢、佔位符經回覆後仍能還原;二是回覆只要不寫出敏感屬性,接收方就猜不出來。兩項新研究檢驗了這兩個前提:一項基於合成文檔的雙語預註冊基準顯示,最佳現有開源工具在多數長文檔中仍漏掉至少一處完整個人值,且往返生成會出現佔位符變形與虛構[1];另一項評估顯示,即便直接泄露低於 1%,助手主動提出的照顧仍會讓接收方推斷出敏感屬性[2]。
整篇漏檢算術與體貼式推斷:兩類失守機制
第一類是可逆假名化的按篇漏檢與往返損耗。Beskorovainyi(2026)指出,若檢測完全,外部服務只見佔位符不見字面值(準標識符仍可能留存),但漏掉一個姓名或證件號就會使防線失效[1]。作者在俄語和英國英語上評測五款開源工具、正則基線及架在兩款最強工具上的薄層引擎[1]。預註冊合格線要求:結構化標識符(護照、税務、醫療、保險號及銀行卡、國際銀行帳戶)召回率至少 99%,姓名、地址與機構至少 95%,漏檢文檔不超過 2%,回答後至少 99% 佔位符還原;執行排除自家數據集規則,運行前公開每語種 1,000 份合成留出文檔的哈希、判定、運行計劃與停止規則[1]。往返測試由兩個 90 億至 120 億參數的 4 比特本地開源模型基於脱敏文本寫摘要和回信後再還原[1]。
外部數據集上無一現有工具全部達標,標識符召回率 96% 至 98%(俄語接近 99% 線,英國英語未達標)[1]。留出集上,最佳現有工具在 61%(俄語)和 58%(英國英語)的文檔中漏掉至少一處完整個人值;無附加噪聲文檔上仍漏檢 41.2%(俄語)與 38.3%(英國英語)[1]。這部分源於算術:每份留出文檔平均含約 30 個(俄語)或 26 個(英國英語)個人值,單值召回率固定時,按篇漏檢率隨長度上升[1]。薄層引擎結合校驗和、地址與機構整值遮蔽、首次命中後全文同值遮蔽、實體消解與容錯還原,將按篇漏檢率降至 0.3%(俄語)與 0.2%(英國英語),但文檔來自其此前六個週期開發的同一生成器[1]。往返測試中,英國英語 760 份回答後至少 99% 佔位符被還原,但俄語姓名佔位符僅還原 94.6%(低於 99% 線),主因姓氏詞尾格變化錯誤,約四分之一俄語回答含至少一個失敗姓名;模型還會編造未簽發佔位符(如一模型在俄語最終集編造 85 個),無法還原而留在文中[1]。侷限:全為合成數據、未測真實文檔;由引擎作者運行(聲明競爭利益並靠預註冊與公開數據緩解);僅計字面值漏檢,不計準標識符或屬性推斷;往返僅用兩個小型本地模型,大型託管模型或有不同[1]。
即便無字面值,上下文仍可推斷屬性。Staab、Vero、Balunović 與 Vechev(2024)在較早模型與網絡論壇真實檔案上表明,模型能從無顯式標識符文本推斷所在地、收入、性別等,首位猜測準確率最高 85%、前三位猜測 95%,成本與耗時僅為人工的 1/100 與 1/240,文本匿名化與模型對齊均未能阻止這種推斷[3]。歐盟《通用數據保護條例》第 4 條第 5 項將假名化定義為無額外資訊即無法歸屬特定數據主體的處理(額外資訊單獨存放並受保護),序言第 26 段指出結合額外資訊仍可歸屬自然人的假名化數據仍屬個人數據,判定可識別性需考慮「單獨挑出」等合理可能手段[4]。在該框架下,假名化數據仍是個人數據,佔位符僅降低暴露而未移出範圍[4]。
第二類是代擬回覆時的推斷泄露。Huang、Fu、Meng 與 Chaudhuri(2026)考察無攻擊者場景:帶持久記憶的助手代表用戶向第三方訂住宿、交通、餐飲或協調日程[2]。實驗含 10 個合成角色、10 項敏感屬性(健康、宗教、財務)與 10 項常規任務共 950 個實例,僅對無需敏感記憶即可完成的 98 個「受保護」配對計分;另一模型模擬「誠實但好奇」的接收方僅憑回覆猜屬性,經無敏感記憶對照組校準,跨五個前沿模型與兩種提示詞(通用個性化、隱私感知)評測[2]。如為糖尿病用戶訂酒店時,回覆未提病名,卻要求放醫療用品的房內冰箱與低糖早餐,協調員即可推斷病情[2]。
五個模型在兩種提示詞下推斷泄露均高於直接泄露,單次猜測推斷率平均高出直接披露 16.8 個百分點[2]。隱私感知提示詞下,三個模型直接泄露低於 1%,但前三次猜測推斷泄露仍達 16.2% 至 25.2%(單次猜測 13.0% 至 21.0%)[2]。一模型提高推理投入後,基線直接披露從 18.1% 降至 4.9%,單次猜測推斷泄露僅從 42.2% 降至 35.4%(任務完成度約 95%)[2]。刪去記憶中的屬性名也幾乎無效(隱私感知提示詞下單次猜測推斷率 20.6% 對 21.0%)[2]。作者觀察到,許多線索來自助手主動提出、任務並不需要的照顧[2]。作者建議:以最少細節表達需求(只問有無冰箱不提醫療用品);有風險時向用戶説明並獲批再發;靠輸入端按任務必要性過濾記憶或輸出端改寫器將隱私保護與生成解耦[2]。侷限為合成角色與記錄、模擬模型接收方、十項常規任務及英文[2]。

工程落地與 rlab.works 能力映射:准入、裁剪與人工關口
我們的工程判斷是:(1)在自有文檔類型與長度上預設閾值,度量按篇殘餘漏檢與還原率;(2)將佔位符視為降低暴露而非匿名化,哪類文檔可外發仍由訪問規則決定;(3)還原前檢查被篡改或編造的佔位符並告警;(4)按任務必要性過濾入模記憶;(5)涉及敏感類別的外發回覆須標出風險並經用戶確認;(6)僅留脱敏軌跡供審計。
在 rlab.works 的模型網關與智能中樞模組中,可映射三項技能包與三項組件:
- 訪問範圍與脱敏留痕:模型網關的團隊模型訪問規則(S14)執行「按角色定規則 → 審閲規則變更(人工關口) → 規則生效 → 抽查請求記錄(人工關口)」,配合提示詞註冊、緩存與語義策略(提示詞模板、意圖分類與護欄證據,上下文優化含建議模式)及脱敏對話軌跡採集(模式校驗、脱敏與標記數據集可用性)。該包在政務場景可遷移,需接入單位身份與實際文檔權限,僅靠提示詞無法強制訪問控制;我們認為哪類文檔可以發往外部服務應在這裏決定。
- 記憶確認與按需裁剪:智能中樞的用戶偏好記憶與回訪(S06)執行「收集自願提供的偏好 → 整理待記錄內容 → 用戶確認記錄項(人工關口) → 繼續對話或轉介 → 按約回訪」,配合個人記憶檢索與生命週期(候選記憶、去重、保留窗口與人工增刪改)。該包在消費應用有源數據驗證(危機引導非專業支援,求助草稿由用戶決定是否發送),在教育場景可遷移(不推斷學習能力或心理問題,不自動發送求助草稿);我們認為其整理與確認步驟可用於把無關的敏感記憶擋在草稿之外。
- 外發交接核准:智能中樞的服務受理與轉交(S09)執行「核對帳戶與角色 → 建立服務記錄 → 批准交接資料(人工關口) → 轉交負責人」。該包在醫療場景可遷移,對接醫院身份與工單系統僅作行政服務,不做按症狀分診;我們認為「批准交接資料(人工關口)」可作為敏感細節交出前的人工確認點。
三項技能包均為合成數據演示的擬議未集成方案;三項組件雖經靜態檢查標為可用,但均未實現可逆假名化還原、按篇漏檢度量或推斷泄露檢測——這是我們從文獻提煉的要求。本文不構成法律、安全或醫療建議。

上線前的三項核查清單
- 按篇測試殘餘漏檢與還原:預設合格線,考核整篇零漏檢率、詞尾格變化還原率及虛構佔位符攔截。
- 按任務必要性過濾記憶:剔除無關敏感記憶,用最小必要事實表達需求。
- 外發第三方回覆由人工確認:對涉及健康、宗教或財務的額外照顧,標出推斷風險並經批准後發送。
覺得有用?分享給需要的人。
參考文獻
- [1]
Beskorovainyi, V. (2026). Reversible pseudonymisation of documents sent to external LLMs: An open bilingual benchmark and an engine (arXiv:2610.34012). arxiv.org ↗
- [2]
Huang, P., Fu, Y., Meng, L., & Chaudhuri, K. (2026). InferPriv: Evaluating inferential privacy leakage in LLM assistants (arXiv:2610.34640). arxiv.org ↗
- [3]
Staab, R., Vero, M., Balunović, M., & Vechev, M. (2024). Beyond memorization: Violating privacy via inference with large language models. *The Twelfth International Conference on Learning Representations (ICLR 2024)*. arxiv.org ↗
- [4]
European Parliament and Council of the European Union. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). *Official Journal of the European Union*, L 119, 1–88. eur-lex.europa.eu ↗