为何受监管系统中的 AI 采用会失败，以及如何解决

Google News 向企业领导者发出了明确警示：受监管的 AI 项目即使演示效果良好、预算已获批准，也往往会失败。核心矛盾并不只是创新与监管之间的冲突，而是 AI 系统“能够做到什么”与组织“能够安全证明什么”之间的鸿沟。

Technology Magazine 的分析认为，当治理工作在模型选定后才介入，部署就容易失败。团队先构建出一个颇具前景的系统，随后却发现其数据、决策、权限或更新无法经受正式审查。到那时，重新设计产品既成本高昂，也在组织政治层面困难重重。

这一诊断挑战了企业 AI 中广受推崇的能力优先方法。一个模型可以在试点期间给出准确答案，却仍不适合用于医疗、银行、保险、政府或关键基础设施。在这些环境中，采用取决于证据、问责与运营控制。

Google News 将治理鸿沟置于焦点

重要进展在于，企业 AI 失败的诊断方式正在发生变化。

这则 Google News 条目 将读者引向 Technology Magazine 关于受监管系统的论述。其信息直截了当：当组织将合规视为最终审批环节时，采用就会受阻。

这一框架之所以重要，是因为许多企业项目仍从模型演示起步。团队测试 AI 助手能否汇总记录、分类案例、起草决策或提出行动建议。一场成功的演示，随后便成为扩大业务提案的基础。

而监管机构、审计人员或内部风险委员会会提出不同的问题：哪些记录进入了系统？谁授权了它们的使用？哪个模型版本生成了该回复？哪位员工批准了结果？六个月后，组织能否复现这一决策？

这些问题揭示了功能表现与运营适用性之间的区别。功能表现衡量模型是否完成任务；运营适用性衡量周边系统能否持续保持问责、安全、可追溯和可维护。

Technology Magazine 此前报道称，在 SS&C Blue Prism 的一项调查中，超过三分之二的先进 AI 项目未能进入实际运营。该调查覆盖了金融服务和医疗保健领域的 1,650 名高管及技术领导者。

同一报告发现，92% 的受访者正在使用 AI 改造运营。但 55% 表示，其实施所带来的收益有限。安全与合规问题是最常被提及的障碍，占比为 37%。

这些数据来自一项由供应商赞助的调查，因此不应被视为普遍失败率。但它们仍说明了一种企业中常见的模式：兴趣与试验的发展速度，可能远快于可信赖的生产环境使用。

进入生产环境后，证明责任随之改变。原型只需表明输出看起来有用；受监管部署则必须说明输出如何生成、审查、记录、质疑、纠正和退役。

这一区别解释了为何一个试点项目可以获得高管赞誉，却始终得不到运营批准。模型已经展示了能力，而机构尚未证明其控制能力。

因此，Google News 的这篇报道不只是又一次对谨慎行业的提醒。它反映出一种日益增强的共识：治理是产品架构的一部分。团队无法等开发结束后，再将其附加到不透明的工作流上。

受监管 AI 项目面临不同的成功定义

在受监管系统中，仅有一个有用的答案还不够，因为每一个重要答案都会带来问责要求。

营销团队可以丢弃一份质量不佳的 AI 草稿，后果有限。但医院、银行、保险公司或公共机构遵循的是不同的风险模型。错误输出可能影响治疗、信贷、就业、福利、安全或法律权利。

这些组织需要明确系统承担什么角色。一个检索政策文本的助手具有一种风险特征；一个对申请者进行排序或建议临床行动的系统，则具有另一种风险特征。

当产品整合多种功能时，这一区别会变得更加困难。一个聊天机器人可能在同一界面中检索记录、总结证据、评估风险并提出决策建议。即使每个组件都存在不同限制，用户仍很容易将这种综合输出视为权威结论。

这给首席信息官、合规团队、安全负责人、模型所有者和业务管理者带来压力。每个群体控制部署中的一部分，但没有任何一方能够独立保证整个系统。

技术团队可以监控延迟和可用性；数据团队可以测试输入质量；法务团队可以解读义务；业务所有者可以界定可接受的结果；安全团队可以限制访问。

