AI 接入治理验收的五项检查

验收 AI 接入治理系统时，功能清单只能说明需要检查什么，不能代替实际测试。配置是否成功发布、执行点是否采取动作、记录是否足以追溯，需要分别核对。

本文给出五项通用检查建议，适用于约定的接入与治理范围，不涉及具体产品能力承诺，也不是完整的 AI 安全评估标准。模型行为、知识库权限和工具执行风险应按项目范围另行评估。

一、确定测试范围和判定依据

测试前应记录部署版本、入口、身份来源、策略版本和业务边界。所有请求使用测试凭证与合成数据，在隔离环境中进行。

将每项能力分为当前可验收、需要额外集成、尚未提供三种状态。对需要额外集成的能力，应说明依赖条件；不能把规划内容作为当前交付结果。

验收判据宜采用具体描述：某类请求在指定条件下，由指定入口接收后，应采取约定动作，并留下可检查的证据。

二、权限撤销检查

先验证测试凭证能够调用，再撤销凭证或其对应权限，观察后续请求。账号登录状态与 API 凭证状态可能相互独立，应明确被撤销的对象。

对于多个接入点，分别记录结果。新请求拒绝、队列取消、运行任务终止是不同能力，需要独立确认，不能混用。

若测试关注时延，需说明时间来源、采样间隔和观察方法。单次测试不足以证明系统在所有负载条件下都能达到同样的撤权时效。

三、预算与隔离检查

在支持项目预算控制的前提下，用较小阈值观察告警或限制动作，并验证正常项目是否受到影响。

验收应区分请求数、Token 用量和货币费用。实时费用可能采用估算口径，最终账单可能存在差异；并发在途请求也会影响阈值附近的实际支出。

把计量延迟、超额边界、额度恢复方式写入记录，比只标注“支持预算管理”更有实际意义。

四、数据处理检查

选择预期命中规则的合成样本和预期放行的正常样本，检查拦截、脱敏或其他约定动作。

如果要求出站前处理，就应验证处理发生的位置及外发内容。界面出现告警不能直接证明处理已在外发前完成。

还应检查审计记录是否保留原文，以及访问权限、保留期限是否符合约定。少量测试样本用于确认流程，不足以计算具有代表性的总体检出率。

五、策略异常与恢复检查

在测试环境模拟配置获取失败，记录执行点采用缓存、拒绝或放行的方式，以及告警状态。

缓存策略需要明确有效期；继续使用旧配置可能意味着新发布的限制暂未生效。恢复后，应验证配置版本与实际请求行为一致，而不只是网络恢复连通。

不同业务可以选择不同的异常处理方式，但应在验收前明确，避免上线后临时决定。

六、审计追溯检查

选择一条异常请求，检查是否能在约定范围内关联身份、应用、目标服务标识、策略版本和处理结果。

如果共享凭证未关联可靠的用户身份，不应将凭证持有方直接当作具体操作者。类似地，日志中的模型标识不能独立证明上游实际模型的身份。

审计本身也需检查查看权限、字段可见范围、导出留痕和保留期限。追溯能力应以可核对的证据为依据。

七、形成统一交付记录

验收结论可采用通过、未通过、待验证和不适用，并写明原因。对边界的准确记录，能够帮助业务、测试和运维团队在交付后按同一套预期协作。