AI 管道为什么需要脱敏层？豆包、企业知识库与火山方舟 API 的三套控制方法

同一份合同，看上去可以用三种近似的方式交给 AI：员工在豆包网页端手动上传，请它提炼违约条款；知识运营人员把一批已批准材料导入企业知识库，供同事反复问答；技术团队在业务系统里调用火山方舟 API，让合同随请求自动流转。

动作都是“把文件交给模型”，责任却完全不同。第一种由具体员工触发，容易绕过组织流程；第二种会经过解析、切片、向量化和长期检索，错误可能被整库放大；第三种由程序持续调用，还多出鉴权、重试、缓存、应用日志与异常队列。把三者都概括成“接入大模型”，会漏掉真正需要治理的数据落点。

本文所说的 AI 脱敏层，不是保证万无一失的过滤器，也不是要求所有 AI 流程照搬同一套系统。它是一组放在原件与模型可见输入之间、并延伸到模型输出之后的控制：先确认用途，再产生最小必要副本，经识别、策略判断和人工复核后才提交；同时记录证据，检查输出，并为删除、停用和回滚预留路径。

脱敏卫士在这条链路中的直接价值，是让真实文件在进入豆包、知识库或 API 请求前先留在本机完成预处理。 团队可以导入文字型或扫描型 PDF、DOCX、TXT 与图片，组合规则和语义识别发现候选字段，人工修正误报与漏报，再输出涂黑、星号或稳定代指副本。模型只接触完成当前任务所需的内容，而不是默认接触整份原件。

先定义清楚：脱敏层改变的是“模型能看见什么”

加密解决的是数据在传输或存储时如何防止未授权读取；脱敏解决的是下游是否还需要接触原值。两者可以同时存在，但不能相互替代。一个已加密传输的完整合同，到达模型服务后仍然是完整合同；一个经过恰当代指的副本，即使进入下游，模型也不必看到真实姓名、证件号和账户号。

因此，脱敏层至少要回答七个问题：原件来自哪里；本次任务真正需要哪些信息；预处理在哪里发生；谁批准副本进入平台；输入和输出会在哪里留存；谁能删除；策略变化或识别失败时怎样停止并恢复到上一版本。

一条可操作的主线是：

1. 用途登记：写清任务、材料来源、允许用途、禁止用途和责任人；
2. 输入解析：检查正文、表格、页眉页脚、批注、图片、OCR 文字层和文件元数据；
3. 候选识别：组合固定格式规则、语义实体识别、自定义词表与黑白名单；
4. 策略执行：按字段选择删除、涂黑、泛化或稳定代指，而不是一律抹掉；
5. 人工复核：处理漏检、误检、跨页关系和图片区域，决定允许、降级或阻断；
6. 平台提交：只发送已验收的最小必要副本，不连带发送映射表；
7. 输出检查：再次检测模型回复、引用片段、下载文件与错误信息；
8. 证据与处置：保留版本、规则、审批和测试证据，并按各系统责任删除或回滚。

三类流程必须拆开画，不能共用一张“数据流示意图”

下面的矩阵不是产品功能表，而是组织应在方案评审时补齐的责任地图。“平台记录”指平台按照其协议、配置和实际功能产生的记录；“组织记录”指企业自己的工单、网关、应用和运维系统。两者不能互相代替。