失败往往出现在这些职责之间。一个系统可能通过准确性测试，却缺少合适的访问控制；它可能保护了数据，却没有申诉流程；它可能记录了输出，却未保留模型版本或检索来源。

监管机构日益期待全生命周期管理，即从初始设计到部署、监控、修改和退役，全程控制 AI 系统。这种方法假定风险会在上线后持续存在。

美国食品药品监督管理局将这一逻辑应用于 AI 赋能的医疗设备。其 生命周期指南 建议针对设计、文档、透明度、偏差、监控和上市后变更进行规划。

FDA 在 2025 年 1 月表示，已通过既有的上市前审查路径授权超过 1,000 款 AI 赋能设备。这个数字表明了采用规模，但也说明一次性批准无法覆盖未来的每一次模型变更。

当患者群体、工作流、数据格式或临床实践发生变化时，AI 产品可能出现漂移。即使模型在技术上保持不变，运行环境的变化也可能导致不同结果。

金融机构也面临类似问题。决策模型所需的治理，不止于原始预测准确性。组织必须了解其预期用途、重大假设、局限性、验证证据及持续表现。

同样的原则也适用于生成式 AI。语言模型可以生成看似合理的解释，却不一定展现稳定的证据链。当员工将流畅的措辞误认为经过批准的机构决策时，这种行为就会变得危险。

因此，受监管组织对成功的定义比消费软件团队更为严格。成功意味着系统在有记录的边界内完成任务，也意味着人们能够发现并控制失败。

这一标准看似缓慢，因为它要求在部署前投入更多工作。然而，它避免了一种成本更高的结果：系统在组织尚未理解自身义务之前就进入生产环境。

能力优先的 AI 与证据优先的运营发生碰撞

核心竞争发生在能力优先的开发与证据优先的部署之间。

能力优先团队首先会问，最新模型能够实现什么。他们选择模型、接入内部数据、构建界面并展示结果。随后，治理团队才会收到一个近乎完成的系统进行审查。

证据优先团队则颠倒了这一顺序。他们先识别受监管的决策、责任人、可接受的输入、所需记录、升级路径和失败阈值。模型选择在这些边界之内进行。

第一种方法可以更快地完成演示；第二种方法则提供了更清晰的生产路径。

这并不是主张避免试验。早期原型能帮助团队判断一个用例是否值得投资。问题在于，原型的架构悄然演变为生产架构时。

演示可能使用人工准备的数据，依赖宽泛的开发者权限、单一模型版本或非正式的人工审查。这些假设未必能够在企业部署中延续。

数据血缘成为核心议题。数据血缘是关于信息起源、变化过程及流动位置的记录。没有它，组织就无法可靠地说明哪些证据塑造了 AI 输出。

检索增强生成（RAG）中也会出现同样的弱点。RAG 会在语言模型生成答案前向其提供精选文档。它可以提升相关性，但并不能自动证明每一份文档都已获授权或仍然有效。

生产系统必须保留检索到的来源、其版本、所应用的访问规则以及生成的回复。它还必须区分原始证据与模型的解读。

这一要求使知识管理成为 AI 治理的一部分。团队需要受控来源，而不是分散的文件和缺乏记录的副本。如果权限和来源历史保持可见，一个得到维护的可搜索知识库可以支持这项工作。

权限构成另一项挑战。许多早期 AI 代理会获得宽泛访问权限，因为开发者希望测试完整工作流。宽泛访问让演示更容易，却也扩大了错误可能造成的后果。

一个仅起草电子邮件的代理，带来的运营风险有限。一个能够读取客户记录、批准付款、修改账户并发送消息的代理，则会带来多项相互关联的风险。一条错误指令就可能跨越多个控制边界。

证据优先的设计会将这些操作分离。系统可以检索信息而不修改信息；可以起草建议而不予批准；可以准备行动，但要求经授权人员执行。

人工审查同样需要谨慎设计。如果审查者缺乏时间、背景或权限，仅仅增加一个批准按钮并不能形成有意义的监督。当员工在不核查证据的情况下例行接受输出时，审查就会沦为形式。

