机器遗忘更安全？双视角推断攻击暴露智慧楼宇隐私盲区

物业公司、园区运营方和楼宇集成商这两年常做一件事：用AI把“人、车、门禁、能耗、工单、摄像头”串成一张智能运营网。效果确实明显——比如冬季用能高峰（12月到次年2月）里，预测与调度做得好的楼宇，能耗波动会更可控，投诉也更少。

但很多团队在隐私上容易踩一个误区：只要支持“机器遗忘”（Machine Unlearning），按用户或租户要求删除数据，就等于更安全。现实更复杂。2025-12-19公开、并被AAAI2026接收的一项研究提出了一个非常尖锐的提醒：在“原始模型 + 遗忘后模型”并存的场景里，攻击者能同时查询两个模型，反而可能获得更多关于未被删除数据（保留数据）的隐私信息。这类风险，对智慧楼宇和物业运营尤其致命，因为你们的“保留数据”往往是最敏感、也最有价值的运营底座。

我把论文的核心结论翻译成运营语言就是一句话：当你把“遗忘前后两个版本的模型”同时暴露给业务系统或外部合作方，你可能在帮攻击者做对比实验。

双视角推断攻击（DVIA）到底在攻击什么

直接说结论：**DVIA（Dual-View Inference Attack）主要推断“某条数据是否参与过训练”，而且目标不是被遗忘的数据，而是“仍被保留的数据”。**这点很反直觉。

传统成员推断攻击（Membership Inference）通常只盯一个模型：给模型喂一个样本，看输出置信度、损失等统计量，推断样本是否在训练集中。新论文提出的“双视角”更狠：

• 你有一个原始模型（还没遗忘）
• 你有一个遗忘后模型（已按请求删去特定数据影响）
• 攻击者对同一条输入，同时查询两者
• 然后利用两者输出差异，推断“这条输入对应的样本是否属于保留训练数据”

研究者从信息论角度引入了“隐私知识增益（privacy knowledge gain）”的概念，强调双视角会带来额外信息：

同时查询两个模型得到的信息量，大于只查询其中一个模型。

把它套进智慧楼宇场景：如果你的门禁异常检测模型、访客风险评分模型、或能耗预测模型，既保留了“历史版本”（供审计/回溯），又上线了“遗忘版”（供合规），而且都能被同一主体访问（哪怕是内部某个系统账号），那就形成了DVIA天然的攻击面。

为什么“机器遗忘”会放大对保留数据的泄露

机器遗忘的目标是：让模型“看起来像从没见过要删除的数据”。为达到这个目标，模型参数、决策边界会发生定向变化。攻击者如果只看一个模型，看到的是“某种输出”。但当它能比较“遗忘前 vs 遗忘后”，它看到的是“变化量”。

变化量往往比绝对值更容易被利用。

就像物业运营里你看单次电费账单不一定能推断用能结构，但你若拿到“改造前后能耗曲线差值”，很多细节就暴露了。

智慧楼宇/物业AI的典型“高风险双视角”场景

直接给几个我在项目里最常见、也最容易被忽略的组合：

1）多租户SaaS：同一输入可触达两代模型

很多楼宇智能化平台是多租户架构：同一API网关下面挂多个模型版本。为了灰度、回滚、对比A/B效果，团队会保留 v1（原始）和 v2（遗忘/修复/重训后）。

风险点在于：只要同一调用方能以任何方式触达两个版本，DVIA就成立。

2）审计与合规“保留原模型”

不少公司为了“可解释、可追责”，会把原模型封存到审计环境。问题是审计环境并不等于安全环境：

• 审计系统经常有更多人能访问
• 权限审批链更长、账号更多
• 日志里可能暴露调用特征

一旦审计环境允许类似黑盒查询（哪怕是批量离线评测接口），双视角就出现了。

3）供应链与楼宇联动：跨系统共享模型能力

你们的主题系列是“房地产与智慧楼宇”，但现实里楼宇运营经常要跟供应链/物流系统联动：

• 物资配送与仓储：安保、车辆、卸货口预约
• 设备备件：工单预测、库存补给
• 跨园区调度：人流/车流与能源联动

