2012年，一家大型投行的风险管理团队发现了一个问题。

一位交易员三年前写的Excel宏，最初只是为了加速自己日常数据整理的工具，已经在不知不觉中成为该部门核心风险报告的计算引擎。没有文档，没有版本控制，没有审计日志。只有这个文件，在所有人都不知道的情况下，每天傍晚自动运行，生成提交给董事会的风险数字。

三年后，一个公式错误被发现了。在那之前，这个错误已经悄悄影响了三年的风险报告，而没有人知道。

这是”EUC”（End User Computing，终端用户计算）风险的经典案例。从2012年到2022年，全球银行和金融机构为此运行了大规模的整治程序：建立电子表格档案库，按风险级别分类，把高风险的”影子系统”重建为受治理的正式应用。这些程序耗时数年，花费数亿美元，但它们最终有效——在2022年之后，由电子表格导致的重大监管事故明显减少了。

然后，2025年，Copilot平台来了。

2026年9月20日，AWS金融行业博客发布了一篇文章，标题是《EUC 2.0：为什么不受控制的Copilot平台是金融服务业的下一个治理挑战》。文章由四位AWS金融行业顾问联合撰写，核心观点简洁而直接：业务人员在托管Copilot平台上自建、无治理的AI Agent，正在成为继电子表格之后金融业新一代EUC风险——而且这次，风险来得更快，影响面更广，后果更难预测。

这不是一家咨询公司的营销文章，也不是学术研究者的假设推演。写这篇文章的人，每天都在与全球顶级银行的CIO和CRO打交道，见到的是真实的混乱正在形成，而不是假想的风险场景。

为什么历史必然会重演

理解EUC 2.0，需要先理解EUC 1.0为什么是一个问题，然后理解AI Copilot如何复制并放大了这个问题的结构。

电子表格的风险不来自电子表格本身，而来自一种特定的模式：一个领域专家，用强大的工具，在没有任何软件工程意识的情况下，创建了一个影响受监管流程的系统。交易员擅长金融建模，不擅长软件工程。他们创建了功能完整、逻辑正确（大多数情况下）的工具，但没有文档、没有测试、没有变更记录。当这个工具意外地成为某个重要流程的关键依赖，整个组织就暴露在一个不透明的风险里——没有人知道这个工具存在，没有人能评估它是否正确，没有人知道如果它出错会影响哪些下游系统。

AI Copilot平台（一种让业务用户在不写代码的情况下，通过自然语言构建AI工作流和Agent的企业环境）的到来，精确地复制了这个模式，但在三个关键维度上将风险量级大幅放大。

速度（Speed）的维度。一个业务用户可以在数小时内构建、部署并投入运营一个AI Agent。相比之下，一个电子表格从”个人工具”变成”影子系统”通常需要数周到数月——这个时间本身给了治理层发现和介入的窗口。AI Agent没有这个窗口。它可以在一个周五下午被创建，周一早上已经在处理真实的业务流程。

主动性（Agency）的维度。电子表格计算数据，人类执行。一个Excel公式不会自己发邮件，不会自己更新客户记录，不会自己触发监管流程中的某个审批步骤。但一个AI Agent会。它在无人监督的情况下发送邮件，更新记录，触发工作流，运行定时任务。当这个Agent出错，它不只是产生一个错误的数字——它产生了一系列错误的行动，每一个行动都可能进一步传播错误。

影响半径速度（Scope radius velocity）的维度。一个电子表格的错误，通常只影响直接依赖它的那一个流程，而且影响速度是人类的工作速度——一天能处理多少文件，错误就影响多少。一个错误的AI Agent可以在多个下游系统中同时传播错误的输出，速度是机器级别的。AWS文章把这三个维度的乘积称为”EUC 2.0的风险量级”：快速扩散 × 自主行动 × 广泛影响，三个维度同时被放大，风险不是加法而是乘法。

AWS的文章提出了一个引人深思的具体场景：

“想象一下你团队里的一个合规分析师，他在托管Copilot平台上构建了一个个人Agent，这个Agent拉取客户投资组合数据，运行分析，输出建议。这些建议被复制粘贴进了一份受监管的建议文件。这位分析师使用的工具、凭证、界面，和他的同事用来总结邮件的完全一样。工具是相同的，但使用方式在类别上完全不同。”

