AI使用责任清单用于登记一次AI使用从发起到退出的责任安排，解决“谁批准、谁复核、记录留在哪里”难以追溯的问题。它适合研发团队在引入代码助手、文档总结、知识问答等工具时逐项登记，也适合作为季度复查的依据。下文提供可直接复制的空白表格、字段判断口径、必填分级、完整填写示例和维护方法，团队可结合自身合规要求与数据敏感级别调整。
要点总览（TL;DR）
- 清单以“一条AI使用场景一条记录”为粒度，核心列包括使用场景与工具、数据范围与敏感级别、发起人、责任人、审批人及结论、使用边界、输出复核方式、留痕位置、复查周期和退出条件。
- 填写顺序为：先登记场景与数据级别，再明确发起、责任、审批、复核四类角色，最后约定使用边界、留痕位置与复查退出安排，避免责任集中在一名使用人身上。
- 使用场景与工具、数据范围与敏感级别、发起人、责任人、审批人及结论、使用边界、留痕位置、复查周期为必填项，缺失时审批环节应阻断；退出条件、备注与关联链接可先登记待定，在首次复查时补齐。
- 清单需要配套版本号、更新日期与维护人，按团队规模裁剪列而不削减必填判断逻辑，并在迭代回顾或季度治理例会上执行复查与退出确认。
可复制空白模板：AI使用责任清单表
清单以“一条AI使用场景一条记录”为粒度。同一工具用于不同场景、不同数据范围时，应分别登记，避免一条记录混合多种责任。下表为空白模板，复制到文档或表格工具后即可填写。
| 序号 | 使用场景与工具 | 数据范围与敏感级别 | 发起人 | 责任人 | 审批人及结论 | 使用边界与禁止事项 | 输出复核方式 | 留痕位置 | 复查周期 | 退出条件 |
|---|---|---|---|---|---|---|---|---|---|---|
两种填写方式按团队规模选择。单条记录方式适合场景少、参与人固定的团队：每个场景单独一份表，表头写明场景名称，审批与复查记录直接附在表后。多条记录方式适合工具多、跨项目使用的团队：用一张总表登记全部场景，序号与场景名称作为索引，审批意见、复查结论等过程材料按序号归档到对应目录。两种方式共用同一套列名，便于后续汇总和审计。
表格之外建议保留三项配套信息：清单版本号、最后更新日期、维护人。它们不占列，写在表头或文档属性中，用于判断手上这份清单是否为最新版本。
字段说明：每一列登记什么、怎么判断
同一份清单会被发起人、审批人、复核人分别填写，字段口径不统一会导致责任无法追溯。以下逐列说明登记内容与判断依据。
使用场景与工具
写法为“动作＋对象＋工具”，例如“用代码助手生成单元测试”“用文档助手总结需求评审纪要”。只写工具名称不足以判断风险，因为同一工具在不同场景下的数据暴露面差别很大。一个场景对应一条记录，场景发生变化时新增记录，不覆盖原记录。
数据范围与敏感级别
数据范围写清输入AI的内容边界，例如“公开文档”“内部需求文档”“含客户信息的工单”。敏感级别按团队既有分级填写，常见做法分为公开、内部、机密三级；团队没有现成分级时，可先按“是否含个人信息、是否含客户数据、是否含未发布产品信息”三个问题判断，任一为“是”即按较高一级处理。级别判断由数据所有者确认，发起人自评后仍需责任人复核。
发起人、责任人、审批人、复核人
四类角色职责不同，不能合并为“使用人”一人。发起人提出使用需求并完成初始登记；责任人对该场景的合规使用负最终责任，通常是场景所属业务或研发负责人；审批人依据数据级别和场景风险给出同意、附条件同意或不同意；复核人检查输出质量与使用边界执行情况，可由同组资深成员或质量角色担任。审批人与复核人可以是同一人，但责任人不宜同时担任审批人，以避免自我批准。
使用边界与禁止事项
用可执行的表述写清“可以做什么、不得做什么”。例如“仅可输入已脱敏日志片段；不得输入完整客户合同原文；生成内容须标注为AI辅助并经人工修改后提交”。避免写“注意数据安全”这类无法核验的表述。禁止事项应与数据敏感级别对应，级别越高，禁止项越具体。
留痕位置与复查周期
留痕位置写清审批记录、使用记录和复核结论存放在哪里，例如“需求管理系统对应工作项的附件”“团队知识库的治理目录”。位置要具体到可被他人找到的层级。复查周期按场景风险设定，高风险场景按月或按迭代复查，低风险场景可按季度复查；周期一经确定应写入清单，复查完成后记录日期与结论。
必填与选填：哪些字段缺失就不能放行
清单的放行判断依据字段完整性。必填字段缺失时，审批环节应阻断，不进入实际使用；选填字段缺失不影响放行，但需在复查时补齐或说明。
| 字段 | 分级 | 缺失时的处理 |
|---|---|---|
| 使用场景与工具 | 必填 | 阻断，无法判断风险范围 |
| 数据范围与敏感级别 | 必填 | 阻断，级别未定不得使用 |
| 发起人 | 必填 | 阻断，记录无来源 |
| 责任人 | 必填 | 阻断，责任无归属 |
| 审批人及结论 | 必填 | 阻断，未审批不得使用 |
| 使用边界与禁止事项 | 必填 | 阻断，缺少可执行约束 |
| 留痕位置 | 必填 | 阻断，过程无法追溯 |
| 输出复核方式 | 必填（涉及对外交付或客户数据时） | 该情形下阻断；纯内部草稿场景可先登记复核人，方式在首次使用前补齐 |
| 复查周期 | 必填 | 阻断，无法安排后续检查 |
| 退出条件 | 选填 | 可先写“待定”，在首次复查时确定 |
| 备注与关联链接 | 选填 | 不影响放行 |
选填字段的适用情形需要说明。退出条件在场景刚启用时往往难以准确预判，允许先登记“待定”，但首次复查必须给出明确条件，例如“工具供应商变更数据处理条款”“场景数据级别上调至机密”。备注与关联链接用于补充审批单号、工具账号归属等信息，便于追溯，不作为放行门槛。
字段缺失时的处理遵循“先补后审”原则：发起人补齐必填项后重新提交，审批人只对完整记录给出结论。审批结论为“附条件同意”时，条件本身应写入使用边界列，作为后续复核的检查项。
填写示例：一条完整的AI使用责任记录
以下示例为演示情景，用于说明各字段如何对应，团队实际填写时应替换为真实场景与角色。
| 字段 | 填写内容 |
|---|---|
| 使用场景与工具 | 用代码助手为订单服务模块生成单元测试初稿 |
| 数据范围与敏感级别 | 输入为已脱敏的接口定义与函数签名，不含客户数据；敏感级别：内部 |
| 发起人 | 订单服务模块开发成员A |
| 责任人 | 订单服务模块负责人B |
| 审批人及结论 | 研发经理C；结论：附条件同意，条件为生成用例须经人工审查后合入 |
| 使用边界与禁止事项 | 仅可输入脱敏代码片段；不得输入生产配置、密钥与客户订单数据；生成用例须标注AI辅助并人工修改 |
| 输出复核方式 | 由模块内另一名开发成员进行代码评审，重点检查断言逻辑与边界用例覆盖 |
| 留痕位置 | 需求管理系统对应工作项附件，存放审批记录与评审意见 |
| 复查周期 | 每迭代复查一次，随迭代回顾会执行 |
| 退出条件 | 工具供应商变更数据处理条款，或场景需输入含客户数据的代码时重新审批 |
逐项对应来看：场景写法包含动作、对象和工具，可直接判断风险范围；数据级别为“内部”，因此禁止事项聚焦生产配置与客户数据；审批结论为附条件同意，条件被写入使用边界列，成为复核检查项；复核方式指定了具体角色和检查重点，复查周期与团队迭代节奏一致。这条记录满足全部必填字段，可以放行。
示例也体现了一个常见安排：责任人B与审批人C为不同角色，复核由模块内其他成员承担。这样责任、批准、检查分布在三个位置，出现问题时能定位到具体环节。
调整与维护：按团队规模裁剪字段并定期复查
清单需要随团队和场景变化调整，否则会退化为一次性文档。裁剪和维护围绕三件事展开：字段取舍、版本记录、复查执行。
按团队与场景裁剪字段
小团队场景单一、参与人少，可将发起人与责任人合并登记为“发起与责任”，但审批人仍需独立；跨项目使用多、审计要求高的团队，建议在模板中增加“关联项目”“工具账号归属”两列，便于按项目汇总。场景风险普遍较低时，复查周期可统一为季度；存在客户数据或对外交付的场景，应保留逐迭代复查。裁剪只减少列，不减少必填判断逻辑：被合并的角色仍需在记录中可识别。
版本与变更记录
每次调整列名、必填分级或审批规则时，更新版本号并在表头记录变更日期、变更内容和批准人。历史记录保留原版本字段值，不随新版本回填，避免追溯时口径混乱。变更记录本身放在清单文档首页或独立目录，与记录数据分开存放。
复查与退出条件的维护
复查按清单登记的周期执行，复查人核对三项内容：使用边界是否被遵守、数据级别是否发生变化、退出条件是否已触发。触发退出条件时，记录退出日期与原因，并将该条记录状态标记为“已退出”，保留历史供审计。长期未触发退出的场景，也应在复查时确认条件是否仍然有效。
与研发平台权限治理的边界
责任清单登记的是“谁对这次AI使用负责、依据什么批准、记录在哪里”，账号权限、数据访问控制、工具接入审批属于平台权限治理的范围，两者配合但不互相替代。清单中的留痕位置可以指向研发管理工具中的工作项或知识库页面，审批结论与复核意见随工作项流转，便于在项目上下文中追溯。以ONES为例，其AI能力在ONES权限体系内进行知识问答和任务执行，输出过程可追踪、结果可审计，团队可将清单记录与对应工作项关联，使审批和复查结论落在同一处；清单字段本身仍由团队按自身治理要求定义。
维护节奏建议与团队现有管理动作对齐：迭代回顾时检查高风险场景记录，季度治理例会上汇总清单整体状态并决定是否调整字段。清单维护人负责版本更新与复查提醒，责任人负责本场景记录内容的准确性，两者分工写入表头，避免维护责任悬空。
常见问题
团队刚开始使用这份清单，字段可以只填一部分吗？
可以分阶段推进，但放行判断仍以必填项完整为准。建议第一轮只登记必填字段，把退出条件、备注与关联链接留待首次复查补齐。如果团队场景较少，也可以先选一个高风险场景试填，跑通审批与留痕流程后再扩展到其他场景。需要提醒的是，数据范围与敏感级别、审批人及结论两项在试填阶段同样不能省略，否则记录无法支撑后续追溯。
责任人、审批人、复核人由同一人担任是否可行？
小团队中复核人与审批人由同一人担任较为常见，但责任人不宜同时担任审批人，否则会形成自我批准。更稳妥的做法是让责任人承担场景合规的最终责任，审批人由上一级负责人或治理角色担任，复核人可由同组资深成员承担。人员确实紧张时，至少保证审批环节有独立于发起人的角色参与，并在清单备注中说明角色兼任情况，便于复查时识别。
清单登记后，审批记录和复查结论放在哪里比较合适？
留痕位置要具体到他人可以找到的层级，例如研发管理工具中对应工作项的附件、团队知识库的治理目录。把审批结论、复核意见与工作项关联，可以让记录随项目上下文流转，复查时不必跨多个系统查找。以ONES为例，其AI能力在ONES权限体系内进行知识问答和任务执行，输出过程可追踪、结果可审计，团队可将清单记录与对应工作项关联，使审批和复查结论落在同一处；清单字段本身仍由团队按自身治理要求定义。
工具升级或使用场景变化后，原记录需要修改吗？
建议新增记录而非覆盖原记录。场景发生变化，例如输入数据从脱敏片段变为含客户信息的工单，或工具供应商调整了数据处理条款，都属于需要重新判断风险的情形，应新增一条记录并注明与原记录的关系。原记录保留历史状态，标记为“已退出”或“已被替代”，并写明变更日期与原因。这样在审计或复查时能看清责任安排的演变过程。
这份清单与研发平台的账号权限管理是什么关系？
清单登记的是“谁对这次AI使用负责、依据什么批准、记录在哪里”，账号权限、数据访问控制、工具接入审批属于平台权限治理的范围，两者配合但不互相替代。清单不能替代权限配置，权限系统也不会自动生成责任归属。实际操作中，可让清单中的留痕位置指向权限申请单或工作项，使审批链路连贯；清单维护人定期与平台权限管理员核对场景清单，确认已退出场景的账号权限同步回收。
