我们推荐的私有 AI 服务交接记录

NIST 的 AI 风险管理框架涵盖了 AI 系统设计、开发、使用和评估过程中的可信性。[1] 运营期间同样需要独立的证据。对于进入常规使用阶段的私有 AI 试点项目，我们推荐一份交接记录，使接收团队能够识别安装环境，了解其限制，并在出现故障时做出响应。

这是我们提出的交接格式，而非经过审计的客户部署报告。它补充了 Software Tailor 信任中心中的技术和数据边界信息。每个组织应根据自身运营模式分配相应职责。

明确接收负责人及其允许的工作范围

从一个明确的角色开始，该角色承担服务责任。记录其联系方式及常规负责人不可用时的替代安排。供应商的支持地址虽有用，但组织还需有人能决定在事件发生时服务是否应继续运行。

描述获准常规使用的任务及仍限于试点的任务。包括允许使用服务的群组及预期的运营时间。未解决的试点问题应保持可见，指定负责人和计划决策日期；不应因安装状态变更而消失。

延续采购决策中使用的容量和截止时间假设这为接收团队在工作负载变化时提供调查依据。

记录应用程序和服务器版本、运行时及精确模型引用。通过组织的常规受控文档流程保留安装源和相关配置。凭据通过其凭据管理流程存储，交接记录中引用凭据而非复制秘密值。

Hugging Face 模型卡提供模型用途、限制和评估的文档。[2] 链接相关卡片及版本，并补充试点的本地发现。发布者描述和组织测试结果回答不同问题；接收团队应能找到两者。

对于系统中可选的外部提供者，记录启用的访问路径。描述每条路径的预期数据边界及谁可批准变更。避免使用“本地”等宽泛标签，当运营配置需要更精确说明时应详细描述。

对于代理集成，附上商定的工具列表和每个连接使用的身份。OWASP建议限制代理的能力和权限，并在下游系统中强制执行授权。[3] 我们的交接方案将该指导转化为所有权问题：谁可以审查或撤销每项授权？

包括工具调用集成检查的结果，以及任何剩余的限制。区分提议操作的权限与执行操作的权限。如果某个操作必须由人员批准，需明确该批准发生的位置以及失败或放弃批准时的处理方式。

接收方所有者还应了解存在哪些诊断记录，谁可以访问这些记录以及保存期限。使用已配置的策略和经过验证的示例。不要仅因为某个组件设计了无内容的审计，就推断所有连接组件都不存在提示。

选择一个商定的、无破坏性的中断操作，在测试环境中进行。让接收团队按照恢复说明操作，原实施者进行观察。记录他们遇到的缺失信息，并在签字确认前更新说明。

该演练应确定如何识别问题，谁可以停止受影响的工作，以及如何检查恢复后的服务。如果回滚是计划的一部分，需明确保留的版本及适合回滚的时间点。未测试的恢复假设应标记为未测试。

对于 Software Tailor 服务讨论，一份经过编辑的配置记录和对失败步骤的清晰说明，比无支持的系统整体故障声明更有用。交接应说明如何通过组织批准的支持渠道收集该信息。

以接收方所有者的接受、日期和未解决事项结束。列出应触发复审的变更，如不同模型、新连接器或更广泛的允许任务。这是一种建议的运营纪律，而非认证方案。

当接收团队能够利用该记录做出决策，而无需凭记忆重建试点时，记录即为准备就绪。

[1] NIST。 AI 风险管理框架。框架 1.0 于 2023 年发布；背景指导。访问日期 2026-09-26。

[2] Hugging Face。模型卡模型文档指导。访问日期：2026-09-26。

[3] OWASP 生成式 AI 安全项目。 LLM06:2025 过度代理2025 版。访问日期：2026-09-26。