AI操作授权要解决的是：团队用AI处理数据、调用模型、执行动作时，权限边界清楚、审批有据、事后可查。本文按“操作清单—风险分级—审批授权—留痕复核”四步展开，给出可直接填写的表格与检查项，并在授权申请与审批环节说明ONES可承载的管理动作。
要点总览（TL;DR）
- AI操作授权从一份操作清单开始：把数据输入、模型调用、结果输出与执行拆成可命名、可归属、可判断影响的具体动作，再逐条分级。
- 分级看数据敏感度、操作可逆性、影响范围三个维度，按就高原则定为L1至L4，级别决定审批强度。
- 审批配置要写清谁批、走什么路径、批多久：L1备案使用，L2团队负责人授权，L3数据责任人与安全审核人确认，L4逐次审批且单次有效。
- 留痕记录操作人、时间、操作对象、授权依据与结果，复核按级别设定频率，发现超范围操作先暂停授权再评估处置。
- 机制可用的判断标准是清单、分级、审批、留痕四类证据齐备并能相互对应，之后按季度复核结果调整清单与分级。
先定授权对象：把AI操作拆成可管理的动作清单
授权机制失效，常见原因是授权对象太粗，例如只写“允许使用AI助手”。这种表述无法判断具体风险，也无法在事后核对。第一步是把AI使用拆成一条条可命名、可归属、可判断影响的操作，形成清单，后续分级和审批都以清单条目为单位。
三类操作对象
盘点时按数据输入、模型调用、结果输出与执行三类分别梳理，避免遗漏发生在AI之外的环节。
- 数据输入：把需求文档、代码片段、测试数据、客户反馈、会议记录等提交给AI。风险集中在数据是否含敏感信息、是否超出授权范围。
- 模型调用：选择模型、配置提示词、调用外部接口或MCP服务、启用插件。风险集中在调用对象是否合规、是否把数据带出受控环境。
- 结果输出与执行：AI生成的内容被写入文档、创建或修改工作项、发送通知、触发自动化动作。风险集中在错误结果是否直接进入业务流程、动作是否可撤回。
清单字段
每条操作至少记录以下字段，字段设计要让审批人只看一行就能判断风险。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 操作名称 | 动词开头，指向具体动作 | 将客户访谈记录提交AI做摘要 |
| 涉及数据 | 数据类别与敏感级别 | 客户访谈记录，含客户名称与联系方式 |
| 执行角色 | 实际发起操作的角色 | 产品经理、客户成功 |
| 影响范围 | 结果流向哪里、影响多少人 | 摘要写入内部Wiki，供项目组查阅 |
| 可逆性 | 操作能否撤回或纠正 | 可编辑、可删除，原始记录保留 |
| 现有控制 | 已有的权限或流程约束 | Wiki页面按项目组授权访问 |
从现有场景盘点
盘点以“人—工具—数据—产出”为线索，逐个团队收集，避免只由安全团队闭门编写。可执行的做法是：先让各团队列出近一个月实际发生的AI使用场景，再合并同类项，最后对照三类操作对象检查是否有遗漏。盘点完成的标志是：每个在用的AI场景都能对应到清单中的至少一条操作，且每条操作都有明确的执行角色和数据范围。清单建议每季度更新一次，新工具或新场景上线前先补条目再开放使用。
按风险分级：AI操作授权的四级划分与判定标准
分级的作用是让授权强度与风险匹配：低风险操作减少审批负担，高风险操作增加审核环节。分级不看工具名称，只看这一次操作对数据、业务和外部的影响。
三个分级维度
- 数据敏感度：公开数据、内部一般数据、敏感业务数据、个人敏感信息与客户机密，逐级升高。
- 操作可逆性：可随时撤回或纠正、需人工确认后生效、一经执行难以撤回，逐级升高。
- 影响范围：仅影响本人、影响单个项目组、影响跨团队或对外交付，逐级升高。
四级划分与动作要求
| 级别 | 典型特征 | 授权强度 |
|---|---|---|
| L1 日常辅助 | 公开或内部一般数据，结果仅供本人参考，可逆 | 纳入清单即可使用，按团队规范执行，无需逐次审批 |
| L2 受控使用 | 涉及内部业务数据，结果进入团队文档或工作项，可编辑 | 团队负责人一次性授权，限定数据范围与使用场景 |
| L3 敏感操作 | 涉及敏感业务数据或客户信息，结果影响跨团队协作 | 逐次或按批次申请，数据责任人与安全审核人共同确认 |
| L4 高风险执行 | 涉及客户机密、个人敏感信息，或AI直接触发对外动作、批量修改 | 逐次审批，最小审批链包含数据责任人、安全合规审核人与业务审批人，执行前留档 |
边界判定与升级
三个维度结论不一致时按就高原则处理：只要有一项落在更高级别，整条操作按更高级别授权。典型边界情况包括：数据本身是内部数据，但AI输出会发给客户，按影响范围升级；操作可撤回，但批量执行后纠错成本高，按可逆性升级；不确定数据是否含个人信息时，先按敏感数据处理，核实后再降级。降级需要记录理由和核实人，不能由使用人自行判断。
配置审批与授权：角色分工、审批路径与授权时效
分级确定后，需要回答三个问题：谁批、走什么路径、批多久。授权配置的目标是让每条操作都有明确的责任人，同时避免所有操作都挤到同一个审批人。
角色分工
- AI使用人：发起申请，说明操作内容、数据范围和预期产出，对实际执行与结果负责。
- 数据责任人：判断所涉数据能否用于该场景，确认数据范围与使用边界。
- 安全或合规审核人：检查调用方式、外部服务使用、个人信息处理是否符合团队规定。
- 审批人：通常是业务或团队负责人，对操作的必要性和业务影响做最终判断。
小团队可以一人兼多个角色，但申请人与最终审批人应分开，避免自批自用。
分级审批矩阵
| 操作级别 | 申请人 | 最小审批链 | 授权时效 |
|---|---|---|---|
| L1 | 使用人 | 无需逐次审批，团队规范备案 | 随清单有效期，季度复核 |
| L2 | 使用人 | 团队负责人 | 建议按项目周期或不超过一个季度 |
| L3 | 使用人 | 数据责任人 → 安全或合规审核人 | 按批次授权，单批次完成后失效 |
| L4 | 使用人 | 数据责任人 → 安全或合规审核人 → 业务审批人 | 单次有效，执行完成即失效 |
授权范围与到期处理
每条授权写明四项限定：可用数据范围、可用工具或模型、可执行的动作边界、有效期。到期后授权自动失效，继续使用需重新申请；项目提前结束时由使用人主动注销。授权变更（扩大数据范围、增加执行动作）按原级别重新审批，不能沿用旧授权。审批记录与授权结论应保存在可检索的位置，便于执行时核对和复核时取证。在ONES中，这类申请可以作为工作项提交，审批意见、授权范围和有效期随工作项流转并保留记录，使授权结论与后续执行在同一处可查。
留痕与复核：操作日志、审计记录与定期检查
授权是事前控制，留痕与复核负责验证授权是否被按约定执行。留痕要能回答“谁在什么时候、依据哪条授权、对什么对象做了什么、结果如何”，复核则按固定节奏检查这些记录。
留痕字段
| 字段 | 记录内容 | 用途 |
|---|---|---|
| 操作人 | 账号与所属团队 | 定位责任人 |
| 操作时间 | 发起与完成时间 | 核对授权有效期 |
| 操作对象 | 数据范围、文档、工作项或系统 | 判断是否超出授权范围 |
| 授权依据 | 授权编号或审批记录链接 | 证明操作有据 |
| 操作内容与结果 | 调用的模型或工具、输入摘要、输出去向 | 支持问题追溯 |
| 异常标记 | 失败、超范围、人工纠正 | 进入复核重点 |
保存与查阅
日志集中存放，按团队和操作级别可筛选；访问权限限定在使用人本人、审批人和复核人范围内。保存期限与团队现有审计要求保持一致，涉及客户数据或个人信息的操作适当延长。查阅方式应支持按授权编号反查全部关联操作，这是复核时最常用的入口。
定期复核
复核频率建议：L1与L2按季度抽查，L3按月检查，L4在每次执行后即时检查。检查项包括：授权是否在有效期内、实际操作是否超出授权范围、异常标记是否已处理、到期授权是否已注销。发现超范围操作时，先暂停相关授权，由数据责任人与安全审核人评估影响，补充审批或收回权限，并在复核记录中写明处置结果。复核结论作为下一轮授权调整的依据。
示例：一次高风险AI操作的完整授权流程
以下为演示情景，用于说明各环节的动作与产出，不代表任何具体团队的实际案例。
场景设定：客户成功团队希望把一批客户工单记录提交AI，生成问题归类摘要，并写入共享Wiki供产品团队参考。工单记录含客户名称与联系人信息。
分级判定
数据涉及客户信息，属敏感数据；摘要写入共享Wiki后影响跨团队，影响范围较大；内容可编辑但已对外可见，纠错需要时间。三项中两项指向较高级别，按就高原则定为L4，走逐次审批。
申请与审批
- 使用人提交申请：操作名称、工单批次范围、使用的AI工具、输出写入位置、预计完成时间。
- 数据责任人确认：工单数据可用于内部分析，要求去除联系人字段后再提交。
- 安全或合规审核人确认：调用方式不将数据用于外部留存，输出页面访问范围限定为产品与客户成功团队。
- 业务审批人确认：摘要用于季度产品改进，批准本次执行。
- 产出：一条带授权编号的审批记录，写明数据范围、工具、输出位置和单次有效期。
执行与留痕
使用人按批准范围提交数据，记录操作时间、数据批次、工具名称和输出页面链接，关联授权编号。执行中发现部分工单含未脱敏的联系方式，立即停止提交，删除已生成内容，并在记录中标记异常。
复核与处置
复核人检查该授权下的操作记录，确认异常已处理、输出页面访问范围符合审批要求。处置结果为：本次授权执行完毕即失效；数据责任人补充“提交前脱敏检查”作为该类操作的前置步骤，下一批次申请时一并执行。复核记录归档，作为后续同类申请的参考。
完成检查：AI操作授权机制是否可用的验收项
机制是否可用，不看制度文档写得多完整，而看清单、分级、审批、留痕四类证据是否齐备并能相互对应。以下检查项可逐条核对。
| 类别 | 检查项 | 通过标准与证据 |
|---|---|---|
| 清单 | 在用AI场景是否全部入册 | 每个场景对应清单条目，字段填写完整；证据为最新版操作清单与场景对照表 |
| 清单 | 新增场景是否有补充流程 | 新工具或新用法上线前先补条目；证据为近期的清单变更记录 |
| 分级 | 每条操作是否有明确级别 | 级别有判定依据，边界情况有升级记录；证据为分级表与判定说明 |
| 分级 | 级别与授权强度是否一致 | 抽查若干条操作，审批链与时效符合矩阵；证据为审批记录 |
| 审批 | 授权是否写明范围与有效期 | 每条授权含数据范围、工具、动作边界、有效期；证据为授权记录 |
| 审批 | 到期与变更是否处理 | 到期授权已失效或续期，变更按原级别重审；证据为授权台账 |
| 留痕 | 关键字段是否完整 | 操作人、时间、对象、授权依据、结果可查；证据为日志样本 |
| 留痕 | 复核是否按频率执行 | 有复核记录、异常处置结论和后续改进动作；证据为复核清单 |
常见缺口与补正方向
- 清单停留在工具层面：只列了用了哪些AI工具，没有拆到具体操作。补正方向是按数据输入、模型调用、结果执行三类重新拆分。
- 分级靠感觉：同一类操作在不同团队级别不一致。补正方向是统一三个维度的判定口径，并保留边界升级记录。
- 授权没有期限：一次审批长期有效，人员或项目变化后仍在使用。补正方向是为每条授权设定有效期并建立到期提醒。
- 留痕与授权脱节：日志里查不到对应的审批记录。补正方向是要求操作记录关联授权编号，复核时按编号反查。
四类检查全部通过，且抽查记录能相互印证，即可认为机制进入运行状态；此后按季度复核结果调整清单与分级，保持授权强度与实际风险匹配。
常见问题
团队规模较小，审批角色可以合并吗？
可以合并，但要保留一条底线：申请人与最终审批人分开，避免自批自用。小团队常见的做法是团队负责人同时承担数据责任人和业务审批人的判断，安全或合规审核由上级或职能接口人兼任。角色合并后，审批矩阵仍按操作级别填写，只是同一人出现在多个环节，复核时更容易发现授权是否被滥用。
AI工具本身有权限设置，还需要单独做操作授权吗？
需要，两者管的不是同一件事。工具权限决定谁能登录、能访问哪些功能；操作授权决定某一次具体操作是否被允许，包括数据范围、执行动作和有效期。工具权限通常较粗，无法覆盖“同一批数据这次能不能提交给AI”“生成结果能不能写入共享文档”这类判断。实际操作中，工具权限作为基础控制，操作授权作为场景控制，两者配合使用。
授权到期后仍在执行的任务怎么处理？
到期即失效，继续执行需要重新申请。对于跨周期的任务，建议在申请时按任务阶段拆成多次授权，或在授权记录中写明分阶段的有效期。到期前由使用人确认任务是否延续，延续则按原级别重新审批；任务已结束则由使用人主动注销授权。复核时把“到期未注销”列为检查项，能减少长期挂账的授权。
复核发现超范围操作，第一步做什么？
先暂停相关授权，阻止影响继续扩大，再由数据责任人与安全审核人评估影响范围，判断是否需要通知相关方或采取补救措施。处置完成后，在复核记录中写明超范围的具体情形、原因和处置结果，并据此调整授权范围或补充前置检查步骤。复核结论要进入下一轮授权调整，避免同类问题重复出现。
操作清单多久更新一次比较合适？
建议每季度随复核一起更新，同时保留触发式更新：新工具上线、新场景启用、数据范围变化时，先补清单条目再开放使用。更新内容包括新增操作、删除已停用的操作、修正数据范围和执行角色。清单版本要可追溯，便于复核时对照当时生效的条目判断操作是否在授权范围内。
