当 AI 应用既接收文本输入也接收附件时敏感信息控制不能只放在“调用模型之前”这一个点。更稳妥的设计是把附件接入、内容解析、模型前策略、模型后检查、交付与审计拆成五个阶段并让每次放行、替换、阻断和人工复核都有一致的上下文。这样做不能消除所有泄露风险但能把判断位置、失败处理和责任边界说清楚。为什么只在调用模型前脱敏一次还不够一个看似简单的 AI 问答请求可能同时包含用户输入、上传文件、文件元数据、检索片段、系统拼接的上下文、工具返回值和模型输出。敏感信息也不一定只出现在正文里文件名、批注、隐藏内容、图片中的文字、历史版本或日志载荷都可能成为暴露面。如果所有控制都压在模型调用前的一次检测上常见问题有三类- 上下文不完整策略只看到了文本框却没有看到附件解析结果或检索片段。- 处理结果不可解释请求被拒绝或内容被替换后应用无法回答“哪条策略在什么对象上做了什么”。- 输出侧重新带出敏感信息模型可能从获准上下文中复述不应面向当前用户展示的内容工具调用也可能把新数据带回响应。因此脱敏模块更适合被看作 AI 工作流中的一个控制能力而不是一个孤立的字符串替换函数。它需要与身份、权限、策略、内容处理、人工复核和审计共同工作。开始设计前的四个问题在画架构图之前先回答四个问题。1. 哪些内容需要检查至少区分用户直接输入、附件原件、附件解析文本、检索片段、提示词拼装结果、工具返回值、模型输出和最终下载文件。不同对象的可见范围、生命周期和处理方式可能不同不能只用一个 content 字段概括。2. 系统根据什么决定放行还是拦截同一段信息对项目负责人可能可见对外部协作者却需要移除。策略上下文通常要包含用户、角色、项目、用途、数据类别、目标模型或工具、交付对象和当前操作。缺少这些信息时系统不应猜测为低风险。3. 检查服务出错时是继续还是停止解析超时、策略服务不可用、输出检查失败和日志写入失败不是同一种故障。每类故障都要预先定义动作阻断、有限降级、进入人工队列或只允许处理低风险内容。默认行为应由业务风险决定并通过演练验证。4. 被替换的敏感信息以后还能还原吗有些流程只需要生成不含原敏感值的副本另一些流程可能需要在受控范围内保留映射以便授权人员复核。是否保存映射、谁能访问、保存多久、何时销毁都是独立的高风险决策。不能把“遮住显示”和“从输出中移除”当成同一件事。一份文件从上传到返回要经过哪五道检查[AI 敏感信息五阶段控制链路]第一步先确认谁上传了什么文件接入层先建立一次请求的统一标识并记录提交者、业务场景、目标操作和附件清单。这里的重点不是立即判断所有敏感信息而是防止对象在后续阶段失去来源关系。建议把原始内容与后续处理副本分开保存避免模型任务误读原件。文件名、大小、类型声明等元数据只能作为路由信息不能代替内容检查。对于无法识别、受密码保护或不在批准范围内的附件应进入明确的异常分支而不是按普通文本继续处理。第二步把文件内容读出来并标出没读到的部分附件需要先转换为策略引擎能够检查的对象。这个阶段可以包括正文提取、页面或段落定位、图片文字识别、表格结构保留等但具体能力要按所选解析组件验证。解析结果应带回原对象的位置引用例如附件、页、段落或区域标识。解析不完整也要成为显式状态。若只提取到部分内容后续策略不能把“未发现”写成“确认不存在”。这一阶段的输出不是一大段无结构文本而是一份待检查对象清单哪些对象成功解析、哪些失败、哪些需要人工处理以及每个对象来自哪里。第三步在内容发给模型前决定放行、处理还是拦截策略服务同时读取内容对象和业务上下文给出可解释的动作。常见动作可以抽象为放行、替换或移除、阻断、转人工。这里不预设某个厂商的规则语法或接口。模型前控制至少要覆盖三条路径1. 用户直接输入2. 附件解析内容3. 应用通过检索或工具补充的上下文。如果内容经过替换或移除送往模型的应是处理后的工作副本。原件与模型载荷之间要有清晰隔离。若业务允许保留还原映射映射应位于独立受控域中并与普通应用日志分离。策略结果应携带版本信息。否则同一请求在事后无法重现当时为什么被放行或阻断。策略更新时也要说明正在处理的长任务继续使用旧版本还是重新评估。第四步模型返回内容后再检查一次模型只接收阶段三批准的载荷。调用完成后输出不能直接返回给用户还要结合当前接收者和交付场景再检查一次。输出检查不是简单重复输入检查。它需要关注模型是否复述了受限上下文工具返回是否引入新敏感信息引用或链接是否越过权限边界以及最终响应是否应被替换、阻断或转人工。流式输出要单独设计。如果系统先把片段推送给前端再在完整响应上检查检查到风险时内容可能已经展示。可选方案包括按缓冲区检查后再释放、只对批准场景启用流式响应或对高风险任务关闭流式输出。具体选择取决于可接受的延迟和暴露风险。第五步只交付通过检查的版本并留下必要记录应用只交付通过输出策略的版本同时记录本次处理的结果和异常。审计记录的目标是回答谁在何时以什么场景提交了哪些对象使用了哪个策略版本各阶段做了什么决定是否发生人工复核最终交付的是哪个版本。日志本身也可能含有敏感信息。更稳妥的做法是记录对象标识、类别、位置、动作、策略版本和结果摘要避免把原始敏感值、完整提示词或完整模型响应复制进普通日志。若排障确实需要样本应使用单独授权、受限保存期和访问审计。## 各环节之间需要传递哪些信息不同系统可以使用同步调用、消息队列、工作流引擎或人工任务但各阶段之间最好共享一组稳定语义这些是架构字段建议不是 bestCoffer 已公开的接口或日志字段。实际名称、范围、保存期与集成方式需要由产品和项目团队确认。哪些错误最容易让敏感信息绕过检查下面这份清单适合在设计评审和联调时逐项过一遍。完整可复用版本见[失败模式清单]上线前应该测试哪些情况不要只准备“正常文件”。至少覆盖以下测试组- 文本输入、单附件、多附件、检索片段和工具返回分别命中策略- 附件无法解析、只解析一部分、内容层不在当前覆盖范围- 同一内容在不同用户、项目和交付对象下得到不同决策- 策略更新、长任务重试和重复提交- 输出被替换、阻断和转人工- 流式输出在风险命中前后是否存在已展示片段- 日志、告警和排障页面是否意外保存原始敏感值- 原件、模型工作副本和最终交付版本是否可以被明确区分。每项测试都应检查“最终结果”和“审计证据”是否一致。对于文件格式覆盖、处理性能、部署范围、集成深度、还原权限和具体日志字段需要在产品验证或 POC 中单独确认不能从通用架构直接推导。企业选方案时可以比较哪些供应商企业级产品大致走四条技术路线关注点并不相同这几类产品并不是简单的替代关系。Microsoft Purview 更靠近企业统一策略与终端出口Google Cloud Sensitive Data Protection 更像可编排的去标识技术组件Amazon Macie 聚焦云存储发现bestCoffer 则更靠近文档进入 AI 前的处理和复核流程。企业最终仍需要根据现有技术栈、文件类型、部署区域、人工复核要求和五阶段链路的覆盖范围做验证。敏感信息控制的价值不在于增加一个“扫描步骤”而在于让每个进入模型和离开模型的对象都有来源、有策略、有版本、有异常路径。五个阶段一旦能被独立观察和验证团队才有条件持续改规则、查失败、做人工复核并避免把一次检测误当成完整的安全保证。 边界说明本文提供通用架构设计思路不构成法律、监管或合规建议也不承诺阻止所有敏感信息泄露。具体义务与控制选择取决于司法辖区、部署模式、系统配置、内部制度和客户工作流程。