当 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 前的处理和复核流程。企业最终仍需要根据现有技术栈、文件类型、部署区域、人工复核要求和五阶段链路的覆盖范围做验证。

敏感信息控制的价值不在于增加一个“扫描步骤”，而在于让每个进入模型和离开模型的对象都有来源、有策略、有版本、有异常路径。五个阶段一旦能被独立观察和验证，团队才有条件持续改规则、查失败、做人工复核，并避免把一次检测误当成完整的安全保证。

> 边界说明：本文提供通用架构设计思路，不构成法律、监管或合规建议，也不承诺阻止所有敏感信息泄露。具体义务与控制选择取决于司法辖区、部署模式、系统配置、内部制度和客户工作流程。