研发AI权限设置的核心，是把“谁能用、能用哪些数据、能做什么动作、留下什么记录”四件事分开定义。先按岗位和项目角色划分AI使用层级，再按数据敏感度划定可输入范围，然后按动作风险设定审批与人工复核要求，最后用日志、抽查和定期复核形成闭环。落地时从一份权限矩阵和一份数据分级表起步，先在单个研发场景试点，再扩展到代码、需求、测试等环节。AI使用申请与使用记录可以依托ONES的工作项与文档流程承载，本文围绕这套机制的维度、步骤、分工、示例与检查展开。
要点总览（TL;DR）
- 研发AI权限设置拆成角色、数据、动作、记录四个维度，每个维度回答一个独立问题，再组合成可执行规则。
- 实施顺序为盘点场景与数据对象、制定角色分层与数据分级表、定义动作审批与复核点、配置工具侧权限、试点运行并收集记录。
- 规则维护需要研发管理者、安全或合规角色、团队负责人、研发人员、平台管理员分工协作，各自交付可交接的文档与记录。
- 权限矩阵按“角色×数据级别”和“动作类型×确认要求”两张表填写，示例团队可直接参照迁移。
- 上线前用角色覆盖、数据分级一致性、高风险复核、日志可查询、定期复核与越权处置六项检查逐条核对通过标准。
研发AI权限先定哪四类边界
把AI权限笼统写成“控制使用”，执行时会出现两种偏差：要么所有人都被同一套规则限制，影响正常研发效率；要么只靠口头约定，敏感数据和高风险动作无人把关。可行的做法是把权限拆成四个维度，每个维度回答一个独立问题，再组合成具体规则。
| 维度 | 要回答的问题 | 典型划分方式 | 产出物 |
|---|---|---|---|
| 角色 | 谁可以使用AI，可以使用到什么程度 | 按岗位（普通研发、技术负责人、测试、外部协作人员）或按项目角色分层 | 角色分层表 |
| 数据 | 哪些研发数据可以输入AI | 按敏感度分为公开、内部、敏感三档，分别对应可用、限制使用、禁止输入 | 数据分级表与敏感数据清单 |
| 动作 | AI输出可以直接落地，还是必须人工确认 | 按动作风险分为直接采用、人工复核后采用、禁止自动执行 | 动作审批规则与复核点清单 |
| 记录 | 使用过程留下什么痕迹，能否追溯 | 记录使用者、使用场景、输入数据类别、输出用途与确认人 | 使用日志字段定义与留存要求 |
四个维度需要组合使用。角色决定基础权限，数据分级决定输入边界，动作规则决定输出如何落地，记录维度保证前三条可以被检查和追责。只做角色分层而不做数据分级，普通研发仍可能把敏感代码贴进外部工具；只做数据分级而不做动作规则，AI生成的代码或文档可能未经确认就进入交付物。
边界定义还要写清适用范围。例如规则覆盖哪些AI工具、哪些项目、哪些数据存储位置，是否包含个人自行注册的外部服务。范围写得越具体，后续配置工具权限和检查越容易执行。
按步骤搭建AI使用权限：从分级到上线
权限机制适合按“先盘点、再定规则、后配置、再试点”的顺序推进。每一步都明确输入、动作、输出和完成标志，便于直接排入项目计划。
第一步：盘点研发场景与涉及的数据对象
输入是团队当前的研发流程和AI使用现状。动作包括列出正在使用或计划使用AI的环节（代码补全与评审、需求文档撰写、测试用例生成、日志分析等），并标注每个环节涉及的代码仓库、需求文档、测试数据、生产日志等数据对象。输出是一张“场景—数据对象”对照表。完成标志是每个AI使用场景都能对应到具体数据类别，且没有遗漏已在私下使用的工具。
第二步：制定角色分层与数据分级表
输入是第一步的场景清单和公司已有的数据分类要求。动作是确定角色层级（如普通研发、技术负责人、外部协作人员），并为每类数据标注敏感级别及对应的AI使用规则。输出是角色分层表和数据分级表。完成标志是任意一个“角色×数据级别”组合都能查到明确结论：可用、需审批或禁止。
第三步：定义动作审批规则与人工复核点
输入是场景清单中AI输出的实际用途。动作是按风险给动作分类：代码建议进入合并请求前需人工评审，需求文档生成后需负责人确认，涉及生产数据的分析结果需双人复核，直接修改生产配置或执行脚本类动作禁止由AI自动完成。输出是动作规则清单，标明每个复核点的确认人和确认方式。完成标志是每个高风险动作都有对应的人工确认环节，且确认人明确到角色。
第四步：配置工具侧权限与访问控制
输入是前三步形成的规则表。动作是在AI工具和管理平台中落实账号分组、数据访问范围、审批流和日志开关，把纸面规则转成系统配置。输出是配置记录和账号权限清单。完成标志是新加入的研发人员按角色自动获得对应权限，敏感数据访问需要额外授权，日志可以正常采集。
第五步：试点运行并收集使用记录
输入是配置完成的权限环境和选定的试点团队。动作是选择一个研发场景运行两到四周，收集使用日志、审批记录和用户反馈，识别规则过严或过松的地方。输出是试点报告和规则修订建议。完成标志是试点期内所有AI使用都有记录可查，发现的越权或规则空白已完成修订，并明确推广到其他场景的时间点。
角色分工与交付物：谁定规则、谁执行、谁复核
AI权限规则失效，常见原因是规则由一个人临时编写，后续无人维护。把职责分配到具体角色，并为每个角色定义可交接的交付物，规则才能持续运转。
| 角色 | 主要职责 | 交付物 | 交接对象 |
|---|---|---|---|
| 研发管理者 | 确定AI使用范围和审批层级，批准高风险场景 | AI使用范围说明、审批层级表 | 安全或合规角色、团队负责人 |
| 安全或合规角色 | 制定数据分级标准，维护敏感数据清单，处理越权事件 | 数据分级表、敏感数据清单、事件处置记录 | 平台管理员、研发管理者 |
| 项目或团队负责人 | 把团队规范落到具体项目和人员，确认本团队复核点 | 团队AI使用规范、复核人名单 | 研发人员、平台管理员 |
| 研发人员 | 按规范选择可用工具和数据范围，完成必要记录与确认 | 使用记录、复核确认记录 | 团队负责人 |
| 平台或工具管理员 | 配置账号与权限、维护访问控制、保障日志可查询 | 账号权限清单、配置变更记录、日志查询入口 | 安全或合规角色 |
交接关系需要固定节奏。数据分级表更新后，平台管理员应在约定时间内同步调整访问控制；团队负责人发现新的使用场景，应提交给研发管理者判断是否需要新增审批层级；安全角色定期抽查日志，把发现的问题反馈给团队负责人整改。规则文档本身也要指定维护人，避免多个版本并存。
在研发管理平台上，这套分工可以借助工作项和文档流程承载：AI工具开通或数据访问申请以工作项提交，按审批层级流转；使用规范和分级表以文档形式发布并保留版本；复核确认记录挂在对应需求或代码变更上，便于后续追溯。ONES支持工作项流转、文档协作与操作记录留存，可作为承载申请、审批与记录的流程载体，具体配置方式按团队现有流程设计。
示例：一个研发团队的AI权限矩阵怎么填
以下为一个包含代码、需求文档和测试数据的研发团队示例，用于说明矩阵的填写方式，实际规则需结合团队情况调整。
场景设定：团队约二十人，使用AI辅助代码补全、需求文档初稿撰写和测试数据分析，涉及内部代码仓库、需求管理文档、脱敏测试数据和少量生产日志。
角色分层：普通研发、技术负责人、外部协作人员三类。普通研发可使用经批准的AI工具处理内部数据；技术负责人额外拥有敏感数据使用的审批权；外部协作人员仅可使用公开数据和已脱敏材料。
| 数据级别 | 示例数据 | 普通研发 | 技术负责人 | 外部协作人员 |
|---|---|---|---|---|
| 公开 | 已发布文档、开源代码 | 可直接使用 | 可直接使用 | 可直接使用 |
| 内部 | 内部代码、需求文档、脱敏测试数据 | 可使用，需记录使用场景 | 可使用 | 禁止输入 |
| 敏感 | 未脱敏生产日志、客户数据、密钥配置 | 禁止输入 | 经审批后限定场景使用 | 禁止输入 |
| 动作类型 | 确认要求 | 确认人 |
|---|---|---|
| 代码建议 | 进入合并请求前人工评审，AI生成部分需标注 | 代码评审人 |
| 需求文档生成 | 负责人确认内容准确后发布 | 需求负责人 |
| 测试数据分析 | 基于脱敏数据；涉及敏感数据需审批并双人复核 | 技术负责人与复核人 |
| 脚本或配置修改 | 禁止AI自动执行，人工编写并走变更流程 | 变更审批人 |
矩阵填写完成后，团队的使用效果体现在三个方面：新成员按角色即可查到自己的可用范围，减少逐次询问；敏感数据输入有明确禁止项和审批通道，而不是一律禁止使用AI；代码和文档的AI参与部分有确认记录，评审时可以追溯。边界说明也要写进矩阵：矩阵只覆盖已登记的AI工具，个人自行注册的外部服务不在授权范围内；审批通过不代表可以扩大数据范围，每次使用仍需符合对应数据级别。
上线前如何检查AI权限设置是否到位
权限机制是否可以投入使用，用一份检查清单逐项核对，每项给出通过标准，避免凭感觉判断。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 角色与账号覆盖 | 对照团队人员名单核对AI工具账号和角色分组 | 全部AI使用人员都有对应角色，离职和转岗账号已处理 |
| 数据分级一致性 | 数据分级表与敏感数据清单逐条比对 | 清单中每类数据都能在分级表中找到级别和AI使用规则 |
| 高风险动作复核 | 抽查动作规则清单中的高风险项 | 每项都有明确复核人和确认方式，且已在流程中配置 |
| 日志可查询 | 实际查询一次近期使用记录 | 能查到使用者、场景、数据类别和确认记录，留存期限符合要求 |
| 定期复核与回收 | 检查是否设定复核周期和权限回收规则 | 有固定复核时间点，项目结束或角色变更时权限可及时收回 |
| 越权处置路径 | 确认发现越权使用后的上报和处理流程 | 上报对象、处置时限和记录要求明确，团队负责人知晓 |
检查中发现的问题按影响程度处理：账号缺失或敏感数据规则空白属于上线前必须解决的问题；日志字段不完整可以在试点期补齐，但需设定完成时间。检查结果和建议整改项一并记录，作为下一轮复核的对照依据。上线后保持定期抽查，把使用记录、审批记录和规则版本放在同一处管理，权限治理才能随研发场景变化持续更新。
常见问题
团队规模较小，是否也需要完整的角色分层和数据分级表？
规模较小的团队可以简化层级，但两类表仍建议保留。角色可以合并为“研发人员”和“负责人”两层，数据分级至少区分公开、内部、敏感三档，并写明每档对应的AI使用规则。这样做的目的是让新成员和外部协作人员能查到明确结论，减少逐次口头确认。规则条目可以少，但“角色×数据级别”的组合结论要完整。
研发人员自行注册的外部AI工具，权限规则应该怎么处理？
建议在规则中明确授权工具清单，并说明清单之外的工具不在授权范围内。对于确有需要使用的外部服务，可以设置申请通道：由研发人员提交使用场景和数据范围，团队负责人或安全角色判断是否批准，批准后纳入清单并补充对应的数据使用限制。这样既保留灵活性，也避免敏感数据通过未登记渠道流出。
数据分级表和敏感数据清单由谁维护，更新后如何同步到权限配置？
通常由安全或合规角色维护数据分级标准和敏感数据清单，平台或工具管理员负责把变更落到账号分组和访问控制上。两者之间需要约定同步时限，例如清单更新后在固定工作日内完成配置调整。团队负责人发现新的数据对象或使用场景时，提交给安全角色判断级别，再进入配置环节。规则文档指定唯一维护人，避免多个版本并存。
试点期发现规则过严影响研发效率，应该调整哪一部分？
先定位是哪个维度造成阻碍。如果是角色分层过粗，可以按项目角色细分使用范围；如果是数据分级把常用材料划得过高，可以复核分级依据，对已脱敏或已发布材料重新定级；如果是动作复核点过多，可以按输出用途区分，只对进入交付物的内容保留人工确认。调整后同步更新矩阵和配置，并记录修订原因，便于下一轮复核对照。
上线检查发现日志字段不完整，是否必须先补齐才能推广？
可以分情况处理。账号缺失或敏感数据规则空白属于上线前必须解决的问题；日志字段不完整可以在试点期补齐，但需要设定完成时间和责任人。补齐期间应保证至少能查到使用者、使用场景和数据类别，满足基本追溯要求。检查结果与整改项一并记录，作为下一轮复核的对照依据。
