关于我们

质量为本、客户为根、勇于拼搏、务实创新

< 返回新闻公共列表

欧盟云合同从 2025 年 9 月起多了一类条款:换供应商的过渡期和出口费该怎么谈

发布时间:2026-10-14

把一笔典型的云迁移预算摊开看,会发现一个不太合理的地方:那几十 TB 数据本身按容量算并不贵,真正把账单推上去的是另外几项。数据离开原服务商网络时按流量计的那一段、把专有快照与内部格式转成可以再次写入的形态所需的转换与人工、切换期间两边同时运行造成的双份资源、为了压缩停机窗口而必须在夜间完成的加班与验证。数据越攒越多,反而越走不动,贵的不是数据,是“离开”这个动作本身。

更麻烦的是,这几笔账过去并不由你决定。出网怎么计费、导出给不给机器可读的格式、可否并行运行多久、多久才能把人放走,几乎全在原供应商的一侧手里。谈判桌上能做的,只有一项一项地申请减免,运气好拿到部分免除,运气不好就是在切换窗口前几周才发现某些数据根本导不出来。欧盟《数据法案》改变的不是“能不能换”,而是把这些变量的定价权与时间点,从供应商的政策文件挪进了合同义务。

把“离开的成本”拆成四笔,才知道该谈哪一项

第一笔是出网与搬运。只要数据是在别人的网络里,离开时通常会按流量单独计费,而且这份计费与安全策略、合规要求无关,纯粹是商业定价。数据量越大、搬运窗口越短、跨区域与跨厂商的情况越多,这一段就越难压。第二笔是格式与转换。对象存储的一桶文件相对好搬,块快照、托管数据库内部格式、运行在特定平台上的消息队列偏移量就没那么友好,往往需要在目标侧重建结构、重建索引、重新验证一致性。

第三笔是并行期的双份资源。稳妥的迁移几乎必然要并行一段时间:先同步、再做增量追平、再切流量、再观察。这段时间源侧不会因为你要走而暂停计费,目标侧也已经开始计费,等于同一份负载付两次。第四笔是隐性成本,包括 DNS 与证书的切换、外部回调白名单与授权网段的变更、监控告警与看板定义的重建、回滚演练的时间。前两笔能被法令直接改写上限,后两笔不会,这也是“出口费归零”不等于“迁移免费”的原因。

《数据法案》到底改了什么:把切换写进合同义务

这部法案的正式名称是《数据法案》,即欧洲议会与理事会条例 (EU) 2023/2854,2024-01-11 生效,主体义务自 2025-09-12 起适用。它的主线是让数据更容易在不同主体之间流动,第六章是专门针对数据处理服务切换的条款,即 Art.25 至 Art.30,互操作性另有 Art.34。要注意的关键点是:它不是号召性的政策文件,而是直接适用的条例,落到客户身上的表现形式是合同里必须出现相应的义务。

换句话说,过去你要向服务商申请“能不能给我导出”“能不能给我多留一个月”,是自下而上的请求;现在这些点应当以合同条款的形式事先写清楚:供应商应当在什么条件下配合切换、什么时候通知、什么时候完成迁移、以什么格式交付数据、不得设置哪些类型的阻碍。谈判的性质随之变化,从争取豁免变成核对履约。

另一个容易忽略的设计是“必须事先写明”。义务写在事前才有意义,因为真正需要迁移的时刻通常伴随着业务压力、连续性要求与时间焦虑,那时再谈条件是最被动的。是否把这一章的内容复用到自有服务器上并不一定适用,但把“万一要走,多久能走完、花多少”这个问句提前写进合同台账,对所有形态都不亏。

第六章改写的是三件事:通知期、过渡期、导出内容

Art.25 至 Art.30 这一组条款可以从三个端点去理解。第一个端点是时间,包含通知期上限与过渡期长度。切换意向提出后,供应商要求的通知期不得超过 2 个月,这限制的是“提前多久打招呼”;随后进入过渡期,原则上为 30 日历日,只有在技术必要时才可延长一次,延长的上限为 7 个月。这里的“一次”很重要:不是无限延期,也不是每次业务理由都能成立,技术必要性需要说明。

