主权 AI 本质上是一个控制问题

COO 兼联合创始人

主权 AI 的核心在于掌控你的 AI 运行所遵循的规则。继续阅读以了解真正的主权内涵、应提出的关键问题，以及实现路径。

• 你需要自主选择组件，并管控流经它们的信息。仅凭供应商的国籍很难判断这两点。
• 一次请求可能横跨模型、检索服务、工具及日志。数据存储地点无法回答谁能访问数据或数据如何被使用。
• 需厘清哪些系统由自身运营，哪些承诺依赖于其他供应商的条款，并保留切实可行的更换供应商途径。
• 明确该承诺涵盖的范围，包括查询、输出、日志及下游系统。
• Agent 需要新鲜且相关的信息，但其搜索行为可能暴露商业意图。需同时评估其发现信息的实用性及其查询方式的处理机制。
• 我们自家的搜索索引、区域化数据处理、零数据保留及自定义配置，帮助组织在符合自身要求的前提下将 AI 连接至外部信息。

对于采购 AI 的企业而言，一个实际问题已然浮现：这套系统能否在我们需要设定的边界内完成工作？

主权正从政策文件走向采购实践。政府资助国家算力建设，超大规模云厂商出售主权云区域，模型实验室也在开设区域化部署。金融、国防、医疗、电信及公共部门的企业，如今已将主权要求写入 RFP。

有人将主权视为国籍测试：本国模型、云、数据中心及供应商。也有人将其视为云控制台里的下拉选项，选定 EU 区域即告终。两者都触及了部分问题，但单独来看，都无法确立一个组织对其 AI 的实际控制程度。

Linkup 采用另一种定义。所谓主权 AI 系统，是指其所有者能够自主划定系统运行的边界，并且在供应商、技术和环境变化时，持续维护这些边界。

落实到实践中，就是两件事：保留对所用组件的选择权，以及掌控流经这些组件的上下文。按照这个定义，主权是一种架构属性。

Linkup 正是在这些需求的交汇处发挥作用。也就是 AI 系统与外部信息之间的连接。我们自建搜索索引，提供区域化处理和零数据保留，并针对特定需求提供定制配置。

关于主权 AI 的四种主张

围绕主权 AI 的诸多分歧，很大程度上源于对这个词的不同理解。目前主要有四种立场：

• 国家冠军。自建国内基础设施、模型和人才梯队。Mistral 在欧洲就体现了这一雄心：发展本地能力，争取谈判筹码。
• 运营主权。Palantir 的 Alex Karp 强调对数据、上下文和模型权重的控制——正是这些资产让一个组织的 AI 具有价值。
• 受控依赖。Brookings 主张"受控的相互依赖"：审慎选择合作伙伴，同时保留更换供应商的能力。
• 关键 IT 优先。Cory Doctorow 认为，主权应从组织已经依赖的基础设施谈起，AI 是这场更大讨论的一部分。

Linkup 的立场：这些观点引出一个务实的检验标准：掌控你的上下文，保留选择供应商的权利，并清楚更换供应商意味着什么。这正是我们做检索服务的思路。

风险升级：AI 在每个环节都需要可控

欧洲围绕数字主权的讨论已持续十余年：如何保护数据、认证云服务、管理跨境数据传输。生成式 AI 让这些问题变得更加复杂。

传统云负载只负责存储和处理数据，而 AI 系统还会引入外部信息、对其进行推理，并且越来越多地根据结果采取行动。随着 copilot 演变为 agent，一次请求可能要经过多层环节：

• 企业的应用与编排层。
• 模型提供商。
• 检索或搜索服务及外部工具。
• 可观测性与日志系统。
• 支撑它们的云与算力基础设施。

这些层级可能由不同公司运营，并受不同司法辖区的法律管辖。

这种链条改变了买家需要提出的核心问题。“我的数据存在哪里？”仅覆盖了其中一个环节。

完整的问题范畴更广：谁能访问这些数据？可以做哪些操作？若某家服务商修改条款，会发生什么？

这一逻辑不仅适用于欧洲。美国、亚洲、海湾地区及印度等地的组织，既希望接入全球 AI 能力，又需对关键数据保持掌控。