跨系统共享AI能力时，往往会把“旧模型（历史口径）”和“新模型（合规口径）”同时开放给合作方做对账。这对业务很方便，但对隐私是灾难：合作方拿到双口径，就拿到了推断信号。

你需要的不是“能遗忘”，而是“遗忘后不暴露对比面”

这里我态度很明确：**机器遗忘不是万能钥匙，甚至可能制造新的攻击通道。**在楼宇与物业的生产系统里，要把遗忘当成“合规流程的一部分”，而不是“安全方案本身”。

1）架构层：避免同一主体可查询两代模型

最有效的手段往往最朴素：消灭双视角可达性。

可落地的做法：

1. 版本隔离：遗忘前模型只允许离线归档，不提供任何在线预测接口。
2. 调用面最小化：同一业务账号不允许跨版本调用；必要时按环境（生产/审计）拆身份域。
3. 回滚策略改造：不要用“在线保留旧模型”作为回滚，改用“参数快照 + 受控恢复”，恢复期间禁止外部查询。

2）接口层：给黑盒查询“加摩擦”

DVIA强调无需训练攻击模型、用轻量似然比模块就能推断，这意味着攻击成本更低。防守端需要提高攻击者拿样本的效率门槛：

• 严格限流与配额：对同一输入分布的高频查询要报警（门禁、车牌、工单文本都可能被枚举）。
• 输出收敛：减少返回的细粒度置信度；很多业务只需要Top-1标签或区间分档。
• 一致性噪声：在不影响业务的前提下，让输出对微小扰动不那么敏感（要结合任务评估，别一刀切）。

3）训练与治理：把“保留数据隐私”纳入验收指标

论文提醒的重点是：**风险不只在被遗忘的数据，也在保留数据。**这会改变你们的验收方式。

我建议在智慧楼宇AI上线/改版时，把以下指标写进门禁与安防模型、能耗预测模型、工单NLP模型的交付清单：

• 成员推断风险评估：至少做一次黑盒成员推断测试（内部红队即可）。
• 双版本对比泄露评估：凡是涉及遗忘或重训的版本迭代，都做“可达性审计”：谁能同时访问两代模型？
• 数据删除闭环：删除请求不仅要“训练侧生效”，还要“模型分发侧生效”（缓存、边缘节点、第三方推理服务）。

一句话标准：删除请求结束的标志，不是“模型更新完成”，而是“旧模型不可被查询”。

常见追问：我们必须用机器遗忘吗？还能怎么选

智慧楼宇场景里，“删除请求”通常来自业主、租户、访客、员工。你确实可能需要机器遗忘，但并非只有这一条路。

Q1：直接重训是不是更安全？

很多时候是的。完全重训不会产生“遗忘前后差异可被利用”的同款对比面（前提是旧模型下线且不可查询）。代价是算力与交付周期。

Q2：边缘侧（摄像头/门禁）模型也有风险吗？

更高。边缘侧常见问题是：

• 设备上同时保留多个版本便于回滚
• 维护人员、集成商账号权限大
• 日志与调试接口暴露

边缘侧尤其需要“版本单一可见”与“调试接口封口”。

Q3：如果业务必须保留旧模型做审计怎么办？

可以保留，但要做到两点：

1. 不可查询（只保留文件与签名，必要时在受控环境离线复现）
2. 不可与新模型被同主体同时调用（审计人员与业务系统身份隔离）

面向2026：智慧楼宇AI的隐私合规，开始进入“对抗视角”

2025年底这个时间点很微妙：一边是楼宇智能化预算在新一年集中审批，另一边是数据合规与安全审计越来越常态化。把机器遗忘当作“合规必选项”的团队，会在2026遇到更现实的问题：你删得越快，可能越容易留下可推断的痕迹。

对于“人工智能在房地产与智慧楼宇”这条内容线，我更愿意把这篇研究当作一个分水岭：智慧楼宇的AI不再只是“更准、更省”，还必须回答“在攻击者眼里，它会泄露什么”。

如果你正在规划门禁安防、能耗优化、工单自动化或跨园区联动的AI项目，我建议从今天就把一个问题放到立项会上：**我们系统里是否存在任何形式的“双视角模型可达性”？**如果答案不确定，那就先把它查清楚再谈规模化。