AI使用责任清单要长期可用，关键在于把它当作有版本、有触发条件、有责任人的治理台账来维护，而非一次性文档。具体要落实三件事：字段能支撑逐条变更，更新有定期与事件两类触发节奏，每个环节都有明确角色和留痕。本文按字段设计、更新节奏、角色分工、单条更新流程、一致性检查、机制验收六个部分展开，并说明如何借助ONES的工作项与Wiki页面承载清单条目和变更记录。
要点总览（TL;DR）
- 清单要能长期维护，先固定最小字段集：使用场景、工具或模型、数据范围、责任人、审批人、使用边界、复核日期、状态，颗粒度按使用场景划分。
- 更新采用定期复核与事件触发两类节奏：工具更换、模型调整、数据范围扩大、人员变动、制度调整在生效前完成审核，事件触发优先于定期复核。
- 维护分工覆盖使用人、场景负责人、治理或安全审核角色、清单管理员四类角色，每次变更留下申请、审批意见、版本号和通知记录。
- 用抽样检查比对清单记录与实际使用，发现偏差后区分清单滞后与使用违规，整改后再次抽样验证，形成闭环。
- 机制验收看四项：字段完整责任到人、变更可追溯、检查问题已闭环、发布通知有记录；不成熟时先覆盖高风险场景，从最小字段集起步。
清单先定字段：哪些信息决定它能否被维护
责任清单能否被维护，取决于字段是否足以支撑“找到这一条、判断要不要改、改完能追溯”。字段太少，变更时无从判断影响范围；字段太多，维护成本高，实际执行容易流于形式。建议先固定一组最小字段集，再按团队治理成熟度逐步扩展。
| 字段 | 填写要求 | 维护作用 |
|---|---|---|
| 使用场景 | 用一句话描述业务动作，如“需求文档辅助撰写”“代码补全与评审建议” | 作为清单条目的唯一标识，决定颗粒度 |
| AI工具或模型 | 记录工具名称、接入方式、所用模型或版本标识 | 工具或版本变化时定位受影响条目 |
| 数据范围 | 说明输入AI的数据类型与来源，如公开文档、内部需求、客户数据 | 数据范围扩大时触发重新审核 |
| 责任人 | 场景负责人姓名与岗位，一名责任人对应一条场景 | 变更申请与日常复核的发起人 |
| 审批人 | 审核该场景的治理或安全角色 | 变更审批与发布签字的承担者 |
| 使用边界 | 写明允许与禁止的用法，如“不得将输出直接作为对外交付物” | 审核判断与检查比对的依据 |
| 复核日期 | 下一次定期复核的具体日期 | 驱动定期复核节奏 |
| 状态 | 草稿、生效、暂停、下线 | 区分在用条目与已停用条目，避免误用 |
颗粒度按使用场景划分，而非按人划分。按人划分会出现同一场景多人重复登记、责任边界模糊的问题；按场景划分后，一条记录对应一个可审核的业务动作，人员变动只需更新责任人字段，场景本身保持稳定。同一场景下不同团队使用不同工具时，可拆成多条记录，但每条仍需独立的责任人与审批人。
字段与变更记录要建立关联：每条清单记录带唯一编号，变更记录以该编号为索引，记录变更前后字段值、申请人、审批人、生效时间。这样任一字段的历史取值都能回溯，检查时也能判断某次使用是否发生在旧版本生效期间。在ONES中，清单条目可作为工作项管理，变更记录与审批意见保存在对应工作项的流转记录和Wiki页面中，形成条目与记录的对应关系。
更新节奏：定期复核与事件触发怎么配合
清单更新需要两类节奏并行：定期复核保证所有条目在固定周期内被重新确认，事件触发保证重大变化发生时清单及时跟上。只做定期复核，工具或数据范围变化后清单会滞后；只做事件触发，长期未变的条目会逐渐失真。
| 触发类型 | 典型情形 | 处理时限建议 | 处理方式 |
|---|---|---|---|
| 定期复核 | 复核日期到期，条目本身无变化 | 按设定周期，如每季度或每半年 | 责任人确认字段仍准确，更新复核日期，记录确认结论 |
| 事件触发 | 更换AI工具或接入方式 | 变更生效前完成 | 提交变更申请，重新审核使用边界与数据范围 |
| 事件触发 | 模型或版本调整，输出特性变化 | 调整上线前完成 | 评估对使用边界的影响，必要时暂停条目直至审核完成 |
| 事件触发 | 数据范围扩大，如新增客户数据输入 | 扩大使用前完成 | 重新审核数据合规性与审批层级 |
| 事件触发 | 责任人、审批人岗位变动 | 变动后一周内 | 更新责任人字段，完成交接确认 |
| 事件触发 | 监管要求或内部制度调整 | 按制度生效日期倒排 | 批量评估受影响条目，逐条修订使用边界 |
定期复核周期依据场景风险和数据敏感度设定：涉及客户数据或对外输出的场景可缩短至每季度，内部辅助类场景可每半年。周期没有统一标准，应结合企业自身制度与监管要求确定，并在清单中写明设定理由，便于后续调整时有据可依。
两类节奏冲突时，事件触发优先。例如某条目距离定期复核还有两个月，但工具版本已升级，应先按事件触发流程完成审核，再在审核结论中顺延或重置复核日期，避免同一周期内重复审核。若事件触发导致条目暂停，定期复核可暂缓，待条目恢复生效后重新计算复核日期。
角色与交付物：谁提出、谁审核、谁发布
清单维护涉及四类角色，每类角色有明确的输入、动作与输出。角色可以兼任，但职责不能合并到无人承担。
| 角色 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 使用人 | 日常使用中发现的工具变化、数据范围变化、边界疑问 | 向场景负责人报告变化或提出变更需求 | 变更线索或问题记录 |
| 场景负责人 | 使用人反馈、定期复核提醒、制度调整通知 | 判断是否需要变更，填写变更申请，确认字段准确性 | 变更申请单、复核确认记录 |
| AI治理或安全审核角色 | 变更申请、使用边界、数据范围说明 | 审核合规性、风险等级与审批层级，给出通过、退回或附条件通过结论 | 审核意见与审批签字 |
| 清单管理员 | 审核通过的变更申请 | 更新清单条目、发布新版本、通知相关方、归档旧版本 | 新版本清单、发布通知、版本归档记录 |
审批与发布环节的留痕要求包括：审批人身份与审批时间、审批结论及理由、发布版本号与生效时间、通知范围与通知方式。留痕的作用是当检查发现某次使用存在争议时，能判断当时清单处于哪个版本、由谁批准。在ONES中，审批意见可随工作项流转记录保存，清单版本可作为Wiki页面保留历史版本，通知范围可通过工作项的关注人或相关项目成员确定。
一次完整更新怎么做：从变更申请到发布通知
以下步骤以单条清单更新为单位，适用于事件触发和定期复核中需要修订的情形。
- 提交变更申请。场景负责人填写：清单编号、变更类型（工具、模型、数据范围、人员、制度）、变更前后内容、变更原因、预计生效时间、受影响的使用团队。信息不全的申请由清单管理员退回补充。
- 审核判断。治理或安全审核角色重点判断：新工具或新数据范围是否超出原审批层级；使用边界是否需要同步修订；是否需要暂停当前使用直至审核完成。出现数据范围明显扩大但未说明用途、工具来源不明、使用边界与制度冲突等情形时退回，并写明退回理由。
- 更新条目并发布版本。清单管理员按审核结论修改字段，生成新版本号，记录生效时间。旧版本保留归档，标注失效时间，不删除。
- 通知相关方。通知范围包括该场景的使用人、场景负责人、审批人及受影响的相邻团队。通知内容包含变更点、生效时间、使用边界调整和需要停止的旧用法。
示例（演示情景）：某研发团队计划在需求评审环节新增AI代码辅助场景。场景负责人提交变更申请，说明使用工具、输入为内部代码仓库的脱敏片段、输出仅用于参考建议、不进入交付物。审核角色确认数据范围不含客户数据，审批层级为团队级，附条件通过：要求使用边界中写明“生成代码须经人工评审后合入”。清单管理员新增条目，状态设为生效，复核日期设为三个月后，发布通知给该团队全体成员与代码评审负责人。整个过程留下申请单、审核意见、版本记录和通知记录，后续检查时可逐项核对。
维护效果怎么检查：抽样、比对与整改闭环
清单写得完整不等于执行一致，需要用抽样检查验证清单记录与实际使用是否吻合。检查对象包括：清单条目本身（字段是否仍准确、复核日期是否过期）、实际使用行为（是否按使用边界执行、是否使用了未登记的工具）、变更记录（是否每次变更都有申请与审批）。
抽样频次可与定期复核节奏对齐，每季度抽取一定比例的条目，覆盖高风险场景和近期发生变更的条目。比对方法包括：调取工具使用记录或访问日志，与清单登记的工具和数据范围对照；访谈使用人，确认其了解当前版本的使用边界；抽查输出物，判断是否存在超出边界的用法。
发现偏差后按以下闭环处理：记录偏差事实与涉及条目；由场景负责人判断是清单滞后还是使用违规；清单滞后则走变更流程补正，使用违规则暂停相关用法并通知使用人；整改完成后再次抽样验证同一问题是否消除；将偏差类型、整改措施和再验证结果记入整改记录。检查结果按周期向治理负责人汇报，汇报内容包括抽查覆盖率、偏差数量与类型、整改完成率、仍待处理事项，便于治理负责人判断机制运行状态并调整复核周期或审批层级。
完成检查：清单维护机制可以交付的标志
判断机制是否落地，可逐项核对以下条件，全部满足即可认为清单维护机制进入可运转状态。
- 字段完整、责任到人：每条生效条目均填写最小字段集，责任人与审批人为具体人员，无空缺；复核日期均为未来日期或已按流程完成复核。
- 变更可追溯：每次条目变更都能找到对应的申请记录、审批意见、版本号和生效时间；旧版本可查，未被直接覆盖。
- 检查问题已闭环：最近一次抽样检查发现的偏差均有整改记录和再验证结论，无长期挂起事项。
- 通知有记录：每次发布均有通知范围与通知方式记录，使用人可确认已知悉当前版本。
机制暂不成熟时，可采用最小可行起点：先覆盖高风险场景，只维护最小字段集，定期复核按季度执行，检查以条目自查加少量抽查为主。待运行一至两个周期、变更流程顺畅后，再扩展字段、缩短周期或增加抽查比例。起点可以小，但字段、触发条件、责任人三项不能缺，否则清单会重新退化为一次性文档。
常见问题
清单条目按人登记还是按使用场景登记，团队规模变化时怎么处理？
按使用场景登记更利于长期维护。一条记录对应一个可审核的业务动作，人员变动时只需更新责任人字段，场景本身保持稳定；按人登记容易出现同一场景多人重复登记、责任边界模糊。团队规模扩大后，同一场景下不同团队使用不同工具时，可拆成多条记录，但每条仍需独立的责任人与审批人。
定期复核还没到期，但工具版本升级了，应该先走哪个流程？
先按事件触发流程完成审核，再在审核结论中顺延或重置复核日期，避免同一周期内重复审核。如果升级导致使用边界需要调整，可先暂停该条目，待审核通过后恢复生效并重新计算复核日期。事件触发优先于定期复核，是为了让清单在重大变化发生时及时跟上。
审核角色退回变更申请时，需要写明哪些内容才算可追溯？
退回记录应包含退回理由、涉及的清单编号、需要补充的信息，以及退回人和退回时间。常见退回情形包括数据范围明显扩大但未说明用途、工具来源不明、使用边界与制度冲突。退回理由写清楚，场景负责人补充后重新提交时，检查环节才能判断这次变更是否已按审核意见处理。
抽样检查发现使用人用了未登记的工具，应该改清单还是处理使用行为？
先由场景负责人判断偏差性质：属于清单滞后，就走变更流程补正，把新工具纳入审核；属于使用违规，则暂停相关用法并通知使用人，必要时补充使用边界说明。两类处理完成后都要再次抽样验证同一问题是否消除，并把偏差类型、整改措施和再验证结果记入整改记录。
机制刚起步、人手有限，清单维护可以从哪里开始？
可以先覆盖高风险场景，只维护最小字段集，定期复核按季度执行，检查以条目自查加少量抽查为主。运行一至两个周期、变更流程顺畅后，再扩展字段、缩短周期或增加抽查比例。起点可以小，但字段、触发条件、责任人三项需要保留，否则清单容易退回为一次性文档。
