AI Suite 内的每个管理操作都会生成一条 JSONL 审计记录。该记录包含时间戳、操作者邮箱、操作动词、受影响资源、 X-App-Id 发起客户端的标识，以及一个稳定的哈希值，方便审核人员将该记录与后续事件关联。该记录不包含 模型的任何输入或输出内容. 无提示文本，无完成文本，无文档内容，无提取实体。此设计选择——无内容设计——使审计记录对采购和合规审核人员有用，值得详细说明原因。
审计记录包含什么，不包含什么
一条代表性记录，略作脱敏：
{"ts":"2026-06-05T09:14:22Z","actor":"jane@bank.example","action":"license.assign",
"subject":"user@bank.example","tier":"commercial","x_app_id":"ai-admin-console",
"ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}它包含：足够的元数据以回答审计人员关于部署者义务的问题—— 谁在何时对哪个资源进行了何种操作，来自哪个客户端。它不包含：AI 工作流的任何有效载荷。如果该操作调用了模型（本例中未调用，但可能调用），会有一条记录调用事件的审计记录，但我们的基础设施中不会记录提示或响应内容。
这种分离是刻意为之。审计记录是 操作发生的证据操作内容——发送给模型的提示和返回的答案——保存在部署者自己的硬件上，受部署者自身的保留政策管理。我们从未接触这些内容。
内容为何不存储在行中
有两个原因，一个是监管原因，一个是运营原因。
监管：欧盟《人工智能法案》要求高风险人工智能的部署者“在适当期限内”保留日志，以监控系统运行，并在请求时证明合规性。 [1]责任在于部署者证明发生了什么。云端大型语言模型API通过将提示和响应存储在供应商基础设施上来解决这一问题，这将数据处理问题转移给供应商——并形成部署者无法控制的第二个合规边界。无内容本地审计以不转移数据的方式回答同样的监管问题： 部署者 将内容保存在部署者自己的存储中，遵循部署者自己的保留规则。
运营：存储的每一个模型内容字节都需要加密、访问控制、保留、按计划删除，并在电子发现中提供。无内容行体积小（几百字节）、结构固定、仅追加，且可轻松序列化到部署者现有的安全信息和事件管理系统（SIEM）中。它们是满足义务的最小证据单位。
这在主要框架中的对应关系
NIST AI RMF 1.0将可审计性定义为可信赖人工智能的核心维度，要求部署者维护“足以重建决策的系统操作记录” [2]“足以重建”是关键短语：该行必须让审查者能够重建发生的事件。无内容行能做到这一点，适用于 管理 操作（如发放许可、更改策略、注册服务器），而无需保留推理的 内容 。对于推理内容方面的义务，部署者自己的本地存储是答案。
ENISA的人工智能网络安全指导从威胁建模角度阐述 [3]：每个存储在供应商基础设施上的提示和响应都会扩大部署者的攻击面，涵盖供应商的攻击面。将模型内容从供应商端移除，则将攻击面缩小到部署者已控制的范围。
我们交付的形态 — AI Admin Console 用户界面， AI Server 守护进程的 JSONL 审计以及每个组织的 SIEM 转发钩子——直接实现了这一点。每个管理事件都会记录在部署者可读的行中；在本地或客户托管的推理路径上，提示和响应内容不会发送到 Software Tailor 的控制平面。
采购审核中的表现
阻碍云端AI供应商采购的问题是：“推理内容存储在哪里，我们的合规团队能否按需提供？”内容无关审计解决的采购问题也是这个，且给出了两个明确的回答： 内容存储在您的硬件上，您的团队之所以能产出内容，是因为他们已经拥有这些内容我们的审计记录证明了操作的发生；您方的内容证明了该操作的具体效果。
关于更广泛的采购框架——包括如何利用这些属性而非供应商方面的认证来引导供应商问卷调查——请参见 本地部署的人工智能为何在采购阶段停滞不前 和 欧盟人工智能法案合规文章。
部署者的责任范围
无内容审计是部署的结构性特征，而非端到端的合规解决方案。部署者仍然负责：
- 定义“足以重建”的含义 针对其自身工作流程——保留期限、掩码规则、电子发现状态。
- 操作本地内容存储 （无论部署者选择何种方式——文件系统、文档数据库、加密二进制存储）并将我们的审计记录行转发到SIEM中，在那里它们会与自己的日志进行关联。
- 编写部署者义务备忘录 在采购过程中指向此架构。
我们提供架构和审计行格式。其下游的所有内容——包括内容的保留政策——均由部署者的合规团队根据自身规则执行。
参考资料
- 欧洲委员会。“AI 法案——人工智能监管框架。” https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. 访问日期 2026-06-03。
- NIST。“AI 风险管理框架（AI RMF 1.0）。” https://www.nist.gov/itl/ai-risk-management-framework. 访问日期 2026-06-03。
- ENISA。“人工智能网络安全。” https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. 访问日期 2026-06-03。