第二个端点是内容,即交付给客户的到底是什么。第六章要求以结构化、通用、机器可读的格式提供导出,并且涵盖的范围不止原始数据文件本身,还包括在切换过程中需要一并交还的数字资产与必要的元信息。对客户来说,这一句的实际含义是:导出来的是一堆专有快照还是一堆能被另一套系统直接消费的表与对象,不再完全由厂商单方面定义。第三个端点是行为,即不得设置阻碍切换的技术、商业或合同障碍,包括不得通过数据格式、服务绑定或部署方式的安排,让“理论上可导出”变成“实际上搬不走”。

还要补一句 Art.34 的互操作性安排。互操作性关注的是同一类服务之间、以及数据处理服务之间在数据、接口与格式层面的互通要求,它指向的是“接收方能不能真的用起来”。单看导出条款会误以为只要把数据包拿回来就算完成,实际上如果目标环境读不懂这套结构,导出只完成了半个动作。因此评估迁移可行性时,导出与互操作要当成一件事来看。

时间轴怎么排:三个日期决定三笔预算

这部法案对迁移决策有直接影响的,主要是三个日期加一份附属材料。生效日是 2024-01-11,这只是法律生效,主体义务尚未适用;适用起点是 2025-09-12,从这一天起第六章的切换义务、导出义务与费用规则才真正进入合同世界;费用规则的终点是 2027-01-12,从这一天起切换相关的附加收费被取消。再往下还有 2026-09-12 这个节点,针对的是联网产品投放市场时的数据可访问要求,属于设备侧议题,与云迁移不在同一个场景,但同属一部法。附属材料则是欧盟委员会专家组于 2025-04-02 发布的示范合同条款最终报告,这份报告的定位是非强制的商用参考,不能直接当成立法细则使用。

下表按时间顺序把这些节点与“该做什么”对应起来,供做迁移排期时对照。表中不给出任何价格数字,因为不同厂商与客户规模的差异极大,数字只能从各自的账单与合同里取。

时间节点 适用内容 对迁移决策的影响 现在可做的准备动作
2024-01-11 条例生效,主体义务尚未适用 这段时间内签的合同,需要按适用日之后的规则重新核对条款是否已更新 整理合同台账,记录签署日、适用方主体、服务类型与续约日
2025-04-02 欧盟委员会专家组发布示范合同条款最终报告,性质为非强制 有了可以对照的商用样板,但不能主张其具有强制效力 把示范条款当作谈判清单使用,逐条比对自家合同差在哪
2025-09-12 主体义务开始适用;第六章切换条款进入合同;切换费不得超过与切换直接相关的成本 “离开时的附加费”有了封顶依据,迁移预算从不可预测变成可估算 要求服务商在报价中拆分收费名目,把与切换直接相关的成本逐项列明
2026-09-12 投放市场的联网产品须满足默认可访问数据的要求 影响设备侧数据能否回流,进而决定上行链路与边缘侧的部署方式 在设备采购与招标环节写清数据可访问性,作为交付验收项
2027-01-12 不得再收取切换费用 长期的锁定风险折价下降,混合部署与回迁场景变得可以算账 重新算一遍“部分负载回自有基础设施”的三年或五年总账

切换费归零,到底取消了什么、保留着什么

这是最容易被误读的一点,必须逐项说清。第一步分野在 2025-09-12 到 2027-01-12 之间:这段过渡期内,切换费用不是禁收,而是不得超过与切换直接相关的成本,含义是原服务商不能借客户离开这件事牟利,也不能把与切换无关的开销塞进这张账单。第二步从 2027-01-12 起:切换费用不得收取,即“因为你要走而单独向你收的那笔钱”取消。

