本地模型处理隐私资料时仍要防哪些数据泄露路径

把模型下载到本机，确实能少走一段“把提示词和附件发送给外部模型服务”的链路，但它并不等于资料从此不会离开设备。真正处理隐私资料的是一整套应用：界面会保存会话，检索增强会建立向量库，插件可能访问网络，系统还会生成缓存、临时文件、崩溃记录和备份。只盯着模型文件是否本地化，很容易漏掉这些外围路径。

更稳妥的模式是把部署目标命名为本地受控处理区：模型只是区内的一个计算组件，输入、持久化、网络、权限和输出都要有边界。这个模式适合处理合同、客户资料、源代码、研发记录等不应随意外传的内容，也适合个人在离线设备上做私密笔记整理。

本地运行解决的是“推理在哪里发生”，隐私方案还要回答“数据在哪里出现、保存多久、谁能访问、能否联网、最后被带到哪里”。

本地推理仍然有多条外泄路径

第一类路径来自联网能力。桌面客户端即使调用本机模型，也可能保留联网搜索、插件、更新检查、错误上报或第三方解析服务。资料未必直接交给模型供应商，却可能在工具调用时进入另一个服务。尤其是带代理能力的应用，读取文档后还可以调用邮件、网盘或网页工具；若没有明确的授权边界，提示注入或错误操作会放大数据外发风险。

第二类路径来自监听端口。本地推理服务常通过 HTTP 接口被界面调用。如果服务绑定到所有网卡、缺少鉴权，或者端口经路由器、容器映射和远程开发工具暴露出去，同一网络中的其他设备就可能访问它。此时“服务在本机”并不代表“只有本人能调用”。

第三类路径来自持久化。提示历史、上传附件的解析文本、向量数据库、模型缓存、临时目录、操作系统交换区以及崩溃转储，都可能留下隐私资料的副本。若工作目录恰好位于云盘同步范围，或者整机备份没有独立保护，这些副本仍会离开本地处理边界。

第四类路径来自输出。模型生成的摘要、脱敏不完整的表格、引用片段和导出文件，很容易被复制到群聊、工单或在线文档。输入被严格限制但输出随意流转，最终仍可能暴露原始事实。对隐私任务来说，输出同样属于敏感数据生命周期的一部分。

NIST 的生成式 AI 风险框架把数据隐私、信息安全和模型可能记忆敏感信息分别列为需要治理的问题；OWASP 的生成式 AI 安全项目也持续强调敏感信息披露、提示注入与过度代理权限。这些风险并不会因为推理进程位于个人电脑就自动消失，区别只在于防护责任更多落到本地应用和设备管理者身上。

典型实现：把模型放进本地受控处理区

受控处理区先从输入边界开始。为隐私任务建立专用工作目录，不直接把整个个人文件夹或团队共享盘授权给应用。每次只导入完成当前任务所需的文件，先删除无关字段，再决定是否需要建立长期索引。这样既符合最小化原则，也能降低误选目录后被批量扫描的风险。

网络边界应采用“默认不需要”的思路。推理接口优先绑定回环地址，只允许本机进程访问；确实需要局域网共享时，再增加明确的身份验证、访问来源限制和传输保护。插件、网页搜索、遥测与自动更新最好与隐私处理会话分开，敏感任务期间关闭非必要出站连接。这里的重点不是永久断网，而是让每一条外连都有用途、范围和负责人。

权限边界要覆盖应用、模型服务和工具。它们不应默认拥有整块磁盘、通讯录、浏览器会话或管理员权限。若应用支持工具调用，应按任务逐项授权，并把“读取”和“写入/发送”区分开。只读检索工具不应顺带获得外发能力，生成结果也不应自动发布到远程系统。

存储边界要处理会话历史、向量库和日志。不同项目使用不同索引，不把客户 A 的资料与客户 B 的资料放入同一检索库；日志只记录排障所需信息，避免把完整提示词、附件正文和模型输出作为默认日志。日志本身要限制访问，并设定保留期限。CISA 的日志建议强调按政策保留并保护日志，放到本地 AI 场景同样成立：既不能为了“安全”无限保存敏感文本，也不能完全不留能够解释异常访问的记录。

