当 AI 接管例行工作，谁来维护 AI？

Geoffrey Chen

研究与版本说明 本文属于《世界依靠谁来维护？》第 0.1 版研究稿，讨论 AI 系统部署后的持续维护，而不是对任何特定产品作安全认证。文中引用的政府政策和技术报告截至 2026 年 8 月；组织仍须依据具体用途、法律、合同和风险进行独立评估。

《世界依靠谁来维护？》· 第 11 篇

快速阅读

AI 经常以减少例行劳动的方式进入组织：整理文档、分流请求、发现异常、起草答复或提出建议。商业论证容易把部署日写成终点，仿佛模型通过测试后便会持续产生同样价值。实际情况更接近新维护体系的开始。

模型面对的数据、用户行为、业务定义和外部环境会变化。供应商更新基础模型，检索资料失效，提示与接口被修改，员工也会逐渐改变对输出的依赖方式。系统性能即使在测试集上没有下降，其现实作用仍可能改变。NIST 2026 年关于已部署 AI 监测的报告因此把功能、运行、人因、安全、合规和大规模影响分别列为监测类别，同时明确指出方法与术语仍不成熟。

“让人工复核”并不能自动解决问题。复核者需要时间、原始材料、拒绝输出的权限和持续技能。如果大多数结果看起来合理，人会形成自动化依赖；若例行判断长期交给系统，人又可能失去识别罕见错误的实践能力。名义上的 human in the loop 可能只是责任留在人身上，实际控制却已经移走。

维护 AI 的人也不止模型工程师。业务人员定义什么算正确，数据人员维护输入，安全团队处理攻击，前线员工发现情境错误，受影响用户通过申诉暴露看不见的失败。采购合同还决定组织能否取得日志、通知更新、回滚版本或在供应商退出后继续服务。

真正的维护对象应是具有正当目的的服务，而不只是模型在线。模型指标稳定时，员工仍可能误用输出，用户也可能失去纠错路径。技术监测必须与服务结果和申诉连接，并预先规定何时调查、限制或暂停。

本文暂定认为，任何承担持续任务的 AI 都需要一个可识别的维护制度：明确负责人、监测对象、变化控制、事件渠道、人工干预、申诉和退役条件。维护成本应在采购时进入商业案例，而非上线后由少数员工无预算承担。AI 可以减少某些工作，却不会消除维护；它把维护转移到更分散、也更需要权力与证据的位置。

一、“上线成功”为什么不是完成

AI 项目通常在上线前最容易被看见。团队收集数据、评估模型、进行隐私和安全审查，然后通过一个 go-live 决定。项目预算和管理注意也常在这一天达到高点。

上线以后，AI 才进入真实工作。用户输入比测试样本更杂，工作人员可能复制输出到未预想的决定，外部政策会改变“正确答案”，攻击者也开始试探边界。一项离线准确率无法覆盖这些关系。

传统软件同样需要补丁、监测和支持，但 AI 增加了另一层不稳定：输入分布与要预测的关系都可能变化，生成式系统还可能对相近输入产生不同输出。部署前评估仍然必要，只是它证明的是某个版本在某些条件下的表现。

二、先分清模型、系统和使用情境

组织说“我们使用一个 AI”时，往往把三种对象混在一起。模型产生分类或文本；系统还包含提示、检索资料、规则、界面、身份权限和日志；使用情境则包括员工怎样解释输出、决定怎样作出以及受到影响的人能否纠错。

模型没有改变，系统也可能退化。知识库链接过期会使检索内容错误，身份配置失误会泄露资料，界面措辞可能让建议看起来像命令。相反，供应商悄然更新模型时，组织的应用代码没有改变，实际行为却可能变化。

因此，维护清单若只问“模型准确率是否稳定”，会错过真实服务。一个客服摘要工具可能仍准确概括对话，却因员工用它取代完整记录而改变投诉处理。系统指标良好，也不能说明权利和程序没有受损。

三、漂移只是维护问题的一部分

数据漂移指输入分布与训练或验证时期不同；概念漂移则涉及输入与目标之间的关系改变。诈骗方式、语言使用、经济条件和行政定义都可能变化。模型在旧关系上保持一致，恰恰会在新环境中持续犯错。

