私有 AI 与数据治理：哪些数据能进模型，如何留下证据

“私有”需要一个清楚的定义

私有 AI 可能指模型运行在本地、数据不进入供应商训练、服务部署在专属网络，或仅限特定用户访问。这些含义不同，不能只凭“私有部署”四个字判断风险。数据在传输、推理、日志、缓存、备份和监控各阶段都会被处理；本地模型仍可能把提示词写入磁盘日志或被管理员读取。治理应先确定数据类别、处理目的、用户范围和保留期限，再比较本地、托管与混合架构的真实控制点。

建立数据分类和流向图

按敏感程度划分公开资料、内部资料、个人信息、商业秘密和受监管数据，给每类定义允许使用的模型与处理方式。绘制数据流：用户输入经过哪些代理、API 网关、日志系统、模型运行时、向量索引和备份存储。为每条流标注处理者、区域、访问角色、加密状态、保留期限和删除方式。知识库还需要维护原文权限，确保检索结果不能超出用户原有访问范围。分类规则应能在实际应用里落地，不要设计成没人知道该怎么判断的抽象标签。

本地、托管与混合方案比较

本地推理可以控制网络边界和硬件，但需要自己承担补丁、物理安全、访问控制、容量和备份。托管 API 降低运维负担，需核对数据处理条款、保留策略、区域、模型改进使用和删除机制，并使用最小化发送的数据。混合模式可以将高敏感任务留在内网，把公开信息或非敏感任务交给外部模型，但路由规则必须透明且经过测试。不要把“数据不用于训练”等同于“数据从不被处理或保留”；要以具体服务条款和配置为准，并保留核查日期。

身份、权限与审计

模型本身不应成为绕过现有授权的捷径。用户通过组织身份认证，服务端根据请求者权限检索文档；工具调用采用独立的最小权限身份，写操作需要额外确认或审批。管理员、开发者、用户和供应商的访问边界应可区分。审计记录至少要能关联请求者、模型版本、数据源、工具调用与结果状态，但需避免为了审计而长期保存完整敏感提示词。日志字段采用数据最小化原则，设置访问审批、保留期限与删除机制。

供应链与模型风险

检查模型权重、容器镜像、插件和依赖的来源与许可证；固定可复现版本，监控安全公告。模型输出可能泄露训练数据、编造事实或被提示注入影响，需通过访问控制、输出检查和人工复核降低影响。若开放文件上传，应处理恶意文件、解析器漏洞和隐藏提示内容。私有环境也要有备份、修补、监控和事件响应。对外发布结果时标注信息来源和验证方式，不能以“模型在本地运行”替代事实核查。

数据治理闭环

可以落地的制度

为每个 AI 用例指定业务负责人、数据负责人和技术维护者，记录允许输入、禁止输入、模型版本、日志字段和用户告知。上线前进行威胁建模，测试跨用户检索、提示注入、异常输出和工具滥用。建立删除请求与数据导出流程；模型升级、供应商变更或数据源扩充时重新评估。每季度抽样检查实际流量是否符合分类策略，并演练密钥泄露、日志误存和数据源权限变更。治理的目标不是阻止使用 AI，而是让使用范围、责任和证据都可被解释。

深入实践：隐私风险分级

可以把 AI 使用场景分为公开信息、内部一般信息和受限敏感信息，针对每一级设定允许的模型端点、提示词最小化、日志保留和人工审核要求。不要把整个数据库导出后交给模型，优先检索必要片段并去除无关标识。供应商政策、服务地区和配置可能改变，定期核查并记录核查日期。对本地部署仍要审查谁能进入机房、谁能登录主机、备份是否加密、向量索引保存了什么。出现误传时要能识别数据、定位接收位置、轮换令牌并按流程删除副本。

风险评估样例：从上传文档到模型输出

以员工将合同上传到内部问答系统为例，先确认合同是否允许进入该模型、文件是否会被保留、谁能检索、输出是否会写入日志。随后检查文档解析服务、向量索引、模型推理和备份都由哪些身份访问。若采用外部 API，应发送完成任务所需的最小片段，并确认供应商的数据处理配置与当前合约相符。若采用本地模型，仍要限制日志访问并加密备份。模型输出涉及价格或义务时，应附上原文出处并由专业人员核对，不能因为部署在内部就作为法律或商业结论。

数据生命周期要可执行

为输入数据设置保存期限、删除触发条件和责任人。临时聊天历史是否保存、是否允许用户删除、删除后备份何时过期，都要说明。向量索引中的片段也属于数据副本，不能只删除原始文件便宣称数据已清除。模型调试日志要默认脱敏，必要时使用短期受控采样。每个处理环节记录数据类别与访问角色，发生误传时可以定位副本、撤销令牌并向负责人报告。定期以实际流程测试删除请求是否真正覆盖缓存、索引和备份生命周期。

治理不是一次审批

新模型、插件、数据源、外部工具或网络出口发生变化时，重新判断数据流和威胁模型。提供使用说明告诉员工哪些内容不得输入、哪些输出必须复核，以及如何报告错误。AI 应用发布前对提示注入、越权检索、敏感信息回显和异常工具调用进行测试。审计中抽查实际用户路径与批准设计是否一致；策略例外应写明期限并到期复核。将治理责任分配给业务、数据、安全和运维角色，避免所有问题都归到“IT 已经批准”。