可申诉性差距：如何工程化设计用户真正可申诉的 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 法案对高风险系统审计追踪的预期进一步推高了这个数字。这条记录是审计员上门时索要的东西，也是你的“二次审核”流水线在用户申诉时读取的内容。

第二是具有 SLA 的面向用户的申诉端点。不是一个没有决策标识符、最后进入客服工单队列的联系表单；而是一个真实的、具有模式（schema）的端点，用户（或代表他们的客服人员）可以提交”我想审核决策 <id>”以及原始决策不具备的新上下文。该端点创建一个申诉案例，将其链接到持久化决策记录，并开始计时。计时很重要。没有 SLA 的申诉是一个在积压工作中悄悄消亡的申诉，对于任何需要快速解决的用户来说，“我们会尽快回复你”与“不行”的结果是一样的。Cove 的申诉 API 是内容审核领域的一个例子；同样的想法可以推广到你的用户关心的任何决策类别。向你的申诉端点发送 POST 请求会创建一个案例；向你的回调（或客服工具）发送 POST 请求会记录解决结果；两者都可以永久链接到原始决策 ID。

第三是一个不仅仅是重复运行第一条流水线的二次审核流水线。这是团队最容易偷工减料并毁掉整个架构的地方。如果申诉处理器只是用原始上下文重新调用原始智能体，模型——在 temperature 为 0 时是确定性的，在其他情况下也近似确定——会产生相同的答案，而用户会收到一段措辞委婉的“我们已审核你的案例并维持原判”，而实际上没有任何人工审核过。有意义的人工审核（Meaningful human review）——这是 GDPR 执行者和英国信息专员办公室（ICO）多年来一直在强调的术语——是指拥有权力和能力推翻决策的人工审核。为了实现这一点，二次审核流水线需要至少执行以下操作之一：运行一个具有更长上下文窗口和不同系统提示词的不同模型、直接升级到附带案例记录的人工审核队列，或者应用一个专门为申诉路径存在的、更宽松的政策包。通常，这三者都需要。

决策分类问题

并非每个模型输出都值得分配一个申诉端点。如果用户让 AI 智能体总结 PDF 但得到了一个糟糕的摘要，并不需要为此保留七年的可质疑性记录。但如果用户申请退款被拒绝，则确实需要。在这两者之间存在一条界线，你团队中的某个人需要明确地划定它，否则你的持久化记录库将充斥着对话摘要噪音，而你的申诉队列将塞满要求客服修改要点的用户。

一个有用的初步框架是根据决策的“可逆性”和“错误决策对用户的影响”来对决策进行分类。低影响且用户可轻易撤销的决策（重新生成摘要、换种说法再次询问智能体）在设计上就是终结性的，只需要标准的观测追踪（observability trace）。影响较高但用户仍可撤销的决策（智能体选错了文档、推荐了错误的产品）通常需要一个透明的覆盖（override）路径，而非正式的申诉流水线。而那些高影响且用户不可逆的决策——拒绝、删除、否决、降权、封禁——才是可质疑性基础设施发挥作用的地方，也是监管机构最感兴趣的地方。

划定这条界线是一个产品决策，而非工程决策，但工程团队必须负责执行它。最干净的执行方式是在网关层（gateway layer）：在已经进行成本归因、限流和供应商路由的同一个地方，也应该对决策进行分类，写入持久化记录，并将决策 ID 返回给应用程序。处理高风险结果的应用可以免费获得可质疑性功能；而那些不处理高风险结果的应用则无需支付成本。对于任何在生产环境中运行超过两个或三个 AI 功能的组织来说，这是集中化 LLM 网关的有力理由之一。

技术失败背后的组织失败模式

可质疑性缺口难以弥补的原因并非架构新颖。事实并非如此——金融服务和医疗保健行业几十年来一直在编写带有审计轨迹的裁决系统。原因是组织层面的。发布智能体的团队隶属于产品部门，其目标是分流率、自动化率和单次解决成本。而处理申诉的团队则属于支持、信任与安全或合规部门，其目标是解决时间和准确度。没人负责这个“接缝处”。智能体团队的路线图不包括“构建一个供其他团队运营的申诉流水线”，而支持团队的路线图也不包括“构建智能体团队本该交付的数据管道”。

第一张监管机构的传票、第一场集体诉讼，或者第一条来自找不到人工服务的用户的爆火 Twitter 推文，都会在短短几周内让这变成每个人的问题。那些平稳渡过难关而没有陷入救火状态的团队，通常是很早就做了三件事。他们为“申诉路径”指定了唯一的负责人——通常是一个负责网关、持久化记录库和申诉端点的小型平台团队——并让该团队负责与智能体团队和审核团队之间的契约。他们在第一次发布之前，而不是在第一次事故之后，就写下了决策分类政策。他们将持久化记录的 Schema 视为一个版本化的、经过破坏性变更审查的产物，就像对待公共 API 一样，因为如果 Schema 在无声无息中发生偏移，每一个下游消费者（法务、审计、二次审查流水线、编写公平性报告的分析师）都会受到影响。

在收到第一张传票之前该做什么

如果你现在就在生产环境中发布由 AI 介入的决策，找出可质疑性缺口最快的方法就是亲自走一遍流程。挑选一个最近的否决案例——退款申请、内容删除、验证失败——并尝试回答四个问题。模型实际看到的输入是什么（逐字节还原）？是哪个模型版本和策略包产生的输出？在面向用户的产品中，用户可以在哪里申请对该特定决策进行人工复核？当该请求进入时，运行的是什么流水线？它是否与原始流程有足够的差异，从而能够产生不同的答案？

如果你能针对任何超过 24 小时的决策清晰地回答这四个问题，那么你已经领先于大多数在 2026 年交付产品的团队。如果你不能——大多数团队都不能——那么你刚刚找到了需要做的工作。先构建持久化记录；没有它，其他一切都是摆设。其次构建申诉端点，即使在第一个季度唯一的消费者是支持团队的内部工具。最后构建差异化的二次审查流水线，前提是你已经有了足够的申诉量，知道针对每种决策类别，路由到不同的模型、不同的策略还是人工审核才是正确的升级路径。

AI 系统的正向路径只是工作的一小部分。逆向路径——可解释、可质疑且可由具有实际权限的人类推翻——才是未来两年平台工程的重点，也是未来两年监管压力的核心所在。