这个场景的可怕之处在于：平台无法自动看到这个区别。从技术层面，总结邮件和生成监管建议，在系统日志里看起来是同一类操作。这意味着传统的”应用白名单”机制——先批准工具，然后所有人都可以用——在AI Copilot的时代完全失效了。

发现优先：治理框架中最常被跳过的步骤

AWS文章提出的核心主张是：任何治理框架，如果从”分类你们组织里运行的AI工作负载”开始，都已经跳过了最关键的前提步骤。分类需要清单，清单需要发现。

这是EUC 1.0整治运动最昂贵的教训。银行在2012-2022年间，花费了治理成本的很大比例在”找到那些重要的电子表格”上。不是分类，不是治理，而只是发现它们存在。很多银行运行了多轮清查运动，每次都在他们以为已经覆盖的范围之外，发现了更多没有被记录的影子系统。一部分电子表格的发现，是通过事故倒推的——因为某个报告出了问题，追查来源才发现某个关键计算依赖一个无人知晓的文件。

在AI Copilot平台上，同样的挑战以更难的形式出现，但也有一个关键的新优势。

难的部分是：AI Agent的创建比电子表格的创建更快、更隐蔽。一个合规分析师不需要写任何代码，她/他只需要在Copilot界面里用自然语言描述任务，点击几次，Agent就运行了。这个过程可以在10分钟内完成，而且在创建的那一刻，创建者很可能完全没意识到她/他在构建一个”系统”。

优势在于：托管Copilot平台提供了电子表格时代从未有过的可观测性。平台日志记录了对话历史、Agent创建事件、数据源连接请求，以及自动化调度的运行记录。这些探测控制（detective controls）能够在技术上提供”发现”的能力——只要有人设置了正确的监控和报警机制。

这是AWS文章最重要的洞察之一：与电子表格时代相比，EUC 2.0的问题在技术层面更难，但治理层面的工具更强。银行有机会做到当年电子表格治理运动做不到的事情——真正在风险发展成危机之前发现并处理它。

但这个优势能否实现，取决于银行是否愿意为”发现”投入资源。这不是技术投资，而是组织优先级的投资——需要有人提出这个问题，分配预算，建立流程，并坚持执行。

四层分类框架的逻辑与局限

假设发现机制已经到位，接下来的问题是：发现了这些AI Agent之后，如何处理？

AWS的文章提出了一个四层分类框架，把AI Copilot使用场景按照风险级别分层管理：

第一层（个人生产力）：不接触组织数据的个人工具。总结邮件、帮助起草文件、辅助个人研究。Agent的输出不会进入任何业务流程，即使出错，影响范围也只限于这一个用户。这一层按照EUC的经验，不需要额外的治理负担，但需要基本的注册记录。

第二层（团队工作流）：在团队内部共享，可能接触内部数据，但不直接影响外部监管流程或客户面向的输出。这一层需要基本的文档和Owner认定，但不需要正式软件工程级别的测试和审计要求。

第三层（业务关键流程）：接触客户数据、内部财务数据，或者其输出会影响业务决策——但不一定是受监管的决定。这一层需要完整的文档、定期的准确性审查，以及明确的人工复核机制，确保AI的输出在进入业务决策之前经过了人类的有效确认。

第四层（关键任务流程）：直接影响受监管的输出，或者直接影响客户面向的建议和决策。这一层需要完整的软件开发生命周期治理：版本控制、测试套件、变更管理、完整的审计日志、以及正式的风险评估。对于金融机构，这一层的Agent，应该被当作”正式业务系统”来管理，而不是”Copilot平台上的工作流”。

这个框架的价值在于它提供了一个可操作的分类起点，而不是把所有AI使用都纳入最高级别的合规要求（那会让所有人放弃使用）或者完全不管理（那会复制EUC的灾难）。

但AWS文章自己也承认了这个框架一个无法绕过的核心难题：分类会漂移。