不过，“漂移”不应成为所有部署失败的通称。错误也可能来自标签本来不可靠、反馈数据被系统自己的决定改变、业务人员将模型用于未经测试的人群，或供应链组件被更新。生成式 AI 的问题还包括检索污染、提示注入、不可接受内容和事实无法追溯。

NIST 2026 年的 NIST AI 800-4把已部署系统的监测整理为六类：功能、运行、人因、安全、合规与大规模影响。报告的意义不在于提供一份已经完成的标准，而是说明“监测 AI”本身仍是分散而未成熟的领域。组织不能购买一个仪表板便宣称完成治理。

四、监测什么，取决于系统做了什么

维护指标应从用途和伤害路径出发。生成内部会议摘要的工具，与影响福利资格或临床优先次序的系统，不应共享同一种监测强度。输出频率、错误可逆性、涉及群体与人工检查机会都会改变要求。

技术层可以观察延迟、故障、输入变化、已知测试集表现和安全事件。服务层还要看工作人员是否误解输出、哪些人无法完成流程、申诉是否集中在特定群体，以及系统是否制造额外工作。只看平均准确率，会让低频但严重的伤害消失。

监测也需要比较基准和触发条件。发现指标变化以后，谁必须调查？达到什么程度会限制使用、回滚版本或暂停系统？如果仪表板只产生无人负责的警报，组织拥有的是可见性，不是维护能力。

五、人工参与可能只是一个标签

“最后由人决定”经常被当作安全保证。要使它成立，复核者必须知道 AI 参与了什么，能够取得原始证据，理解输出限制，并有实际权力改变结果。工作量也必须允许认真复核。

如果系统每天产生数千项建议，而少量员工只有数秒确认，人的动作更接近批准程序。模型输出被界面置于首位，员工又因推翻建议而需要额外说明时，组织实际上在奖励服从。错误责任仍可能落在签字者身上。

长期自动化还会改变技能。人员不再处理常见案例，便较少看到正常变异；系统把最困难或异常案件留给人时，人面对的是高难度样本，却缺少日常练习。维护计划应保留抽样独立判断、培训和轮换，而不能假定专业能力在不使用时保持不变。

受影响用户也是监测来源，但不应成为无偿测试者。投诉渠道需要容易找到，申诉不能要求个人先理解模型内部。系统性错误被发现后，机构还应回查类似案件，而非只修正最坚持的那一位。

六、供应商更新了什么，使用者可能并不知道

很多组织通过 API 或云服务取得 AI 能力。模型权重、过滤规则和服务限制由供应商维护，部署者控制的只是部分应用。责任因而分散，却不会消失。

采购阶段要约定版本通知、可用日志、数据处理、事故协作、测试窗口、服务终止与迁移。若组织无法知道重要变化何时发生，就不能解释某项输出为何与过去不同。若没有回滚或替代路径，所谓暂停权可能在业务上不可用。

商业机密可以保护具体知识产权，却不应成为所有运行证据的替代。高影响用途至少需要足够资料评估系统是否适合目的、发生了何种变化，以及供应商与部署者分别承担哪部分行动。合同不能把公共机构的法定责任转移给模型提供者。

七、澳大利亚政府政策把责任放在哪里

澳大利亚政府 Policy for the responsible use of AI in government, version 2.0自 2025 年 12 月 15 日起对非公司制联邦实体适用，并设有明确例外。它要求可问责的官员、透明度声明、战略方法、内部 use-case registers、培训与基于用途的影响评估等安排。

该政策的 preparedness and operations部分强调 APS 人员使用 AI 时仍需解释、证明并承担建议和决定；影响评估部分则把持续监测与评价列为原则。这些要求的重要性在于，它们没有把责任放到“AI”这个抽象主体上。

政策框架仍需在每个机构转化为实际能力。登记表不会自动发现事件，accountable official 也不可能亲自监测所有用途。预算、技术人员、业务负责人、前线反馈和停止机制若没有连接，正式问责会停留在组织图上。

八、谁是 AI 的维护者