Linkup 帮助将这种掌控力延伸至检索环节，提供区域性处理与零数据保留选项，让客户的部署与其需求精准匹配。

选择能赋予你控制力的服务商

面对依赖风险，本能的反应是追求自给自足。若认为外国基础设施存在隐患，便会试图在每一层构建本土设施。

投资本土基础设施、人才和技术确有充分理由。它们能构建能力，并给买家提供更多选择。但将“自给自足”作为主权的定义，会与供应链现实相冲突。例如，欧洲模型往往依赖全球供应链：

• 在加州设计、在台湾制造、使用荷兰设备的 GPU。
• 网络设备全球采购的数据中心。
• 由多国贡献者共同开发的开源软件。
• 全球各地托管的 API 和数据源。

错误在于将“来源”与“控制”混为一谈。供应商的“护照”（产地背景）对你能否审计、约束或替换其服务几乎无用。一个境外构建的组件，若处于所有者强制执行的边界之内，并不会危害系统安全。

Linkup 在超大规模云基础设施上运营自有的搜索索引。 虽然底层算力依赖云服务商，但索引与检索服务由我们自行操作。这使得客户能清晰看到我们控制的是哪一层，以及该层如何支撑我们的处理与保留策略。

大多数组织将混合使用本土与国际技术。它们将面临一系列实际决策：哪些依赖可以接受？哪些必须自主掌控？在需要时能否替换某个依赖项？

这篇文章的其余部分，将帮助你把这些疑问转化为可执行的策略。

确保依赖可控

没有哪家银行因为外购芯片而非自研，就觉得自己丧失了主权。关键在于，它对这项依赖保留了多大的控制权。

试看两套系统。第一套只使用总部位于本国的供应商，但运行在专有平台上，若要迁移需耗时数年。该平台无限期保留敏感提示词，且对处理数据的其他公司几乎不提供信息。

第二套系统则混合使用国内外供应商。敏感工作负载被锁定在指定区域，推理服务商不保留任何数据。合同与技术手段严格限制了数据的使用方式，接口具备可移植性，依赖关系有文档记录，关键组件可随时替换。

第二套系统赋予所有者更大的控制权，主权属性也更强——但单看供应商的国籍，你绝无法得出这一结论。

检索环节同理。若服务商使用第三方的搜索索引，就必须纳入该供应商的处理实践与条款进行考量。自建索引能让服务商对该环节拥有更直接的掌控力。

这正是 Linkup 运营自有索引的重要原因。它支持我们自主决定查询处理方式，并为客户提供区域化处理与零数据保留服务。

目标是使用能力强大的技术，同时确保依赖关系清晰可控。优质的检索能力与明确的控制权限，应纳入同一决策框架。

主权 AI 系统的五项测试

营销助手与支撑国防情报工具的代理，所需的安全边界截然不同。询问供应商是否具备“主权”特性，得到的只能是市场话术；而五项测试，给你的才是工程答案：

1. 了解数据的使用方式。明确提示词、查询、文档及输出的处理位置、保留时长、是否用于训练，以及哪些服务商能访问这些数据。评估时务必包含搜索查询。
2. 选择工作负载的运行位置。将工作负载绑定至批准的区域，并通过自有的身份认证与网络控制限制访问。你无需拥有服务器，但必须清楚谁在运营这些服务器。
3. 决定涉及哪些模型。由你来决定哪个模型负责哪类工作负载，这样无需重构应用就能更换供应商。无论国内外，绑定单一模型的系统都没有多少腾挪空间。
4. 为你的 agent 设定边界。通过规定 agent 可以访问哪些数据源和工具、可以发送哪些信息、哪些操作需要人工审批，建立运营层面的控制。这些策略把组织的要求落实到 agent 的日常工作中。
5. 保持一条现实可行的换供应商路径。避免被供应商锁定。弄清楚哪些数据可以导出、哪些组件可以替换、迁移需要付出什么代价。对每一家供应商都做这个测试，包括 Linkup 自己。

没有哪个组织需要在每一项测试上都拿满分。它需要知道每类工作负载真正在乎的是哪些答案，然后有意识地做出选择。

该向你的“主权”检索供应商提出的问题

