企业用AI工具前先梳理哪些权限
企业上线 AI 工具前，应先梳理人员角色、资料分级、应用连接、动作边界、输出去向、日志审计和例外审批。
很多企业开始用 AI 工具时，第一反应是选模型、选套餐、选插件、选谁先试用。销售团队想接 CRM，市场团队想接素材库，研发团队想接代码仓库，行政和财务想接文档与表格。大家都希望 AI 能更快找到资料、更快生成内容、更快完成流程。
更容易出问题的，往往不是工具会不会回答，而是它能看到什么、能调用什么、能替谁行动、结果会留下在哪里。
AI 工具和普通 SaaS 不一样。普通 SaaS 多数时候只是把数据展示给人看，或者让人点一个按钮。AI 工具会读取上下文、整合多处资料、生成新内容，还可能通过连接器、应用、API、MCP 工具或自动化流程执行动作。它不只是一个新页面，而是一个新的“信息入口”和“行动入口”。
所以，企业上线 AI 工具前，不能只问“这个工具好不好用”。更应该先问：哪些人能用？能连哪些系统？能读哪些资料？能执行哪些动作？输出能发到哪里？日志保留多久？谁来审批例外？出错后如何追踪？
这篇文章给企业团队一个实用的权限盘点框架。它不是法律意见，也不是某个产品的配置手册，而是一种上线前可以拿来开会、做表、分工和审查的检查方式。
为什么 AI 工具上线前要先盘权限
权限盘点听起来像 IT 或安全团队的工作，但 AI 工具会把它变成业务团队也必须理解的问题。
NIST 对身份与访问管理的描述很朴素：让正确的人和事物，在正确的时间，对正确的资源拥有正确的访问。企业过去做权限管理，多数围绕账号、系统、角色、文件夹、审批和审计。AI 工具进入后，这些对象没有消失，只是多了一层：模型会把原本分散的访问能力汇总到一个对话框、一个 Agent 或一个自动化流程里。
如果一个员工原本能看 A 系统、B 文档和 C 表格，AI 连接后可能帮他把这些资料整合成一份报告。这本身不一定违规，但它改变了信息被发现、组合、复制和外发的速度。Microsoft Purview 文档也指出，生成式 AI 会放大数据过度共享和泄露风险，因为 AI 可以更主动、更快速地呈现内容。
这就是权限盘点的价值：不是阻止大家使用 AI，而是在使用前知道边界在哪里。
权限不只是“谁能登录”
很多团队把权限理解成“谁有账号”。这太窄了。
企业 AI 工具至少涉及六类权限。
第一，身份权限：谁能进入 AI 工作区，谁是管理员，谁能创建 Agent，谁能添加连接器或应用。
第二，资料权限：AI 可以读取哪些文档、表格、邮件、知识库、代码、工单、客户记录和内部页面。
第三，应用权限：AI 可以连接哪些 SaaS、数据库、文件系统、日历、消息工具、代码仓库和自动化平台。
第四，动作权限：AI 只能读，还是能写入、修改、删除、发布、发送、下单、审批、导出。
第五，输出权限：AI 生成的内容能发到哪里，能不能复制到外部工具，能不能进入公开页面，能不能用于客户沟通。
第六，治理权限：谁能看日志，谁能审计，谁能调整留存策略，谁能批准例外，谁负责暂停问题工具。
只梳理登录账号，会漏掉后面五类。风险经常发生在“能读得太多”“能做得太多”“输出走得太远”“日志没人看”。
先画一张“人、资料、工具、动作”关系图
权限盘点可以从一张关系图开始。
横向写团队角色：普通成员、主管、管理员、外包协作者、系统服务账号、Agent 构建者、审稿人、审计人。
纵向写资源类型：公开资料、内部文档、客户资料、财务资料、研发代码、合同法务、员工信息、运营后台、发布系统。
再加一列动作：读取、搜索、汇总、下载、写入、修改、删除、发送、公开发布、调用外部 API。
最后给每个格子填三种状态：允许、需审批、禁止。
这个表看起来很普通，却能暴露很多问题。比如市场团队可以搜索素材库，但不能读取合同；客服可以查客户工单，但不能批量导出完整客户表；内容团队可以生成公开文案草稿，但不能让 Agent 自动发布；研发 Agent 可以读文档和代码片段，但不能把私有代码发到不受控的外部工具。
AI 权限盘点的第一步，不是立刻配置后台，而是把这张关系图画出来。没有图，后面的配置容易变成谁声音大谁先开权限。
第二步：给资料做分级
资料没有分级，AI 权限就很难说清楚。因为“公司资料”这个词太宽了。
可以先用五层分类：
第一层，公开资料。官网、公开说明书、公开招聘信息、公开新闻稿、公开产品手册。这些资料适合成为 AI 的默认知识来源。
第二层，内部通用资料。制度流程、项目模板、培训材料、非敏感会议纪要。它们能减少查找和整理时间，但仍应限制在公司账号内使用。
第三层，部门限制资料。销售报价策略、运营数据、未发布活动、内部复盘、供应商清单。这类资料应按团队和角色开放。
第四层，敏感资料。客户个人信息、员工信息、合同、财务、账号权限、生产密钥、未公开代码、并购和战略资料。这类资料默认不应进入普通 AI 连接范围。
第五层，受监管资料。医疗、金融、教育、未成年人、跨境数据、行业合规要求相关内容。是否能用于 AI 工具，要看组织政策、合同条款、地区法规和供应商承诺。
Google Workspace 的文档提到，Drive 分类标签可以作为文件的描述性元数据，用于数据保护、审计调查和留存；Google 也提供 AI classification 辅助给 Drive 文件自动打标签。无论使用哪家平台，思路都类似：先知道资料属于哪一层，才能决定 AI 能不能碰。
第三步：盘连接器、应用和 OAuth 范围
企业 AI 工具越来越依赖连接器或应用。OpenAI 企业隐私说明提到，应用可以让 ChatGPT 从连接的内部来源和第三方应用发送与检索信息；管理员可以控制哪些应用可用，用户需要先在对应应用中认证。OpenAI Help 文档还提到，企业和教育工作区中应用默认关闭，管理员可以通过 RBAC 控制哪些角色能访问应用，并对支持 Action control 的应用设置允许动作。
这说明企业不能只说“允许接 Google Drive”或“允许接 SharePoint”。应该继续问：
- 接的是全部空间，还是指定文件夹；
- 是每个用户按自己的权限读取，还是集中授权；
- 是只读，还是可以写入和执行动作；
- 新增动作是否默认关闭；
- 是否需要管理员重新审查；
- 是否有日志和合规导出；
- 连接的数据是否会进入索引；
- 索引和日志位于哪个区域；
- 用户离职后授权如何撤销。
Microsoft Entra 文档对 OAuth 范围的解释也很适合做参考：权限可以把资源功能拆成更小的集合，应用应只请求完成工作所需的权限；某些高权限范围需要管理员批准。Entra 的企业应用权限文档还说明，管理员可以查看已授予应用的权限，并撤销组织级或用户级授权。
换成业务语言就是：别只看工具名字，要看它要了哪些权限。
第四步：把“读取”和“行动”分开
AI 工具最容易混淆的，是读取权限和行动权限。
读取权限是看资料、搜索资料、总结资料。行动权限是发邮件、改字段、创建工单、发布内容、删除文件、授权账号、提交表单、调用外部系统。
两者风险不同。一个客服 Agent 能读取某个客户工单，和它能自动给客户发送补偿方案，不是同一件事。一个内容 Agent 能读取产品资料并生成草稿，和它能直接发布到官网，也不是同一件事。
建议把行动权限分成四层：
- 只读：搜索、浏览、总结、引用；
- 低影响写入：创建草稿、填写测试环境表单、给内部记录加标签；
- 需审批动作：发送邮件、发布内容、修改客户记录、导出资料；
- 禁止动作：删除重要数据、变更权限、批量外发敏感内容、无人确认的财务或法律提交。
这样做的好处是，AI 可以先成为“资料助手”和“草稿助手”，而不是一上来就成为“无人操作员”。
第五步：确定管理员、构建者和审计人的边界
AI 工具上线后，常见的管理角色至少有四种。
管理员负责工作区、账号、应用、日志、留存和全局策略。
构建者负责创建 GPT、Agent、工作流、提示模板、知识库和工具调用。
业务负责人负责判断某个场景是否值得上线、数据是否合适、输出是否能用于真实业务。
审计人负责抽查日志、检查异常、复盘事故、维护权限清单。
这些角色不能混成一个人。尤其是构建者，不应该默认拥有所有数据和所有动作权限。一个会写提示词的人，不等于有权连接全公司资料。一个能做自动化的人，也不等于能批准自动发布、批量导出或修改客户资料。
OpenAI 应用管理文档提到，RBAC 控制谁能使用应用，Action control 控制应用能做什么，App permissions 决定何时向成员询问。这个分层很值得借鉴：谁能用、能做什么、什么时候要问，这三件事要分开。
第六步：决定日志、留存和可追溯方式
没有日志，AI 权限就很难治理。
企业至少要知道：
- 谁在什么时候用了哪个 AI 工具；
- 连接了哪些应用或资料源；
- 发起了哪些工具调用；
- 是否读取了敏感资料；
- 是否执行了写入或外发动作；
- 输出进入了哪个系统；
- 哪些动作经过了人审；
- 哪些异常被暂停或撤销；
- 日志保留多久；
- 谁有权查看日志。
OpenAI 企业隐私说明提到，企业工作区管理员可以访问对话和 GPT 的 audit log；OpenAI Help 文档也说明，应用调用会作为合规日志记录。Microsoft Purview 则提供面向 AI 使用的数据安全与合规控制，帮助发现、保护并应用合规控制。
这类能力的实现方式会因供应商不同而不同，但盘点时的方向一致：AI 不应该成为不可追踪的黑箱。至少在企业场景里，重要动作要能回看，异常结果要能定位，授权变化要能追溯。
第七步：设置例外审批，而不是靠口头承诺
权限表做完后，总会遇到例外。
比如某个项目临时需要让 AI 读取一批客户访谈；某个团队想接入代码仓库；某个部门想用 AI 生成面向客户的邮件；某个高管希望把多个系统的信息汇总到个人知识库。
例外不是不能有，但要有审批字段：
- 申请人是谁；
- 场景是什么；
- 需要哪些资料；
- 需要哪些动作；
- 涉及哪些用户或客户；
- 使用期限多久；
- 是否需要脱敏；
- 是否需要人审；
- 由谁批准；
- 到期后如何关闭；
- 发生问题由谁负责复盘。
没有例外机制，权限治理容易走向两个极端：要么所有人都绕路，要么所有权限越开越大。写清例外审批，反而能让 AI 工具更快进入真实工作。
常见误区一：把供应商承诺当成本公司权限设计
很多 AI 产品都会说明自己的安全、隐私和合规能力。这些说明很重要，但它们不能替代企业自己的权限设计。
供应商可以说明数据是否用于训练、是否支持加密、是否支持 SSO、是否支持日志、是否有数据保留策略、是否能限制连接应用。企业仍然要决定：哪些部门能用，哪些资料能连，哪些动作能开，哪些输出能外发，哪些场景要人审。
OpenAI 企业隐私说明提到，企业客户拥有并控制业务数据，默认不使用业务数据训练模型，管理员可控制内部来源连接和访问。Google Workspace 说明 Gemini 会应用组织现有控制和数据处理实践，并按用户已有权限检索内容。这些都是重要前提，但如果组织内部原本就把资料权限开得过宽，AI 仍可能更快地暴露过度共享问题。
所以，上 AI 前要顺手检查旧权限。AI 工具有时不是制造风险，而是把原来就存在的权限松散问题照得更清楚。
常见误区二：只管输入，不管输出
企业常常强调“不要把敏感信息输入 AI”，这当然重要。但输出同样要管。
AI 输出可能包含：
- 对内部资料的总结；
- 对客户数据的重新组织；
- 从多个系统合成的判断；
- 带有业务策略的文案；
- 可被外部误读的结论；
- 未经确认的数据引用；
- 可以暴露内部结构的信息。
如果只管输入，不管输出，结果可能是员工没有复制原始文档，却把 AI 总结后的敏感内容发到了外部邮件、公开网页或客户聊天里。
权限盘点要把输出目的地写清楚：内部草稿、团队知识库、客户沟通、公开发布、外部协作、自动化系统。越靠外，越需要人审和证据。
一个可落地的最小权限表
企业可以从一个很小的表开始，不需要一上来做成复杂系统。
每个 AI 场景至少记录十二个字段：
1. 场景名称； 2. 业务负责人； 3. 使用团队； 4. AI 工具或工作区； 5. 连接的资料源； 6. 资料分级； 7. 使用角色； 8. 读取范围； 9. 允许动作； 10. 禁止动作； 11. 人审节点； 12. 日志与留存方式。
再加上三个运维字段：上线日期、复查日期、例外审批编号。
这张表不花哨，却能解决很多争论。业务团队能看到自己要什么，IT 能知道要开哪些权限，安全和法务能看到哪些地方需要审查，审计人能知道以后查哪里。
上线前的十个问题
准备开通 AI 工具前，可以让项目负责人逐项回答：
- 这个 AI 工具服务的是哪个具体场景；
- 使用者是否按角色分组；
- 是否启用 SSO、MFA 和离职回收；
- 连接器或应用是否默认关闭再逐个启用；
- 每个连接器要了哪些读取和行动权限；
- 资料是否分级，敏感资料是否默认排除；
- 是否限制输出去向；
- 高影响动作是否有人审；
- 日志、合规导出和留存策略是否明确；
- 是否设定 30 天或 60 天后复查权限。
如果这些问题回答不出来，说明不是工具不能用，而是还没到可控使用的状态。
结论：先梳权限，AI 才能进入日常工作
企业用 AI 工具，最怕两种状态。一种是因为担心风险，什么都不开，员工只好各自找外部工具。另一种是为了效率什么都开，结果谁能读什么、能发什么、能做什么都说不清。
更稳的做法是先盘点权限，再分层开放。
把人、资料、应用、动作、输出、日志和例外审批梳理清楚，AI 工具就不再只是一个“好用的新玩具”，而是可以被管理、被复查、被审计、被持续改进的团队能力。权限不是 AI 落地的阻碍，它是 AI 能进入企业日常工作的前提。