把合同和尽调材料交给云端大模型前，先在本地完成这 4 步脱敏
企业使用云端大模型处理合同、尽调、财务、客服或知识库材料时，应先在本地识别并替换不必要的敏感信息，由业务人员复核实际导出物，再只发送安全版本；原始材料与映射字典继续留在受控环境。
核心要点
- 提示词无法撤回已经上传的原始字段，安全控制应前移到模型调用之前。
- AI 只使用经过人工复核的安全版本，未经脱敏的原始材料不直接交给 AI 厂商。
- 混淆代指应保留任务所需的人物、机构、金额与时间关系，避免脱敏后无法分析。
- 映射字典和还原关联信息仍属敏感资产，应留在受控环境并限制访问。
企业账号、服务协议和关闭训练选项都很重要，但它们不能自动回答另一个更早的问题：这份原始合同、案卷或尽调底稿，是否真的需要原样进入云端模型？
能上传，不等于适合直接上传。法律、财务、咨询和客服材料里，模型完成摘要或问答可能只需要人物角色、交易关系、时间线和金额结构，却不需要真实姓名、身份证号、账户、住址、客户名称或内部项目代号。
因此，值得固定下来的检查层不是再加一句禁止泄密的提示词，而是把控制点前移到模型调用之前：未经脱敏的原始材料不直接交给 AI 厂商；AI 使用经过人工复核的安全版本；需要还原时，映射字典留在受控环境。
这一步改变的不是模型能力，而是原始材料进入模型前的数据边界。
为什么安全步骤必须放在提示词之前
生成式 AI 的输入本身就是一条数据流。把整份业务材料粘贴进对话框、上传为附件，或接入知识库索引，意味着下游系统必须读取这些内容。即使服务商提供企业级数据控制，组织仍要核对实际使用的产品版本、区域、日志、留存、管理员权限和分包商安排。
提示词只能约束模型如何回答，不能把已经发送的原始字段变成未发送。OWASP 在生成式 AI 敏感信息披露风险中，把输入前的数据清洗、遮蔽和标记化列为缓解措施；Google Cloud 的生成式 AI 安全实践也把进入基础模型前的提示内容视为需要识别或移除敏感元素的数据边界。这些实践共同指向一个朴素结论：先减少输入，再讨论模型端控制。
在中国个人信息处理场景中，这也与现行规则的方向一致。《个人信息保护法》第六条要求处理目的明确、合理，并采取对个人权益影响最小的方式，收集限于实现目的的最小范围；第五十一条列出的安全措施包括分类管理、加密、去标识化和合理确定操作权限。若云端服务构成委托处理，第二十一条还要求约定处理目的、期限、方式、信息种类和保护措施，并监督受托人的处理活动。
这不意味着做了脱敏就当然合规，也不意味着所有云端 AI 调用都属于同一种法律关系。合法性基础、告知同意、敏感个人信息、数据出境、行业保密义务和合同约定，仍需按具体材料与服务链路判断。端侧脱敏的价值，是在这些判断之外先完成一项可验证的风险收敛：不把下游任务不需要的原始标识一起送出。
默认前置，不等于一刀切删除
真正可用的安全版本，要同时满足两个条件：不能继续暴露不必要的原始信息，也不能破坏 AI 完成任务所需的语义。
例如，合同审查要识别谁承担义务、谁付款、违约责任如何传导。如果把所有主体直接删除，模型看到的只剩残缺句子。把真实名称替换为 <单位1>、<单位2>，把自然人替换为 <人物1>，通常更能保留角色关系。企业知识库和多文件尽调还要考虑同一主体在不同材料中的代指一致，否则模型难以串起交易链条。
财务分析也不能机械涂黑全部数字。若任务只需要判断付款节奏或异常波动，可以根据用途隐藏真实金额，同时保留差额、比例或区间；如果分析根本不需要账户、身份证号和联系方式，则应直接移除或替换。处理前先列一份敏感信息清单，比默认把所有字段交给模型再寄希望于输出过滤更可靠。
可逆与不可逆处理也要按任务分开。外发公开稿更适合不可逆遮蔽；内部分析可能需要一致代指，并在授权审批后回看原文。两者的选择标准可以参考可逆脱敏和不可逆脱敏的边界，但无论哪一种，都不能让安全版本和映射字典作为同一个无差别附件流转。
四步把本地脱敏接到云端 AI 前面
第一步：只保留任务真正需要的信息
先写清楚 AI 要完成的动作，而不是先上传文件再探索。
合同审查需要条款、主体角色、期限和责任结构；尽调需要跨文件关系、交易时间和风险事实；客服质检需要意图、问题类型和处理结果；咨询分析需要行业、问题和决策条件。逐项标出哪些字段必须保留原值，哪些可以代指、泛化、偏移或删除。
这一步同时决定复核标准。没有任务范围，就无法判断一个被保留的客户名称究竟是必要信息，还是一次不必要的暴露。
第二步：在本地生成工作副本
原始材料保留在受控位置，在本机工作副本上完成识别与替换。RedactOS 桌面端支持在本机完成导入、识别、复核和导出，文档、处理过程、任务记录和还原关联信息留在本机，也可在断网环境使用。
识别方式应按字段特征组合：身份证号、手机号、邮箱、合同编号等固定结构适合规则识别；姓名、地址、机构等依赖上下文的内容需要语义识别辅助；内部项目代号、客户简称和组织特有编号再用自定义规则或黑白名单补齐。
随后按下游任务选择输出。面向 AI 的摘要、问答、检索或分析，通常需要保留实体类型和文档结构，可以优先评估混淆代指；公开展示则更适合涂黑或星号遮盖。这里没有对所有材料都正确的默认替换方式，只有与任务匹配的安全版本。
第三步：由人核对误报、漏报和语义损失
自动识别缩小了检查范围，不能替代最终判断。扫描质量、上下文、语言、专业术语和组织内部缩写都会影响命中结果。
复核人员至少要处理三类问题：关闭不该替换的误报；补标没有识别到的敏感内容；确认替换后的人物、机构、金额和时间关系仍足以支持 AI 任务。如果多份文件属于同一项目，还要检查代指是否一致。
真实产品界面中，原文、处理结果和命中列表并排呈现，复核者可以检查每类替换是否准确。
RedactOS 的产品边界也是自动识别加人工复核，不承诺一次自动处理即可零遗漏。发现漏脱时可划词补标，发现误脱时可关闭对应项目；高频特例再沉淀为自定义规则、黑名单或白名单。
第四步：只把安全版本交给 AI
复核完成后，从实际导出物做一次反向检查，再将安全版本上传到云端模型、企业知识库或后续 Agent。不要只看编辑界面，因为模型读取的是导出的文本、PDF、Word、图片或 Markdown 文件。
映射字典、任务记录和还原关联信息继续留在受控环境。它们能恢复安全版本与原文之间的对应关系，本身仍是敏感资产，应限制谁能查看、导出和执行还原，并设定保存期限与留痕要求。
此时可以准确描述数据边界：未经脱敏的原始材料不直接交给 AI 厂商；AI 使用经过复核的安全版本；映射字典留在受控环境。不能把它改写成业务数据完全不传给 AI 厂商，因为安全版本仍会进入所选的模型或服务，具体日志、留存和访问边界仍由下游配置决定。
六类业务任务，分别该保留什么
法律文书摘要应保留案件角色、请求、争点、时间线和证据关系，通常无需真实姓名、证件号、住址和联系方式。若案号不是分析条件，也应替换。
合同审查应保留甲乙方角色、标的、期限、付款节点、责任和条件关系；真实公司名称、银行账户、联系人和签章信息通常可以代指或删除。
财务分析应先判断模型需要绝对数值、比例、区间还是变化趋势。账户信息与身份字段通常不是计算条件，金额是否偏移则取决于分析目的。
尽调与咨询材料经常跨文件引用同一主体。安全版本应维持代指一致，同时把映射保留在项目受控空间，避免随分析包一起外发。
客服质检需要问题类型、服务过程、情绪和解决结果，但通常不需要客户真实姓名、手机号、地址、订单号和支付信息。知识库入库前还要检查附件和历史对话中的残留字段。
企业知识库需要的不只是首次清洗。新增文档、版本更新、索引重建和权限变更都可能让未经处理的材料重新进入检索链路，因此应把本地脱敏作为入库门禁，而不是一次性专项清理。
上线前，用实际导出物完成验收
可以把以下项目固化为模型调用前的验收单：
- [ ] 已写明 AI 任务、输入范围和必须保留的语义；
- [ ] 原始材料与脱敏工作副本分开保存；
- [ ] 已覆盖固定字段、上下文实体和组织特有字段；
- [ ] 已处理误报、漏报和跨文件代指不一致；
- [ ] 已从最终导出物搜索已知姓名、账号、地址和项目代号；
- [ ] 已检查扫描页、图片层、批注、附件和复制出的文本；
- [ ] 安全版本与映射字典没有打包在一起；
- [ ] 已核对下游 AI 服务的区域、留存、日志、权限和合同边界；
- [ ] 已确定任务记录、映射与临时文件的保存和删除规则。
这份清单不能替代具体法律审查，也不能证明材料已经匿名化。它的作用是让每次 AI 使用都经过同一扇门：先在本地减少不必要的原始信息，再由人确认安全版本确实可用，最后才调用云端模型。
当这套顺序进入模板、Agent 或知识库入库流程后，端侧脱敏就不再是一项临时补救，而会成为使用云端大模型的默认安全步骤。RedactOS 可以承担其中的本地识别、替换、复核、导出和任务内还原；组织仍需对材料用途、复核责任、映射权限和下游服务边界作出自己的判断。
参考资料
常见问题
使用企业版云端大模型还需要先脱敏吗？
仍应先判断任务是否需要原始身份、账户和客户信息，并核对具体产品的数据条款、日志、留存和权限边界。
脱敏后是否等于业务数据完全不传给 AI 厂商？
不是。AI 仍会接收经过复核的安全版本，只是未经脱敏的原始材料不直接发送，映射字典留在受控环境。
为什么不能把姓名和机构全部删除？
合同、尽调和知识库任务常需要主体角色与跨文件关系，使用一致代指通常比直接删除更能保留分析语义。
自动识别完成后还要人工复核吗？
需要。文档质量、上下文和组织特有字段都会影响识别结果，正式导出前应处理误报、漏报和语义损失。