企业系统为什么需要可审计事事要留痕这句话在很多企业里被当成口头禅背后的原因不只是管理习惯而是实际的业务需要。一笔采购单被批了三个月之后出了问题需要追溯当时谁批的、基于什么数据批的、审批链路是什么。一个客户投诉说报价有问题需要查当时系统给出这个报价的依据。一次库存盘点发现数据对不上需要回溯每一笔出入库记录。这些场景里能追溯不是锦上添花是基本要求。很多行业有明确的合规要求金融、医疗、制造业的质量管理都有相关法规规定操作记录必须保存多久、能否被篡改。现在把AI接进来让AI去做这些操作同样的要求还在AI做了什么必须有记录记录必须完整能够被查。但现有的大多数AI Agent方案在这件事上几乎是空白的。三个不可控我自己做过一个实验用一个主流的Agent框架接了公司内部的几个API让它帮我完成一个涉及多步骤的数据处理任务。任务完成了结果是对的。但当我试图回答它具体做了什么的时候我能拿到的只有框架自带的日志记录了每次LLM调用的输入输出以及API网关的访问日志记录了哪些接口被调用了。这两份日志是分开的没有关联。我知道模型输出了调用接口A的意图也知道接口A被调用了但这两件事在日志里是两条独立的记录中间的执行过程不透明。如果中间出了问题我需要手动把两份日志对上还不一定对得准。这是行为不可控不知道AI实际执行了什么执行的顺序是什么中间做了哪些判断。权限问题更直接。企业系统里的权限通常是基于角色的不同的人能看到不同的数据、能做不同的操作。这个逻辑在人机交互的场景里运转得很好因为用户登录之后系统知道这是谁每个请求都带着身份信息。但Agent在调用接口的时候它的身份是什么很多实现方式是给Agent配一个服务账号这个账号有固定的权限。问题是这个权限往往比实际需要的要宽——因为你不知道Agent会被用来完成什么任务所以倾向于给宽一点以免任务失败。结果是一个普通员工触发了一个Agent任务这个任务在执行过程中可能访问了这个员工本人根本没有权限访问的数据。这是权限不可控AI的实际执行权限和触发它的用户的权限是脱钩的。第三个问题是流程不可控也就是审计缺失。即使你有行为日志也有权限控制还差一件事这些记录是否足够完整足够可信能够支撑事后的追溯一条日志记录了Agent调用了接口X参数是Y返回了Z但没有记录这次调用是由哪个用户的哪个会话触发的在整个任务链路中处于第几步上下文是什么。脱离了上下文的日志在审计的时候很难用。更大的问题是如果Agent有能力写文件、调接口、执行脚本这些操作的日志分散在不同的地方没有一个统一的审计链路。出了问题你能知道发生了什么但可能需要花几个小时把各处的日志拼起来。准确性和可管理性指向同一个根因把上一篇和这一篇放在一起看会发现两类问题有一个共同的特征AI在操作企业系统的时候它的行为缺少约束。上一篇说的准确性问题根源是AI不知道你的系统里每个概念的具体含义只能靠猜猜出来的结果有时候在业务上是错的。这一篇说的可管理性问题根源是AI的执行过程没有被纳入企业已有的权限体系和审计体系它的行为游离在管控之外。两个问题的解法在工程上也指向同一个方向在AI和业务系统之间需要一个中间层这个中间层既能告诉AI系统里有什么、每个东西是什么含义也能在AI执行操作的时候把权限校验和审计记录接进来。这不是一个全新的概念。企业软件里早就有类似的东西叫语义层Semantic Layer或者服务总线ESB做的事情是在系统和使用方之间建立一层翻译和控制。只是过去这一层是给人或者传统软件用的现在需要让它也能服务于AI。
企业系统为什么需要可审计事事要留痕这句话在很多企业里被当成口头禅背后的原因不只是管理习惯而是实际的业务需要。一笔采购单被批了三个月之后出了问题需要追溯当时谁批的、基于什么数据批的、审批链路是什么。一个客户投诉说报价有问题需要查当时系统给出这个报价的依据。一次库存盘点发现数据对不上需要回溯每一笔出入库记录。这些场景里能追溯不是锦上添花是基本要求。很多行业有明确的合规要求金融、医疗、制造业的质量管理都有相关法规规定操作记录必须保存多久、能否被篡改。现在把AI接进来让AI去做这些操作同样的要求还在AI做了什么必须有记录记录必须完整能够被查。但现有的大多数AI Agent方案在这件事上几乎是空白的。三个不可控我自己做过一个实验用一个主流的Agent框架接了公司内部的几个API让它帮我完成一个涉及多步骤的数据处理任务。任务完成了结果是对的。但当我试图回答它具体做了什么的时候我能拿到的只有框架自带的日志记录了每次LLM调用的输入输出以及API网关的访问日志记录了哪些接口被调用了。这两份日志是分开的没有关联。我知道模型输出了调用接口A的意图也知道接口A被调用了但这两件事在日志里是两条独立的记录中间的执行过程不透明。如果中间出了问题我需要手动把两份日志对上还不一定对得准。这是行为不可控不知道AI实际执行了什么执行的顺序是什么中间做了哪些判断。权限问题更直接。企业系统里的权限通常是基于角色的不同的人能看到不同的数据、能做不同的操作。这个逻辑在人机交互的场景里运转得很好因为用户登录之后系统知道这是谁每个请求都带着身份信息。但Agent在调用接口的时候它的身份是什么很多实现方式是给Agent配一个服务账号这个账号有固定的权限。问题是这个权限往往比实际需要的要宽——因为你不知道Agent会被用来完成什么任务所以倾向于给宽一点以免任务失败。结果是一个普通员工触发了一个Agent任务这个任务在执行过程中可能访问了这个员工本人根本没有权限访问的数据。这是权限不可控AI的实际执行权限和触发它的用户的权限是脱钩的。第三个问题是流程不可控也就是审计缺失。即使你有行为日志也有权限控制还差一件事这些记录是否足够完整足够可信能够支撑事后的追溯一条日志记录了Agent调用了接口X参数是Y返回了Z但没有记录这次调用是由哪个用户的哪个会话触发的在整个任务链路中处于第几步上下文是什么。脱离了上下文的日志在审计的时候很难用。更大的问题是如果Agent有能力写文件、调接口、执行脚本这些操作的日志分散在不同的地方没有一个统一的审计链路。出了问题你能知道发生了什么但可能需要花几个小时把各处的日志拼起来。准确性和可管理性指向同一个根因把上一篇和这一篇放在一起看会发现两类问题有一个共同的特征AI在操作企业系统的时候它的行为缺少约束。上一篇说的准确性问题根源是AI不知道你的系统里每个概念的具体含义只能靠猜猜出来的结果有时候在业务上是错的。这一篇说的可管理性问题根源是AI的执行过程没有被纳入企业已有的权限体系和审计体系它的行为游离在管控之外。两个问题的解法在工程上也指向同一个方向在AI和业务系统之间需要一个中间层这个中间层既能告诉AI系统里有什么、每个东西是什么含义也能在AI执行操作的时候把权限校验和审计记录接进来。这不是一个全新的概念。企业软件里早就有类似的东西叫语义层Semantic Layer或者服务总线ESB做的事情是在系统和使用方之间建立一层翻译和控制。只是过去这一层是给人或者传统软件用的现在需要让它也能服务于AI。