被取消的是离开时的附加费,不是服务本身的费用。这句话的另一半同样重要:服务本身的常规费用照付。数据离开,不代表这段时间的服务可以免费,也不代表合同期内的订阅、用量、存储占用、技术支持可以减免到零。换句话说,如果为了缩短并行期而把周期压缩,节省的是重复计费;如果为了稳妥而延长并行期,多付的是两边的常规费用,这两部分都不在“免切换费”的范围里。

还剩三类成本一分不少:一是搬运本身的工程量,包括带宽、介质、导出任务与目标侧写入;二是转换与验证,包括格式转换、一致性校验、抽样比对、灰度与回滚演练;三是不确定性带来的时间成本,包括停机窗口的协调、DNS 与证书的切换、外部依赖侧的联动。厂商不能把这三类的某一部分包装成“切换费”再加价,但也不能帮你把它们做掉。判断一笔报价是否合理,方法很简单:要求把收费名目拆开,看每一行对应哪一项具体工作,凡是写成笼统的“迁移支持费”而无法对应到工作的,就是应当追问的那一行。

2 个月、30 天、7 个月:三个时间值怎么落进排程

通知期上限 2 个月,限制的是“你提出要走之后,对方可以要求你再等多久”。这个值决定了向后倒排的起点:假设你在某一天正式提出切换,最迟两个月之后应当进入实际搬迁阶段。对有业务峰谷的系统来说,这个口子反过来意味着你可以把正式提出的时间点安排在旺季之前,从而让切换窗口避开业务高峰。

过渡期原则上 30 日历日,注意是日历日而不是工作日。这个区别在实践中很实:跨节假日、跨财务结算周期、跨当地公共假日的排期,按工作日估算会低估实际难度。可行延长的条件是技术必要,且只能延长一次,最长到 7 个月。这意味着从提出到走完,理论上的最长路径大约是 2 个月通知期加 7 个月过渡期,中间不计的自然月则是常态;任何超过这个尺度的安排,都应该问依据在哪里。

把这三个值翻译成排程,就是一条倒排链:目标侧环境与账号先就绪——导出与首次全量传输完成——进入增量追平——安排一至两次演练切换——正式切换窗口——观察期——清理源侧残留与关闭双写。每一段都要留出验证时间,尤其是最后一次增量追平与正式切换之间,必须留下足以做一致性校验的空隙。很多组织把计划书上的 30 天理解成“传输 30 天”,实际应该理解成“包含验证、回滚与观察在内的完整退出周期 30 天”,这两者的差别往往就是切换当晚是否手忙脚乱。

迁移前的技术准备清单:先把“能不能导出来”验一遍

权利写进合同,只是让对方必须配合;能不能真的搬走,取决于你自己这边的技术状态。下面这份清单不分先后顺序,但每一项最好在上云之前就存在,而不是在决定切换之后才开始准备。清单上的大部分动作平时就该周期性执行,因为它们同时也是备份完整性与灾难恢复能力的验证手段。

第一项,数据清单与位置。把散布在各处的数据写成一张表:对象存储的各桶、块存储的各卷、托管数据库的实例与库表、消息队列的主题与偏移量、日志归档、备份副本。逐项确认是否存在官方导出通道、导出粒度是整库还是表级、是否需要停机导出、导出出来的形态是什么。这一步不需要切换决定,只需要平时就维护。

第二项,出口带宽与时间的换算。用自有监控里的出网流量和总数据量做一次粗算:全量在某个窗口内走完需要多少时间,增量追平能否在可接受间隔内完成。这个换算是判断“30 天够不够”的唯一可靠依据,靠直觉估出来的时间通常偏乐观。

第三项,格式与版本。结构化、通用、机器可读是条款上的表述,落到具体产出物上要问三句话:导出格式能否被目标侧直接写入?版本差异会不会导致字段丢失?依赖项(权限、标签、索引、触发器、存储过程)是否被包含在导出范围内?专有快照只能算是一种厂商内部的中间状态,不能直接当作已经具备可携性。

第四项,基础设施即代码与配置可重现。目标环境的网络、子网、安全组、负载均衡、证书策略、告警规则,最好是代码化的。控制台手工点出来的环境,迁移时能重建但很难完全一致,而且配置漂移会在切换当晚集中爆发。

