直接回答。 企业AI的拒答机制要同时回答三个问题：哪些条件下不能给结论，用户接下来能做什么，以及谁负责把悬而未决的任务接走。只让模型说“无法回答”，并没有完成业务流程；让它在依据不足时猜一个结果，也不是提高完成率。
核心要点
- 把缺材料、权限不足、政策冲突和超出业务范围分成不同状态。
- 拒答时说明能够安全披露的原因，不泄露被保护资料是否存在。
- 将补材料、查阅来源和转人工做成可执行入口。
- 同时检查错误回答与不必要拒答，不能只看回答覆盖率。
- 人工队列必须有任务编号、接手人和处理状态。
先定义什么叫没有完成
假设内部助手回答员工报销政策。员工问某项费用能否报销，系统找到两份规则，一份针对总部，一份针对海外机构。如果没有员工所属组织的信息，系统应补问适用范围，而不是把两份标准拼成一条通用规则。这个例子是流程设计示例，不是对任何企业制度的描述。
同样是没有直接给答案，补问、明确拒绝和等待审批的含义不同。补问表示用户提供一个字段后可以继续；拒绝表示任务不在允许范围；等待审批表示流程已经创建但尚未获得授权。界面和日志需要保留这些差异，否则运营人员无法判断该补数据、改产品还是处理积压。
业务负责人应先列出不能自动下结论的条件。条件可以来自有效政策、数据授权、技术能力边界和错误后果。不要把“模型自己觉得不确定”设成唯一条件，因为模型表达的自信程度不等同于事实正确率。规则判断、来源可用性和人工升级需要共同参与。
建一张拒答处置表
| 触发状态 | 用户看到什么 | 后续动作 |
|---|---|---|
| 关键字段缺失 | 指明需要补充的业务字段 | 保留上下文后补问 |
| 来源互相冲突 | 说明当前无法确定适用版本 | 交给制度负责人核定 |
| 权限不允许 | 告知不能处理该请求 | 引导到获准申请渠道 |
| 超出服务范围 | 说明助手的任务边界 | 转给合适团队 |
| 涉及必须审批的动作 | 显示申请已进入审核 | 等待授权，不执行动作 |
权限拒答尤其要避免过度解释。如果用户无权访问某份文件，助手不应为了证明自己没有回答而透露文件标题、金额或人员姓名。错误提示也属于输出，应该接受与正常回答相同的信息披露检查。需要的排障细节可进入受控日志，而不是直接展示给所有用户。
转人工不是把问题扔进邮箱
转交记录至少包含原始请求、已经获得的授权输入、未解决原因、任务状态和负责人。没有必要把完整聊天记录无条件复制给每个接手人；先确认接手角色是否有权看到这些材料，再按处理需要提供摘要和原始依据。
人工接手者要能区分“助手没有做”与“助手可能已经做了一部分”。对于只读问答，主要问题是依据；对于创建申请、修改记录等动作，还要检查远端是否已经产生结果。不能让人工人员因看到失败提示就重新执行一次，形成重复操作。
队列的等待承诺应由运营团队确定。用户应能查询状态，必要时取消或补材料，而不是反复重新发起同一问题。处理完成后，把纠正原因分类：材料缺失、知识版本错误、权限配置、模型理解或服务范围不清。不同原因应进入不同整改路径。
如何验证拒答是否合适
测试集应包含可正常回答、缺关键字段、来源冲突、无权访问和超出范围的样本。对每个样本预先标注期待的处理状态，不只标注参考答案。测试人员要检查理由是否真实、后续动作是否可用，以及界面有没有泄露受保护信息。
单一拒答率无法代表质量。拒答很多可能意味着系统安全边界清楚，也可能意味着正常工作无法完成；拒答很少可能意味着体验流畅，也可能意味着助手一直在猜。要把正确拒答、不必要拒答、应拒未拒和错误转交分开报告，并说明分母和样本来源。
对高影响任务，某类严重错误可能需要成为单独的上线阻断条件。具体门槛应由业务、风险和技术负责人共同确定，不能照搬另一个场景的百分比。小样本中没有出现错误，只能说明这批样本的观察结果，不能承诺生产环境永不出错。
把拒答机制纳入日常维护
政策更新、知识库迁移和权限调整都可能改变正确处置。每次相关变更后，重新运行对应样本，特别是以前应当拒答而现在可以处理、或者以前可以处理而现在必须拒答的情况。只检查正常答案容易漏掉边界倒置。
运营看板可保留各类拒答数量、人工积压、重复发起和最终处理结果。统计必须符合数据最小化要求，避免为了优化模型永久保存不必要的敏感问题全文。指标的用途是定位工作哪里卡住，而不是以压低拒答率作为一线人员的单一考核。
理门的企业AI方法把责任边界放在验证之前；培训可以用真实且获准的例外案例练习接手与升级。准备好拒答处置表后，再通过沟通入口讨论试点，不必先购买更大的模型。
常见问题
有来源就能直接回答吗？
不能。来源还要适用、有效、授权可见，并且确实支持结论。发现一份相关文件只是验证的起点。
转人工以后是否就算系统成功？
应分开记录自动处理完成与人工接手完成。否则自动化覆盖率会掩盖人工工作量和未解决问题。
用户坚持要求答案怎么办？
不能因为用户催促而越过业务边界。可以解释允许披露的限制、提供补材料路径，但不得编造结论或替用户授予权限。
参考来源
- NIST AI RMF Core：MAP 2.2涉及知识边界，MANAGE 2.4涉及停用或解除系统。本文处置表是理门的实践建议，框架为自愿使用，不是中国法律或产品认证。
- NIST AI RMF Playbook：提供可按情境选用的风险管理建议，不规定所有业务统一的拒答阈值。