可申诉性差距：如何工程化设计用户真正可申诉的 AI 决策

一个用户打开聊天窗口，请求退款，得到“抱歉，此次购买不符合退款条件”的回复后，关闭了标签页，再也没有回来。在内部，智能体生成了一条完美的追踪记录：工具调用、中间推理过程、参考的政策包，以及运行的模型版本。每一个 span（追踪跨度）都进入了可观测性平台。但没有任何内容是用户可以触及的。这里没有标为“请求人工再次审核”的按钮，即使有，后面也没有相应的服务。这个决定在默认情况下就是终局，而非设计使然。

这就是“可争议性差距”（contestability gap），它是监管机构、律师和愤怒的用户接下来要撕开的口子。这也是一个最典型的例子：一个从外部看像是政策问题，而从内部看实际上是工程链路（plumbing）的问题。

这种差距存在的工程原因是，生产环境中的 AI 流水线是针对正向路径优化的。智能体读取请求，获取上下文，选择工具，生成输出并返回。推理追踪确实存在，但它是为值班工程师记录的，而不是为用户记录的。模型实际看到的输入快照存储在一个存储库中；限制决策的政策包存储在另一个库中；模型版本是部署上的一个标签，而不是决策记录中的一个字段。三周后询问“为什么拒绝这个用户？”通常意味着需要关联四个日志库，并祈祷它们的存储周期（retention windows）是一致的。要求“在不同的假设下重新评估此案例”几乎总是意味着针对相同的上下文运行相同的提示词，并预见性地得到相同的答案。

当本不该是“终局”时，“终局”是什么样子的

梳理任何 AI 辅助产品中用户可见的决策边界，你会发现一长串在事后看来团队会将其归类为“可申诉”的输出——以及极少数真正允许用户申诉的 UI 功能。智能体拒绝了退款。内容审核流水线删除了一篇帖子。内容排序器埋没了创作者的视频。身份服务将账号标记为可疑并强制进入重新验证循环。招聘工具悄悄地给简历打低分。推荐系统停止向曾经购买过的买家展示商家的产品。

每一项都是“模型说是就是”。每一项也都是监管机构现在希望你能够解释，并在许多情况下允许用户提出异议的决策。欧盟 AI 法案（EU AI Act）第 86 条规定的解释权，赋予了受高风险 AI 决策影响的人获得“AI 系统在决策过程中所起作用的清晰且有意义的解释”的权利。而 GDPR 第 22 条长期以来一直要求，对于具有法律或类似重大影响的纯自动化决策，数据主体必须能够获得人工干预、表达观点并对决策提出异议。虽然这些措辞比最新一代模型还要久远，但义务并未改变：一条通往人工的真实路径，并有获得不同结果的真实机会。

工程团队往往会以错误的顺序发现这一要求。首先，他们发布了智能体。然后有人问“申诉路径是什么？”接着有人意识到根本没有。于是有人提议“我们会路由给客服”。然后客服指出他们没有输入快照，没有政策版本，没有智能体实际看到的记录——只有一条写着“AI 说不行”的客户对话记录，以及一个被要求在不了解系统决策依据的情况下推翻“系统”的迷茫的人。这种对话通常以申诉因为错误的理由被支持或因为错误的理由被拒绝而告终，这两者都不是“可争议性”。这只是一次有着更友好声音的抛硬币。

在你需要之前就需要准备好的三件事

可争议性不是你在一个下午就能强行添加给已发布智能体的功能。它是三个基础设施组件，跳过其中任何一个都会让申诉流程变成一场表演。

第一是针对每项决策的持久化记录。不是一个 span，不是一行日志，而是一条记录。对于每一项跨过“可能影响用户利益”阈值的决策，你需要一行数据来捕获：模型看到的完整输入快照（规范化处理，以便对相同输入的两次运行哈希值一致）、模型版本和供应商、限制输出的政策包或规则版本、尝试过的工具调用及其结果，以及返回给用户的最终输出。该记录需要自己的存储策略，与你的热观测存储解耦。12 个月是不够的；对于高风险决策，监管机构的要求更接近 3 到 7 年，而 AI 法案对高风险系统审计追踪的预期进一步推高了这个数字。这条记录是审计员上门时索要的东西，也是你的“二次审核”流水线在用户申诉时读取的内容。

加载中…