AI Admin Console 提供六大功能。每个功能都是侧边菜单项,分别回答采购审核员或合规负责人在企业尽职调查过程中会提出的具体问题。这六项功能共同涵盖了欧盟 AI 法案所称的部署者义务[1]以及 NIST AI RMF 所称的“足以重建决策的系统操作记录”[2]——所有这些都集成在 IT 团队已熟悉安装的单一桌面应用中。

这些功能按它们在控制台侧边菜单中的顺序列出。以下每节将说明采购问题、控制台如何处理该问题以及数据存储位置。

成员与访问权限

问题: 我们组织中谁被允许使用 AI Suite,且使用的是哪个许可证等级?

控制台允许管理员通过电子邮件邀请团队成员,分配个人或商业许可证席位(按月、按年或一次性),并在员工离职时撤销访问权限。支持从 CSV 批量邀请。成员名单是部署者关于“谁有访问权限”的唯一权威来源——这也是合规团队在被要求证明人工监督时提供的答案。

存储在 Software Tailor 后端的是组织成员名单。未存储的是这些成员在模型内部的任何操作记录。控制台是访问入口;推理过程在本地进行。

许可证

问题: 每位成员拥有哪个等级的许可证,且如何离线强制执行?

每用户许可证密钥支持离线验证。当席位需要在无网络往返的情况下继续工作时非常有用——这是受监管行业中 AI 工作站位于隔离网络时的常见需求。控制台负责发放和撤销密钥;每用户的等级覆盖设置与组织默认设置并列显示。

这是控制台唯一会写入必须传输到用户机器的值的功能。其他所有功能均为部署元数据,而非内容相关。

AI Server 注册

问题: 我们的组织信任什么硬件来运行推理?

AI Suite 安装程序会与本地 aisuite-server 进程通信;该进程可以与设备上的模型通信,也可以与运行在客户网络内、由客户控制的 AI Server 通信。AI Server 注册是控制台将这些服务器实例绑定到组织的方式,以便它们接受来自已批准 AI Suite 安装的签名请求。配对、轮换凭据、撤销,无需接触服务器本身。

采购角度:推理硬件属于部署者。注册即证明这一点。控制台从未看到模型的输入或输出。

策略

问题: 哪些模型、提供商和数据处理规则适用于我们组织的 AI Suite 安装?

策略是整个组织范围内的配置,每个 AI Suite 应用都遵守:允许使用哪些模型、数据驻留提示、登录提供商以及 OIDC 租户配置。更改将在下次启动时传播到每个安装。这就是部署者在被问及“有哪些安全防护措施?”时所指的内容——也是他们在欧盟 AI 法案修订(最近一次是2026年5月7日的综合协议收紧了高风险系统定义[1])时所编辑的内容。

审计

问题: 发生了什么,何时,由谁执行——我们能否按需提供?

每个管理操作都会记录在 JSONL 审计行中:时间戳、执行者邮箱、操作动词、受影响资源、发起客户端的 X-App-Id 。无提示。无响应。无文档内容。部署者的内容存储保留推理内容;控制台的审计行保留操作发生的证明。

这种分离使得该审计行满足 NIST AI RMF 中“系统操作记录足以重建决策”[2]的要求,同时不保留部署者不希望保留的模型内容。架构和审计行格式已在我们的 无内容审计日志 文章中有详细说明。

按组织使用情况

问题是: 我们组织整体上到底发生了什么?

一个只读的遥测汇总,范围限定在组织内:活跃安装数、主要事件、平均推理时长、模型评分。不包含原始提示。所有数据均为汇总且无内容信息,设计如此。部署者的IT团队用它进行容量规划;合规团队用它来确认“政策是否真正被遵守?”

这是唯一一个跨成员显示数字的地方,也是控制台唯一汇总行为随时间变化的地方。

为何使用单一工具

NIST AI RMF [2] 要求“系统操作记录足以重建决策过程”。欧盟AI法案要求部署者证明有人类监督、监控系统运行、保留日志并按需提供[1]。在这两个框架中, 部署者 ——而非供应商——承担义务。控制台的存在是因为部署者的IT团队需要一个地方来履行该义务。

这六项能力不是功能清单。它们是采购审核人员依次提出的六个问题的答案。开始对本地AI部署进行尽职调查的团队应从 为何本地AI部署在采购中受阻开始;控制台即是答案所在。

参考文献

  1. 欧洲委员会。“AI法案——AI监管框架。” https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai。访问日期:2026-07-01。
  2. NIST。“AI风险管理框架。” https://www.nist.gov/itl/ai-risk-management-framework。访问日期:2026-07-01。