保障是让承诺得以兑现的工程手段：测试、评测、审核、监控与发布控制。保障不是越多越好，它的强度应当随两件事而定：出了错后果有多严重，结果有多难验证。一份行情摘要与一笔自动下单，需要的保障相差几个量级。AI 系统给保障带来两个新问题：同样的输入可能得到不同的输出，所以不能靠一次测试判断对错，而要用足够大的评测集作统计验证；它在常见情形上表现很好，却可能在少见而关键的情形上出错，所以评测必须专门覆盖这些情形。上线之后，市场与用户都会变化，保障还要延续为持续的监控与分级发布。最后，保障本身有成本，过度保障会拖慢迭代，强度要与风险相称。
汽车电子的功能安全标准按三项因素确定安全完整性等级：伤害的严重程度、暴露的频率与驾驶者能否控制（国际标准化组织，2018）。金融代理可以借用同样的思路，用两个维度确定保障强度：出了错后果有多严重，以及结果有多难验证。后果轻、容易验证的功能，例如一份附有来源的行情摘要，抽查即可；后果重、难以验证的功能，例如在授权范围内自动执行交易，需要形式化的约束、全量的执行层检查与人工审核。大多数功能介于两者之间。
保障强度：后果 × 验证难度
横向是出了错后果有多严重，纵向是结果有多难验证。每一格标出保障等级。点按一项功能，查看它需要的保障。
传统软件的同一个输入总是得到同一个输出，一次测试通过就说明这条路径是对的。AI 代理不同：同样的问题问两次，答案可能不同；一次答对，不代表每次都答对。要判断它的错误率，需要一组足够大的评测题目并统计结果。统计学的“三分之三规则”给出了一个直观的门槛：如果在 n 次独立试验中一次错误也没有，那么以 95% 的置信度，真实错误率不超过约 3 ÷ n（汉利与利普曼-汉德，1983）。要有把握说错误率低于 1%，至少需要约 300 道题全部答对。
要做多少道题，才能说错误率低于 1%
拖动评测题目的数量与其中出错的次数，看以 95% 的置信度，真实错误率最多可能是多少。
评测集如果按实际使用的比例抽取，绝大多数题目都是常见的简单情形，整体准确率可能很高，却掩盖了少见情形上的失败。金融场景中最关键的恰恰是少见的情形：到期日当天、市场剧烈波动、公司停牌与重组、数据缺失。评测应当按情形分层，对关键而少见的情形单独计算准确率并设定更高的门槛；还要主动寻找让系统失败的输入。甘古利等人（2022）组织了大规模的“红队”测试，专门寻找让模型产生有害输出的输入，并公开了近四万条攻击记录。
上线时的评测只说明系统在当时的数据上表现如何。之后，市场会进入新的状态，用户会提出新的问题，数据源也会改变格式。斯卡利等人（2015）把机器学习系统中这类随时间累积的问题称为隐藏的技术债：系统的表现会在没有任何代码改动的情况下悄悄变差。因此，关键指标要持续监控，例如数据缺失率、请示率、被用户纠正的比例与漏报率；指标越过预先设定的门槛时，自动告警，必要时回退到上一个版本或更保守的模式。
一个新版本即使通过了全部评测，上线后仍可能暴露问题。站点可靠性工程的通行做法是分级发布：先让一小部分流量使用新版本，观察关键指标，确认没有问题再逐步扩大（拜尔等，2016）。这样，一个评测没有发现的缺陷，只会影响少数用户，并且能在扩大之前被发现和撤回。对影响交易与资金的功能，第一级还可以只运行而不生效：新版本给出决定，但不执行，与旧版本的决定对照。
保障越强，上线越慢、成本越高。博姆与特纳（2004）指出，过程的严格程度应当随风险调整：风险低的部分追求敏捷，风险高的部分追求纪律。保障强度的选择可以看作一次权衡：保障不足时，缺陷造成的期望损失高；保障过度时，审核与等待的成本高、迭代变慢，用户迟迟用不上改进。不同风险等级的功能，最优的保障强度不同；把所有功能都按最高标准保障，与把所有功能都按最低标准保障，同样是错误的。
保障多强才合适
保障越强，缺陷造成的期望损失越小，审核与等待的成本越高。选择功能的风险等级，看总成本最低的保障强度在哪里（示意）。
按后果与验证难度给每项功能定级，用统计评测与分层评测验证，上线后持续监控、分级发布，并让保障强度与风险相称。
抽查、评测集、分层评测与审核、形式化约束与全量检查，按等级分配。
按需要证明的错误率确定题目数量，0 次出错也要至少 3 ÷ 目标错误率道题。
到期日、剧烈波动、停牌与数据缺失单独达标。
关键指标设告警与回退；新版本小范围先行；低风险功能不要被最高标准拖慢。