研发AI权限要管住四件事：谁能用、能用哪些数据、能做什么动作、留下什么记录。落地时按“定范围→分等级→配角色→设审批→留记录→做复核”推进，每一步都有明确负责人和可检查的产出。本文聚焦AI使用治理，全平台账号权限体系与模型训练数据治理不在讨论范围内；审批与复核环节会说明ONES如何依托既有权限体系承载流程记录。
要点总览（TL;DR）
- 研发AI权限要拆成四类对象管理：使用者身份、可用模型与工具、可访问数据范围、可执行动作，AI权限依附于研发平台已有账号体系。
- 按数据敏感度、使用场景、输出用途划分AI使用等级，等级表经安全负责人与研发负责人共同确认后作为配置依据。
- 用角色权限矩阵把等级落到人：研发使用者、项目负责人、安全/合规负责人、平台管理员各司其职，申请人与审批人分离。
- 申请、审批、开通、回收四段都要留记录，三者信息一致才能形成可追溯的证据链。
- 上线前逐项核对权限对象清单、等级表、角色矩阵、审批流程与留痕机制，阻断项缺失不得开放使用。
研发AI权限要管住哪四类对象
把“开放AI”拆成可配置的对象，是治理能够落地的前提。笼统地给一个团队开通AI工具，后续既无法判断谁在用、用了什么数据，也无法在出现问题时收窄范围。建议从四个维度建立权限对象清单，每个维度都对应到可配置、可检查的项。
| 权限对象 | 要回答的问题 | 可配置项示例 |
|---|---|---|
| 使用者身份 | 谁在使用AI | 员工账号、所属团队、岗位角色、在职状态 |
| 可用模型与工具 | 能用哪些AI能力 | 编码辅助、文档问答、知识检索、智能助手 |
| 可访问数据范围 | AI能读到哪些数据 | 公开资料、内部文档库、指定项目空间、代码仓库、受限数据集 |
| 可执行动作 | 能对数据做什么 | 提问问答、生成代码、上传文件、调用接口、写入工作项 |
这四类对象中，身份是基础。AI权限依附于研发平台已有的账号体系，不另建一套AI专用账号。这样人员转岗、离职时，账号状态变化能直接反映到AI权限上，避免出现“人已离岗、AI权限仍在”的盲区。模型与工具、数据范围、可执行动作则作为挂在身份上的授权项，按需组合。
范围清单的产出形式建议是一张表：每一行是一个权限对象，列出可配置项、当前取值来源（来自账号体系还是单独配置）、维护责任人。这张表不需要很细，但要能让管理员照着它去配置，让审计人员照着它去核对。需要说明的是，本文讨论的是AI使用侧的授权，全平台的角色权限设计、模型训练数据的采集与脱敏属于另外的治理议题，不在本文展开。
第一步：按数据敏感度划分AI使用等级
分级的作用是给权限配置一个统一依据，避免每次开通都靠个案判断。分级主要看三个维度：数据敏感度（AI会接触什么级别的数据）、使用场景（在什么工作中使用）、输出用途（生成内容去向哪里）。三个维度共同决定等级，单看数据敏感度容易漏掉“低敏数据、高风险输出”的情况。
| 等级 | 典型场景 | 默认允许 | 需审批事项 |
|---|---|---|---|
| L1 公开资料问答 | 查询公开技术文档、通用知识问答 | 全员可用，无需单独申请 | 无 |
| L2 内部文档辅助 | 内部规范、流程文档的总结与问答 | 本团队成员可用本团队文档 | 跨团队文档访问 |
| L3 代码库上下文 | AI编码辅助、基于仓库上下文的代码生成 | 项目成员可用所属项目代码 | 访问其他项目代码、生成代码合入主干 |
| L4 受限数据 | 涉及客户数据、未公开方案、安全敏感信息 | 默认不开放 | 逐次申请，限定数据范围与期限 |
分级的输入是组织已有的数据分类结果。如果数据分类尚未建立，可以先按“公开、内部、受限”三档做粗分，再随数据治理推进细化，不必等分类体系完备才开始。分级的输出是一张AI使用等级表，写清每级的定义、典型场景、默认允许范围和审批要求。
完成标志是等级表经安全负责人与研发负责人共同确认。确认动作本身很重要：它意味着后续配置有了共同认可的依据，出现争议时可以回到这张表，而不是每次重新讨论。等级表还应标注版本和确认日期，数据分类调整时同步更新。
第二步：角色与权限的对应关系怎么配
等级表回答“什么级别”，角色矩阵回答“谁来配、谁来批”。建议划分四类角色，每类角色的授予范围和审批职责分开写清楚。
| 角色 | 权限授予范围 | 审批职责 |
|---|---|---|
| 研发使用者 | 按所属团队和项目获得L1至L3的默认权限 | 无审批职责，按需提交申请 |
| 项目负责人 | 本项目的AI使用范围管理 | 审批本项目内的L2、L3申请 |
| 安全/合规负责人 | 等级表维护、异常处置决策 | 审批L4申请，复核异常处置 |
| 平台管理员 | 按矩阵执行配置与回收 | 无审批权，负责开通登记与到期提醒 |
角色与等级的映射要落到“角色×等级×可执行动作”这一粒度。同样是L3，项目负责人可以批准本项目成员读取代码上下文，但“生成代码合入主干”这类动作应单独列出，由更高一级或额外审批确认。映射表的作用是让管理员配置时有据可依，也让申请人在提交前就知道自己大概能拿到什么。
职责分离是这一环节的硬要求：申请人与审批人不能是同一人，平台管理员不参与审批。这样设计的目的在于让每一次开通都经过一次独立判断，而不是由同一个人既提需求又放行。产出物是角色权限矩阵，矩阵需与等级表交叉核对，确保每个等级都有对应的审批角色，没有出现无人审批的空白等级。
第三步：申请、审批与开通的操作流程
流程设计的目标是让每次开通都可追溯。整条链路分四段，每段说清输入、动作和输出。
申请。申请人填写用途、涉及的数据范围、使用期限和期望的AI能力。用途要写到具体工作任务，例如“为某项目提供编码辅助”，而不是“工作需要”。数据范围要指明项目空间或文档库，期限默认不超过一个项目周期。
审批。按申请等级走对应审批人：L2、L3由项目负责人审批，L4由安全/合规负责人审批。审批意见需记录同意理由或附加限制条件，例如“同意，仅限本项目仓库，期限三个月”。审批记录是后续复核的输入。
开通。平台管理员按角色权限矩阵配置，登记开通记录，包括开通时间、授权项、期限和对应审批单号。开通记录与审批记录要能互相对应，形成一条完整的证据链。
变更与回收。到期前由管理员提醒，到期未续则自动回收；人员转岗时由账号状态变化触发权限调整；项目结束时由项目负责人发起回收。回收动作同样要登记，形成“开通—变更—回收”的完整记录。
在ONES中，这类申请与审批可以依托工作项和文档流程承载：申请单作为工作项流转，审批意见和开通记录附在同一个工作项上，到期提醒和回收状态也在其中更新。ONES AI研发管理方案基于ONES权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，这为开通记录与使用记录之间的对应提供了基础。具体可配置的授权项和流程模板，建议在选型或部署时向厂商确认。
完成标志是每一次开通都能找到对应的申请单、审批意见和开通登记，三者信息一致。可以用抽查的方式验证：随机抽取若干开通记录，回溯其申请与审批是否齐全。
使用留痕与定期复核怎么做
权限发放之后，治理进入运行期。留痕解决“发生了什么”，复核解决“是否仍然合理”。
留痕内容至少包括：使用人、使用时间、涉及的数据范围、关键操作类型（问答、生成、上传、写入）。留痕的目的在于支撑复核和异常追溯，字段设计以够用为准，不必追求全量记录。留痕的查询权限也应限定，由安全/合规负责人和平台管理员按职责查看。
复核建议按固定周期进行，例如每季度一次，由安全/合规负责人牵头，项目负责人配合。复核内容对照三张表：等级表是否仍适用、角色矩阵中的授权是否与实际使用一致、开通记录中是否存在到期未回收的权限。复核人应独立于日常开通操作，避免自己核对自己。
| 复核发现 | 处置动作 | 记录要求 |
|---|---|---|
| 权限超出实际需要 | 降级至匹配等级 | 记录降级依据与新等级 |
| 使用范围与申请不符 | 暂停权限，核实后恢复或回收 | 记录异常事实与处理结论 |
| 人员转岗或项目结束 | 回收权限 | 记录回收时间与操作人 |
| 到期未续且仍在使用 | 立即回收，重新走申请 | 记录超期事实与整改情况 |
异常处置要有闭环：发现、处置、整改跟踪三步都留记录，整改完成后由复核人确认关闭。完成标志是复核有记录、异常有闭环，且下一次复核能查到上一次异常的处理结果。ONES的输出过程可追踪、结果可审计这一特性，可以作为留痕与复核记录的承载基础，具体日志字段与保留期限需结合部署形态确认。
示例：一个研发团队的AI权限落地过程
以下为一个演示情景，用于说明各步骤如何衔接，不代表任何特定企业的真实实施结果。
某研发团队计划引入AI编码辅助和内部文档问答。团队约三十人，分为三个项目组，已有统一的研发平台账号和数据分类（公开、内部、受限三档）。
定范围。团队先列出权限对象清单：身份沿用平台账号；可用能力限定为编码辅助和文档问答两项；数据范围按项目空间划分；可执行动作限定为问答、生成代码建议、读取项目文档，暂不开放接口调用。清单由平台管理员维护。
分等级。对照数据分类，团队定出三级：L1公开资料问答全员可用；L2内部文档问答限本团队文档；L3代码库上下文限本项目仓库。受限数据暂不开放，留待后续评估。等级表经安全负责人和研发负责人确认后发布。
配角色。项目负责人审批本项目的L2、L3申请；安全负责人保留L4审批权和异常处置权；平台管理员负责配置与登记，不参与审批。矩阵中特别注明“生成代码合入主干”需项目负责人额外确认。
走审批。一名后端工程师申请L3权限用于某项目编码辅助，填写用途、项目仓库和三个月期限。项目负责人审批同意并注明仅限该项目仓库。管理员按矩阵开通并登记，关联审批单号。
做复核。季度复核时发现该工程师已转入另一项目，原项目权限未回收。复核人按处置路径回收权限，记录转岗事实，并提醒新项目负责人按需重新申请。整改完成后复核人确认关闭。
这个情景可迁移的规律有三条：分级不必等数据分类完备，粗分三档即可启动；审批与开通分离，让每次开通经过独立判断；复核要对照人员与项目的实际变化，而不是只看权限列表。适用边界在于，团队规模、数据分类成熟度和AI能力范围不同，等级数量和审批层级需相应调整，不宜直接照搬。
上线前的完成检查
开放使用前，逐项核对以下内容。每项都有通过标准和责任人，缺失阻断项的不得开放。
| 检查项 | 通过标准 | 责任人 | 是否阻断 |
|---|---|---|---|
| 权限对象清单 | 四类对象齐全，每项有可配置项和维护人 | 平台管理员 | 是 |
| AI使用等级表 | 等级定义、允许范围、审批要求完整，经双方负责人确认 | 安全负责人 | 是 |
| 角色权限矩阵 | 角色×等级×动作映射完整，无空白等级，职责分离落实 | 研发负责人 | 是 |
| 申请审批流程 | 申请、审批、开通、回收四段均有记录模板 | 平台管理员 | 是 |
| 留痕机制 | 留痕字段确定，查询权限已限定 | 安全负责人 | 是 |
| 复核机制 | 复核周期、复核人、异常处置路径明确 | 安全负责人 | 否，但须在上线后一个月内建立 |
阻断项缺失即不能开放使用，尤其是等级表和角色矩阵：没有这两项，开通就失去了判断依据。复核机制可以稍后建立，但要有明确的建立时间点，不能无限期推迟。
上线后的维护要求包括：数据分类调整时同步更新等级表；人员和组织变化时及时调整角色矩阵；每轮复核后回顾流程中的卡点，简化不必要的审批层级。治理机制的价值在于持续运行，而不是一次性文档。建议指定一名治理负责人统筹这些维护动作，并在每次复核时检查机制本身是否仍然适用。
常见问题
团队还没有完成数据分类，能先开始做AI权限分级吗？
可以。分级依赖数据分类结果，但不必等分类体系完备再启动。可以先按“公开、内部、受限”三档做粗分，形成初版等级表并投入使用，后续随数据治理推进再细化等级定义和审批要求。需要注意的是，粗分阶段应把边界不清的数据默认归入更高一档，等分类明确后再调整，避免一开始就把敏感数据放进低等级。
AI权限和研发平台原有账号权限是什么关系，需要单独建账号吗？
不需要另建一套AI专用账号。AI权限依附于研发平台已有的账号体系，模型与工具、数据范围、可执行动作作为挂在身份上的授权项按需组合。这样人员转岗、离职时，账号状态变化能直接反映到AI权限上，减少“人已离岗、权限仍在”的盲区。全平台角色权限体系的设计属于另一项治理工作，本文只讨论AI使用侧的授权。
审批环节一定要做到申请人与审批人分离吗？小团队人手紧张怎么办？
职责分离是审批环节的基本要求，目的是让每次开通经过一次独立判断。小团队人手紧张时，可以按等级区别处理：低等级（如L1）默认开放、不走审批；中等级由项目负责人审批；涉及受限数据的申请由安全/合规负责人审批。审批人可以从团队外或上级指定，不必由本团队成员兼任。平台管理员负责配置与登记，不参与审批，这条边界建议保留。
复核发现权限与实际使用不符，应该先暂停还是先沟通？
按风险程度区分处置。使用范围与申请明显不符、涉及受限数据的，先暂停权限再核实，核实后决定恢复或回收；权限略超出实际需要、未涉及敏感数据的，可以先沟通确认再降级。无论哪种路径，都要记录异常事实、处置动作和处理结论，整改完成后由复核人确认关闭，下一次复核时能查到上一次的处理结果。
ONES 在AI权限治理中能承载哪些环节？
ONES AI研发管理方案基于ONES权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，可以作为开通记录与使用记录对应的基础。申请与审批可以依托工作项和文档流程承载：申请单作为工作项流转，审批意见和开通记录附在同一工作项上，到期提醒和回收状态也在其中更新。具体的AI授权配置项、流程模板和日志字段，建议在选型或部署时向厂商确认。
