附录B：合规与上线检查清单¶
B.1 附录定位¶
本附录面向“数据集是否可以继续向下流转”的关键关口。它关心的并不是抽象意义上的合规口号，而是更具体的工程问题：某批数据能不能进入标注，能不能进入训练，能不能对外发布，能不能支撑课程实验，能不能接入线上系统。
在大模型数据工程中，最危险的情况通常不是某条法律条文完全没人知道，而是团队在日常推进中逐渐形成一种错觉，认为合规检查只是项目末尾补一个审批表。实际上，合规与上线检查应贯穿数据生命周期，因为来源不清、授权不明、脱敏不稳、评测污染、资源声明缺失、教学环境越权访问等问题，一旦进入后期才被发现，代价会远高于前置识别。
因此，本附录提供的不是法律意见、医学建议、金融或投资建议，也不构成任何监管审批、伦理审查或上线许可。它是一套更适合工程团队执行和留痕的检查框架，目标是让技术负责人、项目经理、课程负责人和合规接口人使用同一套表述，降低跨角色沟通成本。
在涉及法律、医疗、金融、未成年人、跨境数据、个人敏感信息或行业监管的场景中，读者应以所在机构的正式制度、所在司法辖区的现行法规、数据提供方合同、伦理审查要求和专业合规意见为准。在中国大陆语境下，网络安全、数据安全和个人信息保护分别需要结合《中华人民共和国网络安全法》《中华人民共和国数据安全法》和《中华人民共和国个人信息保护法》理解（National People's Congress of the People's Republic of China 2016, 2021a, 2021b）。本附录中的清单只能帮助团队提前发现需要升级评审的问题，不能替代律师、医师、金融合规人员、安全负责人或伦理委员会的专业判断。
B.2 合规检查为什么必须前置¶
如果合规只在发布前做，团队最容易遇到三种高成本返工。第一种是来源返工，数据抓回来了、清洗完了，才发现原始授权并不允许模型训练或二次分发。第二种是标注返工，标注完成后才意识到敏感字段未脱敏，导致全部样本需要重做。第三种是发布返工，公开 benchmark 时才发现训练集与测试集边界不稳，或外部许可证与榜单提交规则冲突。
更稳妥的做法，是把合规拆成四个关口。这个拆分也可以和风险管理框架对齐：NIST AI RMF 强调按治理、映射、度量和管理组织 AI 风险，欧盟《人工智能法案》则进一步体现了按风险等级设置义务和边界的监管思路（National Institute of Standards and Technology 2023; European Parliament and Council of the European Union 2024）。
- 数据接入前的来源与授权检查。
- 标注与加工前的敏感性与委托边界检查。
- 训练与评测前的数据使用边界检查。
- 对外发布与系统上线前的公开暴露检查。
只要把这四个关口建立起来，很多本来会在项目末尾爆炸的问题，都能在更早阶段被限制在可控制范围内。
B.3 数据接入前检查清单¶
B.3.1 来源与授权是第一道门¶
数据接入最先要确认的，不是“值不值得抓”，而是“能不能合法、合约上可解释地抓”。推荐至少检查表 B-1 中的字段。
| 检查项 | 需要回答的问题 | 常见风险 | 建议动作 |
|---|---|---|---|
| 来源主体 | 数据由谁提供 | 来源链断裂、二手转手不明 | 保留来源说明与联系人 |
| 使用许可 | 是否允许训练、评测、再分发 | 论文可用但商用或公开受限 | 建立许可白名单/灰名单 |
| robots / ToS | 抓取是否与站点规则冲突 | 违规抓取、后续下架风险 | 留存规则截图与时间点 |
| 地域边界 | 是否涉及跨境或特殊行业数据 | 传输边界不清 | 与法务/安全接口人确认 |
| 更新周期 | 来源是否稳定变化 | 复现时拿不到同一版本 | 冻结抓取窗口与快照 |
来源检查之所以关键，不是因为团队想“走流程”，而是因为后续所有工程动作都会放大来源问题。越靠近模型训练和公开发布，修改来源策略的成本越高。
B.3.2 个人信息与敏感信息要先分级再处理¶
如果样本中可能包含姓名、联系方式、证件号码、病历、位置轨迹、未成年人信息、企业内部文档或商业秘密，团队不应急着讨论用什么模型脱敏，而应先完成信息分级。一个实用的工程分级如下：
| 等级 | 典型内容 | 默认策略 |
|---|---|---|
| L0 | 公开、低风险、已明确授权数据 | 可进入常规治理流程 |
| L1 | 普通个人信息或业务字段 | 最小化收集、脱敏后再流转 |
| L2 | 敏感个人信息、医疗、金融、教育等 | 需专项审批与隔离处理 |
| L3 | 高敏、涉密、合同限制强的数据 | 原则上不进入通用训练流程 |
这一步最容易犯的错误，是把“脱敏”误解成万能通行证。很多时候，问题不在于某个字段有没有被掩码，而在于任务本身是否依赖这些敏感字段。如果任务定义离不开敏感属性，团队应优先重写任务边界，而不是幻想靠一次正则替换就能解决。
B.4 标注、委托与第三方协作检查¶
B.4.1 标注平台不是天然合规边界¶
很多团队会把样本上传到外部标注平台，然后默认“平台有权限系统，所以应该没问题”。这是风险较高的认知。标注环节至少要确认四件事：
- 第三方是否被明确授权接触该类数据。
- 标注说明中是否存在越权披露的风险。
- 标注结果是否会被再回流到其他项目。
- 标注日志、截图和缓存是否会形成新的泄露面。
表 B-2 给出一个可直接使用的检查框架。
| 检查项 | 需要回答的问题 | 建议动作 |
|---|---|---|
| 委托边界 | 谁可以看到原始样本 | 建立角色分层与最小权限 |
| 数据脱敏 | 标注前是否完成必要处理 | 保留脱敏版本与原始版本隔离 |
| 标注说明 | 指南里是否泄露内部信息 | 发布前复核说明文本 |
| 日志与缓存 | 平台是否保留预览、下载缓存 | 明确清理策略与保留周期 |
| 争议样本 | 是否会流向公开讨论区 | 单独隔离，不外发原文 |
B.4.2 与高校合作时要特别注意成果边界¶
高校合作场景中，一个常见风险是“项目化”和“论文化”边界不清。项目里允许内部使用的样本，未必允许论文附录公开；课堂演示中允许展示的页面，未必允许打包成对外数据集。最稳妥的做法，是在合作开始时就把成果边界写清：
- 哪些结果只限项目内部使用。
- 哪些统计可以论文公开但原样本不能外发。
- 哪些数据可进入课程镜像但不得下载带走。
- 哪些内容可以形成 benchmark，哪些只能形成内部测试集。
如果不把这些边界写清，后续很容易出现“工程上已经做完，合约上却走不通”的尴尬局面。
B.5 训练与评测前检查清单¶
B.5.1 训练集合法并不等于评测集安全¶
不少团队会把训练与评测当成同一类数据治理问题，但它们的风险不同。训练集最关心的是来源、授权、敏感性和任务适配；评测集还必须额外关注污染、隔离和比较公平性。
训练与评测前建议单独确认以下问题：
| 检查项 | 训练前重点 | 评测前重点 |
|---|---|---|
| 来源与许可 | 是否允许训练 | 是否允许公开测试与榜单使用 |
| 数据最小化 | 是否保留了不必要字段 | 是否泄露标准答案或提示 |
| 版本冻结 | 是否锁定训练版本 | 是否锁定测试版本与脚本 |
| 污染检查 | 是否接触公开测试集 | 是否被训练语料反向污染 |
| 资源声明 | 训练资源是否可记录 | 提交资源条件是否可比 |
尤其在开放 benchmark 场景下，评测集不是“只要质量高就行”，而是必须让外部团队相信比较条件是稳定和公正的。否则，即使榜单分数可观，也无法形成长期信任。
B.5.2 LLM judge 与自动脱敏都要进入审计表¶
随着越来越多流程使用大模型做 judge、摘要、分级和脱敏，团队必须把“辅助模型本身”纳入合规视野。检查重点包括：
- 使用的辅助模型是否会把输入样本发送到外部服务。
- 服务协议是否允许保留、训练或人工审阅输入。
- judge 结论是否会决定正式标签或上线结论。
- 脱敏失败样本是否会进入人工复核通道。
这一步之所以重要，是因为技术团队很容易默认“只是内部调用一个 API”，但从治理角度看，这已经是一次新的数据暴露。
B.6 对外发布与公开基准检查清单¶
B.6.1 发布前至少要同时准备四类文档¶
一个准备成熟的数据集或 benchmark，在对外发布前至少应准备以下四类文档。模型卡片的提出，正是为了把用途、限制、性能和风险以稳定格式交代清楚；数据或基准发布也应采用类似的结构化披露思路（Mitchell et al. 2019）。
- 数据/基准卡片：说明任务、样本结构、split、限制。
- 许可与使用说明：说明能做什么、不能做什么。
- baseline bundle：说明最低可复现基线。
- 更新与争议处理机制：说明版本、反馈与撤回路径。
如果只发布样本和论文链接，而没有这四类文档，外部团队很难真正安全使用，也很难在出现争议时迅速处理。
B.6.2 榜单治理比“是否公开”更重要¶
很多 benchmark 失败不是因为不够公开，而是因为公开后没有治理机制。对于排行榜，建议至少明确以下规则：
| 检查项 | 需要回答的问题 |
|---|---|
| 提交方式 | 允许上传什么，禁止上传什么 |
| 资源声明 | 是否要求报告模型规模、推理预算、检索资源 |
| 人工复核 | 哪些情况会触发人工审查 |
| 撤榜规则 | 发现污染、作弊、越权访问后如何处理 |
| 教学隔离 | 课程版本是否与公开榜单版本区分 |
只有把这些规则写清，公开榜单才不会在短时间内从“展示平台”退化成“口径混乱的比分墙”。
B.6.3 对外发布前的最小签发单¶
为了避免临发布时口头确认太多、留痕太少，建议每一次正式公开发布都至少形成一张签发单。它不必复杂，但应能回答最关键的问题。
| 字段 | 需要填写的内容 |
|---|---|
| asset_name | 数据集、benchmark 或课程镜像名称 |
| release_version | 本次对外版本号 |
| owner | 数据 owner 与评测 owner |
| source_check | 来源与许可是否复核完成 |
| privacy_check | 脱敏与敏感信息检查是否完成 |
| contamination_check | 训练/测试污染检查是否完成 |
| baseline_ready | baseline bundle 是否齐全 |
| rollback_path | 出现问题后的撤回路径 |
| public_notice | 发布公告或说明文档位置 |
签发单的价值，在于它把“谁拍板”和“基于什么拍板”留了下来。后续一旦出现争议，这张单据会比散落在聊天记录里的确认更有组织价值。
B.7 系统上线前检查清单¶
B.7.1 从“能跑”到“能上线”之间至少差了五层控制¶
模型或数据流程在实验环境可验证，并不代表可以上线。上线前至少要补齐五层控制：
| 控制层 | 关键问题 | 典型检查点 |
|---|---|---|
| 权限层 | 谁能访问样本与结果 | RBAC、最小权限、审计日志 |
| 隔离层 | 测试与生产是否隔离 | 环境分区、密钥管理 |
| 内容层 | 是否存在违规输出或敏感回显 | 红线样本、拒答策略 |
| 回滚层 | 事故发生后能否快速停用 | 版本锁定、灰度开关 |
| 记录层 | 事后能否复盘 | 请求日志、评测快照、事件台账 |
对大模型应用来说，很多事故并不是“模型突然变坏”，而是数据、提示、检索源或评测口径发生了变化，却没有被上线控制接住。
B.7.2 教学上线与产品上线是两套门槛¶
课程实验通常允许更多可解释过程、更多日志和更慢的响应，但产品环境通常不能。因此，不应把课程镜像直接当成线上系统，也不应把线上审计环境直接暴露给课程实践。建议分别维护：
- 教学镜像版本
- 研究复现实验版本
- 线上服务版本
这三者可以共用数据资产，但不应共用同一套暴露面与权限边界。
B.7.3 教学场景专项检查清单¶
高校合作和课程实验场景往往被误判为“风险较低”，因为系统使用人数有限、周期也较短。但事实上，教学场景有自己独特的高风险点，例如账号共享、实验报告粘贴原始样本、课堂录屏扩散、学期中环境热更新导致答案漂移等。
因此，课程上线前建议额外补一张教学专项清单：
| 检查项 | 需要回答的问题 | 建议动作 |
|---|---|---|
| 版本冻结 | 学期内版本是否保持稳定 | 开课前锁定镜像 |
| 权限范围 | 学生能否下载原始数据 | 默认关闭原始层下载 |
| 样本展示 | 课堂截图是否可能泄露敏感内容 | 使用教学脱敏样本 |
| 作业回收 | 学生提交物是否会包含原始数据 | 增加提交规范与自动扫描 |
| 助教运维 | 谁负责答疑和异常处理 | 建立值班与升级路径 |
这张清单和产品上线清单并不是谁替代谁的关系，而是分别回答“能不能安全教学”和“能不能安全服务”这两类不同问题。
B.7.4 跨境、外部 API 与第三方模型调用的附加检查¶
随着越来越多流程依赖外部基础模型、云 OCR、云存储或 SaaS 标注平台，团队还需要额外识别“样本是否离开了原有控制域”。这类检查至少应覆盖：
- 调用链里是否存在将原文、图像、音频发送给外部服务的动作。
- 这些服务是否保留日志、缓存或训练使用权。
- 是否存在地域跨境、第三方转处理或多级分包。
- 如果外部服务中断或条款变更，内部是否有降级方案。
很多系统上线后才暴露的问题，并不是模型效果，而是基础调用链中藏着团队自己都没有完全意识到的数据暴露点。把这类调用前置列入检查，是第十二篇“开放维护”和本附录“上线审计”之间最值得打通的一条链路。
B.8 事故响应与撤回机制¶
B.8.1 没有撤回机制的公开发布是高风险发布¶
只要数据集、榜单或课程资源已经公开，就必须假设未来可能出现以下情况：
- 外部报告样本侵权或敏感信息泄露。
- 发现训练/测试污染。
- baseline 代码存在严重错误。
- 榜单出现异常提交或可疑作弊。
- 教学镜像中存在越权访问路径。
因此，公开资产必须配套撤回与修复流程。建议至少明确以下动作链：
- 受理入口：谁接收问题报告。
- 分级机制：是否需要立即下线。
- 临时措施：隐藏下载、冻结榜单、停用镜像。
- 调查复盘：确认范围、原因、补救动作。
- 正式公告：发布修订说明与版本变更。
B.8.2 最小事故台账模板¶
| 字段 | 说明 |
|---|---|
| incident_id | 事故编号 |
| reported_time | 首次报告时间 |
| affected_asset | 涉及的数据集、榜单或系统 |
| risk_level | 风险等级 |
| temporary_action | 临时处置动作 |
| root_cause | 根因 |
| public_notice | 对外公告链接或说明 |
| preventive_action | 后续预防措施 |
事故台账制度化的意义不在于增加流程形式，而在于防止同一类问题跨学期、跨项目、跨责任人重复发生。
B.8.3 高风险红旗信号¶
为了帮助团队在日常推进中快速识别问题，下面给出一组适合贴在项目面板上的“红旗信号”：
- 数据来源只能追溯到个人网盘、聊天文件或二次转存链接。
- 标注平台默认所有标注员都可见全部原始样本。
- 教学实验直接复用生产环境或生产密钥。
- 训练集与测试集在不同版本中被重新切分，但没有公告。
- 公开榜单允许上传结果，却没有资源声明和撤榜规则。
- 外部 API 会接触样本正文，但没人能说清其日志保留政策。
- 项目负责人离开后，没有任何人能指出撤回和修复入口。
只要出现其中两三项，就不应该继续按“常规推进”处理，而应尽快进入专项复核。
B.9 角色分工建议¶
合规与上线检查最容易失效的情形，是“所有角色都知道需要执行，但没有明确责任人”。建议至少区分四类角色：
| 角色 | 主要职责 |
|---|---|
| 数据 owner | 来源、授权、版本、下线决策 |
| 评测 owner | 测试隔离、榜单口径、baseline 复核 |
| 安全/合规接口人 | 审批边界、敏感信息处置、外部报告协调 |
| 教学 owner | 课程镜像、学期版本、课堂使用边界 |
这四类角色未必要对应四个独立岗位，但职责本身不能缺位。只有角色清晰，清单才不会变成形式主义。
B.9.1 一个季度一次的合规复盘，至少应该回答什么¶
如果项目处于长期运营状态，建议每季度做一次轻量合规复盘。它不需要像事故复盘那样沉重，但至少要回答下面五个问题：
- 本季度新增的数据来源中，是否有任何许可边界发生变化。
- 本季度是否新增了外部服务调用链，且已经完成留痕。
- 本季度是否出现过样本撤回、脱敏补丁或榜单争议。
- 本季度教学版本、研究版本和公开版本是否仍然保持清晰隔离。
- 下一季度最值得优先补的，是来源治理、权限治理，还是撤回流程。
这样做的好处是，合规检查就不再是“最后一刻拦项目”，而会真正变成帮助项目稳定演进的一部分。
B.9.2 样本撤回演练不应等到真实事故发生时才第一次做¶
很多团队会认真写撤回机制，却从未真正演练过“如果明天有人要求下线一批样本，我们能不能在半天内定位、冻结、公告并重建受影响版本”。这和只写灾备方案却从不演练，本质上是同一类问题。只要没有实际演练，团队就很难知道撤回链路中到底卡在数据定位、版本依赖、教学镜像、榜单冻结，还是外部通知流程。
因此，建议每个学期或每个季度至少做一次小规模撤回演练，哪怕只是选取一组模拟样本，也要完整走一遍流程：
- 确认样本定位是否能从发布版本反查到原始来源与中间版本。
- 确认训练集、评测集、教学镜像和公开下载包是否都能识别受影响范围。
- 确认榜单、baseline 与课程实验是否需要同步冻结或补公告。
- 确认外部问题受理人与内部责任人之间是否存在沟通断点。
- 确认修订后版本能否快速重新生成并保留历史说明。
这类演练的意义并不只是为了应对极端情况。它还能反向暴露一个系统是否真的具备“可治理”的资产结构。如果某个数据集一旦要求撤回样本，团队连受影响版本都找不全，那么问题就不只是应急能力不足，而是整个版本治理链条还没有真正建立起来。
B.10 本附录小结¶
本附录把合规与上线问题翻译成了一套工程团队更容易执行的清单。核心结论有三条。
第一，合规不是项目末尾的附加步骤，而是数据生命周期中的连续关口。
第二，训练、评测、公开发布、课程复现和产品上线的边界并不相同，必须分别检查。
第三，真正能降低长期风险的，不只是“一次审批通过”，而是来源留痕、版本冻结、事故撤回和角色分工的制度化。
参考文献¶
National People's Congress of the People's Republic of China (2016) Cybersecurity Law of the People's Republic of China. http://www.npc.gov.cn/zgrdw/npc/xinwen/2016-11/07/content_2001605.htm.
National People's Congress of the People's Republic of China (2021a) Data Security Law of the People's Republic of China. https://www.cac.gov.cn/2021-06/11/c_1624994566919140.htm.
National People's Congress of the People's Republic of China (2021b) Personal Information Protection Law of the People's Republic of China. http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html.
National Institute of Standards and Technology (2023) AI Risk Management Framework (AI RMF 1.0). https://www.nist.gov/itl/ai-risk-management-framework.
European Parliament and Council of the European Union (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). https://eur-lex.europa.eu/eli/reg/2024/1689/oj.
Mitchell M, Wu S, Zaldivar A, Barnes P, Vasserman L, Hutchinson B, Spitzer E, Raji I D, Gebru T (2019) Model Cards for Model Reporting. In: Proceedings of the Conference on Fairness, Accountability, and Transparency, pp 220-229. https://doi.org/10.1145/3287560.3287596.