数据节点	员工手动上传合同到豆包	组织把批准文件导入企业知识库	技术团队调用火山方舟 API
原始输入	员工本机或部门盘中的单份合同，可能含签章、批注和附件	经内容负责人批准的一批制度、合同模板、案例或业务文档	业务系统实时取得的合同正文、字段或文件解析结果
预处理位置	上传前在受控终端生成副本；不在聊天框里边看边删	入库暂存区；在解析、切片和建立索引之前处理	客户应用侧或独立预处理服务；在构造 API 请求之前处理
最小必要副本	只保留完成本次摘要或条款分析所需内容	只保留知识问答所需段落、结构和可追踪文档编号	只传任务所需字段或片段，并限制提示词携带的上下文
平台提交	由员工手动选择并上传已验收副本	由知识库管理员发布已批准版本，随后解析、切片、索引	由应用使用受控凭证调用指定模型接入点
模型输出	回答、摘要、可能保存的对话或下载文件	答案、引用片段、检索结果、反馈记录	API 响应、流式片段、错误内容及下游业务结果
日志与存储	豆包账号侧的输入、回复、历史对话；组织若需证明，还要另建上传工单	源文件库、暂存副本、知识库、索引、权限记录、问答和反馈，各有独立生命周期	应用日志、请求链路、缓存、重试队列、供应商侧必要处理或审查记录；是否记录正文必须逐项确认
删除与留存责任	员工按平台入口删除历史，部门确认本地原件与副本；组织无法只靠口头要求证明已删除	文档所有者发起撤回，知识库管理员删除文档并触发重新索引，IT 验证缓存、备份和引用是否按制度处理	应用所有者删除客户侧正文和缓存，云管理员按合同及控制台能力处理云侧资源，安全人员验证删除证据
最容易失控处	员工把原件误当附件直接上传，或用个人账号绕过批准	映射表随副本一起入库；文档已删但切片、索引或答案缓存仍在	请求体、错误栈或调试日志保存原值；失败重试把敏感内容复制到多处

这张表的关键不是“哪种更安全”，而是每条链路都存在不同的不可见副本。网页端一次上传没有企业知识库的索引治理；企业知识库的管理员能力也不能自动约束员工个人账号；API 的服务协议更不能证明客户自己的应用日志没有留原文。

流程一：员工手动把合同上传到豆包

个人使用场景最大的变量是人。员工可能只想快速确认续约期，却顺手上传带有法定代表人身份证号、收款账户、联系人手机号和手写签名的整份合同。这里最有效的控制点在点击“上传”之前。

先把任务改写成字段需求。例如，“提炼自动续约、解约通知期和违约责任”通常需要条款正文、日期关系、金额关系和角色关系，但未必需要真实姓名、电话、证件号、银行账号或签名图。人物可以稳定替换为“甲方联系人1”“乙方联系人1”，企业名称若影响责任主体判断，可按批准范围保留，也可稳定替换为“甲方公司”“乙方公司”。金额若决定风险，不要机械删除；可以保留金额区间、比例关系，或由业务负责人确认是否允许保留原值。

上传前还要检查文件层。扫描合同不仅有 OCR 文本，还可能有印章、签字和二维码；文本型 PDF 可能带批注和隐藏文字层。只看页面上几条黑线，不等于下游读不到原值。副本应另存并使用显眼的安全命名，避免员工在文件选择器里点回原件。

截至 2026 年 8 月 3 日核查，豆包《隐私政策》更新于 2026 年 7 月 15 日、生效于 7 月 22 日。政策说明，智能对话会收集用户发送的文字、图片和文件以提供服务；输入信息及回复等在用户未撤回、删除或注销账号期间可能保留，历史对话可在产品入口删除。豆包个人版《帮助模型改进效果 FAQ》还说明，文本对话、上传的图片、视频、文件及相应回复属于相关开关覆盖的数据范围，登录用户可以关闭对应的模型效果优化开关。

这意味着员工在操作前至少要核验账号类型、组织规定、当前开关和删除入口。但关闭模型效果优化不是“允许上传原件”的通行证；删除一次聊天也不等于组织本地副本、浏览器下载和内部工单同步删除。组织若不允许个人账号处理某类材料，正确动作是阻断，而不是要求员工“传完马上删”。

这一流程的责任人可以很简单：员工负责用途与上传动作，业务复核人批准副本，信息安全负责人定义禁传类别。证据也不必复杂：工单号、原件哈希或内部文件编号、脱敏副本版本、规则版本、复核人、提交时间、平台账号类型和删除确认即可。证据里尽量不保存原文。

