云与人工智能发展法案：欧洲真正想修的是什么
欧洲的技术政策已经变成了什么样子，《云与人工智能发展法案》是迄今最清晰的一次表态。它不是消费者保护法，也不是安全法。它是产业政策，针对一个单一问题：欧洲数字经济的大部分，跑在自己控制不了的基础设施上。
这和《通用数据保护条例》或《人工智能法案》不是同一类监管，触及你的机制也不一样。搞清楚是哪个机制，比读序言条款更重要。
它在回应的问题
背后的数字没有人有异议。欧洲云基础设施支出的绝大部分流向非欧洲提供商。欧洲公司用的那些最大的人工智能模型，训练和托管都在欧洲之外。欧洲的算力容量只占全球总量的很小一部分。
有十年时间，这被视作市场的自然结果。2022 年之后，它变成了一种战略脆弱性，原因与技术毫无关系：贸易紧张、出口管制，以及一个逐渐清晰的认识，即基础设施依赖本身就是筹码。
《云与人工智能发展法案》是这次重新评估在立法上的落点。与它并行推进的还有《人工智能大陆行动计划》、InvestAI 倡议、人工智能超级工厂计划，以及从德拉吉报告延伸出来的整套竞争力议程。
预计它会做什么
这份提案是欧盟委员会工作计划的旗舰项目，目标定在 2026 年上半年。历次公告里宣称的目标是一致的：
增强欧洲开发、部署和扩展云与人工智能的能力。 实际上说的是算力、数据中心，以及在欧盟境内训练和提供大模型服务的能力。
弥补监管空白。 现有框架主要通过《数据法案》的切换条款和 NIS2 的安全义务来处理云。两者都不涉及容量或战略依赖。
促进互操作性。 降低在提供商之间迁移的技术成本。《数据法案》 从合同一侧下手，针对的是同一个政策目标。
为公共行政机构和公共采购建立全欧盟范围的云政策。 这一条才真正有约束力。对成员国公共机构如何采购云形成统一做法，并带有欧洲偏好维度。
支持安全且有竞争力的欧洲云与人工智能生态。 兜底项。
真正会触及你的那个机制
关于这份文件，有件事值得弄明白。大多数技术监管直接触及私营公司：你处理个人数据，因此《通用数据保护条例》适用于你。而《云与人工智能发展法案》更可能通过采购间接触及大多数公司。
欧盟公共部门的技术支出规模巨大。如果成员国公共机构被要求、或者被强烈鼓励采购欧洲云，那么每一家向公共部门销售的厂商，可触达的市场都会变，而且这种变化会经由总承包商一层层向下传导到供应商。
这个套路在无障碍领域已经见过一次。《欧洲无障碍法案》 有直接义务，但实践中大量无障碍工作是由公共采购规则推动的，那些规则早在指令适用之前就把不合规的供应商排除在外了。
这里也会一样。你的基础设施跑在哪里、谁在控制、能不能迁走，这些问题会从安全问卷挪进资格标准。
这对架构意味着什么
读到主权政策时的本能反应，要么是无视，要么是恐慌式迁移。两者都不对。合理的做法是确保这个问题你答得上来。
弄清楚你的数据和算力究竟在哪
这听起来是件小事，其实不是。在一个成熟的系统里，“这跑在哪里”的诚实答案往往涉及一个主区域、一个备份区域、一个边缘节点位置不明的 CDN、一个托管数据库、三个各自带有子处理者的 SaaS 依赖、一个可观测性厂商，以及一个推理位置没有文档记录的人工智能 API。
画一张准确的地图是第一项真正的工作，而且它和你做 《通用数据保护条例》跨境传输分析、回答 NIS2 供应链问题时要用的是同一张。画一次就够。
把可移植的部分和不可移植的部分分开
几乎每个系统都有一个可移植的内核，外加一组绑定了特定提供商的依赖。可移植的内核通常是应用本身。不可移植的部分通常是托管服务：专有数据库、无服务器运行时、队列、身份，以及越来越多的模型 API。
你不必把这些都消掉。但你必须清楚它们都有哪些，因为那份清单就是“迁移有多难”的诚实答案，也正是采购问卷真正在问的东西。
把模型提供商当作一条抽象边界
这是最新、也最常被跳过的一条。如果一个应用直接调某一家厂商的模型 API，厂商特有的提示词格式和响应处理又散落在代码库各处，那它其实已经在不知不觉中做了一个依赖决定。
在模型调用之上做一层薄抽象，写的时候成本极低，换来的是随时改道的能力：改到欧洲提供商，改到跑在欧洲基础设施上的开放权重模型，或者干脆换一家厂商。考虑到模型格局变化之快，仅从商业角度看就值得做。
测试退出路径，而不只是把它写进文档
《数据法案》 已经赋予你切换云服务商的权利，切换费用自 2027 年 1 月 12 日起完全取消。很少有买家用这项权利，更少有人去验证自己有权拿到的导出数据能不能真把服务重建起来。
去跑一次导出。试着解读它。提供商声称可以导出的东西，和实际能用起来的东西，中间那段差距就是锁定的所在，也正是主权问题的诚实答案。
它不是什么
保持合理的怀疑是应该的，现在看清楚好过以后被吓一跳。
这不是禁用美国云。 已公布的内容没有任何迹象表明会禁止私营公司使用非欧洲提供商。机制是采购偏好和能力建设，不是禁令。
容量不会因为一部法律说了就出现。 欧洲云容量有限，是因为建数据中心和训练前沿模型是资本密集型的，而欧洲直到最近才按所需规模投入资本。我们在 欧盟技术资助指南 中讨论的资助计划才是这里真正的工具。这部法案是围绕它们的框架。
主权标签不等于主权。 有几种方案把自己包装成主权云，实际上是在授权许可下跑非欧洲技术，运营独立性参差不齐。这能不能满足未来的采购规则，恰恰是这部法案必须回答的问题，而它还没有回答。
它还是一份提案。 在文本出来、理事会和议会各自形成立场之前，细节无从判断。能判断的是方向，而这个方向在欧盟委员会三年来的表述里始终一致。
这与其他一切怎么连起来
《云与人工智能发展法案》是一次协调推进中的一环，孤立地读它会让它显得比实际更弱。
《人工智能法案》 规范人工智能系统的行为。《数据法案》 从合同层面下手，对付云锁定。NIS2 把供应链审查沿着厂商链条往下压。《网络韧性法案》 把安全义务加在产品上。InvestAI 和超级工厂计划把钱投进算力容量。《云与人工智能发展法案》补上采购和互操作性这一层。
单看每一项都像是渐进的负担。合起来看，它们描述了一个相当连贯的赌注：欧洲可以通过把市场准入规则和公共资金结合起来，用监管的方式走出一个本土技术基础。
这个赌注能不能成立，是个合理的疑问。至于赌注已经下了，则没有疑问。
未来十二个月做什么
建基础设施地图。 每样东西跑在哪、谁在运营、合同上的退出路径是什么。这张图另有四种用途。
把真正不可移植的依赖找出来，并诚实地给迁移估个价，哪怕你永远不会真去迁。这是采购问题的答案，本身也只是好的架构习惯。
如果还没有，就在模型提供商之上加一层抽象。 现在便宜，以后昂贵，而且出于与政策无关的理由也有用。
如果你向欧洲公共部门买家销售，盯采购这条线要比盯法案本身更紧。 那里才是这项要求首次以资格标准形式出现的地方。
不要凭猜测搬家。 为一份尚未发布的提案而搬迁基础设施，正是很多组织花掉一年时间和一大笔预算、最后发现根本没这个必要的典型路径。
需要帮助时
我们为在欧洲经营的公司设计和构建云基础设施、数据平台和人工智能集成，包括那些不光鲜的工作：让一个系统真正可移植，而不是名义上可移植。
如果你需要一张基础设施与依赖地图、一次针对现有提供商的退出测试，或者一层模型提供商之上的抽象，请写信到 office@c9group.dev。关于我们的基础设施工作，更多内容见 AWS 成本优化页面，关于我们在欧洲的工作见 欧盟市场进入页面。
更广的立法图景在我们的 欧盟数字立法管线 中，这项议程背后的资金梳理在我们的 欧盟技术资助指南 中。
我们是工程师，不是政策顾问。这是对一份提案的规划视角，不是法律意见。