有效的控制措施会明确审查者必须检查什么。它还会记录所展示的证据、审查者的决定以及任何纠正措施。高风险案例应接受比常规案例更深入的审查。

这将形成一个分级系统。低风险辅助可以快速推进；重大决策则需要更严格的验证、更窄的权限和更详细的记录。

能力优先项目往往抗拒这种分离，因为它会降低表面上的自主性。然而，自主性并非价值的唯一衡量标准。员工能够安全使用的受约束系统，比永远无法走出试点的自主系统更具价值。

标准正成为产品要求

AI 治理框架如今描述的是受监管产品需要提供的能力，而不是团队事后完成的文书工作。

美国国家标准与技术研究院（NIST）将其自愿性 AI 风险管理框架划分为四项功能：治理、映射、测量和管理。这些功能共同将风险管理视为一个持续运行的过程。

治理用于明确职责、政策和问责机制。映射用于识别系统的背景、用户、受影响群体以及潜在危害。测量用于评估性能和风险。管理用于确定应对措施的优先级，并监控控制措施是否有效。

NIST 于 2023 年 1 月发布了原始框架，并于 2024 年 7 月增加了生成式 AI 概要，以应对生成式系统带来或加剧的风险。

该框架并未规定必须采用某一种模型、供应商或技术栈。它的重要性在于迫使组织回答一系列问题。团队必须先定义风险，才能声称自己已经对其进行了管理。

这些答案需要落实为产品功能。如果一项政策要求可追溯性，系统就需要日志和稳定的标识符。如果它要求人工问责，工作流就需要明确具名的决策负责人。

如果组织承诺进行监控，就需要设定性能阈值和事故处理流程。如果承诺保护隐私，就需要数据最小化、留存控制和访问权限执行机制。

欧盟通过《AI 法案》设立了法律义务，推进得更进一步。该法律采用基于风险的结构，对被指定为高风险的用途提出更严格的要求。

随着欧洲机构制定配套规则和标准，该法案的实施时间表也有所调整。根据欧盟委员会当前的《AI 法案》时间表，透明度义务已于 2026 年 8 月 2 日开始适用。

包括就业、教育、关键基础设施和移民在内领域的高风险规则，计划于 2027 年 12 月 2 日实施。嵌入受监管产品中的 AI 规则，计划于 2028 年 8 月 2 日实施。

这些较晚的日期提供的是准备时间，而不是推迟架构决策的许可。当前进入采购流程的系统可能会持续运行多年。买方必须判断，今天的产品能否支持明天的文档记录和监督义务。

技术标准和执法指引仍在不断发展，因此不确定性依然存在。组织不能假定，采用通用框架就能保证符合每一项行业规则。

不过，它们仍可建立可复用的基础。资产清单、风险分类、来源记录、评估结果、事故日志和责任归属图，都能支持多个监管体系。

AI 清单记录的内容不应仅限于模型名称。它还应标明使用场景、操作人员、受影响人群、数据类别、部署环境、外部提供商以及允许采取的操作。

版本控制必须覆盖完整系统。即使模型保持稳定，在提示词、检索来源、安全过滤器或业务规则发生变化后，其行为也可能不同。每个实质性组件都应纳入变更记录。

评估同样需要结合具体背景。单一基准测试分数很少能代表生产环境。团队应测试真实输入、少见情形、对抗性行为，以及人类最依赖输出的场景。

监控必须与行动相连。当没有人负责响应时，报告性能下降的仪表板几乎无法提供保护。阈值应触发审查、限制、回滚或暂停。

这些功能可能会拖慢初期开发，但也能减少买方和审查人员的不确定性。具备可访问证据的产品，比仅靠笼统保证支持的产品更易评估。

治理仍可能沦为昂贵的表演

当组织产出文件却未能获得对系统的控制时，治理便会失效。

证据优先的方法也有其失效模式。团队可能制作出资产清单、风险评估、审批表和政策文件，但日常运营却毫无变化。