流程二：组织把批准文件导入企业知识库

企业知识库不是一次问答，而是一条持续的数据生产线。文件入库后，常见系统会解析文档、切片、建立索引，再根据员工问题检索片段并生成回答。即使原始文档只上传一次，敏感片段也可能出现在多个切片、索引字段、引用预览、答案缓存和反馈样本中。因此，控制点必须前移到“批准入库”之前。

这里适合建立两级材料：受控原件只供授权人员查看；知识副本供检索系统使用。知识副本应删除与组织问答无关的个人标识和商业秘密，同时保留文档标题、版本、适用范围、发布日期、失效日期与可追踪来源。人物或机构在多份文件中需要保持关系时，应使用稳定代指：同一个人始终是“项目负责人1”，不能在每个切片里随机变成不同编号，否则检索和答案会误判关系。

稳定代指带来新的高敏资产——映射关系。映射表不能随知识副本进入知识库，也不应出现在提示词、切片元数据和普通运维日志中。它应与知识副本分开保存，设置独立访问权限、保留期和还原审批。即使系统不需要还原，也要决定是否根本不生成映射；“以后可能用到”不是无限期保存的理由。

如果采用豆包企业版，还要读企业版自己的条款，不能套用个人版结论。上述 2026 年 7 月 15 日版《隐私政策》说明：基于组织身份账号产生的输入、上传及使用记录等组织使用数据归所属组织并受组织控制，豆包按组织指示及协议处理；组织负责必要告知与授权。政策同时注明，使用飞书基础版账号登录企业版时，上传及产生的数据将用于提升豆包企业版使用体验。采购和安全评审因此要确认实际账号版本、合同、管理后台和数据用途，不要把“企业版”三个字直接等同于某个统一的数据策略。

知识库的删除也不是在源文件列表点击一次就结束。文档所有者应提出撤回原因；知识库管理员删除对应版本并触发重新解析或重新索引；应用负责人检查引用缓存、答案缓存和离线评测集；IT 或供应商负责人按协议核验备份与日志边界。若无法验证某个派生位置已清理，记录为残余风险并限制继续检索，而不是把状态标为“已删除”。

发布前可用一组“不能回答的问题”测试边界：询问真实手机号、证件号、个人住址、完整银行账号、未批准项目代号，以及把两个公开片段组合后是否能推出具体个人。知识库不仅要在入库时查漏检，还要对检索片段和最终答案再查一次，因为非敏感片段的组合也可能重新识别出对象。

流程三：技术团队调用火山方舟 API

API 流程的风险常常不在那次 HTTPS 请求，而在请求前后的工程系统。应用可能把完整合同写入调试日志，网关可能记录请求体，失败队列可能重复保存，监控平台可能抓取异常样本，客服排障又可能把日志转存到工单。模型前置脱敏只能减少请求正文暴露，不能替代凭证、日志、缓存和权限治理。

技术团队应先定义请求合同：允许哪些字段进入提示词，哪些字段只能以代指出现，哪些文件类型必须走 OCR 质量检查，哪些业务目的不得调用。然后在客户侧完成解析与脱敏，输出结构化的最小请求。策略服务根据风险返回四类结果：允许；进入人工复核；降级为不含原文的模板化任务；阻断。只有“允许”的副本才进入 API 客户端。

截至 2026 年 8 月 3 日核查，火山方舟《豆包模型服务协议》第三条写明，服务不使用客户提交内容或服务输出训练、重新训练或改进基础模型，但客户主动同意数据授权协议或参与相关协作奖励计划属于例外；协议也说明，为履行法定合规要求，平台可对提交内容和输出进行技术或人工审查。火山方舟官方 API 文档列出了对话接口和 API Key 鉴权等入口。上述事实只说明服务侧条款与接口，不代表客户应用已经自动具备脱敏、队列控制或完整审计。

