AI 脱敏中间层怎么设计？从 OA 到豆包、火山方舟的完整控制链
国内 OA、案件系统或 HIS/EMR 把文件交给豆包、火山方舟前，如何设计脱敏中间层：覆盖同步异步、人审、异常队列、放行阻断降级、重试幂等、日志脱敏、证据留存和输出复检。
核心要点
- AI 脱敏中间层应管理原件、副本、模型输入和模型输出四类对象及其状态。
- 脱敏卫士适合在自动化链路建设前承担桌面端本地预处理与人工复核工作台。
- 低置信度、扫描异常和授权不清的文件必须进入人工队列或默认阻断。
- 脱敏卫士当前不是 OA、HIS、豆包或火山方舟的通用实时连接器。
下午四点，采购 OA 里有一份供应商合同等待审批。业务人员点了“AI 提取付款节点”，系统准备把附件发给大模型。合同里除了价款和交付日期，还有联系人手机号、开户行、银行账号、盖章页、技术附件和未公开折扣。
如果 OA 直接把原件交给豆包或火山方舟，模型也许几秒后就能给出结果；但组织很难回答另外几个问题：文件是否经过了授权检查？隐藏工作表和扫描页是否被识别？低置信度字段由谁确认？超时后系统会不会重复发送？请求日志里是否留下原文？模型输出会不会再次写出真实账号？
所谓 AI 脱敏中间层，不是在调用接口前增加一个“查手机号”的函数，而是在业务系统与外部模型之间建立一套可停、可审、可追踪的控制链。它决定哪些材料可以放行，哪些必须阻断，哪些只能降级成片段或结构化字段，以及谁对例外作最终判断。
本文讨论的是一套架构方法，不是在宣称某个现成产品已经拥有所有接口和集成。尤其要区分两件事：组织需要建设什么，以及当前工具已经验证能做什么。
脱敏卫士可以先把“模型调用前的文件准备”变成一个可验证控制点。 在自动化中间层尚未建成时，业务团队可在桌面端本机导入合同、案件材料或扫描文件，完成候选识别、人工补漏、图片框选与安全副本导出，再由现有审批流程决定是否提交模型。这种落地方式先证明字段规则、人工责任和放行标准，再决定哪些步骤值得系统化。
先把“中间层”放到正确的位置
一个常见主链路是：员工在 OA、合同系统、案件系统或医疗业务系统发起 AI 任务；控制层接收文件和任务目的，完成输入校验、敏感信息识别、策略判断和必要的人审；只有获准的脱敏副本才进入豆包或火山方舟；模型返回后，输出还要再检查一次，才能写回原业务系统。
这里至少有四份不同对象：受控原件、待审工作副本、发送给模型的脱敏副本、模型输出。它们不能共用一个文件名、一套权限和一个保存期限。真正的中间层先管理对象和状态，再谈识别模型。
豆包个人版与火山方舟不是同一个入口
豆包当前《隐私政策》说明，智能对话会收集用户发送的文字、图片和文件以提供服务；个人版还提供“帮助模型改进效果”设置。官方FAQ进一步说明，用户可以按数据类型退出模型效果优化，上传的图片、视频、文件及相应回复属于单独控制的数据类型。关闭优化用途不会让当次对话变成本地处理，也不会替组织完成上传授权、云盘管理和日志治理。
如果业务系统通过火山方舟调用豆包模型，适用的是火山引擎的模型服务、订单和具体功能规则。现行《豆包模型服务协议》对基础模型训练、另行授权和合规审查分别作出约定。组织不能把个人版设置页当作 API 数据处理说明，也不能只摘一句“默认不训练”就省略请求传输、鉴权、审查、客户侧日志和结果回写等环节。
因此，控制层的第一项元数据不是文件名，而是 目标入口：豆包个人版、豆包企业版、火山方舟，还是其他模型服务。入口不明确，请求就不应自动放行。
一套可落地的责任矩阵
中间层最容易失败的地方，是技术团队写了规则，业务团队以为系统会兜底，安全团队却只在上线前看过一次。下面的责任矩阵把架构要求与负责人绑定；其中队列、接口、IAM 和审计能力需要组织自建或采购，不代表任何桌面脱敏工具已经提供。
| 环节 | 主责角色 | 必须回答的问题 | 最低交付物 |
|---|---|---|---|
| 任务发起 | 业务部门、数据所有者 | 为什么需要模型？是否有权提交？最少需要哪些页或字段？ | 用途、文件范围、目标入口、审批依据 |
| 输入接收 | OA/业务系统团队 | 来源是否可信？格式、大小、页数、哈希是否符合要求？ | 请求编号、文件哈希、格式校验结果 |
| 识别与策略 | 数据安全、法务、业务规则负责人 | 哪些字段删除、代指、保留或直接阻断？ | 规则版本、命中清单、风险等级 |
| 人工复核 | 经授权的复核人员 | 误报、漏报、组合识别线索和扫描页是否处理？ | 复核结论、修改记录、复核人 |
| 模型调用 | AI 平台团队 | 调用哪个账号、工作区和模型？超时与重试怎样控制？ | 目标入口、幂等键、调用状态 |
| 输出再检查 | 业务与安全共同负责 | 输出是否复述敏感数据、越权推断或包含不应写回的内容？ | 输出检查结果、放行或退回原因 |
| 证据与运营 | 安全运营、审计、系统运维 | 留哪些证据，日志如何脱敏，保存多久，谁能查询？ | 状态轨迹、规则版本、摘要化证据、处置记录 |
责任矩阵还有一个隐含规则：业务负责人可以决定任务是否必要，却不应单独更改安全规则；复核人员可以修正识别结果，却不应绕过入口授权；运维人员可以排查故障，却不应在工单里复制真实病历或合同原文。
同步、异步和人工复核怎样选择
同步适合短文本和低风险任务
同步模式下，用户点击后等待控制层完成校验、识别、策略处理和模型调用。它适合字段有限、格式稳定、无需人工确认的低风险文本，例如已通过规则裁剪的公开制度片段。
同步不等于“失败就跳过脱敏”。系统应为每一阶段分配延迟预算：输入校验、识别、策略、模型调用、输出检查分别计时。任何安全关键阶段超时，默认结果应是阻断或转人工，而不是把原件直接发给模型。前台可以提示“任务已转人工处理”，不能用“AI 服务繁忙”掩盖安全状态。
异步适合扫描件、批量文件和高风险材料
扫描病历、整卷案件材料、批量简历和带附件的合同比较适合异步。发起后，系统立即返回任务编号，文件在受控区等待处理；识别结束后，根据风险进入自动放行、人工复核或阻断分支；完成时再通知业务人员或由业务系统查询状态。
异步模式的价值不只是提高吞吐，更重要的是允许停下来。它能把低清扫描、页数不一致、OCR 失败、压缩包嵌套、密码保护、规则冲突和高敏字段集中送入异常队列，而不是让失败文件与正常文件混在一起继续前进。
人工复核是一道策略门，不是补救工位
需要人审的条件应提前配置，例如：出现身份证号、病历号、银行卡号或未成年人信息；命中商业秘密词表；识别置信度低于组织阈值；文件包含手写批注、盖章、表格或扫描图片；同一材料多次修改规则；模型输出准备写回核心业务字段。
复核页面至少应同时展示原文位置、候选类型、处理后值、命中来源和上下文。复核人员应能取消误报、补充漏项、调整处理方式，但每次修改都要记录到任务轨迹。否则“有人看过”只是口头承诺，无法解释最终版本为何放行。
放行、阻断与降级要在上线前定义
一个成熟控制层不只有成功和失败两个答案。
- 放行：输入校验通过，敏感字段已按规则处理，必要人审完成，脱敏副本通过反向验证，可以进入指定模型入口。
- 阻断：文件包含禁止外发内容、无法确认授权、格式不可解析、敏感字段无法可靠处理、哈希或页数异常，或目标入口不在批准范围。
- 降级：不发送完整文件，改为发送经批准的页面、字段表、纯文本片段、合成样例，或只返回“需人工处理”的任务建议。
- 转异常队列：结果仍有不确定性，但具备人工判断条件，例如低清扫描、专有项目名、新合同模板或规则冲突。
降级不是绕过阻断。例如 OCR 失败后直接提取可见文字并发送，可能漏掉图片中的身份证；正确的降级可能是只让用户手工填写不含身份信息的三个付款节点，或要求上传经确认的文字版副本。
请求状态模型：任何时刻都能说清文件在哪里
仅在数据库里写“处理中”不够。建议为每次请求保存明确状态，并限制允许的状态跳转。
| 状态 | 含义 | 允许的下一步 |
|---|---|---|
RECEIVED 已接收 |
已生成任务编号，原件尚未处理 | 输入校验 |
VALIDATED 已校验 |
格式、大小、页数、哈希和来源通过 | 识别与策略 |
ANALYZED 已分析 |
识别、规则和工作副本生成完成 | 自动批准、待复核、阻断或降级 |
EXCEPTION_QUEUED 异常排队 |
解析失败、规则冲突或材料异常 | 人工修复、阻断或重新发起 |
REVIEW_REQUIRED 待复核 |
命中高风险或存在不确定项 | 人工批准、阻断、降级 |
APPROVED 已批准 |
脱敏副本和目标入口均获准 | 模型调用 |
BLOCKED 已阻断 |
不满足授权或安全条件 | 结束或重新发起 |
DEGRADED 已降级 |
文件范围或任务能力被缩小 | 重新校验后调用 |
SENT 已发送 |
脱敏副本已交给指定模型 | 等待输出 |
OUTPUT_REVIEW 输出待检 |
模型结果正在做敏感信息与业务检查 | 完成、退回或阻断 |
COMPLETED 已完成 |
获准结果已写回业务系统 | 按期限保留证据 |
RETRY_WAIT 待重试 |
可重试故障，尚未再次发送 | 受控重试或失败 |
FAILED 已失败 |
超过重试上限或出现不可恢复错误 | 人工处置或重新发起 |
状态模型应禁止几种危险跳转：RECEIVED 不能直接到 SENT；REVIEW_REQUIRED 不能因等待超时自动变成 APPROVED；FAILED 不能沿用旧文件重新发送；模型已经收到请求后，前台超时也不能简单把任务恢复为“未发送”。
重试、幂等和重复提交是同一个安全问题
网络超时并不能证明下游没有收到文件。若系统在 30 秒后盲目重试，同一份合同可能被发送两次，生成两份输出和两套日志。设计时至少需要三种标识：业务请求编号、文件内容哈希、模型调用幂等键。
同一业务请求、同一文件哈希、同一规则版本和同一目标入口，应优先返回既有任务状态，而不是重新创建。若文件内容、规则版本、处理方式或目标模型有任一变化，则应形成新版本，并明确关联旧任务。重试只能发生在被列为“可重试”的错误上，例如临时网络失败或限流；授权失败、格式损坏、规则冲突和人工阻断不得自动重试。
还要处理“响应丢失”这一分支：模型已经成功处理，但控制层没有收到响应。系统应先查询下游任务状态或按幂等键取回结果；无法确认时转人工，不要同时向多个模型补发真实业务材料。
输入和输出都要验证
输入验证不只看扩展名
输入侧至少检查实际文件类型与扩展名是否一致、是否加密或损坏、页数和大小是否异常、是否包含宏、嵌入附件、外部链接、隐藏工作表、批注、修订和 OCR 文本层。压缩包、可执行内容和不支持的格式应在受控区停止，不能先上传模型再看是否能打开。
脱敏完成后，还要对最终副本做反向验证：搜索原姓名和账号，尝试复制与文本提取，检查图片区域、表格、页眉页脚、附件和元数据；确认文件哈希、页数及版式符合预期。中间层返回的不能只是“识别成功”，而应是“哪个版本通过了哪些检查”。
模型输出可能把敏感关系重新写出来
模型输出不一定只复述脱敏副本。它可能根据上下文推断真实主体，重新组合被分散的信息，或者把提示词、附件名称和业务标识带入摘要。输出还可能包含错误判断、越权建议或不适合自动写回 HIS、案件系统和财务字段的内容。
因此，输出侧需要第二套策略：再次扫描敏感字段；检查模型是否泄露系统提示或内部标识；验证结构化输出是否符合字段模式、长度、枚举和数值范围；高影响结果必须由业务人员确认。输出检查失败时，应保留原始返回的受控副本供调查，但不得直接展示给无权用户。
日志脱敏与证据留存不能互相抵消
系统为了排障和审计需要证据，但“为了审计保存全部原文”会制造新的高风险数据仓。建议业务日志只记录任务编号、文件哈希、文件类型、页数、规则版本、命中类型及数量、状态变化、操作角色、目标入口、耗时、错误码和输出校验结果。
提示词、原始文件名、真实姓名、手机号、账号、病历内容和模型完整输出默认不进入普通应用日志。必须调试内容时，应进入单独受控流程，限定人员、目的和期限，并记录调阅行为。错误栈也要检查，避免解析器把整段原文写进异常消息。
证据留存则应遵循“足以证明，不多保存”的原则。可保留规则版本、处理前后哈希、脱敏命中摘要、人工修改记录、放行依据、模型入口、幂等键和状态时间线。是否保存原件、工作副本和模型原始输出，应由数据所有者、法务和安全负责人按场景确定，不应由开发人员写死为永久保存。
《个人信息保护法》要求处理个人信息具有明确、合理目的，采取对个人权益影响最小的方式，并将收集范围限制在实现目的的最小范围。《生成式人工智能服务管理暂行办法》也明确了提供者对用户输入信息和使用记录的保护义务。平台承担保护义务，不代表调用方可以省略自己的最小必要、授权和内部治理。
四类国内场景怎样落到这套架构
HIS/EMR：先拆任务，再决定是否允许出域
医院希望用模型生成出院宣教摘要时，原始病历可能包含姓名、身份证号、住址、联系电话、病案号、诊断、用药和检查结果。控制层首先要判断所用模型、部署位置和院内制度是否允许该数据流；不允许出域的材料应直接阻断，不能因为做了部分遮盖就绕过制度。
允许试点时，可先把任务缩小到经批准的病种模板或去标识片段。扫描页、手写记录和罕见诊断进入人工队列；模型输出不得自动写回诊断、处方或医嘱字段，只能作为待医务人员确认的草稿。这里的 HIS/EMR 连接器、身份权限和审计平台均由医院现有系统或项目自建能力承担。
律所案件系统：主体代指要跨材料一致
律师让模型汇总合同、补充协议和往来函时，同一客户、对方公司和经办人需要保持一致代指，否则模型会把一个主体理解成多个对象。案件号、律师姓名、账户、报价和谈判底线也应按事项规则处理。
异步任务可以先生成整批材料的脱敏工作副本，交由承办团队复核，再释放到批准的火山方舟工作区。模型输出带回案件系统前，再检查是否复述真实主体或产生新的事实判断。映射和还原权限应留在受控环境，不能与脱敏副本一起发送。
电子案卷（电子卷宗）：保密等级先于自动化效率
电子案卷（电子卷宗）可能混合身份证明、证据材料、未公开案情、未成年人信息和不允许外传的内容。系统应先按密级、案件阶段和材料类型做前置分流；涉密或制度禁止进入外部模型的文件直接阻断。可以处理的公开或内部材料，也应按页面、附件和图像区域逐项验证。
如果组织使用自建或专用模型，仍然需要输入输出控制、权限、日志和证据链。部署在“内网”不是自动放行理由，控制层要回答具体模型、具体人员和具体任务是否有权访问。
国内协作平台：分享范围和 AI 入口必须同时管
员工可能从 WPS、飞书、钉钉、企业微信或 OA 下载附件，再粘贴到豆包个人版；也可能从协作平台发起企业模型任务。对前一种情况，技术中间层往往接不到请求，因此组织还需要账号策略、终端管控、培训和审批。对后一种情况，才能在正式集成点实施统一状态和策略。
豆包《云盘使用须知》说明，对话内上传文件会自动存在云盘，且在对话中删除文件不影响云盘原文件。这说明“模型调用完成”与“后续文件管理完成”是两件事。流程设计应把目标账号、对话记录、云盘、分享链接和写回位置一并纳入收尾清单。
脱敏卫士桌面预处理工作台在架构中的位置
脱敏卫士（RedactOS）当前适合承担的是 模型调用前的桌面文件预处理和人工复核工作台。桌面端可在本机导入 DOCX、TXT、文字型 PDF、扫描型 PDF 和图片，组合规则与 AI/NER 识别候选信息；复核人员可以取消误报、补充漏项、框选图片区域，并按任务选择涂黑、星号或混淆代指后导出副本。
对于合同、案件材料和财务文件，同批材料还可以使用一致代指；已完成任务形成任务记录，必要时在受控环境中执行任务内还原。自动识别仍需人工复核，映射表、任务记录和还原关联信息本身也需要按敏感数据保护。
在半自动流程中，业务系统可以先把待处理文件送入受控工作区，由授权人员使用脱敏卫士生成并复核副本，再将批准版本上传豆包或提交给火山方舟。此时脱敏卫士完成的是本机预处理节点，不是服务器端中间件。
当前可验证资料不支持把脱敏卫士写成通用中间件 API、SDK、消息队列连接器、OA/HIS/EMR 原生集成、集中 IAM 或审计平台、高可用集群。前文的队列、状态机、幂等、回调、日志平台和故障恢复均是组织建设中间层时需要自建或采购的架构能力。即使通过 Skill 或 CLI 在支持的本地 Agent 中调用脱敏步骤，也不能推断整个模型链路都在本地，更不能省略兼容性、权限和数据流核验。
最小可行 POC：先证明控制链，不追求全系统接入
POC 的目标不是一个月接通所有 OA、HIS 和案件系统，而是证明一类文件、一条模型链路和一组异常能够被可靠控制。
- 限定范围：选择一个部门、一种文件模板、一个明确任务和一个批准的模型入口，例如采购合同付款节点提取；准备合成或已授权样本，不直接拿全量生产材料试跑。
- 建立基线：收集正常、扫描、表格、批注、隐藏内容、低清、加密、损坏和重复提交样本；人工标注必须处理的字段和预期放行结果。
- 跑通状态：实现请求编号、哈希、规则版本、待复核、阻断、降级、发送、输出复检和完成状态；至少演练一次超时、重复提交和响应丢失。
- 设置人审：明确谁能复核、谁能放行、超时如何升级；记录误报、漏报、平均等待、人工修改和失败原因，不用单一“准确率”概括效果。
- 验证交付：对脱敏副本执行搜索、复制、提取和版式检查；对模型输出执行敏感字段与结构校验；核对日志中没有原始敏感内容。
- 作出结论：只有当安全、业务、法务、运维共同认可剩余风险、人员负荷和退出方案，才扩大文件类型或接入第二个系统。
POC 故障表
| 故障 | 不安全的默认动作 | 建议处置 | 恢复条件 |
|---|---|---|---|
| OCR 或解析失败 | 跳过失败页继续发送 | 阻断并进入异常队列 | 人工确认全部页面或取得可解析源件 |
| 识别服务超时 | 原件直通模型 | 转人工或结束任务 | 安全处理完成且副本重新验证 |
| 低置信度高敏字段 | 当作未命中 | 强制人审 | 复核人确认处理方式 |
| 模型接口限流 | 无限重试 | 指数退避、限制次数、保留幂等键 | 可确认未重复处理或取回既有结果 |
| 响应丢失 | 换模型再次发送 | 查询下游状态，无法确认则转人工 | 找到原结果或批准重新发起 |
| 日志含原文 | 继续上线后再清理 | 停止试点、清理暴露面、修改日志策略 | 复测错误路径无敏感原文 |
| 输出复述敏感字段 | 直接写回业务系统 | 阻断输出并调查输入与规则 | 输出复检通过且业务确认 |
| 规则版本更新 | 覆盖旧任务记录 | 新建版本并保留关联 | 新旧结果差异完成复核 |
上线验收清单
- [ ] 每个请求都记录业务目的、数据所有者、目标入口和批准依据。
- [ ] 原件、工作副本、脱敏副本和模型输出使用不同标识、权限和期限。
- [ ] 同步超时不会导致原件直通；异步任务有可查询的明确状态。
- [ ] 高风险、低置信度、解析失败和规则冲突会进入人工或异常队列。
- [ ] 放行、阻断、降级的条件和最终责任人已经书面确定。
- [ ] 文件哈希、规则版本和幂等键能防止重复提交与盲目重试。
- [ ] 最终副本经过搜索、复制、文本提取、图片与隐藏内容检查。
- [ ] 模型输出经过敏感信息、结构和高影响业务结果检查。
- [ ] 普通日志不含原文件名、提示词、真实字段和模型完整输出。
- [ ] 证据留存足以重建状态与责任，但没有默认永久保存全部原文。
- [ ] 故障演练覆盖解析失败、超时、限流、响应丢失和输出阻断。
- [ ] 文档明确区分现有工具能力与自建、第三方或待验证能力。
常见问题
1. 有了模型平台的安全承诺，还需要脱敏中间层吗？
需要分别判断。平台负责其收到数据后的处理与保护，调用方仍要控制是否有权发送、发送多少、失败如何处置、日志是否泄露以及输出怎样写回。中间层解决的是组织自己的入口和流程责任，不能由平台条款替代。
2. 关闭豆包“帮助模型改进效果”，是否可以直接上传原件？
不能据此得出这个结论。关闭设置限制的是对应内容用于模型效果优化，不改变完成当前请求所需的发送和处理，也不自动解决对话历史、AI 云盘、上传授权和组织制度问题。高敏文件仍应先判断必要性并生成最小化副本。
3. 所有请求都必须人工复核吗？
不一定。格式稳定、字段有限、风险较低且经过充分验证的任务可以自动放行；高敏字段、扫描件、低置信度、规则冲突和高影响输出应进入人审。是否人审由风险策略决定，不能只以延迟为标准。
4. 中间层失败时，应该默认阻断还是降级？
安全关键步骤失败时不应让原件直通。能否降级取决于是否存在经过验证的最小任务，例如只提交批准字段或合成样例；没有安全降级路径就阻断。降级方案应在上线前定义，不能临时由代码猜测。
5. 脱敏卫士能否直接接入 OA、HIS 或火山方舟 API？
当前已验证定位是桌面预处理与人工复核工作台，不应宣传为已提供通用 API、SDK、队列连接器或原生集成。组织可以把它放在半自动受控节点，由人员处理并放行副本；服务器端接入能力必须依据真实接口和部署文档另行建设与验证。
6. 只检查模型输入，为什么还不够？
模型输出可能复述、重组或推断敏感关系，也可能产生错误内容并被自动写回核心系统。输出侧至少要重新扫描敏感字段、验证结构和业务约束；医疗、法律、财务等高影响结果还需要专业人员确认。
最后：真正的中间层是一套可拒绝的流程
AI 脱敏中间层的价值，不是让每份文件更快进入模型，而是让系统有能力在不确定时停下来。它需要清楚的入口、责任、状态、异常、证据和退出路径；任何一个环节无法说明，所谓“自动脱敏”都可能只是在隐藏失败。
对大多数组织，更稳妥的起点不是购买一个“万能中间件”标签，而是选定一类文件和一个模型任务，用本地预处理、人工复核和受控提交先跑通闭环。等规则、状态、故障和责任经过验证，再决定哪些步骤值得自动化。
说明：本文由脱敏卫士团队发布，文中的 OA、医院、律所与电子案卷流程均为架构示例，不代表脱敏卫士已与相关系统或平台形成原生集成。平台政策核查至 2026 年 8 月 3 日；正式实施时应再次核对实际账号、组织合同、管理员设置和功能即时提示。本文为一般技术与治理信息，不构成具体法律意见。
下一步： 可以先查看脱敏卫士产品能力，用一类高频文件建立“导入—识别—人工复核—导出—批准提交”的最小闭环；在线验证时仅使用虚构或已获授权的非敏感样本进入在线体验。