当治理以文件完成度来衡量时，就会发生这种情况。项目获得批准，是因为每个必填字段都填了文字，而不是因为审查人员验证过相关声明。

泛泛的风险表述会让问题更加严重。诸如“已提供人工监督”之类的说法，并未说明谁审查输出、何时审查，或审查者能获得哪些证据。

同样的弱点也会出现在供应商问卷中。供应商可以描述加密、测试和监控，却不展示这些控制措施如何适用于买方的特定工作流。买方随后便会继承这一保证缺口。

采用框架并不会消除这一缺口。NIST 明确将其框架定位为自愿且可适配的。组织仍需将其中的功能转化为适合各使用场景的控制措施。

合规团队也可能设置过多限制。将每项 AI 功能都视为同等危险，会增加审查成本，并促使员工转向未经批准的工具。当官方系统无法满足日常需求时，影子 AI 就会增长。

风险分类提供了务实的答案。团队应将最严格的控制措施留给影响权利、安全、资金或基本服务的系统。低风险辅助功能则可在较轻的规则下运行。

这种按比例施策的方法之所以困难，是因为风险会随背景变化。总结工具在员工用其输出拒绝理赔前，看起来可能无害。检索助手在获取受法律特权保护的法律记录或医疗记录时，会变得更加敏感。

因此，组织需要同时审查预期用途和合理可预见的滥用方式。它们应观察员工实际如何使用产品，而不只是看最初提案如何描述。

另一个不确定性涉及模型评估。供应商通常报告基准测试结果，但受监管的买方需要来自自身数据和工作流的证据。通用性能并不能证明其适合特定人群。

测试也可能遗漏罕见但严重的故障。在数千个案例中看似很小的错误率，若错误影响患者安全或个人权利，仍可能不可接受。

人工监督并非万无一失的解决方案。审查人员可能变得过度自信，尤其是在 AI 输出流畅且通常正确时。重复会助长自动化偏见，即倾向于相信自动化建议而非相反证据。

有效监督需要培训、工作负荷规划和界面设计。审查人员需要看到明确的来源和不确定性信号，也需要能够拒绝建议，而不因此面临生产率惩罚。

组织必须跟踪人工覆盖和分歧。较高的覆盖率可能揭示模型质量不佳。极低的覆盖率则可能表明性能强劲，也可能意味着审查薄弱。

外部审计提供了另一层检查，但其范围至关重要。对模型提供商的审计，并不会自动验证客户的提示词、数据、集成或人工工作流。

对供应商的依赖进一步增加了问责的复杂性。提供商可能更新模型、安全政策或托管安排。客户必须知道哪些变更需要重新测试，以及是否能够提前收到通知。

这些局限并不会削弱治理的必要性，反而说明了有意义的治理需要什么。它必须影响权限、架构、评估、部署和事故响应。

受监管的 AI 项目应当能够证明这种影响。如果治理未带来任何可观察到的技术或运营变化，它很可能只是一场表演。

修复始于一个明确负责的工作流

组织应先证明一个受控工作流可行，再将模型扩展至整个企业，以此改善采用效果。

第一步是选择一个边界明确的使用场景。边界明确的使用场景应有具名负责人、定义清晰的用户、获批数据、可衡量的结果，以及对自动化操作的明确限制。

“利用 AI 改善客户服务”并不算边界明确。“使用经批准的政策文件，为常规账户问题起草回复”则更接近可操作的定义。

第二步是梳理决策路径。团队应记录哪些内容进入系统、模型产生什么、由谁审查，以及随后采取什么行动。

这张图应识别每一个存储或转换数据的系统，也应显示外部模型提供商在何处接收信息，以及它们会保留哪些信息。

第三步是在采购前定义证据要求。买方应决定自己需要哪些日志、评估记录、安全控制和变更通知。随后便可依据具体的运营要求评估供应商。

第四步是创建 AI 系统记录。该记录应标明负责人、模型、版本、数据来源、用途、用户、已知限制、评估方法、审批状态和监控计划。

第五步是评估完整工作流。模型准确性只是其中一个组成部分。团队还应测试检索、访问权限执行、输出呈现、人工审查、下游操作和故障恢复。

