一个 AI 助手要帮助销售团队更快地准备报价。试点中检查了 100 个案例，没有发现错误。这就足以批准销售团队使用了吗？这里用的是一个说明性示例，并非 Fassbender 的客户案例。
这个数字听起来让人放心。但它还没有说明：测试查找的是哪些错误，谁有能力识别这些错误，以及所测案例是否反映了今后的实际工作。错误的交付承诺与措辞不够严谨的段落，不是同一类问题。如果把两者都归入“测试通过”，就无法形成可靠的决策依据。
我不会仅凭“100 次测试，零错误”就批准使用，而会依据已经验证的使用范围，以及这些证据的适用边界来决定。 这样做不仅能减少错误决策，也能避免另一个问题：因为被要求证明绝对安全，团队迟迟不敢启用一个范围有限、却确实有用的功能。
100 个未发现错误的案例，究竟能证明什么
一项仅用于说明的模型计算，可以把证据的边界说清楚。假设在系统状态不变的条件下，独立选取了 100 个案例，并按照明确的二元错误定义进行检查：每个案例只判定为有错误或无错误。在这个统计模型中，每个案例的错误概率相同。如果要把结果用于实际运营，所选案例还必须能够代表相关的实际使用情形。
在观察到零个错误时， 错误比例的单侧精确 95% 置信上限约为 3%。 这项计算基于二项分布，更精确的结果约为 2.95%。NIST 的文档介绍了精确置信限的计算方法。这不是实测的 AI 错误率，也不是对贵公司系统预期错误比例的预测。这里的 95% 指统计方法的置信水平，并不表示这个试点有 95% 的概率是安全的。1
对管理层而言，首先要明确：没有观察到错误，不等于已经证明风险为零。即使是上述有限的统计结论，也只有在假设成立时才有效。把同一个简单问题变换 100 种问法来反复测试，不能替代从未来实际使用中选取的 100 个独立且有代表性的案例。
增加测试数量，可以增强结论的依据。但如果错误定义不对，或者某个重要的案例类型根本没有进入测试，再多测试也解决不了这两个问题。
先说清楚证据，再讨论是否批准使用
在下一次试点评审前，我会要求团队提交一份简短的测试说明。负责相关业务的人应共同确认其内容，而不能只由开发团队负责。一页纸需要写清楚：
- ◆测试对象： 测的是哪项具体工作，使用了哪个版本的模型、信息来源和配置？
- ◆错误定义： 什么属于业务上错误或不允许的结果，由谁判断？
- ◆案例选择： 案例来自哪里，覆盖了哪些使用情形，还有哪些没有覆盖？
- ◆适用边界： 这些证据适用于哪些用途，又明确不适用于哪些用途？
这不是要增加一套报告手续。缺少这些信息，管理层就无法准确理解“试点成功”意味着什么。团队日后也很难复现这一结果。
以上述报价场景为例，试点可能只验证了汇总已经批准使用的信息，并没有测试助手自主调整价格的能力。信息汇总没有发现错误，并不能成为允许它参与定价决策的依据。
对于经常出现的标准案例，以及少见但后果重大的例外情形，也必须分别看清各自有什么证据。不能因为整体平均表现良好，就忽略一项不允许作出的承诺。剩余的不确定性是否可以接受，取决于可能造成的后果和现有的控制措施。这是管理层要作出的判断，不是套用一个通用基准就能决定的。
美国 2024 年发布的自愿性参考框架 NIST AI 600-1 建议，在贴近现实的场景中测试 AI 的行为。它提醒使用者，受控测试与实际使用之间可能存在测量盲区。这份框架提供的是参考指导，不是认证，也不是法律保障。2
证据有边界，使用也要有边界
如果测试说明能够支持一项有用且范围明确的用途，我会按这个范围批准使用。例如，允许助手为报价草稿整理信息。但在报价对外发出之前，仍由具备相应业务授权的人审核具有约束力的交易条件。
审核必须真正做得到。如果审核人看不到必要的信息来源，或者没有时间检查，仅仅规定“必须审核”并没有多少作用。因此，新增的审核工作量也要纳入经济性评估。真正重要的是从开始准备到报价完成业务审核并获准发出的总用时，而不只是第一版草稿生成得有多快。
部分案例应保留到最终评估时才使用，不能提前用于测试和改进。否则，测试可能只能说明团队对已经熟悉的任务修正得有多好。当信息来源、模型版本或使用范围发生变化时，必须重新确认原有证据中哪些仍然有效。
如果多个工作方向的使用边界和批准标准都尚待明确， 高管 AI 转型蓝图（Executive AI Transformation Blueprint） 可以为这些决策建立管理框架。为期三周的集中工作将明确优先事项、责任归属和价值验证依据。它不能替代随后在实际运营中的检验。
因此，在下一次评审中，我不会只看那 100 个标为通过的结果。我会问：这些测试足以支持批准哪一项具体用途，又有哪些用途并不在其支持范围内？