AI数字员工进了公司，它的权限谁来管？

多数公司招新员工，常规流程都是这样子的——

• HR给新员工开工号，IT给新员工配电脑，部门经理给新员工划定工作范围。
• 新员工能看什么数据、能批什么文件、能用什么系统，在入职第一天就定好了。

但假设这位员工在三个月后，他离职了，那么HR就会收回工号，IT会注销账号，这位员工的所有系统权限也会同时失效。

然而不同的情况是：当下的一些公司正在跃跃欲试、成群结队的上线“AI数字员工”。这位AI员工它也能查数据、发审批、调系统、写报告。但没有人给它开工号，也没有人给它划权限范围。它离职的那天也不会有人注销它。因为它不是一个真正的“人”。

这就是AI数字员工给企业带来的核心治理问题。

它具备了人的执行能力，却没有人的身份约束。

本文从身份、权限、审计三个层面，讲清楚AI数字员工的权限到底应该怎么管。

一、先给数字员工一个身份

传统企业系统里的操作主体只有两类。

• 一类是人，有工号、有部门、有岗位职责。
• 另一类是系统进程，有固定的触发条件和执行逻辑。

两者的权限管理都有成熟框架。人走RBAC，基于角色的访问控制。进程走服务账号和API鉴权。

AI数字员工不属于这两类。它没有工号，但能代表某个真实的人去执行操作。它不是固定进程，但能自主串联多个系统的能力。

因此，管好AI数字员工的第一步，是给它一个明确的身份。这个身份是挂载式的，不是一个独立的"超级用户"。每一次操作，必须绑定到一个真实的人或一个被授权的系统角色上。它上午在帮张经理查采购数据，就以张经理的身份和数据权限运行。下午帮李总监做销售分析，就以李总监的身份和权限运行。

织信平台的身份绑定机制就是这样设计的。AI数字员工不是一个独立账号，它没有自己的一整套权限。它是当前操作主体的代理。它能看多少数据、能碰哪些功能，完全取决于它挂载的那个人在那一刻的权限范围。

这种设计的核心价值在于，权限边界不需要为AI单独定义一套规则。人有什么权限，AI代理这个人时就有什么权限。不多一个数据表。不多一个字段。不多一条记录。

二、把权限分成六个层级来管

有了身份之后，第二个问题是：权限的范围怎么划定。

传统的系统权限通常只分两级或者三级。普通用户和管理员。或者普通员工、部门经理、系统管理员。这种粗放的分级在AI数字员工进入之后不够用了。因为AI可以跨系统、跨部门、跨数据层级执行任务。一次简单的"帮我分析一下这个季度的销售趋势"，底层可能涉及三个层级的数据访问。

织信平台的权限框架分了六个层级来应对这个复杂度。

第一层，团队级。

不同团队之间的数据默认物理隔离。AI在A团队执行任务时，不会触碰到B团队的数据。

第二层，应用级。

一个团队下面有多个应用。财务部的人能进ERP但进不了CRM。AI代理财务部的人时，同样碰不到CRM里的客户数据。

第三层，模块级。

进了ERP之后，能操作哪些功能模块。能查看采购单数据表，但可能不能操作付款审批流。AI代理的这个人没有付款审批权限，AI就同样点不了那个审批按钮。

第四层，记录级。

同一张客户表里，销售只能看到自己名下的客户记录，部门经理能看到全部门，总监能看到全公司。AI代理销售时查"本月业绩"，返回的就是这个销售名下的数据。

第五层，字段级。

同一条客户记录里，公司名称和联系人字段所有人都能看到。但合同金额字段只有经理以上才能看到。AI生成的报表里如果有合同金额那一列，而当前操作主体无权访问，这一列就不会出现。

第六层，控件级。

页面上每个按钮的显隐和可用性都可以按角色配置。普通员工看不到"导出全部数据"的按钮。AI代理普通员工时，页面上同样没有这个按钮。

六层权限在统一引擎上分层叠加，不是六套独立的规则拼起来的。AI在执行操作的过程中，每一层都在起作用，每一层都在卡位。少一道都不行。

三、每一步操作都必须留痕

身份定了，权限边界划清楚了。第三个问题是，AI做了之后怎么追责。