测试应涵盖预期情形和边界情形，也应包括试图获取被禁止的信息、绕过控制措施，或通过不可信内容操纵系统的行为。

第六步是限制权限。读取、起草、建议、批准和执行应保持为不同权限。模型只能获得完成其任务所需的权限。

第七步是建立干预规则。团队必须决定，当置信度下降、证据相互矛盾、监控发现漂移，或用户报告损害时应如何处理。

回滚计划很重要，因为仅更换模型并不总是足够。组织可能需要停用某项集成、恢复之前的提示词、移除数据源，或让工作流回到人工操作。

第八步是在衡量风险的同时衡量采用情况。仅看使用量是一个薄弱指标。大量生成输出，并不能说明员工是否信任它们，或它们是否改善了结果。

有用的指标包括完成时间、修正率、升级处理、审查人员分歧、缺乏支持的声明、访问违规和事故。正确的组合取决于工作流。

组织还应关注谁在避开该系统。低采用率可能反映培训不足，但也可能暴露产品与实际工作相冲突。当官方工具增加审查步骤却无法节省时间时，员工往往会保留手工替代流程。

第九步是发布清晰的运行边界。用户应知道系统能够做什么、不能决定什么、可以接收哪些数据，以及应在何处报告问题。

最后一步是受控扩展。团队在增加部门或操作时，应复用已被验证的控制措施。它们不应假定，一个工作流中的成功就证明另一个工作流同样安全。

这一顺序将 AI 采用重新定义为一种运营纪律。它以一系列可测试的部署，替代了一个宏大的转型承诺。

这种方法在高管演示中或许显得不那么雄心勃勃，但它为员工、审查人员和监管机构提供了更有价值的东西：一个其行为和责任归属都能被理解的系统。

Google News 读者接下来应关注什么

下一阶段将显示，供应商和企业买方是否会将治理声明转化为可验证的产品行为。

第一个信号是欧盟透明度要求的落实情况。根据欧盟委员会当前的时间表，这些规则已于 2026 年 8 月 2 日开始适用。

买方应关注供应商是否提供更清晰的信息披露、内容标签、系统文档和模型信息。一致的落实将强化证据优先的方法；模糊的说明则表明，合规仍与产品设计相互脱节。

第二个信号是高风险 AI 技术标准的发展。标准可以将宽泛的法律要求转化为可重复执行的工程与评估实践。

其价值取决于具体程度。实用的标准应帮助团队明确文档、监控、测试、数据质量和人工监督的要求。若要求始终停留在抽象层面，买方仍将面临同样的解释难题。

第三个信号是部署后的实际情况。组织应披露更多关于事故、人工干预、模型变更和暂停使用系统的信息。

成功的试点很容易被宣布。真正持久的采用，则会通过稳定使用、可衡量的成果、有记录的纠正措施和受控扩展体现出来。

Google News 的报道可能仍会强调大规模失败统计数据，因为这类数字容易形成清晰的新闻标题。读者应透过这些数字，了解每项研究如何定义“失败”。

从未进入生产环境的项目，与上线后却没有可衡量回报的项目不同。因安全原因被撤回的系统，也不同于员工单纯不喜欢使用的工具。

这种区分很重要，因为每种失败都需要不同的应对方式。集成薄弱需要重新设计工作流程；准确性不足需要技术改进；信任度低则需要证据和用户参与。

职责不清需要治理机制。风险过高则需要缩小自动化范围，或完全不部署。

更广泛的教训并非监管会阻碍 AI 采用。只要组织能够建立安全性、问责机制和运营价值，受监管行业已经在部署 AI。

真正的障碍，是从演示直接跃迁到机构信任，却缺乏支撑。只有当模型周边的系统能够产出证据时，模型才能跨越这一鸿沟。

企业买方在批准下一项试点前，应提出一个实际问题：这一工作流程能否解释其来源、权限、决策、审查者和变更？

如果答案是否定的，再多一次模型演示也无法修复项目。如果答案变为肯定，受监管领域的 AI 采用就拥有了一条超越试点的可信路径。