AI数据泄露防护要盯住哪些环节，训练和推理阶段各有什么风险
AI数据泄露防护的核心不是拦住所有请求，而是先分清数据在哪个环节可能流出。
训练阶段看数据来源和留存策略，推理阶段看输入是否夹带敏感信息、输出是否回显内部内容，日志阶段看有没有把原始请求完整落盘。
三个环节都做基础控制，比只在一个入口加过滤更实际。
先分清数据在哪个阶段可能流出
AI 系统的数据泄露通常出现在四个位置：
- 训练数据：语料中混入身份证号、手机号、内部文档或客户合同，模型可能记住并在回答中复述。
- 推理输入：用户把数据库连接串、密钥、内部工单贴进对话，输入被第三方模型服务接收或留存。
- 模型输出：模型把系统提示词、内部知识库片段或训练样本原样返回给不该看到的人。
- 日志与缓存：网关、应用或模型服务把完整请求体写入日志，运维人员或日志平台成为新的泄露面。
判断自己的系统属于哪种情况，可以先回答一个问题：敏感数据是进入模型前被过滤，还是进入后才被处理？ 事前过滤成本低但容易误伤，事后检测准确但要求日志里已经有敏感数据，需要权衡。
训练数据侧：来源审查和最小化
训练阶段的防护重点不是模型本身，而是语料进入训练流程之前有没有做筛选。
- 建立数据来源清单，记录每批语料的获取渠道、授权状态和负责人。来源不明的语料不进入训练集。
- 对文本做正则和规则扫描，至少覆盖手机号、身份证号、银行卡号、邮箱地址和常见密钥前缀。扫描命中后不直接删除，先人工确认是否属于业务必需字段。
- 训练集和验证集分开存放，验证集不要复用生产环境里的真实用户对话。
- 如果使用外部预训练模型，确认服务方的数据使用条款中关于训练数据留存和二次使用的说明，不确定时按最保守方式处理。
这里的边界是：规则扫描只能发现格式固定的敏感信息，无法识别业务语义上的机密内容。
涉及合同条款、内部定价这类非结构化机密，需要配合人工抽检和访问权限控制，不能只依赖正则。
推理阶段：输入过滤和输出约束
推理阶段是用户感知最强、也最容易出问题的环节。
可落地的控制点包括：
- 在应用层对用户输入做敏感信息检测，命中密钥、连接串、身份证号等模式时提示用户脱敏后再提交，而不是静默放行。
- 系统提示词中不写入数据库密码、内部接口地址或完整密钥，系统提示词一旦进入上下文就有被诱导输出的可能。
- 对模型输出做回显检查，如果输出中包含与系统提示词高度相似的片段，应拦截并记录。
- 知识库检索场景下，按用户权限过滤检索结果，避免低权限用户通过提问拿到高权限文档片段。
一个常见误区是只在模型服务端做过滤。
实际上，如果应用层已经把完整请求发给第三方 API，过滤发生在发送之后就没有意义。过滤必须放在数据离开自己可控环境之前。
日志和缓存：最容易被忽略的泄露面
很多团队在输入输出上做了控制，却把完整请求写进了访问日志。
检查以下几点：
- 网关和应用的日志级别是否记录了请求体，如果记录，是否对敏感字段做了脱敏。
- 模型服务的调用日志保留多久，谁能访问，是否接入了统一的日志审计。
- 对话缓存或会话历史是否明文存储，是否按用户隔离。
- 调试开关是否在生产环境关闭，调试日志往往包含最完整的原始内容。
日志脱敏的验证方式很简单：构造一条包含测试手机号的请求，走完整链路后检索日志文件，确认日志中不出现完整号码。
这个检查可以定期执行，比只看配置项更可靠。
怎么判断防护是否到位
不需要追求零风险，但可以用几个可核对的检查项判断基础防护是否成立：
- 训练语料有来源记录和敏感信息扫描记录，扫描规则有版本管理。
- 用户输入在离开可控环境前经过过滤，过滤规则覆盖密钥、证件号和连接串。
- 系统提示词中不包含可直接使用的凭据。
- 日志中不出现完整的敏感字段，脱敏规则经过实际请求验证。
- 模型输出有回显检查或抽样审计机制。
如果以上有几项做不到，优先补日志脱敏和输入过滤，这两项改动成本低、影响面直接。
训练数据治理周期长，可以按批次逐步推进，但来源清单要先建立起来。
需要说明的是，不同部署方式边界不同。
调用外部模型 API 时，数据会离开自己的服务器，防护重点在发送前的过滤和合同条款确认；
私有化部署时，日志和缓存的管理责任完全在自己这边。
先确认部署形态，再决定控制点放在哪里。