第五项,账号、凭据与密钥清单。包含身份与访问管理配置、密钥托管、外发邮件域名的验证记录、第三方接口的调用凭据、单点登录配置。这类东西最容易漏,因为它们在业务看来是“不是数据的东西”,一旦漏掉,迁移夜就会出现接口全部 401 的典型事故。

第六项,外部依赖清单。DNS 解析记录和 TTL、加速节点配置、回调地址、对端 IP 授权白名单、合作伙伴侧开放的策略。DNS 尤其要提前降 TTL,否则正式切换后的解析收敛时间会主导你的观察期长度。

第七项,验证与回滚。一致性校验要有可执行的办法,例如校验和抽样比对或按业务主键做全量比对;回滚要有一份写清楚触发条件与执行步骤的方案,而不是口头上的“先退回去”。第八项,日常就跑一次导出。最稳妥的做法是把完整导出做成周期性任务,而不是等到决定切换那天才第一次运行,因为第一次运行往往才发现配额、接口限制或格式问题。

预算这块要单独说一句。在同时比较云上方案与托管或整机方案时,收费口径的差别会直接影响你算不算得清:云上的存储容量、出网流量与接口调用通常是分开计价的几行,取回数据时还会额外出现一行;托管或整机方案的报价通常只有资源与带宽这两行。一万网络(深耕 19 年,成立于 2007 年)这类形态下,导出与复制的成本可以直接摊进带宽估算里,不必单独预留一笔不可预测的“离开费”。

SaaS 与 IaaS 的要求差别在哪里

同一部法案,对不同层级的服务,落点并不相同。底层设施类的核心问题是“数据能不能出来、镜像能不能转移”,只要数据能以结构化形态导出、镜像或卷能够迁移,接收方在工程上就有办法承接,因此这一层受益最直接:可导出性一旦成为义务,被锁住的感觉会迅速下降。

上层应用类的核心问题则是“换一个产品之后还能不能用”。SaaS 的切换往往不是把数据搬到另一个 SaaS,而是换成一个不同工作台,报表字段、权限模型、工作流定义、插件生态都不一样。此时导出再多的数据,也不等于功能等价。法案在这部分的重心转向了接口访问与互操作性,也就是 Art.34 的方向:要求服务之间在数据与接口层具备互通能力,并且开放必要的接口规格。

因此对 SaaS 客户来说,谈判重点不是“你能不能给我一份全量导出”,而是下面几条:导出接口是否存在频率与体量限制、是否支持增量导出而不必每次全量、API 配额是否足以支撑迁移期的密集调用、数据模型文档是否可读到可以重建的程度、附件与二进制对象是否与结构化数据一起导出。这些技术细节往往比合同条款更早决定迁移是否可行,所以在选服务时就该问,而不是等到想走的时候。

老合同要不要重签:把“自动适用”和“合同更新”分开看

条例是直接适用的,这意味着义务的存在不依赖于你的合同是否写过它。但从可执行性角度看,合同里没有相应条款,你就只能援引法令去主张权利,主张的成本远高于执行的成本。因此更实际的路径是更新,而不是推翻重签。

操作时可以按三档处理。第一档是即将续约或发生重大变更的合同,这是最好的窗口,切换条款、导出格式、通知期与过渡期、费用口径可以一次性写进去。第二档是长期未到期的合同,通常用修订协议或附录补充,把缺失的义务补上即可,不必重开全部条款。第三档是短期内不会碰的合同,至少做一件低成本的事:把现有的期限、变更与终止条款通读一遍,看里面有没有需要提前很久提申请的约束,或者与将来切换意图冲突的写法,这样万一某天要谈,起点在哪里心里有数。

这里可以利用两份材料。其一是欧盟委员会专家组 2025-04-02 的示范合同条款最终报告,作为非强制的商用参考,用它来比对自家合同缺哪些块。其二是 Art.13 引入的 B2B 不公平条款规则,它针对的是单方面强加且明显偏离诚信要求的商业条款,意义在于提示:并不是所有打印在标准条款里的限制都天然可执行。是否真的构成不公平,需要结合具体条款与司法实践判断,这篇不对此下结论,但谈判时可以据此要求对方说明某一项限制的合理性。