因此，客户侧日志策略应明确到字段：业务请求号可留，原合同正文默认不留；脱敏规则版本、命中类型、人工决策和响应状态可留；映射表、API Key、真实姓名与证件号不得进入普通日志。必要排障如需短期样本，应走单独审批、限时保存和访问审计。重试必须复用已验收副本，不能重新从原件组装请求。

输出也要进入同一套判断。模型可能照抄输入中的代指，也可能从上下文推断出未直接提交的身份，还可能生成看似真实的号码。输出检测发现禁传字段或高风险模式时，不应直接展示给最终用户：可以遮盖后返回、转人工复核，或只返回“需人工处理”的降级结果。若新策略造成大量误拦或业务异常，应能切回上一版本；若旧策略存在漏检，应暂停相关类别而不是带病回滚。

脱敏失败不止是漏掉一个手机号

模型前加了一层处理，不代表风险归零。验收时至少要把下列八类失败放进同一张挑战矩阵。

挑战	可能表现	设计与验证办法
模型记忆或复现风险	输入、精调数据或其他处理内容可能在特定条件下被复现；不能据此断言某次提交必然被记忆	先减少提交内容，核查实际服务条款及例外；用专门测试集验证输出，不以“平台不会训练”替代输入控制
重新识别	姓名已去掉，但公司、职位、日期、地区和罕见事件组合后仍指向一人	设计组合攻击问题；对准标识符做泛化；限制跨库联查和返回片段数量
漏检	新格式证件号、表格字段、签章图片或上下文人名没有命中	固定规则与语义识别组合；业务抽检；漏检样本进入回归集；高风险类型漏检时阻断
误检	合同金额、条款编号或必要机构名被删，导致任务无法完成	业务人员复核；白名单和用途化规则；比较脱敏前后任务可用性，但不把原件发送给模型做比较
偏差与覆盖缺口	少数民族姓名、外文姓名、简称、方言地址或特定行业编号覆盖不足	按语言、地区、文档来源和实体类型分层抽样；单独记录弱覆盖组，不只看总体结果
时延	OCR、识别和人工复核拉长接口响应，员工因此绕开流程	区分同步与异步任务；低风险结构化字段走快速路径；超时降级或转人工，不跳过检查
策略或模型漂移	规则、OCR、识别模型、知识库解析器或外部模型更新后表现变化	固定版本与基准集；变更前后对比；小流量发布；保留上一稳定策略和停用开关
OCR 质量	歪斜、模糊、双层文字、手写签名或复杂表格导致识别错位	记录页级质量；低质量页转人工；检查图像层与文字层；不引用未经本项目实测的通用下降比例

决策不是“脱敏成功/失败”二选一

把每个文件强行分成通过或拒绝，往往会逼出绕行。更可用的办法是提前定义四种处置，并把谁能改变决定写清楚。

决策	适用条件示例	后续动作	最终责任人
允许	必要字段清楚，禁传字段已处理，输入与输出检查均通过	提交最小副本，记录策略和版本	业务数据负责人
人工复核	扫描质量低、实体关系复杂、存在少量不确定命中	暂停提交，由授权复核人处理漏检和误检	业务复核人
降级	AI 任务可在不带正文时完成，或只需统计、模板、公开信息	仅传摘要字段、分类标签或预设模板	应用负责人
阻断	原件属于禁传类别、授权不清、映射表混入、发现高风险漏检	不调用平台，回到原系统或人工流程	信息安全/数据负责人

不要让识别置信度单独决定结果。同一个“低置信度姓名”，出现在公开通讯录和未公开并购协议中，后果不同；同一个手机号，在员工手动上传和批量 API 中，暴露规模也不同。策略应结合数据等级、用途、主体、渠道和可恢复性。

输入、输出和证据要形成闭环

输入检查回答“模型前还剩什么”。除了实体命中数量，还要核验：原件与副本是否分开；副本是否只含必要页；代指是否跨文档稳定；图片区域是否处理；映射是否隔离；抽取文本与视觉页面是否一致；禁传词测试是否能够真正阻断。

