一项客户请求正等待回复。AI 助手在并未掌握适用于此情形的有效规则时，拟定了一项善意补偿承诺。措辞听起来很明确，但企业可能因此承担原本无人有意作出的义务。
这是一种示例情形，并非客户案例。但它揭示了在部署助手之前必须作出的决策：系统是否可以用一个看似合理的回答，填补缺失的业务规则？
我的答案是否定的。必要依据缺失时，助手必须说明这一缺口，提出有针对性的追问，或将请求转交处理。一项暂时未被回答的问题，可能就是当下正确的服务。关键在于，后续工作能否在控制下继续推进。
高回复率并不等于高质量
2026 年发表于 Nature 的一项研究清楚呈现了这一取舍。在一项界定明确的 SimpleQA 测试中，包含 4,326 个简短事实问题，模型 o4-mini 对全部测试问题中的 76.8% 给出了错误回答。仅有 2.6% 未作回答。这些结果来自这一特定模型测试及其设定，并不是当今企业中 AI 助手的错误率，也不是对其客户服务质量的比较。1
这项研究更重要的结论与评估方式有关：如果只奖励正确回答，并将不回答与错误回答同等对待，就可能鼓励猜测。对企业运营而言，这一区别至关重要。一次追问会花时间，但对合同作出虚构的解释，可能带来完全不同的后果。
因此，我不会把尽可能高的回复率设为唯一目标。业务负责人必须界定：在何种任务中，可以接受何种程度的不确定性。内部创意草案所需的边界，与面向客户的承诺截然不同。
审查的不是措辞，而是依据
在善意补偿的示例中，仅仅发现一份文件并不够。它必须适用于相关客户群体，仍然有效，并且确实涵盖所涉例外情形。一条关于客户导向的笼统提示，并不等于有权承诺一项具体服务。
如果仅缺少订单的一项信息，有针对性的追问就可能澄清请求。相反，若两套看似有效的规则彼此矛盾，则需要业务判断。如果某一来源无法访问，系统不得据此推断允许或禁止。它也不得绕过访问限制，只为仍然给出答案。
输出应当清楚说明缺少什么依据，以及下一步将如何处理。在仍作出明确承诺的文字下附上一则笼统警示，意义不大。助手可以汇总已有依据支持的信息，但必须保留尚未解决的决策。
美国自愿性参考框架 NIST AI 600-1（2024）支持这种工作方式。它建议在部署前及持续监测过程中审查来源和引文，并核实数据来源。安全的系统还应能够在超出其知识边界时安全中止。这是设计和审查的指引，不是认证，也不构成法律保证。2
测试那些本不应作答的情形
首先，我会选取一个范围明确的流程。对该流程，由业务责任人确定允许使用的依据以及预期行为。随后，在隔离的测试环境中，以那些直接回答显然错误的情形来检验助手：
- ◆关键规则缺失。系统应说明缺口，而不是编造规则。
- ◆两个来源相互矛盾。请求应转交给指定的业务部门。
- ◆只有一项已失效的规则可用。不得将其作为当前依据。
- ◆请求缺少一项决定性信息。助手应准确追问这一项信息。
同时，测试中也应包含可以正常回答的情形。否则，一个拒绝所有问题的系统也可能通过测试，却几乎无法在运营中提供帮助。因此，需要检验的是错误承诺、合理追问以及不必要的拒答。此类错误的严重程度，应由管理层依据各流程的后果来决定，而不是依据一个通用的基准比例。
交接不应只是一句“交给人工”。负责的角色必须明确，确实能够收到该请求，并且能够看到尚未解决的问题及其上下文。对于未被处理的情况，需要约定回退路径。若某项承诺会带来重大后果，在问题澄清前，相关操作必须暂停执行。规则、来源或模型发生变更后，也必须重新审查这些规定。
这是可治理的 AI 运营体系（AI Operating System）的一个小而具体的组成部分。如果需要先为多个流程确定并排序此类决策规则，高管 AI 转型蓝图（Executive AI Transformation Blueprint） 可以建立所需的管理架构。这个为期三周的蓝图用于规划职责、控制措施和实施安排。它不能替代后续在运营中的测试。
因此，在下一次复盘中，我不会只问助手回答了多少请求。我会要求查看一个它有理由暂不回答的请求，并核实该请求是否已送达正确的处理角色。