还有一个现实理由支持“早更新”:真正想要走的时候,谈判窗口和迁移窗口会同时到来。若切换条款已经写好,你想走时可以直接启动流程;若没有,谈判会与迁移同时发生,时间压力全部落在你这边。把这件事放进合同续签清单里,成本几乎为零。

取回门槛下降之后,混合与回迁重新变得可以算清

过去很多团队不是不想做混合部署,而是不知道将来退出的价钱。当出网与切换收费长期不受约束时,“我们把一部分负载放在云上”这个决定,隐含了一笔未定价的负债:将来拿回来要付多少,现在说不清。既然说不清,理性选择就是把所有东西都留在同一处,或者干脆只敢放置那些将来即使拿不回来也不影响主业务的数据。

这条时间轴的作用是给这笔隐性负债加上了上限。2025-09-12 至 2027-01-12 这段时间,收费不得超过与切换直接相关的成本;2027-01-12 之后,切换费用不得收取。也就是说,留还是走这一件事不再由对方单方定价。于是“逐步把一部分负载拿回来”从一个无法预期的支出,变成了可以写进年度计划的常规项。

最典型的场景是稳定负载回迁与分层持有。稳定负载的特征是可预测:CPU 与内存的基线常年维持在一定水位,数据增长速率稳定,访问模式不随营销活动剧烈波动,这类负载放进云之后再拿出来,账最好算。做法是把可预测的底座与真正需要弹性的部分分开:底座放在自己能控制的区位,波峰部分仍然使用云上资源,两者之间靠加密隧道与私有网段规划互联。这套架构的可行性,过去卡在退出费用,现在卡在怎么设计,后者是技术问题,而技术问题是有解的。

对打算把欧洲业务长期放在固定机房的客户来说,一万网络(深耕 19 年,成立于 2007 年)这类可自主决定镜像与数据导出方式的服务形态,在「要不要留一条回迁路径」这个问题上比纯订阅制更容易算清。

判定自己在不在这张网里:适用范围的边界

这部法案约束的是数据处理服务的提供方,以及与之对应的客户权利,而不是每一个卖机器、卖机柜、卖带宽的主体。按照法案的口径,数据处理服务是这样一类服务:面向客户提供、可按需管理、可通过网络远程访问的可伸缩弹性共享计算资源池。这个说法指向的是成套的云服务形态,而不是单台设备或单个软件的销售。

由此产生两个必须承认的限制。第一,是否落入适用范围需要个案判断。同一个集团内部,不同实体的服务形态可能完全不同:有的买的是整机托管,有的买的是平台上的托管数据库,有的买的是成品 SaaS,三者的结论可能不一致,不存在“我们全适用”或“我们全不适用”这样的概括答案。第二,即便落入适用范围,法规的目的也不是鼓励你频繁更换。它保证的是你有切换的权利、有时限、有格式、有费用上限,它不保证你一定能找到合适的接收方,也不保证切换过程不痛。

还需要区分两件事:示范合同条款与实际立法细则。2025-04-02 的专家组最终报告是商用样板,标准与规范的推进是另一条线。把样板当成强制要求去主张,会在谈判中失去可信度;把样板完全忽略,又会漏掉一批现成的措辞。合适的姿态是把它当作对照清单。

六个高频疑问的拆法

切换费归零是不是等于迁移免费?不是。归零的是因为离开而单独加收的费用,服务本身的常规费用照付,搬运、转换、验证、并行运行的人力与目标侧资源都不在其中。

30 天过渡期从哪天开始算?从提出切换意向、走完不超过 2 个月的通知期之后进入过渡阶段起算,单位是日历日,只有在技术必要时才可延长一次,最长延长至 7 个月。具体起算节点应由合同条款明确,不要靠邮件里的一句话来界定。

