这份清单适合哪些团队？
- 正在准备脱敏 POC 的法务、数据安全和 IT 团队；
- 需要把合同、项目资料或内部文档交给外部人员的业务团队；
- 准备在 RAG、AI 助手或测试流程前处理敏感文件的项目负责人；
- 需要定义样本、人工复核、版本边界和上线验收条件的采购与实施团队。
先把“首批上线”说清楚
“首批上线”如果没有范围，很快就会变成“把所有历史文件、业务系统和敏感类型都纳入”。更稳妥的起点，是选一条责任人明确、能够人工复核的文件流程。
- 合同交给外部顾问前，生成不附带还原关系的清洁副本；
- 内部调查或质量核对时，保留受控还原路径；
- 文件进入测试或企业批准的 AI 流程前，移除任务不需要的敏感信息；
- 已由现有工具或人工流程发现的终端文件，进入后续脱敏和复核环节。
项目启动时应写下一句可验证的目标：哪类文件、从哪里进入、给谁使用、需要处理哪些信息、由谁复核，以及什么证据代表可以进入首批业务流程。
| 判断维度 | 适合进入首批试点 | 建议暂缓或缩小范围 |
|---|---|---|
| 文件流程 | 来源和接收方明确的一类文件 | “公司所有文件”或来源无法说明的混合目录 |
| 样本 | 已获授权，包含常见情况和边界案例 | 只挑排版整齐的演示文件，或样本使用权限不清 |
| 复核 | 有业务人员建立参考答案并承担复核 | 只看系统输出，没有人工判断责任人 |
| 输出用途 | 能说明用于内部核对、外发、测试还是 AI 流程 | 同一版本同时承担内部还原和外部交付 |
| 退出条件 | 能按证据决定进入有限上线、延期或停止 | 只规定日期，没有关键门槛和异常回退 |
30 天试点规划模板
这份模板按 30 天展开，方便团队安排依赖关系。文件数量、格式、扫描质量、字段复杂度、部署审批和系统接入不同，实际节奏可以缩短、延长，也可以重新排序。
| 示例时间 | 主要任务 | 关键产出 | 进入下一阶段前确认 |
|---|---|---|---|
| 第 1—3 天 | 场景与责任梳理 | 场景说明、接收方、业务负责人、复核人、不可处理范围 | 目标是验证一条真实工作流，不是做一次演示 |
| 第 4—7 天 | 建立代表性样本 | 授权样本集、敏感类型、边界案例、人工参考答案 | 覆盖常见文件和容易出错的情况 |
| 第 8—12 天 | 策略映射与首次运行 | 字段规则、保留项、转人工条件、候选结果 | 每类信息的处理理由能够解释 |
| 第 13—17 天 | 双模式与人工复核 | 可逆版本、不可逆清洁副本、误标与漏标记录 | 还原权限与外发副本分开，结果经过人工复核 |
| 第 18—22 天 | 失败路径与接入核对 | 异常样本、退回机制、输入输出约定、问题单 | 格式、接口、部署、日志等未知项已标记 |
| 第 23—26 天 | 小范围业务试点 | 限定团队、限定文件范围、问题清单、版本记录 | 上游发现方式、处理入口和责任人明确 |
| 第 27—30 天 | 验收与运营交接 | 验收结论、未通过项、规则变更流程、复查节奏 | 每项结论都有样本、复核或记录依据 |
如果部署审批、真实样本准备或接口确认尚未完成，不应为了满足第 30 天而跳过。项目可以停在“样本验证完成”或“具备有限试点条件”。
样本别只挑最好处理的
样本必须经过授权，也要有人能解释业务语境。只选排版整齐、字段明显的文件，测不出真正的边界；把未经批准的真实敏感材料带进不明确的环境，则会引入新的风险。
一个可复用的样本包至少包括：
- 文件用途、来源和允许使用的测试环境；
- 需要处理的敏感类型及典型写法；
- 必须保留的业务字段和上下文；
- 容易误标、漏标或产生歧义的边界案例；
- 人工确认的参考答案；
- 期望生成可逆版本还是不可逆清洁副本；
- 文件无法处理、版式不可用或结果有争议时的处置方式。
策略要能解释为什么这样处理
| 情况 | 建议处理思路 | 验证重点 |
|---|---|---|
| 定义稳定、写法明确的字段 | 评估规则或模板路径 | 是否覆盖真实写法，是否误伤业务必需字段 |
| 依赖上下文才能判断的内容 | 使用候选识别并转人工复核 | 复核人员能否看到足够上下文并修正结果 |
| 内部仍需核对真实值 | 评估可逆版本 | 谁能申请、批准和执行还原，适用于哪个版本 |
| 外发、测试或进入 AI 流程 | 优先评估不可逆清洁副本 | 副本不附带还原关系，并保留任务需要的内容 |
| 无法读取或结果不稳定 | 停止自动交付并转异常处理 | 是否保留失败原因、原始版本和重新处理入口 |
bestCoffer 可用于在共享、审阅或进入 AI 流程前识别候选敏感信息，并在人工复核后按用途准备处理版本。规则、指令或语义识别的具体范围，以及文件格式、扫描件处理和批量能力，都需要用当前版本和真实样本确认。
两种输出，要分别验证
- 可逆版本适合仍需内部核对、纠错或特定交付的场景。试点要确认申请目的、还原范围、批准责任和结果使用边界。
- 不可逆清洁副本适合外发、测试或不需要对应真实身份的 AI 使用场景。这里的不可逆只表示该副本不附带还原关系，不表示原件、工作件或其他副本已被删除。
双模式验收至少要检查：同一输入能否按不同用途形成可区分的版本；复核结果是否被带入正确输出；可逆版本的还原条件是否符合项目约定；不可逆副本是否保留业务可用性；发送或入库时是否选中了正确版本。
终端试点从“已经发现的文件”开始
如果首批场景涉及员工电脑或工作目录，先说明文件怎样进入处理范围。线索可能来自企业现有资产工具、终端管理、项目检查或人工上报。bestCoffer 脱敏承接的是已经发现并纳入范围的文件；未经确认，不能写成原生扫描全部终端、实时监控文件变化或远程整改设备。
部署和集成问题，提前列成问题单
- 实际文件怎样进入和离开处理流程；
- 数据在哪个环境处理，经过哪些系统；
- 当前版本接受哪些样本，失败时如何返回；
- 身份、权限和人工复核怎样衔接；
- 项目需要哪些操作记录，实际能够查询或导出什么；
- 批量规模、处理时间和资源使用怎样通过样本测量；
- 版本升级、规则变更和异常回退由谁负责。
这些问题的答案可能来自产品确认、解决方案设计、POC 记录或合同。没有证据时应保持“待确认”，不能补写成默认能力。
首批上线验收清单
范围与责任
- 首批场景、文件来源、接收方和业务目的已写清。
- 业务负责人、样本标注人、复核人、批准人和技术负责人已明确。
- 不在首批范围内的系统、文件和敏感类型已列出。
样本、策略与版本
- 样本经过授权，并覆盖常见情况与边界案例。
- 人工参考答案、保留项和转人工条件已经确认。
- 没有使用未经批准的通用准确率或效率数字替代项目结果。
- 原件、工作件、可逆版本和不可逆清洁副本能够区分。
- 误标、漏标和业务上下文由责任明确的人复核。
- 不可逆副本不附带还原关系，并通过实际文件检查。
接入、异常与运营
- 文件格式、扫描内容、批量范围、部署、接口和性能均以当前项目证据确认。
- 输入失败、处理失败、复核退回和输出异常均有停止或回退路径。
- 上游发现工具与 bestCoffer 处理范围的责任边界已写清。
- 小范围试点没有被描述为全公司、全终端或全格式覆盖。
- 规则新增、修改、复查和停用有负责人。
- 发现高风险遗漏或范围变化时，可以暂停并重新评估。
试点结束后，必须做出一个明确决定
| 决定 | 适用条件 | 下一步 |
|---|---|---|
| 进入有限上线 | 首批范围内关键门槛通过，人工复核、异常回退和责任分工可执行 | 保留适用范围与例外，按业务节奏复查 |
| 延期补证 | 主要流程可行，但部署、接口、格式、性能、权限或日志仍缺证据 | 完成问题单后再复测 |
| 停止或缩小范围 | 高风险敏感类型持续漏检、输出无法用于业务，或责任边界不清 | 回到样本与策略阶段，重新定义范围 |
准确率或综合得分可以帮助分析，但不能覆盖关键门槛。某个高风险字段持续遗漏时，即使平均结果看起来不错，也不应自动进入上线。
有限上线后，规则还要继续维护
首批上线会带来新文件、新写法和新例外。团队应按业务节奏复查误标、漏标、退回原因、规则变更和人工负担，并区分产品问题、样本问题、策略问题与流程问题。每次变更至少记录提出原因、影响场景、样本验证、批准人、生效范围和复查时间。
bestCoffer 放在流程的哪个位置
bestCoffer 脱敏适合从一条文件用途明确、能够人工复核的流程开始：团队先准备经授权的代表性样本，识别候选敏感信息，按业务用途选择可逆版本或不可逆清洁副本，再用项目约定的标准检查输出、权限与记录。
具体格式、扫描件处理、批量规模、部署区域、接口、性能、还原权限和日志字段，需要在当前版本、项目配置和 POC 中逐项确认。
本文提供项目规划与验收参考，不构成法律、监管或合规意见。具体义务取决于适用地区、企业制度、产品版本、部署与项目配置，以及客户自身工作流。
常见问题
不能这样承诺。30 天只是帮助团队组织范围、样本、策略、复核、试点和交接的规划示例。文件复杂度、人员、部署审批和系统接入都会影响时间，项目可以在证据不足时延期或缩小范围。
没有适用于所有项目的固定数量。样本应覆盖首批场景的常见文件、敏感类型和边界案例，并由业务人员建立参考答案。新增样本仍不断出现新错误类型时，说明样本覆盖还不稳定。
不够。还应检查高风险漏标、误标、人工复核负担、输出可用性、版本选择、异常回退和业务责任。阈值要由项目根据敏感类型和使用场景确定。
如果项目同时存在内部核对和外发、测试或 AI 使用，建议分别验证。可逆版本要检查还原权限和批准边界；不可逆清洁副本要确认不附带还原关系，并与原件和工作件分开。
不是。本文中的终端试点从文件已被现有工具、项目检查或人工流程发现并纳入范围之后开始。是否存在终端代理、自动发现或实时监控，需要单独核验，不能从本文推断。
不等于。POC 只能为约定场景、样本和配置提供技术与流程证据，不能替代法律判断、访问控制、安全治理或客户自身合规评估。
带着一条真实文件流程来验证
如果团队已经有明确的文件来源、接收方和披露目的，可以带一组经过授权的代表性样本，先验证候选识别、人工复核、可逆与不可逆版本，以及异常回退是否适合当前流程。