一个从第一层个人工具开始的Agent，在没有任何人主动决策的情况下，可能因为有效而被越来越多的人使用，最终处理着越来越关键的数据和流程。这种”自主性漂移”——AWS文章的用词——是EUC整治运动中最难对付的问题：你成功地给今天的系统分了类，但系统会悄悄地改变自己的重要性级别。

对抗自主性漂移，需要的不只是初始分类，而是持续的使用监控和自动化的重新分类触发机制。这在技术上可实现，但在组织执行层面需要持续投入，是一个需要永久维护的体系，而不是一次性建立后就可以完成的项目。

与中国金融机构的对话

AWS文章的直接受众是在欧美监管框架下运营的金融机构，但它描述的问题在中国同样真实，甚至在某些方面更为紧迫。

中国四大行以及主要股份制银行，都在2024-2026年大规模部署了企业级AI平台。根据各银行年报和公开声明，建设银行在2025年已有超过10万名员工在使用AI辅助工具；招商银行部署的AI客服系统处理了超过60%的线上客户咨询；工商银行的AI中台项目已覆盖信贷、风控、客服等多个核心业务线。

这些是经过IT部门正式立项、经过合规审批的”官方”AI系统。但在这些系统之外，有多少业务人员在企业Copilot平台上自行构建了AI工作流？有多少这样的工作流已经进入了第三层甚至第四层的风险级别，但没有经过任何正式的审批流程？

目前没有公开的数据能够回答这个问题，但按照EUC 1.0的历史经验，可以有相当高的信心判断：数量不少，风险不低。

中国金融监管机构（中国人民银行、国家金融监督管理总局）在2023-2026年间发布了一系列关于金融科技和AI使用的监管指导文件。2024年8月，金融监管总局发布的《银行保险机构数据安全管理办法》要求金融机构对数据处理活动（包括AI处理）进行分类分级管理，并建立相应的审批流程。2025年3月，人民银行的《金融人工智能应用自律公约》进一步明确了AI系统应当具备可解释性和人工介入机制的要求。

这些监管要求在原则上覆盖了EUC 2.0的风险场景，但在操作层面，”业务人员在Copilot平台上构建的工作流是否属于需要报批的AI系统”，仍然是一个待定的模糊地带。监管的执行，通常落后于技术实践，这不是中国特有的问题，而是全球监管机构面对AI速度时共同的挑战。

中国金融机构在这个问题上的窗口期，可能比西方机构更短。中国监管机构的执行速度在一些领域（比如数据安全、互联网金融）已经展示出可以非常迅速。如果某个AI Agent引发的事故引起了监管层的注意，整个行业的应对时间可能以月计，而非年计。

McKinsey的数字与治理成本的现实

AWS文章引用了McKinsey的估算：AI每年可以为全球银行业带来2000亿到3400亿美元的生产力潜力，相当于行业运营利润的9%到15%。这个数字在AI投资决策的Pitch材料里几乎无处不在。

但有一个对应的数字很少被同时引用：EUC整治程序在2012-2022年间花费的成本。行业分析师的估算差异很大，从数十亿到数百亿美元不等，取决于统计口径。无论具体数字是多少，EUC整治是近20年来金融机构规模最大的内部IT项目之一，许多银行把它列为”比Y2K更贵的合规项目”。

如果EUC 2.0以同样的轨迹发展，同样规模的整治成本会在更短的时间内到来，因为AI的渗透速度比电子表格快得多。

McKinsey 2000亿到3400亿美元的生产力潜力，需要用什么作为分母？一个现实的分母，应该包括治理成本、合规成本、以及一旦出现重大事故时的补救成本。在没有把这些成本纳入计算之前，这个潜力数字是一个上限估算，而不是一个净收益预测。

AWS文章说得非常直接：”不采用AI生产力工具的竞争含义，与在没有治理的情况下采用它们的风险同样重要。”这是一个均衡的陈述，但它的逻辑指向很清楚：效率和治理不是选择题，而是必须同时推进的两条腿。

已知的历史警告：EUC 1.0的两个灾难案例

在讨论理论框架之前，值得回顾EUC 1.0留下的两个具体历史教训，因为这两个案例的模式，在EUC 2.0的场景里会精确地重演。