输出检查回答“模型又带回了什么”。检测范围包括回答正文、引用片段、附件、文件名、错误信息和可观测性平台采样。对于法律、财务、人事等高风险用途，还应由业务人员检查事实准确性和上下文完整性。脱敏只减少敏感信息，并不保证模型结论正确。

证据则回答“当时为什么放行”。建议至少记录任务 ID、材料内部编号、用途、数据等级、输入副本哈希、规则与识别版本、命中类别和数量、人工修改、决策、提交渠道、输出检查结果、删除到期日和异常编号。证据字段尽量结构化、无原文；如确需保留样本，单独受控。

监控不要只看接口成功率。应按场景观察禁传拦截、人工退回原因、漏检回报、误检修正、OCR 低质量页、处理耗时、绕行事件和删除逾期。任何指标的警戒线都要来自本组织基线、风险承受度和人工能力，不能从别人的案例抄一个“行业标准”。

用小规模 POC 决定阈值，而不是先写一个漂亮数字

POC 的目标不是证明某个模型“准确率很高”，而是确认这条具体链路在可接受的风险和成本下能否运行。可以按以下顺序执行：

1. 圈定一个任务：例如只做采购合同条款摘要，不同时覆盖简历、客服与财务报表；
2. 建立代表性样本：包含文本 PDF、扫描件、表格、批注、签章、不同语言姓名和组织自有编号，并加入设计好的困难样本；
3. 人工建立基准：由两类角色标注必须删除、允许保留、必须稳定代指和禁止进入模型的内容，分歧由数据负责人裁决；
4. 分别跑三道检查：解析/OCR、脱敏结果、模型输出，不能只验最终回答；
5. 记录业务代价：统计漏检类型、误检修正、人工时间、端到端时延、降级率、阻断率和任务可用性；
6. 演练异常：测试上传原件、映射混入、服务超时、重复请求、策略升级、知识库撤稿和员工离职后的删除；
7. 设定本地门槛：由业务、数据、安全和运维共同决定哪些实体不得漏、哪些文档必须人工复核、可接受的时延与误拦范围；
8. 小范围上线：固定版本、限制用户和材料类型，保留停用开关；达到预设观察期后再扩展。

验收报告应按文档类型、实体类型、语言与质量分层，不用单一平均数掩盖短板。上线条件至少包括：高风险漏检处置符合组织门槛；模型输出未越过既定禁传规则；稳定代指不破坏关键关系；映射访问与删除可验证；超时、服务不可用和策略异常时能降级或阻断；上一稳定版本可以恢复。具体阈值由本次 POC 形成，本文不提供可跨组织照搬的百分比。

脱敏卫士能在 AI 管道中承担哪一个动作？

脱敏卫士（RedactOS）的主要角色，是在文件进入上述 AI 工作流之前，作为桌面端预处理与人工复核工具。桌面端可在本机导入 DOCX、TXT、文字型 PDF、扫描型 PDF 和常见图片，组合固定格式规则、语义实体识别、自定义规则与黑白名单，复核者可以取消误报、补标漏项并框选图片区域，再导出涂黑、星号或稳定代指副本。多份关联材料可使用批量处理与跨文档一致代指。

对需要 AI 理解人物和机构关系的材料，稳定代指通常比把所有字段涂成黑块更有用；但代指与原值之间的映射属于敏感资产。桌面端的任务记录、还原关联信息和导出的映射表都应受控，映射表不得随副本提交给豆包、企业知识库或火山方舟。

边界同样重要：脱敏卫士目前不应被描述为已经集成豆包、火山方舟、企业知识库或任意 AI 管道，也不是实时 API、消息队列、企业策略网关或集中审计平台。本文中的 API 网关、自动阻断、集中证据、监控和回滚属于组织架构建议，需要技术团队另行建设或核验。使用桌面端本地处理，也只说明预处理阶段的数据边界，不能推导后续模型服务仍在本地。

上线前检查清单