最后是清理与输出。任务结束后，删除不再需要的上传副本、索引和导出文件，并确认同步目录、回收站、临时目录和备份策略是否仍保存副本。输出进入协作平台前做人工复核：检查姓名、联系方式、账号、合同编号、代码密钥以及可反向识别个人的信息。对于高度敏感资料，应把“允许输出什么”写成模板，而不是只靠操作人员临场判断。

五个看似本地、实际边界失守的反例

反例一：推理服务监听所有网卡

界面地址写着 localhost，并不能证明后端只监听本机。容器端口映射、远程开发代理和路由器配置都可能扩大可访问范围。正确做法是从服务绑定、鉴权和网络访问规则三个层面同时确认，而不是只看浏览器地址栏。

反例二：离线模型搭配在线插件

模型权重在本地，但“帮我查资料”“解析网页”“发送邮件”等工具会把上下文交给外部系统。隐私任务应使用明确的工具白名单，并在调用前展示将要发送的最小字段。

反例三：历史和向量库放在同步目录

云盘同步让资料获得了额外副本，也引入账号共享、历史版本和远端保留问题。专用工作目录应位于受控位置，备份是否允许、保存多久、如何加密要单独决定。

反例四：多个项目共用一个检索库

共享索引会造成跨项目召回，模型可能在回答一个客户的问题时引用另一个客户的片段。按项目或数据等级分区，删除原文件时同步清理对应向量，才能让生命周期保持一致。

反例五：只检查输入，不检查生成结果

摘要和改写仍可能包含精确数字、个人身份线索或原文片段。输出复核应成为发布前的固定关口，自动发送和自动发布默认关闭。

采用这个模式要接受哪些代价

受控处理区会牺牲一部分便利：关闭联网插件后，资料检索不再“一键完成”；项目隔离会占用更多磁盘；短期日志让长期追溯更困难；严格清理也会降低恢复误删文件的能力。因此，控制强度应与资料敏感度匹配。普通公开资料可以保留更多协作能力，客户隐私、医疗记录、未公开代码和访问凭据则应使用更严格的隔离与保留策略。

还要注意模型来源与更新。离线并不等于可信，应记录模型、运行器和插件的来源及版本，在受控窗口完成更新。若用隐私资料做微调、适配器训练或长期记忆，训练产物本身也可能承载敏感模式，应按与原始资料相近的等级保管，不能当作普通模型文件随意分享。

上线前的判断清单

• 推理接口是否只绑定预期地址，并有与使用范围匹配的鉴权？
• 客户端、插件、遥测、更新和错误上报中，哪些会访问外网？
• 应用实际能读取哪些目录，是否拥有不必要的管理员权限或远程写入能力？
• 提示历史、附件文本、向量库、缓存、日志和崩溃文件分别存在哪里？
• 工作目录是否被云盘、系统备份、远程开发工具或团队共享软件自动同步？
• 不同项目和不同敏感等级是否使用独立索引与独立存储？
• 资料删除后，索引、缓存、回收站和备份中的副本如何处理？
• 模型输出进入邮件、群聊、工单或在线文档前，是否有人工复核？
• 模型、运行器与插件的来源、版本和更新责任是否可追踪？
• 发生异常访问时，是否有足够但不过量的审计记录用于定位？

如果这些问题没有答案，部署只能称为“本地推理”，还不能称为“隐私处理”。可靠的本地 AI 隐私不是一个开关，而是一组围绕数据路径建立的边界：让资料只在必要位置出现、只保存必要时间、只被必要主体访问，并在离开处理区之前接受复核。

参考资料：NIST AI 600-1：生成式 AI 风险管理框架配置文件；OWASP Top 10 for LLM and GenAI；CISA：业务系统日志与监控建议。