数据在欧洲，技术却不是真正自主的

6月12日，数千家机构发现了一个令人不安的事实：他们所使用的AI工具，其控制权并不在自己手中。

美国政府发布了一项出口管制指令，影响了两款Anthropic模型。Anthropic的应对方式是对所有客户禁用这些模型。虽然限制后来被解除，但这几乎没有带来多少安慰。访问权限的消失和恢复，都取决于客户自身既无法做出、也无法掌控的决定。

许多人在Cloudflare宕机、CrowdStrike宕机、Meta宕机、AWS宕机等事件之后，都曾声称自己得到了”警醒”。然而，面对这一事件，整个行业依然表现出一种可预见的惊讶——这恰恰说明，业界一直在回避关于数字主权这个可能令人不适的话题。

我们经常讨论数据中心的位置、区域可用性以及合规认证。我们争论服务器究竟放在约克还是纽约，然后就为自己做出了”主权选择”而自我庆贺。

但如果一个外国政府可以撤销你的服务，一次宕机可以让整个业务陷入瘫痪，供应商可以随意改变你的运营模式，或者一个专有API让迁移在经济上变得不可行，那么服务器的物理位置几乎已经无关紧要。

数据驻留只是一种自我安慰

把服务器放在巴黎，并不会让你的架构因此变成”法国的”。服务器只是系统的一部分，甚至可能不是最重要的部分。主权关乎对整个运营链条的控制权。这不仅包括基础设施本身，还包括用于配置、访问、部署软件以及维持其运转的各种工具。

企业完全可以满足数据驻留要求，却依然完全依赖外国技术。合规的方框被打上了勾，企业也以为自己因为数据迁移而降低了风险，但掌控这些数据的真正杠杆仍握在别人手中。

控制平面很重要。开发工具很重要。源代码平台、身份认证提供商、编排系统和AI助手，这些都很重要。只要其中任何一个成为无法摆脱的依赖，组织的自主程度就远低于它自己的想象。

作为一个行业，我们之所以聚焦于服务器的物理位置，是因为它容易理解。而技术自主性则要困难得多，它要求组织去审视那些多年来被假装成”别人的问题”的各种依赖关系。

企业被困在法律的夹缝中

如果技术层面的锁定还不够糟糕，法律层面的局面则更为复杂。现代企业越来越多地发现自己陷入一种法律上的”三明治”困境，被同时适用却方向并不一致的规则困在中间。

Weave Intelligence的案例展示了美国《云法案》（CLOUD Act）与欧盟GDPR之间的摩擦。

《云法案》可以要求美国本土的科技公司披露其所掌控的数据，即便这些数据存储在美国境外。而GDPR则对欧洲个人数据向第三国的转移以及外国当局的访问设置了严格的条件。

这对使用美国企业提供技术服务的欧洲公司来说，造成了明显的问题。数据可能存放在法兰克福，但运营该服务的公司仍可能受美国法律管辖。如果该公司收到美国当局合法有效的要求，供应商可能在一个司法辖区承担的义务，却在另一个司法辖区带来严重的法律与监管风险。

当然，这不仅仅是美国与欧盟之间的问题，而是一个典型案例，说明数据所在地的重要性往往要排在复杂的数据所有权法律定义之后。尽管企业无法通过架构设计来解决国际法层面的问题，但它们可以避免让问题变得更糟——不要把每一项关键业务流程都建立在同一个供应商、同一个司法辖区和同一套专有服务之上。

当”三明治”里的内容无法被更换时，这个困境就变得更加难以摆脱。

如果你无法离开，你就不是真正自主的

数字主权意味着保留切实可行的能力，能够在不中断业务的情况下更换供应商、司法辖区或部署模式。

托管服务让团队能够快速构建应用，而不必操心底层基础设施的每一个细节。但每一项供应商专属的服务，都会制造新的依赖，而每一个依赖都会让”退出之门”变得更窄一点。这正是超大规模云服务商的精妙之处，也是其真正的代价所在。

检验的方法很简单：如果你的供应商明天突然消失，你的团队还能继续构建和运营软件吗？

如果答案只存在于一份从未经过实际检验的、长达40页的退出策略文档中，那么答案就是”不能”。真正的退出策略必须是可执行的，企业必须能够迁移工作负载、更换供应商，或将关键能力转移到自有环境中，而不需要重新设计每个开发团队的工作方式。

掌控开发者与基础设施之间的那一层

要实现真正的技术自主性，组织必须将软件交付与底层基础设施解耦。这正是内部开发者平台（IDP）发挥战略作用的地方。

IDP在开发团队与其软件运行的各种不同环境之间，提供了一个一致的中间层。无论最终部署目标是本地云服务商、全球超大规模云服务商还是自建环境，开发者都遵循相同的”黄金路径”来构建、测试和部署。

基础设施可以发生变化，而不必强迫每个开发者改变自己的工作方式。更重要的是，组织保留了对保持软件持续运转所需工作流程的控制权。部署逻辑、策略、配置和运营知识，不会被牢牢焊接在某一个基础设施供应商身上。

这使得”可迁移性”从风险文档中的一段文字，变成了一种可以被实际演练和检验的能力。组织可以在正常运营期间在不同环境之间迁移工作负载，识别出仍然存在的依赖关系，并在危机到来之前加以解决。

别再空谈主权，拿出证明

真正的主权必须被设计、测试并持续维护。组织应当定期在不同环境之间迁移工作负载，测试关键工具是否能够独立运行，并揭露那些隐藏在架构图背后的各种依赖关系。

因为检验你的主权能力的第一次机会，绝不应该是在宕机、法律纠纷或地缘政治危机发生的时候。

我们已经为您整理了最佳数据库软件。

本文作为TechRadar Pro Perspectives栏目的一部分制作，该栏目旨在展示当今科技行业最优秀、最具洞见的思想。

文中观点仅代表作者本人，不一定代表TechRadarPro或Future plc的立场。如果您有兴趣投稿，可访问：https://www.techradar.com/pro/perspectives-how-to-submit