2026年8月2日，EU AI Act中针对高风险AI系统的合规义务正式生效。
同一天，国内GB/T 47507-2026《人工智能可信赖通则》进入实施阶段。两套法规，一个共同指向：AI在企业中的应用，从"能用"进入了"能管"的时代。
这不是一个遥远的话题。Forrester在2026年的威胁报告中指出，AI智能体正在成为企业安全边界上最不确定的变量。当一个Agent可以自主查询数据、发起审批、调用API、发送邮件时，"它做了什么"和"能不能对它的行为负责"，比"它能不能做"更为紧要。
织信团队在过去半年和客户的交流中，反复验证了同一个判断：企业对AI的信任，不取决于模型本身有多强，而取决于底座有没有把审计和追溯这件事做透。这篇文章，我们就从可审计和可追溯这两个维度，讲一下织信底座的对应设计。
一、什么是可审计、可追溯的AI底座
要理解这两个概念在企业场景中的具体含义，可以先看一个反例。
一台没有黑匣子的飞机。飞的时候一切正常，但一旦出了事故，你无法还原飞行员在驾驶舱里做了什么操作，无法判断是人的失误还是机械故障。这样的飞机，没有人敢坐。
一个没有审计能力的AI底座，就是一台没有黑匣子的飞机。Agent在企业系统里跑了一个月，帮员工查了数据、批了流程、发了邮件。某天财务发现一笔异常的审批，追查下来发现是Agent代某个员工发出的。这时候你要回答三个问题：谁让Agent发起的这次操作，Agent在执行过程中实际调用了哪些系统能力，Agent的操作结果是否符合当时的权限边界。如果底座没有把这三个问题的答案记录下来，你就只能靠猜。
可审计，说的是底座能不能把每一次AI操作的完整链路记下来，并且在需要的时候能被检索、能被还原。可追溯，说的是当一条异常操作被识别出来之后，你能不能沿着记录链路快速定位到问题节点，找到责任归属。
EU AI Act把这两条写进了法规。高风险AI系统必须保留日志记录，用于追溯和审计。日志需要覆盖系统的整个生命周期，包括开发、部署和使用阶段。任何对系统行为的修改、任何关键决策的生成过程，都需要被记录且可被人类理解。
二、织信底座的三层审计架构
织信平台的审计体系设计，建立在一个简单的判断之上：AI Agent的操作链路比人的操作链路长得多，也复杂得多。传统系统的审计日志只记录"谁在几点几分点击了什么按钮"，对于Agent是完全不够用的。一条"帮我分析一下这个月哪个产品退货率最高"的自然语言指令，Agent在底层可能需要执行十几次数据查询、交叉比对和结果拼接。只记最后输出，等于没记。全记每一条底层操作，日志量又会指数级膨胀。
织信的做法是把审计分成三层来记。
第一层，意图日志。 记录用户对Agent发出的每一条自然语言指令。谁、什么时间、说了什么。这一层回答的是"指令发起者是谁"。EU AI Act要求的"人类监督的可追溯性"，在这一层得到原始保障。
第二层，操作日志。 记录Agent在执行过程中实际调用的每一个系统能力。查了哪个数据表、触发了哪个审批流、修改了哪条记录、调用了哪个外部API。这一层回答的是"Agent实际做了什么、触碰了哪些数据"。对于合规审计来说，这一层是最核心的证据链。
第三层，告警日志。 Agent的操作模式偏离常规时自动触发。比如短时间内大量导出数据、在非工作时间发起敏感审批、访问了与当前挂载身份不匹配的数据域。这一层回答的是"有什么不对劲"。告警条件可以由企业管理员根据自身的合规策略自定义配置。
三层日志之间不是三个独立的记录体系。每一条指令、每一步操作、每一次告警，都通过统一的trace_id串联在一条完整的"指令、执行、结果"链路上。出了问题时，从意图日志定位到原始指令，从操作日志还原执行全链路，从告警日志判断是否存在异常行为。三步走完，通常在几分钟内可以定位到问题节点。
三、权限底座：审计的前提是"有边界"
审计和追溯的前提，是Agent的操作有一个清晰的边界。一个没有权限约束的Agent，审计做得再好也只是在事后记录一场灾难。
织信的权限体系覆盖了六个粒度。团队级，不同团队的数据默认物理隔离。应用级，控制谁能进入ERP、谁能进入CRM。模块级，控制谁能访问某个数据表、操作某个工作流。记录级，同一张表里不同角色看到的数据行数不同。字段级，同一条记录里合同金额字段对销售不可见、对财务可见。控件级，页面上每个按钮和输入框都可以按角色做显隐和可用性控制。
Agent在这个框架中没有独立的"超级用户"身份。它挂载到哪个操作主体，就继承哪个主体在这六个粒度上的全部权限约束。Agent想访问任何数据、执行任何操作，都必须先经过权限引擎的校验。引擎说能看，数据才出得来。引擎说不能，直接拦住。全程没有后门，没有直连。
EU AI Act对高风险AI系统提出了"数据治理"的要求，包括对训练数据和输入数据的质量管控。织信的权限体系通过统一的权限引擎强制执行，保证了Agent在执行过程中"输入了什么数据"这件事本身就处于权限的约束之下。审计层再把这个约束的执行过程完整记录下来，形成从"允许"到"执行"到"记录"的完整闭环。
四、Audit Trail的保存与追溯机制
合规审计有一个容易被忽略的实操问题。你记了日志，但是能保存多久？需要追溯的时候，能不能快速查出来？
织信的审计日志会在平台上持久化保存。每一条日志记录都包含时间戳、操作主体身份、操作类型、操作对象和操作结果。日志可以通过管理后台按时间范围、操作主体、操作类型等维度进行筛选和检索。当需要导出审计证据时，日志支持按条件批量导出为结构化的数据文件。
在可追溯性上，织信的分层日志和trace_id机制搭出了一个关键的溯源路径。假设某天运营经理发现一条有问题的AI操作记录，追溯过程是这样的：打开审计日志模块，输入时间范围和涉及的Agent身份，定位到对应时间段的所有意图日志。找到可疑的那条自然语言指令，通过trace_id关联到操作日志，看到Agent在执行这条指令时实际调用了哪些系统能力。如果操作日志中出现了异常写操作或跨部门数据访问，再通过告警日志查看该系统是否触发过相关告警。整条追查链路不需要跨系统拼接数据，在织信平台内部的审计模块中就可以独立完成。
五、实操举例：一次完整的Agent审计追溯
用一个具体场景来看整个审计追溯过程。
某企业财务部门在月度对账时发现一笔异常的采购审批。金额不大，只有3500元，但审批人是一个普通采购员，不是该部门的采购主管。查下来发现，这笔审批是这个采购员通过AI助手发起的。
追溯第一步：打开意图日志，搜索该采购员在审批发生日期的所有Agent指令，找到一句"帮我把这周的采购单都批掉"。指令发出时间是当天上午10:23。
追溯第二步：通过trace_id关联操作日志，看到AI助手在执行这条指令时做了以下操作。查询了该采购员权限范围内的所有待审批采购单，共4张。逐一触发了审批流程，其中3张金额在3000元以下审批通过，1张3500元的触发了校验警告但未中断流程。操作日志还显示，这4张采购单中有1张的供应商是新增供应商，正常审批流程中需要额外提交供应商资质审核，但AI助手在执行时跳过了这个校验步骤。
追溯第三步：查看告警日志，发现当天10:23有一条告警"非审批人发起审批操作"，状态为已触发但未被人工处理。同时有一条关联告警"审批流程中缺失供应商资质校验"，也被标记。
从发现异常到定位到根因，整个追溯过程约3分钟。根因清晰：AI助手在执行审批时，没有正确识别采购员的审批权限边界，同时跳过了供应商资质校验环节。结论明确：权限配置需要调整，让Agent在采购审批场景下增加供应商资质校验的强制前置判断。
在这个过程中，操作日志和告警日志共同构成了完整的审计证据链。如果外部合规审计要求提供这段时间内所有AI辅助决策的记录，这些日志可以直接导出作为合规证据。
结语
EU AI Act的生效不是孤立的信号。它代表了全球监管对AI治理的一个基本共识：当AI可以代替人做决策、执行操作时，它也必须像人一样被纳入问责体系。而问责的基础，是审计和追溯的能力。
织信在这件事上的思路是清晰的。可审计、可追溯不是AI底座的外挂功能，不是等系统出了问题再去加的补丁。它是底座与生俱来的能力，和权限体系、流程引擎、数据模型一样，是织信五层架构中独立且协同的一层。企业在这层能力之上，可以根据自身的合规要求和业务场景，搭建适合自己的AI审计和追溯体系。
AI可以跑得快，但首先得跑得让人放心。