• [ ] 已写明任务用途、材料来源、允许渠道和禁传类别；
• [ ] 已区分豆包个人版、豆包企业版/企业知识库与火山方舟 API 的协议和控制；
• [ ] 原件、暂存副本、知识副本、请求体、输出和映射表有独立生命周期；
• [ ] 预处理发生在上传、入库解析或 API 请求构造之前；
• [ ] 正文、表格、批注、页眉页脚、图片、OCR 层和元数据均纳入检查；
• [ ] 稳定代指满足任务需要，映射表不进入模型或普通日志；
• [ ] 已定义允许、人工复核、降级、阻断及各自责任人；
• [ ] 输入和输出均检查，模型答案不会未经复核直接进入高风险决策；
• [ ] 组织日志不记录原件、映射、密钥等非必要内容；
• [ ] 删除覆盖源文件、切片、索引、缓存、历史、日志和导出副本的责任已分配；
• [ ] POC 使用代表性困难样本，阈值来自本组织验收；
• [ ] 规则、OCR、识别模型或平台变化时可监测、暂停并回滚。

常见问题

1. 关闭豆包“帮助模型改进效果”后，可以上传未脱敏合同吗？

不能据此得出这个结论。该开关针对个人版相关内容数据是否用于模型效果优化；平台仍需处理你主动发送的文件以提供服务，账号历史、组织制度、他人授权和材料保密要求也要分别判断。若材料不允许进入个人账号，应该阻断上传。

2. 火山方舟协议写明不使用输入输出训练基础模型，还需要脱敏吗？

仍要按用途判断。协议存在主动授权等例外，也允许为法定合规进行内容审查；更重要的是，客户应用、日志、缓存、重试队列和下游系统仍由技术团队控制。脱敏用于减少不必要的原值进入整条链路，不是对平台条款的不信任投票。

3. 企业知识库里删除原文，为什么还要检查索引和缓存？

因为入库后可能产生切片、索引字段、引用预览、答案缓存和评测样本。源文件删除只是一个动作，组织要根据实际系统确认派生数据如何失效、重建或删除，并留下可验证结果。

4. 混淆代指一定比涂黑好吗？

不一定。AI 若需要理解跨段、跨文件的人物和机构关系，稳定代指更有可用性；对公开展示或无需关系分析的材料，涂黑或删除可能更合适。选择取决于用途，而且任何方式都需要导出复核。

5. 自动识别达到多少准确率才可以上线？

没有适用于所有组织的单一数字。身份证号漏掉一次与普通日期误删一次的后果不同，扫描件和文本文件也不能混算。应按实体风险、材料质量和业务场景分层验收，并把人工复核、降级与阻断能力一并计算。

6. 脱敏层能阻止模型“记住”所有信息吗？

不能作这种保证。模型是否在特定条件下复现信息与服务形态、数据用途、技术实现和输入内容有关。更稳妥的做法是先减少输入，核查实际协议和设置，限制映射与日志，再通过输出测试、持续监控和异常处置降低风险。

AI 脱敏层的价值，不在于给架构图多画一个方框，而在于把一句模糊的“注意隐私”变成可执行的责任：谁产生副本、谁批准提交、谁检查输出、谁管理证据、谁删除派生数据，以及失败时谁有权按下停止键。

说明：本文中的合同上传、知识库建设和 API 调用为基于常见企业流程整理的合成场景，不代表特定客户案例或集成实测；产品与平台事实按文中所列官方资料截至 2026 年 8 月 3 日核查。本文不构成法律意见。

下一步： 如果团队正在设计模型前置处理，可以先查看脱敏卫士产品能力，再用虚构或已获授权的非敏感样本进行在线体验。真实敏感文件应按组织要求使用桌面端在本机处理，并保留人工复核和放行记录。

相关阅读

• AI 脱敏中间层应该解决哪些问题？
• AI 训练数据为什么需要先脱敏？
• 把文件上传豆包前，为什么要先脱敏？