模型开发者维护训练和评估，平台团队负责基础设施，应用人员维护提示、检索与界面。业务专家判断输出是否仍符合现实定义；安全与隐私人员处理攻击和资料使用；记录管理者确保版本与决定能够追溯。前线工作人员最早看到例外，受影响的人则发现内部测试没有覆盖的处境。

把这些角色写成清单仍不够。维护需要一条从信号到行动的路径。投诉由谁聚合，技术问题怎样联系业务后果，谁可暂停，谁批准恢复，谁通知过去受到影响的人，都要预先确定。

某些角色存在结构冲突。产品负责人可能同时负责采用速度与风险控制，供应商的成功指标可能是使用量，而公共机构关心的应是服务与权利。独立审查并非每个低风险工具都需要，但高影响系统不能只由其商业成功负责人判断自身安全。

九、维护记录是 AI 问责的记忆

系统变化快，使版本记录尤其重要。一次输出需要联系到当时的模型或服务版本、应用配置、主要资料源和适用规则。并非所有提示内容都能永久保存，隐私与安全会限制记录；但完全无法重建决定环境也会使复核失去基础。

变更控制应记录改变原因、验证结果、批准者与回退方案。英国政府的 AI Playbook明确提出上线后的持续性能监测、受管理的模型更新、记录变更和必要时回退。它也区分模型指标与服务指标，提醒技术表现与用户是否真正完成任务不是一回事。

记录还应包括被拒绝的警报和人工推翻。若只保存最终决定，机构无法知道人曾修正模型多少次，也看不见员工是否逐渐停止挑战。维护证据不仅为事故后追责，也帮助系统在事故前学习。

十、AI 退役也是维护的一部分

系统可能因性能下降、法律改变、供应商退出或用途不再正当而停止。没有退役计划，组织会在旧模型旁建立临时补丁，直到没人理解全部依赖。影子用途还可能在正式项目结束后继续存在。

退役需要确定数据如何保留或删除，记录如何继续可读，下游流程怎样替换，以及过去决定是否需要复核。对外部用户而言，服务变化也应有通知和替代渠道。关闭一个模型，不等于关闭它已经形成的制度后果。

商业案例应从一开始计入这部分成本。只比较许可费与节省的人工小时，会把监测、申诉、训练、供应商管理和迁移留给未来预算。自动化看起来便宜，有时只是因为维护劳动被隐藏在其他岗位中。

十一、从维成论看被委托的判断

AI 系统使 delegated knowing 的结构更加明显。没有一个人掌握数据、模型、业务、界面和每个个案的全貌，但组织仍让分布在这些部分的输出进入行动。知识功能被委托，并不意味着理解和责任已经一并转移。

从 Sustenesis 的应用视角看，系统的同一性也不能仅以产品名称判断。供应商、权重、数据、政策和使用方式改变后，“同一个 AI”可能只剩采购名称。维护需要识别哪些变化仍在获准用途内，哪些已经使系统成为另一种制度安排。

人的剩余角色不应被缩减为为机器签字。人必须承担目的、可接受后果、例外、申诉与停止使用的承诺。系统可以帮助发现模式，却不能替组织说明为什么这个用途仍值得维持。

十二、当前判断：没有维护制度，就没有可持续的 AI

部署 AI 不应以一次上线审批结束。每个持续使用的系统都需要指定用途所有者、技术维护者和对受影响人负责的决定者；三者可能不是同一人。监测范围必须覆盖模型、服务、人因和分布后果，并连接到调查、回滚、暂停和补救。

人工复核只有在人员拥有资料、时间、技能和改变结果的权力时才算控制。用户反馈和申诉应进入系统性复查，不能只处理为孤立客服问题。供应商合同则必须支持变更可见性、事故合作和可行退出。

第 0.1 版的结论是：AI 接管的往往是可描述的例行任务，维护 AI 的工作却散布在技术、业务、法律和人际关系之间。若组织只计算被节省的劳动，它会漏掉使自动化继续可靠且正当的劳动。AI 不会让维护消失；它迫使我们重新决定谁能够看见失败，谁有权介入，以及谁仍需为系统的存在作出解释。

主要资料与进一步阅读

系列导航：《世界依靠谁来维护？》系列总览

了解 Geoffrey Chen 的更多信息

订阅后即可通过电子邮件收到最新文章。