一个欧盟区域、一张 GDPR 页面和一份 ISO 27001 报告，并不能告诉你你的查询实际走的完整路径。采购方仍然需要弄明白：到底有哪些系统在处理自己的数据，哪些主体的承诺是有效的。以下四个问题有助于搞清这一点。

1. 我的请求的每个环节在哪里处理？不仅指模型调用，还包括检索、工具调用和日志。“取决于具体组件”只是个起点：请追问每个组件的位置。
2. 涉及我数据的哪些层是你们自己运营的？供应商的承诺取决于它自己的系统以及其供应商的条款。如果它使用了第三方模型或搜索索引，就问清楚这些依赖会如何影响它能承诺的范围。
3. 零数据保留是否写进了合同？要明确这个承诺具体覆盖什么：查询、文档、输出、日志，以及所有例外情况。它应该写在协议里，并明确请求处理链路中各系统的责任划分。光靠控制台里的一个开关设置，算不上这种承诺。
4. 哪些第三方能看到我的查询，基于什么条款？索要一份次级处理者清单，以及各自的 processing 和 retention 条款。这样才能看清服务背后的依赖关系。

能清楚回答全部四个问题的供应商，才是真正为 sovereignty 而构建的。在第二或第三个问题上支支吾吾的，多半只是冲着这个标签来的。

Sovereignty 没法买现成的

由此可见，没有任何单一产品能赋予组织主权能力。每家供应商只能提供其中一部分：

• 云服务商：区域基础设施。
• 模型提供商：区域推理与零留存。
• 数据提供商：明确的处理与留存选项。
• 安全厂商：系统运行时强制执行策略。

最终系统是否具备主权属性，取决于这些组件如何组装和管理。

将主权视为采购清单上的一个选项，本末倒置。工作应从工作负载入手。它涉及哪些数据？数据的敏感度如何？适用哪些司法管辖区？哪些能力至关重要？哪些依赖可以容忍，哪些必须保持可替换性？如果关键供应商明天消失，业务如何应对？基础设施的选择应基于这些问题的答案。

Linkup 在您的主权 AI 架构中的定位

检索是主权边界的一部分。在 Linkup，我们处于主权讨论中常被忽略的层面：AI 系统与外部信息之间的连接。

生产环境中的智能体很少仅依靠模型权重运行。在行动之前，它们会搜索网页、获取文档、核查事实、调研公司与人员，并监控市场。这些步骤引入了智能体所需的信息。同时，它们将查询发送到企业环境之外，引发自身的主权问题：

• 查询在哪里处理？位于哪个地理区域？
• 是否被留存？
• 哪些下游系统能看到它？
• 智能体被允许访问哪些来源？

检索位于模型与开放网络之间，因此这些问题可能会让责任落在不同团队之间的缝隙中。数据层应获得与模型层和云层同等程度的审查。在评估检索调用时，应结合工作负载的驻留和留存要求，与模型调用一同考量。

这一观点塑造了 Linkup 的构建方式。 我们在多个区域运营自己的搜索索引，为客户提供查询处理地点的选择权。拥有索引让我们能直接控制查询处理的核心部分，并支持我们的零数据留存方案。

对于不希望语言模型参与处理其检索查询的客户，我们提供定制方案，将模型排除在检索堆栈之外。

底层算力依赖超大规模云服务商的基础设施。我们对这种依赖性持透明态度：Linkup 负责运营索引和检索服务，但底层算力由云服务商提供。

这些选择使检索成为组织主权架构的一部分。客户可以评估 Linkup 提供的信息，并将其与适用于其部署环境的处理和数据保留承诺相结合。

欧洲、海湾地区、印度及其他市场的主权要求各不相同。但底层需求是一致的：AI 必须实用，且用户需对信息流向、处理方及保留期限拥有明确选择权。

对于将智能体（Agent）接入网络的机构，Linkup 将上述选择权延伸至检索环节：自有搜索索引、区域化处理、零数据保留以及针对特定需求的自定义配置。

从智能体需要执行的任务出发，测试 Linkup 能否找到所需信息，随后与我们合作，使部署方案匹配你的数据处理与保留要求。

探索 Linkup 在你的 AI 工作流中的应用。