传统系统的审计日志很简单。谁在几点几分做了什么操作，一条记录就能说清楚。AI数字员工不是这样。它的一次交互背后可能对应十几次底层操作。用户说了一句"帮我把这周的采购单都批掉"，AI在底层可能做了查询采购单列表、逐条校验状态、逐条触发审批流、记录审批结果等一系列动作。只记那一条自然语言指令不够，把每一次底层操作都记下来日志又会爆炸。

织信的做法是三层审计。

第一层，意图日志。

记用户对AI说的每一句自然语言。谁、什么时间、说的什么。出问题时，第一眼看的是谁下达了这条指令。

第二层，操作日志。

记AI在执行过程中实际调用了哪些系统能力。查了哪个数据表、触发了哪个审批、修改了哪条记录。这一层还原的是AI实际做了什么事。

第三层，告警日志。

AI的操作模式偏离常规时自动触发。比如短时间内大量导出数据、在非工作时间发起敏感审批、访问了与当前挂载身份不匹配的数据域。这一层解决的是有什么不对劲。

三层日志通过统一的trace_id串联成一条完整的追溯链路。出了问题，从意图日志定位到原始指令，从操作日志还原执行全过程，从告警日志判断有没有异常行为。整个追溯在织信平台的审计模块中独立完成，不需要跨多个系统去拼接数据。

四、不同人问同一句话，拿到的答案完全不同

以上三层设计叠加在一起，产生了一个在实际使用中非常直观的效果。同一个AI数字员工，不同的人问同一句话，拿到的答案完全不一样。

举个例子。

销售经理问AI"本月团队业绩怎么样"。AI以销售经理的身份运行，继承了经理的权限，查询到的是整个团队的数据汇总。一个一线销售问同样的"本月业绩"，AI以销售的身份运行，只返回这个销售自己名下的数据。财务问同样的"本月业绩"，AI以财务的身份运行，返回的是财务口径的数据汇总。

同一个AI，同一句问话，三种完全不同的输出。

这不是AI自己有自觉，知道对谁说多少话。是底层的六级权限引擎在每条数据通路上强制卡位。AI想访问任何数据，都必须先从权限引擎那儿过一遍。引擎说能看，数据才出得来。引擎说不能，直接拦住。没有一条路可以绕过去。

五、实操：给AI数字员工配权限的四步法

如果你正在织信平台上启用AI数字员工，权限配置可以按下面四步来推进。

第一步，确定AI的角色范围。

在后台权限管理模块中，AI被管理为一个特殊的服务账号。先定义一套最小默认权限。比如仅允许查询基础数据和查看单据，暂不开通导出、修改、删除、审批功能。后续按业务需要再逐步放开。收紧容易，放开也可以控制节奏。一开始就大开大合的配置方式，后面想收回来就难了。

第二步，绑定数据访问规则。

利用平台的六级权限引擎，逐项设定AI的可见范围。按组织架构设，按数据分类设，按字段级别设。常见的配置是AI能查客户基本信息表和跟进记录表，但不能访问合同金额和报价字段。AI的数据查询范围限定在其服务对象所属部门及下级部门。AI不执行跨法人主体的数据对比操作。

第三步，开启三层审计。

为AI启用独立的审计日志通道。意图日志、操作日志、告警日志全部开启。设定告警阈值，比如单日查询超过一千条触发告警、非工作时间发起审批触发告警。告警推送到企业微信或者钉钉，管理员实时掌握AI的运行状态。

第四步，配置人工确认节点。

在高责任场景里，AI不能自己做最终决策。资金支付、合同签署、大额审批、数据批量导出，这些操作必须留一道人工确认。AI可以给建议、可以生成待办、可以做前置分析。但落槌的那一下，必须是人来敲。织信平台支持在流程节点中插入人工确认环节，AI完成前置处理后暂停，等待人工复核通过才继续执行。

结语

AI数字员工进了公司，治理框架要在它上班之前就搭好。

身份，决定了它代表谁干活。权限，决定了它能碰哪些东西。审计，决定了它干完之后能不能追溯。这三样东西缺任何一样，AI数字员工就从一个受控的生产力工具，退化成一个你不知道它在干什么、也说不清出了事谁负责的黑箱。

织信在这三样东西上都给出了具体的产品方案。身份走挂载式绑定，权限走六级分层，审计走三层日志加统一trace_id。企业在这套底座能力之上，可以根据自身的安全策略和合规要求来做具体配置。框架是织信给的，边界是企业自己定的。