可申诉性差距：如何工程化设计用户真正可申诉的 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 系统的正向路径只是工作的一小部分。逆向路径——可解释、可质疑且可由具有实际权限的人类推翻——才是未来两年平台工程的重点，也是未来两年监管压力的核心所在。