SaaS 和 IaaS 要求一样吗?同一部法,落点不同。底层服务看导出与可迁移性,上层服务更依赖接口访问与互操作性。SaaS 的难点通常不在“拿到数据”,而在“目标侧能不能重建同样的功能”。

老合同要不要重签?通常不需要推翻重签,更新即可。续约与重大变更是最好的窗口,其他合同可用附录补充;最低限度也要把切换相关条款做一次对照记录。

托管与整机租用受影响吗?法案针对的是数据处理服务的提供方,单纯的设备或机柜形态不在这一组义务的直接指向范围内。但客户侧的收益逻辑成立:数据放在你能直接操作的文件系统里时,导出不再是别人的计费策略。

怎么判断自己是不是这部法所说的客户?看买到的东西是不是可按需管理、可远程访问、可伸缩弹性的共享资源池服务。整机、机柜、自建基础设施通常不在此列;平台上的托管组件与成品订阅服务则多半有关。拿不准时,按服务商分类逐合同判断,而不是按供应商整体判断。

数据法案没有改变的几件事

它没有改变搬迁本身的工程量。几十 TB 数据的搬运依然要占用带宽与时间,快照依然要重建为可写入的表与对象,索引依然要重算,应用兼容性依然要验证。它没有把搬迁本身的工程量减半,只是把“不可谈判”的那部分压缩成了“可谈判”的那部分。

它也没有改变连续性约束。DNS 的收敛时间、证书的更换、连接的排空、长连接的重建、客户端缓存与本地解析,这些物理与时间层面的东西不受任何条款影响。切换窗口还是那几个小时的夜里,回滚方案还是得提前写好。

它同样没有改变服务水平与责任分工。并行期的双份资源要有人付费,切换期间的问题仍然分不清是哪一边的责任,接口调用的失败如何在两边之间区分,需要在合同与监控上分别落实。它也没有顺手解决人才问题:能看懂目标侧架构、能在夜里做一致性校验的人,还得靠自己培养。

最根本的是,它没有改变你要不要换这个判断本身。法律只消除了“走不掉”的恐惧,没有制造“必须走”的理由。真正的评估框架仍然回到业务:你的负载形态是否稳定、你的数据是否在增长、你的合规地域是否有要求、你要的弹性是否值得付出溢价。回答完这些之后,再看条款怎么谈,顺序才不会颠倒过来。

本篇事实来源:Data Act 切换条款与时间轴怎么核对

本篇引用的事实限定在以下几项,可直接核对。《数据法案》为欧洲议会与理事会条例 (EU) 2023/2854,2024-01-11 生效,主体义务自 2025-09-12 起适用;第六章为切换条款,范围为 Art.25 至 Art.30;互操作性相关条款为 Art.34;B2B 不公平条款规则见 Art.13。时间值方面:供应商要求的通知期上限为 2 个月;过渡期原则上为 30 日历日,技术必要时可延长一次,最长 7 个月;2025-09-12 至 2027-01-12 期间切换费用不得超过与切换直接相关的成本,2027-01-12 起不得收取切换费用,服务本身的常规费用照付;自 2026-09-12 起投放市场的联网产品须满足默认可访问数据的要求。欧盟委员会专家组于 2025-04-02 发布非强制的示范合同条款最终报告。

核对方式建议按三步走。第一步取官方文本,条例本身可直接按编号在欧盟官方文本库中检索官方语言版本,不要依赖二手摘要;第二步做版本确认,确认引用的是当前有效的合并版本,而不是某个历史稿;第三步做实务对照,把上述时间值与费用规则逐条比对自己的合同台账,差异处列清单交给法务。凡是本篇未列出的条文编号、金额与时间表,都不应被引用为事实。

本篇未给出任何具体价格,也不评估具体厂商的收费水平。所有与成本相关的判断,请以自身的账单、带宽监控与对方提供的报价名目为准。


上一篇:2026 Airbyte 数据集成同步平台服务器租用选型避雷全攻略

下一篇:做欧盟金融业务的服务器合同,为什么必须写清数据存放地和退出安排