案例一：摩根大通2012年”伦敦鲸”事件。布鲁诺·伊克西尔（绰号”伦敦鲸”）在信用违约互换市场上的交易导致了约60亿美元的亏损，是当年最大的交易损失事件之一。事故调查后来揭示的原因之一，是该团队用于计算VaR（风险价值）的电子表格存在模型错误——一个公式把本应相加的数字做了平均计算，低估了头寸的风险。这个电子表格，在没有任何正式IT审查的情况下，已经成为数十亿美元头寸管理的核心工具。这不是唯一原因，但它是一个清晰的EUC风险实例：业务人员构建的工具，在没有软件工程治理的情况下，成为了关键金融决策的依据。

案例二：一个典型的亚太区银行EUC整治触发场景（综合自多家银行的匿名案例）。一个衍生品团队用Excel计算每日的抵押品需求，这个文件在内部被当作”官方数据源”，但实际上从未经过IT部门的正式审批。某次更新导致宏产生了循环引用错误，计算结果出现重大偏差。当天的抵押品缺口没有被正确标记，直到下午结算时才被发现。虽然最终损失有限，但监管机构对这一类事件的关注，直接触发了一批亚太区银行启动EUC整改项目，通常耗时12-24个月，成本从数千万到数亿美元不等。这类案例在行业内部广为流传，但往往以匿名或保密形式处理，因为公开此类事故本身就会引发监管关注。

这两个案例的共同模式是：业务人员构建的工具，在无人管理的情况下积累了足够的重要性，然后在某个意外的节点出错，暴露了整个体系的脆弱性。

AI Copilot的场景，结构完全相同。唯一的不同在于，AI Agent的”出错”不只是一个计算错误——它可能是一系列基于错误推理的主动行为，在被发现之前已经产生了无数个二阶影响。

一个合规Agent因为训练数据偏差，在评估某类客户群体时系统性地降低了风险评分，而这个偏差在六个月内一直没有被发现——因为没有人定期审查这个Agent的输出，也没有任何机制会自动报警。当监管机构的检查揭示了这个问题，银行面临的不只是技术修复，而是对过去六个月所有相关决定的重新审查。

这不是假设。这是2026年已经在一些早期采用AI的金融机构内部悄悄发生的事情，只是还没有一起大到成为公开的监管事件。

组织变革的真正难题

技术框架（四层分类 + 发现优先 + 平台遥测）是可以设计的，但这个框架的有效性最终取决于组织层面的一系列决定，而这些决定都不容易做。

第一个决定是资源分配。治理是成本，效率是收益。在年度预算会议上，为”AI治理框架建设”争取资源，意味着和”扩大Copilot使用规模”的项目竞争同一个预算池。历史经验证明，在EUC整治运动真正启动之前，每一次为治理申请预算的CRO都会遇到”为什么现在？情况还没那么严重”的质疑。

第二个决定是申报摩擦的接受程度。任何要求业务人员主动申报的治理流程，都会降低Copilot的使用便利性。一个第三层或第四层的Agent需要申报并等待审批，这个等待时间可能让业务人员放弃或者寻找绕过机制。组织需要接受一定程度的”便利性损失”，作为治理代价——但接受多少，在不同的业务团队和管理层之间，很难形成共识。

第三个决定是如何处理已存在的未申报Agent。发现机制上线后，必然会发现大量已经在运行的、未经申报的AI Agent，其中一部分可能已经在处理第三层甚至第四层的工作负载。如何处理这些Agent——立即下线？给过渡期？追溯申报？这个决定不只是技术决定，也是影响业务连续性和员工关系的组织决定。

银行在EUC整治运动中学到的一个最重要的教训是：治理的成功，70%在于组织变革管理，30%在于技术框架。技术框架可以外包给咨询公司，但组织变革只能由内部领导层推动。

竞争格局中的压力：谁会先出事

有一个经常被忽视的动态，让EUC 2.0的治理更难推进：竞争压力会让银行倾向于选择”先用起来，治理稍后”的路线，因为那些还在等待治理框架就绪的银行，会落后于那些已经在生产中使用Copilot Agent的竞争对手。

这是一个囚徒困境的变体。如果所有银行都同时推进治理然后再使用，行业整体风险最低。但在竞争市场里，每个银行的个体理性是”先用起来”——因为落后对手6个月部署Copilot，可能意味着失去市场份额，而出事的概率相对还是小的。这个逻辑在EUC 1.0时代同样存在，结果是整个行业都在没有足够治理的情况下深度依赖了电子表格，然后花了十年时间集体治理。

AWS文章没有直接谈这个竞争压力，但任何金融行业的资深从业者都知道它的存在。巴塞尔协议、GDPR、MiFID II等监管框架之所以能真正改变银行行为，是因为它们同时约束了所有竞争者，让”合规”成为最低标准而不是竞争劣势。

如果监管机构不针对AI Copilot使用建立明确的框架要求，个别银行对治理的投入，就会成为单边的竞争负担。这个现实，是推动银行自律治理的最大障碍。

在这个背景下，AWS发布这篇文章的时机值得关注：它不只是一份技术分析，也是向金融行业监管机构发出的一个信号——”行业需要更明确的指导”。如果这类文章和案例积累到足够的量，金融稳定委员会（FSB）、巴塞尔委员会或各国央行很可能会在2027年提出针对金融AI使用的补充监管框架。

届时，那些已经建立了EUC 2.0治理体系的银行，会发现自己的合规成本相对更低；而那些没有建立的，会面临一个仓促应对监管要求的高成本窗口。这是”先行投入治理”的长期理性所在，但在短期竞争压力下，这个长期逻辑很难自然浮现。

结尾：下一个十年的选择

全球银行业在2012-2022年间，用十年时间治理了电子表格的遗留问题。那十年最昂贵的部分，不是治理本身，而是发现问题之前的那十年——当电子表格已经成为影子系统，但没有人知道也没有人管理的那个时期。

AI Copilot平台的普及，正在制造下一个”那十年”的起点。区别在于，这一次，技术工具已经提供了发现的能力，而且有银行业真正经历过EUC 1.0的管理者仍然在岗，能够认出这个正在形成的模式。

这是一个可以改变结局的时刻。不是通过限制AI的使用，而是通过建立让AI的使用可见、可分类、可治理的机制，让Copilot平台的生产力潜力和合规安全不再是对立的。

但这个结局需要有人做出选择：在危机发生之前，为治理投入资源。

历史证明这件事很难。但历史也证明，选择不做的代价，通常比做了的成本更高。

那些在这个时间点选择建立治理框架的银行，不只是在管理风险——它们在为未来的监管要求做投资。在AI治理的历史叙事里，它们会是”做对了的那一批”，而不是那批”等到出了事才开始整改”的机构。这个选择，比任何单一的Copilot生产力项目，对机构的长期合规成本有更深远的影响。

参考资料

  1. EUC 2.0: Why Uncontrolled copilot platforms are Financial Services’ Next Governance Challenge — AWS for Industries Blog, 2026-09-20. https://aws.amazon.com/blogs/industries/euc-2-0-why-uncontrolled-copilot-platforms-are-financial-services-next-governance-challenge/

  2. Banking’s Gen AI Opportunity ($200B-$340B annual productivity potential) — McKinsey & Company, 2024. https://www.mckinsey.com/featured-insights/charts/bankings-gen-ai-opportunity

  3. Amazon’s AI Recruiting Tool Was Systematically Biased Against Women — Reuters, 2018-10-10. https://www.reuters.com/article/us-amazon-com-jobs-automation-insight-idUSKCN1MK08G

  4. EU AI Act: First regulation on artificial intelligence — European Parliament, 2024. https://www.europarl.europa.eu/topics/en/article/20230601STO93804/eu-ai-act-first-regulation-on-artificial-intelligence

  5. AI cloud bills are forcing technology leaders to rethink AWS, Azure and GCP commitments — CIO.com, 2026-09-15. https://www.cio.com/article/4221822/ai-cloud-bills-are-forcing-technology-leaders-to-rethink-aws-azure-and-gcp-commitments.html